<terpri>librejs is kind of useless (compared to just disabling javascript) IME, probably in part because the librejs folks don't seem to have been working with browser vendors <terpri>and it's a bit silly to disable firefox sync when you can self-host a sync server (or you could last time i checked) <terpri>in fact if it's not too difficult i may run a sync server for hcoop.net members, that might provide a better case for toggling it back on than "in theory, you can self-host" <joshuaBPMan>what do ya'll think about the zig programming language? Is it slightly sad that it has to depends on LLVM and not GCC? <terpri>zig is cool, one of my compilers-team colleagues at igalia contributed to the initial release (dunno if he's still involved) <pkill9>i heard of zig recently, the river wayland compositor depends on it <leoprikler>would there be a way for a compiler to emit GENERIC/GIMPLE code and compile it through gcc? <pkill9>joshuaBPMan: it's somewhat new i think <pkill9>it's an implementation of dwm on wyaland ***akko is now known as stallman
<terpri>why would resistFingerprinting do something that makes it more fingerprintable...? <terpri>seems like a bug in the server anyway, as icecat *also* has the Firefox/... bit iirc <guix-vits><fat>All resources currently being thrown to work on switching to the GNU Hurd kernel.</fat> ***apteryx_ is now known as apteryx
<PurpleSym>Can guix-install.sh somehow be made to use daily snapshots? That would save me from doing an expensive (~10 min) `guix pull` on GitHub Actions. <pkill9>why is guix downloading when all i have done is remove a package from the profile? <pkill9>the default user profile that is, not the system profile <pkill9>(i'm using jack2 for the dbus interface, and have jack1 installed as well) <kmicu>pkill9: did you remove it via imperative command or declaratively from an scm file? <pkill9>woops that note in brackets was meant for another channel, disregard <pkill9>kmicu: i ran `guix package -r jack` <guix-vits>pkill9: Probably the grafts for the packages that were left on the system? (Were downloaded) <pkill9>why does it download the grafts? i can't remember <pkill9>wouldn't it only do that if I also ran -u? <guix-vits>pkill9: Seems not. Seems like guix always check for them (but honestly IDK). <kmicu>Is guix package -r jack triggering grafts? I would love to see the log and hashes to check for sure. *kmicu checks guix/scripts/package.scm for some grafting hooks <kmicu>It looks like any ‘guix package’ invocation triggers grafting by default. <pkill9>what you suggested makes sense, because I recently guix gc'd <kmicu>“Warning: Potential Security Risk Ahead” xD <kmicu>The certificate for pkill9.com expired on 8/10/2020 <pkill9>ah yea, i did run certbot and it said it succeeded in renewing <kmicu>pkill9: ah yes, there were CVEs for X11 and it downloads x11 so it’s safe to assume that’s grafting at work. <pkill9>the terminal will process all the weird characters <kmicu>There’s --no-grafts flag if that’s not desired. <pkill9>it still downloads with --no-grafts <pkill9>i don't really get why it doesn't just remove the package *guix-vits "Error if finalization thread: Success" :) <pkill9>oh yea, it's on any 'guix package' invocation <pkill9>so is it actually upgrading the grafts? <kmicu>pkill9: I’m not sure whether ‘guix package’ obeys --no-grafts flag like other tools 😺 <pkill9>i don't get why it isn't just removing the package from the profile <kmicu>I can understand why grafting hook could not apply to ‘guix package remove’ but that’s another ‘defaults’ disscussion. <guix-vits>Maybe it's just work on "profiles", rather than on packages? Like: "i need to remove undesired package, but steel need to update the profile.. check substitutes... apply.." *guix-vits feel like such things were told on IRC before. <kmicu>pkill9: what about GUIX_BUILD_OPTIONS="--dry-run --no-grafts" guix package remove jack ? <kmicu>iiuc guix package dosen’t expose grafts flag in the same way as guix build and that’s why it’s ignored. <nefix>how can I add a custom package to a manifest? e.g. I have a package defined above the manifest, how can I import it in the environment? <joshuaBPMan>has anyone gotten a failed test with compiling guix recently? <joshuaBPMan>test-name: fold-available-packages with/without cache failed for me. <pkill9>kmicu: it still tries to download them <janneke>joshuaBPMan: yes, fails for me; please report <pkill9>nefix: can you post your manifest? <pkill9>im guess you're using specification->packages <kmicu>pkill9: anything interesting if you add --verbose flag? <kmicu>I hope that’s not some cache issue. <joshuaBPMan>janneke: Yes sir! I suppose I'll upload my test-suite.log file as well in the report. <janneke>yes (you can do: make check TESTS=tests/packages.scm) to get a smaller report <pkill9>nefix: i dunno what specifications->manifest produces <pkill9>so i dunno if adding the package to it would help <pkill9>i assume a 'manifest' isn't just a list of package objects <joshuaBPMan>you guys have a fantastic community. I'm still learning, but thanks for the encouragment. *janneke also enjoys the guix gals and guys ;) <joshuaBPMan>janneke: hmmm. It's still running through all tests as far as I can tell. <joshuaBPMan>let me play with it a bit...don't give me the answer just yet. <joshuaBPMan>hmmm. maybe not. The test-suite.log file is still 2,271 lines long.... <joshuaBPMan>oh duh, because it had to run all of the tests in packages.scm. There's lots of tests there. <GNUtoo>hi, (how) do you handle multiple libc in guix? <GNUtoo>I've seen musl and bionic headers in the source <GNUtoo>I'm a bit confused on how to use the android-bionic-uapi package <GNUtoo>It seems to contains headers that conflict with the glibc ones <GNUtoo>I want to use the include/sys/system_properties.h which is part of android-bionic-uapi <GNUtoo>so I coud make cpp use the standard glibc headers and only use that for include/sys/system_properties.h <GNUtoo>but after adding it as native-input the pakcage I am working on is picking all the android-bionic-uapi <joshuaBPMan>holy cow! dbus-run-session sway, makes things run sooo much better! Sway just feels snappier. I wonder why that is. <GNUtoo>/gnu/store/[]-android-bionic-uapi-7.1.2_r36/include/linux/if.h:30:3: error: redeclaration of enumerator ?IFF_UP? <GNUtoo>/gnu/store/[]-glibc-2.31/include/net/if.h:44:5: note: previous definition of ?IFF_UP? was here <GNUtoo>That simply comes from "In file included from ifc_utils.c:29:0:" which has #include <net/if.h> <GNUtoo>-I /gnu/store/97ksyhkzpjy17j79y4g91zjfx2dhr1hd-android-bionic-uapi-7.1.2_r36/include <- I probably need to remove that <GNUtoo>that looks like it's defined by cpath <GNUtoo>hmmm I don't find where it adds -I <input>/include <dftxbs3e>janneke, OK, that's re-assuring, at least to start - then I'll want to put it to a level of excellence <GNUtoo> (map (cut string-append "-I " <> "/include") library-directories) <GNUtoo>I finally found it in guix/build/android-ndk-build-system.scm <GNUtoo>I was looking in guix/build-system instead before <janneke>dftxbs3e: when i can't seem to crack such a problem, it's clear that i need a different perspective: someone else's is great, myself looking again at a later time often works too <janneke>i'm sure power9 will gain more tracktion some time soon <GNUtoo>It probably just need an FSDG distro to support it <nckx>dftxbs3e: I think you get my point 😉 <GNUtoo>I tried to add that example from the guile manual <GNUtoo>Unbound variable: string-replace-substring <GNUtoo>Unbound variable: string-replace-substring <GNUtoo>(string-replace-substring "a ring of strings" "ring" "rut") <GNUtoo>And it gave the error that I accidentally pasted twice above <GNUtoo>How do I create a new string from an old string while replacing part of the string <GNUtoo>Do I need some ice-9 module like regex? <GNUtoo>(use-modules (ice-9 string-fun)) <GNUtoo>ah I didn't see that in the manual <GNUtoo>I'll try it, sorry for the noise <nckx>GNUtoo: Read the paragraphs above it 😉 <GNUtoo>ahh ok, string-replace-substring doesn't seem to be in guile 2.2, so maybe that's why I can't use it from the ice-9 string-fun <dftxbs3e>nckx, cool! 128-long-double is only for LE\ <GNUtoo>I've seen it in guile/utils though <GNUtoo>but I'll read the paragraph before first <nckx>Ah, I didn't get your last messages, GNUtoo. <dftxbs3e>nckx, thanks a lot, I will work up an upstreamable full patch for LE bootstrap binaries <fnstudio>hi all, i get `tmux: need UTF-8 locale (LC_CTYPE) but have ANSI_X3.4-1968` when launching tmux since when i tweaked things locale-wise on my system (guix on debian) <fnstudio>i looked it up on the web, it seems a pretty common issue, although i'm not sure whether the recommended solutions apply to my system <fnstudio>the usual recommendation is to play with localectl and locale-gen, although should i run those commands on the foreign distro or on guix? <dftxbs3e>if I can upstream this and the associated bootstrap binaries, then we got GNU Guix on top of other GNU/Linux distributions on PowerPC 64-bits working <fnstudio>it's not completely clear to me where the line is drawn that separetes the foreign distro and guix, in particular with regard to these locale things <dftxbs3e>nckx, ./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-tarballs - rather <nckx>dftxbs3e: Lookin' good! My patch, at least, didn't change the GCC hash on other arches so can be upstreamed relatively quickly. *nckx has bad lag and is following along on logs.guix.gnu.org :-/ <nckx>fnstudio: I'm not much help on foreign distroes, but can you elaborate on ‘tweaked things locale-wise’? Which changes did you make? Is this tmux from Guix (I assume so)? Are all your Guix packages up-to-date? Is GUIX_LOCPATH set? <nckx>My (Guix System's) mosh suddenly refused to connect to servers due to locale problems a few days ago. A reboot fixed it. I wonder if something was changed. <nckx>dftxbs3e: Do you host your tarballs somewhere? Depending on my evening I can build & compare. <fnstudio>nckx: yes, right, so _tweaked things_ = i kept getting this locale-related warning/hint when launching guix commands; so i installed glibc-locales and glibc-utf8-locales both as root and as my normal user and (after a reboot and some random attempt that i didn't fully understand) that was sorted <fnstudio>nckx: however, i then realised that my system was broken in some other way <fnstudio>nckx: i managed to get urxvt alive again by setting LC_ALL=C - which doesn't make much sense to me, i'd expect it to be en_US.UTF-8 or similar <fnstudio>nckx: and yes, both tmux and urxvt are from guix <fnstudio>i did try with a last resort reboot, but that didn't seem to help either <fnstudio>i just guix pulled... i don't know, maybe i could give it another try and reboot again <dftxbs3e>nckx, it most certainly wont match - I'll upload them somewhere <dftxbs3e>nckx, I have other such binaries since a while, I've just rebuilt and re-uploaded them for you here <dftxbs3e>They're also located in that repo somewhere else <dftxbs3e>nckx, why your patch doesnt change gcc hash and mine would? <nckx>dftxbs3e: That's not what I meant, just that I checked my ‘part’ only. <fnstudio>yes, GUIX_LOCPATH is set by the way, let me double-check on the root user side of things as well <nckx>dftxbs3e: Doesn't it change the libffi hash by patching? <dftxbs3e>nckx, oh ok! I think gcc depends on libffi though.. it's *needed* and would change gcc hash <nckx>fnstudio: The worst I've ever (albeit often) seen a missing root GUIX_LOCPATH produce is annoying but mostly harmless daemon errors. ***terpri__ is now known as terpri
<fnstudio>yeah right nckx and also i double-checked and it is actually set to a location that looks legit to me <nckx>fnstudio: What is LC_ALL otherwise? (Also see what $ locale says, I guess.) By the way, glibc-utf8-locales is a subset of glibc-locales so you shouldn't need both, but it shouldn't cause this kind of problem either. <nckx>It would really be nice if someone with more foreign distro experience were to chime in. I can help with most bugs but not the weird ones 🙂 <fnstudio>nckx: i'm now removing the subset version then, just in case... <fnstudio>(is there an equivalent to apt remove --purge in the guix world by the way? or is it just guix remove?) <nckx>fnstudio: Just guix remove. --purge apparentely deletes configuration files too, which Guix doesn't track or otherwise involve itself with at all. <fnstudio>aka: `bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)` <fnstudio>i suspect the issues with urxvt and tmux are cascading effects of the above <andrew>Hi. Hours after having troubleshooted an Alacritty starting issue on Sway, I've discovered that libxbkcommon.so and libwayland-client.so aren't linked into the Alacritty binary, causing it to fail to launch under pure Wayland environment. Does anyone know what could cause this? <andrew>Wayland and xkbcommon are listed as inputs of the Alacritty package <guix-vits>andrew: is `guix weather alacritty` returns 0% for You too? <guix-vits>and "0.0% (0 out of 1) of the missing items are queued"? <nckx>Bleh, alacritty doesn't contain the string xkbcommon anywhere, so I guess it's a transitive dependency of one of the *many* cargo inputs :-/ <nckx>Also: copypasta/Cargo.toml:wayland-client = { version = "0.23.3", features = ["dlopen"] }, i.e., magic runtime linkydoo that probably broke. ***apteryx_ is now known as apteryx
<tissevert>how come GDM doesn't have a separate herd service ? <kmicu>FWIW alacritty from Nix works but also has no xkbcommon in ldd output. <tissevert>how come restarting xorg-server makes the box completely unusable with a blank tty, no keys allowing to go back to a regular tty and the CPU going into a rage ? <nckx>Alacritty sure takes ages to build for a terminal emulator 😳 <kmicu>It also eats RAM like cookies. <nckx>The build is single-threaded, I guess that's why. <nckx>Or the data centre is on fire like the rest of the continent. <kmicu>Today there’s only 30℃ here. <nckx>...indeed, rustc is consuming a cool 1.7 GiB. Truly the C++ of the future. <guix-vits>tissevert: There was an old joke: "And if Wayland session crashes, then all the apps crash too. Unlike Xorg. And when i asked why, they said it's just a protocol, not a server. And when i'd said "i not geve a ****", they asked: "what is Your troubles?" <andrew>nckx: I gave a quick glance to the Alacritty package recipe and I'm honestly dumbfounded by the complexity of it. In any case, to run it on Sway with xwayland disabled, I had to set LD_LIBRARY_PATH to $(guix build wayland)/lib:$(guix build libxkbcommon)/lib. This is as hacky as it could get <dftxbs3e>nckx, C++ compilers are similar for similarly sized projects, if not more <rpas>Is there no possibility to make the build process use multiple cores? <nckx>andrew: Crazy, right? (The complexity.) <nckx>Thanks for the tip. If nothing else that's a wrapper right there. <kmicu>nckx: use whisper 🤫 do not offend gods of fashion and hype please. <nckx>andrew: How do I start it in glorious future Wayland-only mode? <nckx>It works here, so I assume it's talking to X. <kmicu>Ala automatically detects Wayland nowadays. <andrew>nckx: You actually don't need to. Just run: WINIT_UNIX_BACKEND=wayland alacritty <nckx>That's what I meant. Thanks. <kmicu>thread 'main' panicked at 'Failed to initialize Wayland backend: NoCompositorListening', /build/alacritty-0.4.3-vendor.tar.gz/winit/src/platform_impl/linux/mod.rs:545:28 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace <kmicu>Cool, I’m not on wayland so that’s not a bug. 😺 <andrew>nckx: That doesn't look alright at all to me <nckx>It's just missing the two directories you pasted above, where it would have found the library. <tissevert>it's a good thing that I get to read about service composition again, because I had clearly not understood everything the first time I read the manual when I was pondering whether to install or not <nckx>I'd like to patch in the full patch like we already do for libGL.so, but since this is a transitive mess, I don't know where (and I don't know enough about Rust to find out). <tissevert>although I'm really not sure I want to invest that amount of time, after more than several weeks of struggling and not only a basic system working ^^' <andrew>nckx: I'm on the same boat as you :/ <nckx>I can't even find the part of rust-wayland-client that would dlopen a .so :-/ <guix-vits>tissevert: The services can be used in easier way (especially if some already exist, like gdm). But one'll need to check the differences manually with the new version of service definitions (in git). <guix-vits>*sorry for the respective copyright notices not present <andrew>nckx: How can I help you? I haven't spent 3 hours troubleshooting this only to give up now 😤️ <guix-vits>*when i did makeshift those, i was dazzed enough to 'temporarily omit them <guix-vits>* but the most was taken from gnu/services/xyz.scm's <nckx>andrew: I'm currently writing a wrap-program snippet that just applies you LD_LIBRARY_PATH hack above. So it sounds like you already found the solution! <tissevert>yes, this looks like a lot of code I've been reading through the past weeks. I always have a gview pointing to /run/current-system/profile/share/guile/site/3.0 : ) <andrew>nckx: Oh wow. This must be the first time I'm ever credited with coming up with a solution to a software bug! :o Thanks for tackling this for me! <nckx>andrew: :) So you run pure Wayland? Guix System? <guix-vits>tissevert: with my configs, this should be a `(services (append %my-base-services %my-desktop-services (list (service gdm-service-type))))` <tissevert>what should ? I'm under the impression that you're trying to help me figure how to run gdm at boot : S ^^ <guix-vits>... and, by default, the gdm-service-type is included in %desktop-services. <andrew>nckx: Exactly!.. Well. I reckon I'll have to make an exception for certain software that is incompatible with Wayland at some point, but , for as long as I can, I'll be running pure Wayland on my Guix System box <tissevert>yeah, I know, that's why I'm so puzzled the default «example» configuration would yield something so instable that re-starting a basic system service would «crash» the system <tissevert>and I was wondering if maybe people here had an explanation, if there was a good reason why it should be the case <guix-vits>tissevert: Ah. Maybe post Your system config at paste.debian.net? <tissevert>if maybe I had not understood the relation between *-service-type values in guile and the entries that appear in the output of a «herd status» <dftxbs3e>tissevert, it feels like you are angry at the GNU Guix project, it's a rolling release GNU/Linux distribution much like Arch Linux, if there's a bug, everyone's more than happy if it can be fixed, otherwise, it's just that it hasnt yet <nckx>andrew: I just switched a few days ago, so most things are still running under Xwayland (including my status bar), but good to know it's feasible. I don't think I need anything that can't be convinced to run under Wayland proper. <tissevert>dftxbs3e: on the contrary : I just wished I could reach a point when the thing is usable enough and I can start being useful to the community <tissevert>but I've spent more than 3 weeks at it and I'm starting to worry this was a pure loss ^^ <str1ngs>atleast when thing break in guix, you can --roll-back \o/ <dftxbs3e>tissevert, I am glad you want to contribute. GNU Guix is still in heavy development, so I don't think it makes sense to address it this kind of criticism <tissevert>guix-vits: that's a really nice suggestion, thanks. I won't paste it, it's even versioned on my server <andrew>nckx: There are a few other roadblocks in my way to running pure Wayland comfortably, but this Alacritty issue has been a substantial obstacle to that goal <str1ngs>plus it make my Emacs look crappy :( <andrew>For example, installing qtwayland to a user's profile doesn't make the wayland Qt platform plugin visible to Qt applications.. <andrew>or the fact alone that Qt theming is not currently possible under Guix System (for now) <fnstudio>sorry very briefly on my locale problem again, suppose that you want to change your locale in guix (on a foreign system), is it just a matter of editing the LC_ALL, LC_CTYPE, LANG env variables or am i expected to launch any other locale-gen kind-of commands? *nckx AFK, will reply later. <str1ngs>hmmm maybe "QT_PLUGIN_PATH" should be added to native-search-paths. in qtwebenine I did it within that declaration <fnstudio>and the above variables can all be `en_US.UTF-8` (or equivalent), it's not that i'm mispelling that am i <andrew>str1ngs: According to the project hosting qtwayland's source code: "The QtWayland module consists of two parts: Wayland platform plugin and QtWaylandCompositor API" <andrew>In short: it's required to run Qt apps under pure Wayland <tissevert>guix-vits: sorry about the interruption ^^ time to figure out I had unversioned changes and also that I hadn't set up my SSH config properly <tissevert>since I cleared everything recently just to try whether my personal config could be at fault <tissevert>dftxbs3e: what criticism ? the thing about the behavior of the default GDM service ? <fnstudio>what's the difference between `guix pull` and `guix package --upgrade`? <lfam>fnstudio: `guix pull` updates which packages are available to be installed (like `apt-get update`). The other command updates the packages you have installed, like `apt-get upgrade` <fnstudio>lfam: totally, and it's much appreciated, thanks! <lfam>fnstudio: One big difference between Guix and Debian is that, with Guix, package management is per-user. Whereas on Debian, packages are managed for the entire system. So, each user can do their own `guix pull` and install their own packages <ryanprior>I used to do per-project package management the Debian way using debootstrap and chroot =D <ryanprior>I'm definitely happier doing it with Guix today. My tools of choice evolved from debootstrap -> lxc -> lxd -> docker -> guix, all chasing more or less the same dream <guix-vits>tissevert: So the default config makes "restarting xorg-server makes the box completely unusable with a blank tty, no keys allowing to go back to a regular tty and the CPU going into a rage". Pity. Strange. <tissevert>guix-vits: well it seems to me that I'm close enough from the default config that it would do that but I thought that would be most unlikely and several people here could attest it wasn't the case <tissevert>I'm still trying to figure out what light the GDM service definition could shed on this but I really have a hard time understanding what does get executed in the end from the guile definitions <guix-vits>That may be something wrong with the shepherd. How do it restarting the gdm-service? <tissevert>well I installed lxqt (simply added it to the package.scm that you've seen) and tried to connect using that in GDM <tissevert>I rescued to a tty, looked for a service called GDM <tissevert>figured out it would probably be xorg-server handling this <tissevert>tried to re-run it, found out it wasn't doing anything but now I had duplicate stray GDM processes <tissevert>I killed everyone, started xorg-server manually to get GDM back (that worked) <tissevert>and now that I was a bit more comfortable thinking I had at least a slight idea what could be going on, I thought it would be a great idea to simply get a snapshot of what was running <tissevert>stop GDM and make another snapshot, to observe in detail what was running and what wasn't in both situations <fnstudio>lfam: ooops sorry for the delay; re guix' per-user nature, yes that makes sense and i suppose it's a source of great flexibility, thanks for mentioning that <tissevert>turns out for me, stopping GDM completely locks the box and I was almost relieved that pressing the power button once was handled correctly and made the computer halt after a bit less than 10s. <fnstudio>i'm now upgrading (`guix package -u`) in case that fixes my locale issue <lfam>fnstudio: I can help you fix your locale issue *guix-vits "either WiFi is misconfigured, either.." <guix-vits>tissevert: So `sudo herd status| grep -i gdm` outputs nothing? <tissevert>that's one of the first thing that confused me <guix-vits>IDK, just: (service-type (name 'gdm). The service is part of %desktop-services, and.. where it is, (polite lol)? <tissevert>that sounds like you're being very critic of Guix ! ; ) basically my learning experience so far has been a loooong list of such warning <GNUtoo>I still didn't get string-replace-substring working <GNUtoo>I really don't understand why as it's being used in Guix already <GNUtoo>even copying the #:use-module from tests/utils.scm fails! <tissevert>resulting in my grinding my teeth and thinking «ok, I must be really dumb, of course it must make sense, and I obviously am not familiar enough with the whole thing yet» <GNUtoo>leoprikler: I'm just looking for the module to make string-replace-substring resolved <guix-vits>Hm, ' before gdm means "symbol". Not literal gdm. Ah. <GNUtoo>Unbound variable: string-replace-substring <GNUtoo>That's the issue, it's defined with guile3, not with guile2, and seem to also be defined in guix but I'm unsure <GNUtoo>guix/utils.scm:(define* (string-replace-substring str substr replacement <NieDzejkob>guix-vits: the name of the service type is not the one that shows up in shepherd <GNUtoo>I know only (define and (define-public <NieDzejkob>a guix service can extend the shepherd service type with a shepherd service, and the latter specifies its own name <NieDzejkob>GNUtoo: define* is lambda* in that it accepts #:key and #:optional <GNUtoo> #:export (strip-keyword-arguments <GNUtoo>so "#:use-module (guix utils)" should normally be sufficient <leoprikler>yes, under the assumption, that the code for guile2.2-guix and guile3.0-guix is the same <leoprikler>(though I somewhat struggle to see why you'd using Guile 2.2 for Guix at this point) <leoprikler>If you need the procedure in some other Guile 2.2 code, just copy it there. It is GPL after all ;) <GNUtoo>I'm just trying to make string-replace-substring work <GNUtoo>And I've the standard guix binary install <GNUtoo>I just need to replace one string somewhere but I can't even get that string-replace-substring to resolve <GNUtoo>So what I did to test was to add the following in a lambra expression: <GNUtoo>(string-replace-substring "a ring of strings" "ring" "rut") <GNUtoo>(string-append "foo" "bar" "baz") <GNUtoo>commenting the (string-replace-substring "a ring of strings" "ring" "rut") make it continue and try to compile stuff <GNUtoo>uncommenting make it fail at resolving string-replace-substring <GNUtoo>and I've the import for guix utils <GNUtoo>(define-module (gnu packages android) #:use-module (guix packages) <lfam>GNUtoo: Are you trying to make a package? <leoprikler>if you need guix utils inside the package, you have to add that to the #:modules in (arguments) <lfam>Right, that is what I was going to look for in the package <GNUtoo>The part I'm working on is android-libnetutils <GNUtoo>The code is messy right now as I'm experimenting with it, it'll of course be cleaned before sending it <lfam>You'll need to include (guix utils), but also any other modules, including the build-system itself <lfam>Having said that, you may need to take another approach. We don't usually include (guix utils) in this context <lfam>Depending on what strings you are trying to replace, you may be able to use the (substitute*) procedure <fnstudio>lfam: that's vvv kind of you! i might have some good news though... the issue might be gone after upgrading, let me reboot to be completely sure <GNUtoo>The issue is that I need to remove a -I from the CPPFLAGS *andrew will reconnect back in a few minutes <lfam>Depending on some factors, you may be able to use substitute-keyword-arguments, or you might need to patch makefile.am <str1ngs>hello, is it possible to change one input of an inherited package? <lfam>It really depends on the details, GNUtoo <GNUtoo>This includes the /include directory of all the dependencies <str1ngs>here's my definitions. I need to change nomad-git's g-golf input to g-golf-git. this is just for working in tree. <joshuaBPMan>hey guix, I'm wanting to make a real simple shepherd service to run the command "nmcli con up my_vpn_file". <lfam>str1ngs: Check the package definition of ffmpeg-3.4 <GNUtoo>And because of that it includes android-bionic-uapi /include, which conflict with glibc's includes, <joshuaBPMan>I'd like to add this to the config.scm file...I suppose that's possible... <NieDzejkob>together with (package-inputs package-youre-inheriting-from) <joshuaBPMan>anyane have an example of sending a package to the PID 1 via guile? <lfam>It would be nice if we had something less LISP-y than alist-delete <GNUtoo>however I do need android-bionic-uapi as I need sys/system_properties.h, but I can try to find another way to include these libraries <GNUtoo>All that stuff looks really complicated to do it right <NieDzejkob>joshuaBPMan: look up (service-extension shepherd-root-service-type _) <lfam>joshuaBPMan: I'm not that sharp with Shepherd but I think that style of service creation is for shepherd instances started by your user, rather than PID1 "init" <lfam>GNUtoo: I'm not sure what's the best option here. Hopefully somebody else has advice, or you could ask on the <help-guix@gnu.org> mailing list <GNUtoo>lfam: anyway thanks a lot, I'll try to use that in the meantime and try to find another approach later on <joshuaBPMan>GNUtoo: You said earlier that you did not know that define* was. It's a guile system extension to the standard define. <fnstudio>yay!! upgrading the system (recently installed guix on foreign distro) completely fixed my locale issue! so happy <fnstudio>thanks for your offer lfam but it seems it's all ok now <str1ngs>lfam: ffmpeg-3.4 puts my on the right track. thanks <joshuaBPMan>(define* (my-simple-function) #:key (fun "very") (foo "bar") time) <lfam>Glad to hear it, everyone <joshuaBPMan>lfam: I would love to you my regular shepherd created by the normal user...but running $ shepherd gives me this error: <lfam>joshuaBPMan: Do you see another shepherd running for your user in `ps aux`? <joshuaBPMan>lfam: ps -e | grep shepherd shows only one shepherd...It has PID 1. <joshuaBPMan>joshua 9750 0.0 0.0 6380 1728 pts/1 S+ 12:04 0:00 grep --color=auto shepherd <joshuaBPMan>I think that line is just saying that the command "grep" is has the word shepherd in it?... <joshuaBPMan>hmmm. It may have to do with the fact that I had guile-dbi installed in my default profile. <lfam>So, something I had to do to make user Shepherd work is to set XDG_RUNTIME_DIR. I set it to "$HOME/run" <joshuaBPMan>Which depended on guile2.2....which maybe when I have been reconfiguring, I've been reconfiguring with guile2.2...and maybe guix and shepherd prefer me to use guile 3? <lfam>I was having trouble with making sure the /run/user directory was being created reliably <lfam>Yes, especially because I forget about it every time I reinstall that system (once a year) <joshuaBPMan>lfam: I do have a /run/user/1000 directory...which is probably my regular user... <lfam>The Shepherd manual does mention that this variable can be used, but Shepherd still has a lot of room to grow and improve <lfam>Yes, 1000 is usually "you" on a system with no other users <joshuaBPMan>lfam: I wonder why shepherd isn't working for me then...very odd. <lfam>Well, apparently something is already using that socket <lfam>It would be nice if the backtrace was not abbreviated <joshuaBPMan>lfam: do you have an example bit of code that shows sending guile commands to shepherd? <andrew>That looks like a lot of effort to setup a user shepherd service. I'm already not very optimistic about having to learn how to create them myself in the near future. <lfam>No, I don't. I have an 'init.scm' file and use the `herd start / restart / etc ...` commands <lfam>andrew: Yes, it's currently not as easy as systemd, unfortunately. Shepherd is currently rather simplistic <joshuaBPMan>lfam: me too...but I need to get shepherd to run first...obviously. <lfam>We do aim to make it more sophisticated but need help <pkill9>this grafting situation pisses me off <lfam>joshuaBPMan: So, if you export XDG_RUNTIME_DIR and start shepherd, does it work? <lfam>What grafting situation pkill9? <pkill9>not being able to *remove* a package unless I can *download* a bunch of stuff <pkill9>lfam: if I run `guix package -r jack`, it tries to download a bunch of packages <lfam>It's not necessarily about grafting. If you did `guix pull` since your last `guix package` operation, it could have updated the packages required to create a new profile <lfam>Does that make sense, pkill9? <pkill9>according to kmicu, it's because all invocations of `guix package` try to update the grafts in the profile <lfam>I actually don't think that grafting is related at all <pkill9>lfam: it's downloading gtk+, mesa, glib and python <lfam>I don't understand what they mean by that <str1ngs>andrew: shepherd user service are not hard to create <lfam>Like I said, If you did `guix pull` since your last `guix package` operation, it could have updated the packages required to create a new profile <lfam>pkill9, I'll remind you that people work hard for free to make Guix, and calling it stupid is not going to help improve it. Please try to offer concrete criticism <lfam>I understand that this situation is annoying <andrew>str1ngs: I'd be glad if there was a Guix Cookbook tutorial on their creation for non-geeky users like myself :) <pkill9>i tried an older revision of guix and it's still doing it <str1ngs>andrew: ah I've been using shepherd long before Guix existed :) <lfam>It's definitely annoying and counter-intuitive that removing a package from your profile can require new software <dftxbs3e>andrew, There's an NLnet grant for GNU Guix GUI tools, given the language (Scheme), it is ideal for automated language transformations, so I hope the best <pkill9>lfam: i don't think it's downloading stuff it requires though, why would mesa be required? <lfam>But, building a profile requires some programs. The question of which programs are required for any operation in Guix is determined by the version of Guix that is effective, controlled with `guix pull` <str1ngs>dftxbs3e: theres' a grant for that. maybe I should apply haha <lfam>If you ran `guix pull` since the last time you did something with the profile, there is a chance that the programs used to build profiles has changed <lfam>In that case, you'll need to get those programs <lfam>I actually think there is a bug report about this particular annoyance <dftxbs3e>str1ngs, NLnet really gives grants easily, apply if you've got any interesting idea - anyways they don't take much risk because they only give the money when actual individual milestones for the bigger task are completed. <lfam>As for why mesa is required, I don't know for sure, but mesa is depended on by thousands of programs <joshuaBPMan>lfam: I can start the shepherd now, but $ herd start vpn gives me this error: error: connect: /home/joshua/run/shepherd/socket: No such file or directory <lfam>Make sure that ~/run exists <str1ngs>dftxbs3e: well I've written nomad which is 99% scheme. So writing GUI Guix would not be hard using guile-gi or g-golf <joshuaBPMan>I did export=XDG_RUNTIME_DIR='/home/joshua/run'; shepherd; <str1ngs>dftxbs3e: I've already started working on graphically managing guix profiles using nomad. <dftxbs3e>str1ngs, this would be really helpful! I'm thinking packages, and then configuration management, this could include GNU Shepherd or GNU Guix service configuration <dftxbs3e>emacs-guix is only available to Emacs users <dftxbs3e>A tool like YaST but for GNU Guix would be really awesome, especially the "configure your own system" part. Also to deploy them remotely with guix-deploy. <str1ngs>dftxbs3e: I was hoping to add many of these things to nomad. Since nomad is someone of an application framework. Pretty much like emacs but in scheme. Accept graphical controls are first rate. <lfam>It's exciting to hear this discussion about a Guix GUI :) I think it's really important <andrew>str1ngs! Thanks! Is placing the init.scm file, and running guix reconfigure enough for that service to start or do I need to reference it in my configuration.scm? <str1ngs>andrew: shepherd user services do not relate to Guix at all. as long as a shepherd is running you can use herd to manage services. <andrew>(I'm assuming that the init.scm file is where I specify a program I want to be run as my user) <dftxbs3e>str1ngs, I see thank you, and that supports GUI controls? <dftxbs3e>Emacs also does support GUI controls to some extent, however it has some limitations I believe. <str1ngs>dftxbs3e: yes, it uses GI via g-golf for GTK controls. <str1ngs>this does not have the limitations Emacs has. <str1ngs>also it has first rate Emacs keybinds interactive commands and even M-: evaluations <str1ngs>dftxbs3e: I even support QT, but that's along ways down the road :) <andrew>str1ngs: I reckon there's a way to declaratively create shepherd user services using Guix, right? I'd like to automate the creation and running them as much as it is possible. <str1ngs>andrew: no not use services. only system services. guix only deals with /gnu/ which is nice. So it has no effect on user services especially on foreign distros <str1ngs>it's the same reason you can't use guix system services on foreign distro's <str1ngs>how do I add guix module path so it's available to geiser? <str1ngs>things like (guix packages) are not available to gieser. <andrew>str1ngs: Does that mean that I can't have a one-shot service that executes a bash script as my user? <andrew>..and declare that service in my configuration.scm? <str1ngs>what is configuration.scm? is this your guix system config? <andrew>Yes, I mean my guix system config <str1ngs>okay, you can't configure shepherd user services with Guix at all. though you really don't need to. put them in ~/.config/shepherd/init.scm <andrew>str1ngs: Sorry, I wasn't sure what user services meant in the context of Guix System. One more question and I promise to stop spamming questions regarding Shepherd. Will my user service be automatically started if the init.scm file is present in ~/.config/shepherd or do I need to start it manually with the herd start command? <pkill9>lfam: shouldn't all the inputs required to produce a guix profile be installed along with guix itself? <str1ngs>andrew: I think herd start is enough to start your user services. since shepherd is already running. though you might need to test this. I'm not on guix system right now. if not just calling shepherd as a user will start your shepherd users services <lfam>pkill9: Perhaps... but what a profile "is" is partially determined by what you have installed <lfam>Like, there are different profile hooks that are created based on what is installed <str1ngs>if some one can test herd status works on a guix system without manual starting sheperd for the user. that would be usefule. *str1ngs looks at everyone <lfam>str1ngs: `herd status` will not work if shepherd is not started <lfam>But, `sudo herd status` should work to view the system shepherd's status <str1ngs>[[ ! -S /run/user/$UID/shepherd/socket ]] && shepherd should start shepherd for a user if it's not running <happycorsair>Hello, Guix users! How can I specify package version in config.scm? Thanks in advance! <andrew>str1ngs: Oh!!! Would that go to .bashrc file? <str1ngs>andrew: depends on your desktop environment. it's okay to put it in ~/.bashrc just keep in mind services wont' start until you say start a terminal <pkill9>lfam: maybe the inputs required to build a profile could be registered as gcroots with a command? could thsat work? <lfam>pkill9: "Gcroots" are store items that are protected from being garbage collected. I can imagine some scenarios where that would help avoid downloading things but it's not clear to me how it would help with the problem of "removing a package from my profile requires downloading or building something else" <pkill9>it would prevent the garbage collector removing them, so you wouldn't need to download them again <pkill9>tbh i just need to know which inputs are required and get them on guix pull <lfam>But, you might not have downloaded them yet <lfam>pkill9: I think the easiest way for you to avoid this annoyance is to always do `guix pull && guix package -u .` <lfam>That is, always pull and upgrade the packages at the same time <pkill9>i don't think that would be easiest, because some packages won't have substitutes <happycorsair>wigust: Thanks! I've already found it, package@version works in cmdline, but not it config.scm:-( <pkill9>if i just guix pull to get a particular package, and don't want to upgrade htem all <pkill9>so if i only need the things required to build a profile, then i can just gcroot them <lfam>Sure. You could also not run the garbage collector <wigust>happycorsair: are you sure specification->package is not working? ;-) Could you show your config.scm? <str1ngs>lfam: I'm not sure why I did'nt figure this input modification myself. I appreciate you pointing me in the right direction. <andrew>str1ngs: Had a problem starting the example offlineimap service, but enclosing "offlineimap" with an extra pair of brackets and adding " ' " in front of it fixed it :D <str1ngs>andrew: ah this is for an older shepherd. good catch :) <happycorsair>wigust: If I add rust@1.43.0 it will break everything, saying 'unbound variable' <wigust>leoprikler: either (list (specification->package "rust@1.43.0") "cargo") or (list rust-1.43 "cargo") should work <happycorsair>wigust: finished with rust-1.43 and (list rust-1.43 "cargo") ***andrew is now known as andrew_guix
<andrew_guix>nckx: For some unknown reason I received an empty message from you <nckx>andrew_guix: Weird. It was just: Wrapping alacritty worked. Any name/e-mail you'd prefer over ‘Reported by andrew in #guix.’ before I push? <nckx>Using /msg was just a habit; this information will of course be public in the commit log. <andrew_guix>nckx: I reckon I can't receive private messages since I'm not a registered user on Freenode :( As for the commit log message, you can feel free to take all the credit for fixing it. Andrew is not my real name <nckx>I gathered that much 😉 OK then. <nckx>fnstudio: Have you managed to fix your locale issues? <fnstudio>nckx: hey yes, i did - so kind of you to ask <fnstudio>nckx: i did an upgrade and a reboot and that made everything behave as expected <fnstudio>nckx: to be honest, between you and me, i thought i had done an upgrade with a guix pull already but truth is i didn't know the diff between a `pull` and a `package --upgrade` <nckx>Ah, that happens. I assume someone's already given you the classic apt example by now 🙂 <nckx>(I, on the other hand, always mix up the apt ones -- upgrade & update are too similar for my taste.) <nckx>Couldn't tell you which is which at this very moment. update = pull, I think. <fnstudio>my journey into the guix world has gone quite well so far, if i go on at this pace i may have a guix system reasonably soon! <nckx>Yay! More bug fixe^W^Wusers! <fnstudio>nice thing is i'm exploring guix while also trying to teach myself some scheme, so it's double the fun <nckx>I like you definition of fun 🙂 *NieDzejkob has accepted his role as a bug fixer before choosing between Guix and Nix :P <nckx>fnstudio: Fun hack: guix install sicp && info sicp (although TBH I prefer the pretty PDF version). <nckx>Formbi: Can you elaborate? <nckx>‘(define (???NAME??? ???FORMAL PARAMETERS???) ???BODY???)’ looks suspicious, is that what you mean? Is there a bug report? <PotentialUser-80>I am trying to install guix onto oracle vm and i am seeing lot of hash mismatches errors and as a result base system installation failed :( <PotentialUser-80>i tried expert installation mode as well with --fallback option still same issue <nckx>PotentialUser-80: Could you paste these errors (ideally the full context -- the more the better)? <nckx>paste.debian.net is the house bin, but any non-user-hostile one is fine. <nckx>Honestly no idea, never used it... <nckx>The installer just calls ‘guix system init /etc/config.scm /mnt’ though, so once you've generated a configuration with it you can switch to another VT (Control+Alt+F3, say) and run that. <nckx>Or after it throws an error message. <mfg>so i just built a package with 2 rounds, if there is a difference in these two rounds i get an error, right? ad if there isn't a difference it just runs til the end and there is no error? <pkill9>tfw you get pulseaudio to switch to jack and back seamlessly <pkill9>nckx: not really, it was simple, though finding out how was frustrating, but i think my process is bad <pkill9>the biggest issue is i don't know jack about jack <pkill9>i mostly just try stuff until it works <nckx>Same, so I'm interested in your solution (plz share teh codez, if you will). <nckx>I basically shut down everything, start JACK, do JACK things, stop JACK. <pkill9>the biggest thing that tripped me up is that all software in guix using jack has been compiled with jack-1, not jack-2 <nckx>Much professional, very audio. <pkill9>i got it working by doing LD_LIBRARY_PATH, since jack2 is supposed to be drop-in replacement for jack1, but with dbus interface <lfam>I've heard that JACK 1 is still a better choice, although I haven't used JACK in a very long time <lfam>I think that our JACK support is basically the work of one person, so they made it work for them. More input and help is welcome! <pkill9>it's just that i didn't know what i was trying to achieve, other than 'get it working' <pkill9>nckx: i think all you need to do is put this in ~/.config/pulse/default.pa: https://paste.debian.net/plain/1159936 and make sure pulseaudio, and all clients using jack, are using jack2's libjack libraries, which you can do in the short term by running them with LD_LIBRARY_PATH set to $(guix build jack2)/lib <pkill9>those are the main things i remember doing <pkill9>and jack2 can start/stop jack with jack_control start and jack_control stop <pkill9>when i set it up like that, i can play music with mpv, and run jack_control start, and mpv will switch to jack and continue playing <pkill9>and same when i run jack_control stop <pkill9>2) Run in a terminal: export LD_LIBRARY_PATH=$(guix build jack2)/lib ; pulseaudio -k ; pulseaudio -D <pkill9>3) Run in another terminal: LD_LIBRARY_PATH=$(guix build jack2)/lib mpv <audio file> <pkill9>4) run in another terminal `jack_control start` and mpv should continue playing. Check pulseaudio volume control to see that it switch to jack sink <pkill9>5) Run `jack_control stop` and mpv should again continue playing, switching back to pulseaudio <pkill9>maybe it would be trivial to create a guix profile build script that you can disable build hooks for <PotentialUser-80>@nckx, I am unable to POST logs from vm... the 1st failure is in ghostscript-9.27-doc <PotentialUser-80>guix/ui.scm:1936:12 in procedure run-guix-command: throw to key `lzib-error` with args `(lz-decompress-read 6)` <lfam>Interesting that Linux 5.8 includes a configuration option for some Intel Broxton, but reading online Broxton was cancelled before it even hit the market <lfam>for some Intel Broxton features <lfam>Somebody must be using it <vagrantc>contributing upstream while in development makes it sooner if it ever did hit the market... <lfam>Right, but the news reports declaring it cancelled are from 2016 <vagrantc>i see a fair number of arm boards in upstream u-boot that never hit market <lfam>It's strange that the code would be added now <vagrantc>maybe someone checked off an old todo item :) <lfam>I'm seeing some hints that the technology did make it into *something* <lfam>Sounds more like a Chromebook EC CEC driver to me... <vagrantc>had some variously playfut and heated discussions on #linux-libre regarding how guix is packaging the kernel... <lfam>Yes, surely a continuation of past discussions <lfam>Ultimately they don't really understand how Guix works, and we don't agree with some of their choices <lfam>Most of the programs we use are created by people that don't understand Guix, and we would like them to change something ;) <vagrantc>drakonis: sometimes it was interesting and fun ... but would occasionally diverge into pretty unpleasant dynamics <lfam>Unfortunately I think there is a lack of trust between our communities <drakonis>its ultimately the hardliner position to things <lfam>In the past it has spiraled into insult and accusations <vagrantc>that was the fundamental issue, probably. mhw's comments on the guix-devel recently about trusting linux-libre's infrastructure really hit a sore spot <lfam>There are things feeding that that go beyond the relationship between Guix and the linux-libre team <lfam>The thing about their infrastructure has been discussed since nearly the beginning of GuixSD (predecessor of Guix System) <vagrantc>in particular ... comments along the lines of "why do you trust kernel.org's infrastructure more than linux-libre's, which has a commitment to free software" <lfam>Well, I always remember that GNU and FSF have never been concerned with security, and have never pushed free software as a boon to security <lfam>Or, they have never advocated for free software because it could increase security <vagrantc>i tried to make the case of having independent people verifying the build process was about increasing trust, or not having to rely on trust <drakonis>it has taken the wrong positions on things <vagrantc>and of course i ran diffoscope on a guix-produced and linux-libre produced 5.8 tarball ... all the differences were pretty explainable <lfam>But, to me that is not the primary issue <lfam>There are disagreements that have turned into personal grievances <lfam>It's difficult to recover from that <vagrantc>there's also the case where they restructured the linux-libre release process to have a git repository, largely to accomodate guix's needs <lfam>I noticed that in the recent email thread <vagrantc>so they actually feel they've gone out of their way to accomodate <lfam>I didn't have time to read closely but I did not fully understand how that would help, since cloning a kernel-size repo is not very practical <lfam>I'm sorry if that is something that we requested <vagrantc>weather it actually will work for guix is unclear ... as guix's way of handling git origins is a bit expensive <lfam>We basically throw the cloned repo away every time <lfam>And doing a shallow clone of a large repo is not actually efficient <lfam>At least, it was not useful in the past <lfam>Maybe there are Git servers that have optimized that use case <drakonis>i'm going to go out in a limb and say it might be due to feeling like they should participate on the new hotness <vagrantc>lfam: interestingly, the git is structured such that there is no history between releases ... e.g. there's a tag with precisely one commit for each release. <vagrantc>lfam: so a shallow clone *might* actually be relatively efficient <nckx>PotentialUser-80: It's hard to say anything without logs or exact messages, but everything you've said so far sounds like a bad/flaky network connection. If you run the same ‘guix system init ...’ command several times, does it always die on the same errors? (Hint: you can force it to download one thing at a time with -M1, which makes things more deterministic.) <lfam>Hm, that may be more efficient. I think the servers should be able to reach objects from a tag more efficiently <lfam>I don't remember the details of the problems now <nckx>PotentialUser-80: You're not using a sneaky proxy that modifies HTTP responses, are you? <lfam>But, the easy thing would be to raise some funds to buy more storage and host the tarballs forever, like at kernel.org <lfam>Easy from a technical perspective, that is <vagrantc>lfam: the other thing i think would be interesting is to actually systematically compare the linux-libre tarballs against what guix's tarballs generated using the linux-libre deblobbing scripts produce ... <lfam>Should they not be identical? <vagrantc>well, guix adds at least two patches on most versions <vagrantc>and the timestamps on all the files are different, with guix's predilection for SOURCE_DATE_EPOCH=0 <vagrantc>and ... i think the subdir is different ... e.g. linux-(libre?)-X.Y.Z-gnu vs. linux-X.Y.Z <lfam>Right. I think that part should be controversial <vagrantc>though if the tarballs are produced from git tags, you could instead use the commit date for SOURCE_DATE_EPOCH <lfam>Assuming the tags are not changed. Git tags are mutable <vagrantc>then the diff comparison would be trivial <vagrantc>lfam: but that would be something we would *want* to know happened :) <vagrantc>so, with a bit of my reproducible builds hat on, i tried to make the case for guix's processes being a way of doing independent review <vagrantc>with ... not a lot of success ... but some :) <lfam>I do think that although the discussion is nominally about how we package linux-libre, there are several dimensions to the discussion that are unspoken ***sneek_ is now known as sneek
<vagrantc>yeah, i tried to tip-toe around some of that <lfam>It's for the best, because we are all trying to make great free software systems, so we mostly share common values <drakonis>they seem to be taking some pretty laissez faire stance to security <vagrantc>there were also some points about not including -gnu in the version, in the tarball, etc. <drakonis>cant have microcode mitigations because its software <lfam>We can change the names easily, I think <vagrantc>never got any response to why they used a weak openpgp key to sign their releases <lfam>I think that, in terms of security, we all are living in glass houses <vagrantc>lfam: no, but i saw you propose the idea :) ***jonsger1 is now known as jonsger
<lfam>I'd like to wait to push it until we have new kernels, to avoid unnecessary rebuilds. But maybe we should look into changing those other names? <lfam>Back to security, look at how much exploits cost. Sad to say but iOS and ChromeOS are probably the only OS vendors I would say are serious about security, if we define it as protection against 3rd party code execution or snooping <vagrantc>i didn't bring it up in the discussion, but i think guix's priority on deterministic/reproducible builds and bootstrapping are *huge* benefits to free software ... i daresay i consider reproducibility and bootstrappability preconditions for actual software freedom <lfam>Our world is way more focused on adding features <lfam>Right, it's another level of making free software practical, which is important <vagrantc>lfam: it seems mhw cranks out new updates so regularly, i'm not sure it's worth waiting, per se <drakonis>practical free software is the route to victory <lfam>I'd like to coordinate with mhw about queuing kernel updates so that they are already built when they hit the master branch. He used to do this on hydra.gnu.org <lfam>I think it's best if nobody has to build their own kernel <lfam>Especially on ARM devices <lfam>What do you mean drakonis? <lfam>That's not something we use in Guix <drakonis>as you're talking about nobody having to build their own kernel <lfam>I meant, Guix users using our linux-libre packages should not have to build them. Distro kernels are really expensive to build <vagrantc>lfam: from all that, if there's any way we can also address at least some of the linux-libre folks concerns, even if not all of them, i think it would be a show of good faith <lfam>I agree vagrantc. Do you have anything in mind, as a first step? <vagrantc>lfam: e.g. including -gnu in more places ... <lfam>It's a valid concern. It takes a lot of effort to do their work, and they should be credited for that <vagrantc>i don't quite understand the deblob scripts relationship, but apparently they argued that running deblob-check against the tarball might have also caught my issue (which was really just a typo on the hash update) <lfam>I think that your issue was really our bug <drakonis>well, their work is deblobbing the mainline kernel, which takes way more effort <vagrantc>drakonis: but if it's not fundamentally problematic, it's not that hard to fix <lfam>We try to add descriptive file-names wherever they are needed <lfam>This deblob-check thing was an oversight <nckx>vagrantc: I'm re-reading your discussion there, and perhaps it's been pointed out already, but ‘the url is part of what gets cached’ → no, it's not. <drakonis>i just think its a bit strange to be concerned about branding when guix is already under the gnu umbrella <vagrantc>nckx: yeah, that was clearly a misunderstanding on my part <nckx>It can get confusing because the URL often dictates the file-name, which *is* cached, but that's... incidental at best. <lfam>Well, that may be, but if it's easy for us to change, and they'd like us to change it, we should do it <vagrantc>i'm still new at this ... after ... 2 or 3 years :) <lfam>We've always tried to maintain cordial relationships with the people making the things that we package <lfam>It's especially important because sometimes we bring strange requests to them, such as SOURCE_DATE_EPOCH <vagrantc>and this might be good to summarize on guix-devel ... <drakonis>the reproducible builds folks also do that <lfam>Yes, but that was just an example <lfam>And several upstream teams find dealing with distros exhausting, especially in the age of PyPi, Cargo, etc <vagrantc>lfam: i *think* they're using SOURCE_DATE_EPOCH, because all the files on the linux-libre tarballs have the same datestamp <lfam>That was just an example :) <drakonis>might as well teach guix a few new tricks like pulling in dependencies from third party repos <lfam>I've seen upstreams practically beg distros not to package them, because of the burden of supporting obsolete versions of their software <lfam>It's a matter of courtesy, really <vagrantc>drakonis: it's not plausible to get functional package management when you're relying on a third-party package manager that may not share your priorities <drakonis>thus the policy to not take those packages <lfam>There's one case where I made a personal commitment about how I would package the program, and they were grateful. This did not happen with Debian, and as a result they quit developing their program. Then, we all lost <lfam>Yes, it was really disappointing. The whole thing was a debacle that could have been avoided if people had acted more generously <vagrantc>things blow up for a lot of reasons ... just gotta learn from them when we can and try not to make the same mistakes :) <lfam>At this point we have diverged so much! I wonder if we could collaborate on a technical level. But, it would be awesome to have a "functional systems" meeting where we all got together <lfam>It's extremely useful perspective <vagrantc>there was a lot of coordination between the guix and nix folks at the reproducible builds summit a couple years ago <drakonis>i think eelco was on this year's guix dev days <drakonis>he's still in contact with ludo it seems? <lfam>Right, I forgot about that! It seems like so long ago... <lfam>Wasn't I there last year? (2019) <lfam>Time moves at a strange pace these days <vagrantc>we also coordinated on cross-distro (guix, nix, debian) bit-for-bit identical builds of mes at the last summit <nckx>My memory's not great and 2020 has been the longest year ever but it didn't seem that ‘recent’ 🤷 <lfam>February 2020 sounds like 10 years ago <drakonis>i think the current state of things is that nix is going to soon borrow some guix things <apteryx>I added libsocketcan to qtserialbus, but when try to use it, I get this kind of error: RTNETLINK answers: Operation not supported. Ideas? <apteryx>running the application that uses libsocketcan as root (!) doesn't change that. <nckx>apteryx: Sounds like missing kernel support? <nckx>Perhaps the right modules are not auto-loaded even if they are built. <nckx>apteryx: Anything in dmesg? <apteryx>ah, perhaps! wouldn't I get more explicit messages when this is the case? <nckx>‘Error: no’ means go check dmesg and hope :-/ <apteryx>I could set up a can0 interface using the 'ip' command. <apteryx>but yeah, the description of my under test libsocketcan package says: It requires a kernel built with SocketCAN support. <nckx>Isn't this stuff used in cars? I've never enabled it in my kernels, but configuring them is the only reason I know about it at all. <kmicu>lfam: there was a CVE for X11 ~week ago and pkill9's ‘guix package remove jack’ triggers downlaoding of x11 and packages that depend on it. guix/scripts/package.scm shows that it grafts by default and iiuc --no-grafts has no effect on it. <apteryx>nckx: yeah, cars mostly. But could be used anywhere you need a resilient serial protocol. <lfam>I see kmicu, that makes sense. However, the problem of "removing a package requires downloading some other things" can occur with or without grafts. It has to do with `guix pull` having updated the set of available software <kmicu>lfam: pkill9 provided logs so it was pretty clear it only downloads x11 stuff. <nckx>apteryx: Can you ‘sudo modprobe vcan’ and play around with virtual interfaces? *apteryx wonders we should store a defconfig instead of the full .config in linux-libre: 236K /gnu/store/whzp4bzwzm0x5ifzfpbyg9dv7vhqfv3b-linux-libre-5.7.14/.config <apteryx>SocketCAN is probably something more <lfam>apteryx: What would that mean? What is the difference? <nckx>Actually I'm not that sure. <nckx>That's it's more I mean. <nckx>Afraid I can't help much since my kernel doesn't support it. <apteryx>lfam: the defconfig only saves the config that *differs* from the defaults, so it's much smaller <lfam>That would be great apteryx <lfam>Do you have an idea of how much smaller it would be? A distro kernel like ours goes against many of the defaults, since we enable most drivers <vagrantc>apteryx: there is a way to generate the minimal config from a fully built defconfig that should result in the same options <nckx>And disables the ‘problematic’ ones. <lfam>On my disk, the linux-libre store item is 236 MB. It would be nice to save some space in the config but I probably won't work on it myself, since it will only givea small reduction <apteryx>lfam: a comparison from a buildroot project I have at hand: the defconfig is 65 lines. The corresponding .config file is 3477 lines. <vagrantc>more interesting would be to save the minimal configs to guix.git ... as it makes diffs between releases include a lot of noise <lfam>The Guix config is ~10k lines <nckx>I did assume that's what apteryx meant. *vagrantc uses the -generic kernels for arm* <lfam>Although I made the 5.7 configs and am working on the 5.8 config, I am totally new to this. I'm doing it because it needed to be done and I felt some motivation, not because I'm an expert. So all advice welcome <nckx>vagrantc: Who configures those? <vagrantc>nckx: they just use the shipped defconfigs <apteryx>lfam: I haven't played with linux targets much, but there should be a 'make savedefconfig' or similar to output the minimal resulting confing. <lfam>So, would we still install the full config? And just use the minimal diff-style one for our Git commits? <apteryx>the full config can be recreated from the matching sources <vagrantc>then it'd be easy to update between version bumps ... build, copy the changed config into guix.git ... git diff ... <nckx>lfam: I'd enable it, otherwise the per-type submenus are hidden and revert to their defaults (all y). That could hide freedom issues? <vagrantc>well ... you might have a harder time seeing what potential non-free options are enabled ... i know mhw worked hard to not bother with things that would never work <lfam>nckx: I'm using the linux-libre tarball to create the config. Shouldn't it already have all that stuff removed? <vagrantc>lfam: i don't think they change the config options, they just disable the functionality <lfam>I mean, shouldn't all the features that are not free have been removed <nckx>Why would you install the minimal config? I don't see the advantage (saving kilobytes is not one). <nckx>Are you talking about /run/current-system/kernel/.config? <vagrantc>though ... i'd actually propose to install both the minimal and full config <nckx>That serves as a non-insane /proc/config.gz, for one. <lfam>On that issue, it's always been claimed that a goal of linux-libre is to allow the use of any firmware, and that it's a bug that it does not support non-free firmware a user may have installed <lfam>So I don't really know what it is the right thing to do here <nckx>vagrantc: I grep it all the time 🤷 <nckx>And I'm not loading a gzipped file into unswappable kernel RAM for that. That silly. <vagrantc>nckx: ah, yes, that's a symlink to the full .config <apteryx>I'm no expert, but if the minimal config can be used as easily as the full config (can it?), why bother installing the bloated full config? <vagrantc>apteryx: to review what hidden options might have accidentally gotten enabled <nckx>And just to see what the current kernel supports. <nckx>TBH I'm puzzled why you wouldn't install it (or call it bloated)... <nckx>so maybe I misunderstand all y'all's motives. <vagrantc>a 200-300k file isn't going to break /gnu/store :) <vagrantc>lfam: i'd install both the full and minimal, but only commit the minimal to git ... but maybe there's a compelling reason otherwise <lfam>Well, like I said, I'll let other people work on this, since the gain seems minimal <lfam>It does appear that the linux-libre config includes support for devices without free drivers, and that we enable them. But my understanding is that they won't actually work <apteryx>right. I don't feel strongly about it, I just wanted to point that it's redundant. If it's actually useful to those working on linux-libre, then it's a good reason to keep it. <lfam>I don't have a citation for the claim that they are supposed to work if installed by the user, but I'm going to keep that precedent <vagrantc>lfam: yeah, so having such drivers is just a waste of build time ... <nckx>apteryx: It's very useful for me as a *user*, albeit one interested in kernels & other low-level stuff. But then so is being able to grep guix.git's configs (which I don't use) for support here. Otherwise I'd first have to ‘expand’ them through a full kernel tree or something. But if making *those* minimal would ease maintenance I'd gladly give that up. <lfam>Sure, but how much? And how much time will be wasted changing it? <lfam>I would say that human time is worth more than computer time by a very large factor <lfam>I'd rather let the computer work, and wait for linux-libre to fix the bug <vagrantc>lfam: on that note, i'd say go with the defconfigs and a list of differences to them rather than a fully built config :) <vagrantc>but again, that takes some work ... but i think in the long run would reduce overall work <vagrantc>but that's basically what i've been doing with the linux-libre-arm*-generic configs <lfam>To be honest, I use the Guix configs to build a variety of kernels for private use. If the configs disabled support for popular hardware, I won't be able to justify working on the configs *vagrantc runs away from where this could go :) <lfam>It's not a new situation <vagrantc>just licking some fresh, though minor wounds from the past couple days over that sort of thing :) <lfam>The free software movement started on hardware that needed nonfree drivers. It was sustained through the decades on that sort of hardware. <lfam>The goal is to get something better, but ultimately we need to offer something compelling to *many* people <lfam>We have almost reached that goal, many times, but the situation keeps changing, and the goalposts keep moving <drakonis>i'd prefer to not shut down new users because they dont have niche hardware produced 15 years ago <drakonis>i ascribe the general failing of gnu distros acquiring any adoption to trying to chase away people for having consumer hardware developed within a recent timeframe <drakonis>i tried to run guix on my machine but it had a bunch of hardware papercuts <nckx>Or want secure microcode for the rest. <lfam>It's a big challenge for us <lfam>How do we balance these concerns? <drakonis>the problem is that the gnu project and the fsf have a huge issue with the forest for the trees <lfam>Currently, users have the "freedom zero" option of solving the difficulties themselves <drakonis>freedom zero means nothing if you constantly feel like you're not welcome to do so <lfam>I understand why this is distasteful for some people <lfam>But, we can only do so much given the commitments we made in the past to follow the FSDG <vagrantc>i hear that, though also see value in making a firm commitment to a hard path <drakonis>google has been investing on free hardware <lfam>I identify wifi as a big problem for us. There are no recent wifi chips supported by Guix. And frankly, wifi is going to become a legacy technology, replaced by LTE <lfam>It's important that the GNU system can connect to the internet <lfam>We need to motivate some people to write free drivers for these devices, it at all possible <lfam>Are you asking if wifi will fade away?