<ericson2314>but I think a will to create standard that is bigger than either community would be very useful
<ericson2314>e.g. say one is trying to, at their school or research institution, set up a build farm
<ericson2314>it would be nice if guix and nix users can ask for a single build farm they both share
<ericson2314>there are a lot of improvements to the store layer implementation I think could happen, especially for the "data center" use case, and I figure it would be nice if both projects could benefit form day 1
<ericson2314>it has resurfaced after some time incubating on a private branch
<ericson2314>I have a few dreams with this thin waste stuff. One is that anyone that is implementing new build system infra and wanting to show off their fancy implemention should want to implement the "store standard" as a way to get nice comparison with other system
<ericson2314>So I can explain the technical merits of what I want, but I am not really sure yet how to pitch it in a way that makes people excited
<ericson2314>Sticking with the Ninja example, the dual of new implementations implementing it as a "proving ground" is new higher lever things being able to output it
<ericson2314>like CMake outputs ninja, I really wish the Cargos, Yarns, etc. of the world would spit out something both our projects were ready to consume
<ericson2314>I am not sure if you all have "lang2guix" tools like we have "lang2nix" ones, but while those can work surprisingly well, they are always doing something the upstream language-specific package managers did not really anticipate
<vldn1>maybe the guix program is an exception or needs some things to be compiled at runtime don't know
<ericson2314>well anyways, I gave 3 basic motivations: new back end implementations, trying to get the upstream projects to help out on the `guix import` front, and trying to generally reuse work / get around personpower shortages
<yuu[m]>i think we would benefit very much in having greater integration in such a standard. people from nix would try guix and guix people would try nix in a more seamlessly way
<yuu[m]>for example, i've got increasingly interested in guix because its emacs ecosystems seems better. so i want to use Guix specifically for that, while still for now maintaining main use on NixOS (although i'm trying to dualboot).
<yuu[m]>and i know Guix users also use Nix for greater software availability
<yuu[m]><ericson2314> "I am not sure if you all have "..." <- guix has built-in importers for langauges. but they differ with Nix ecosystem in that they try to bootstrap the packages including dependencies for everything; so no downloading binaries for the dependency-tree in fixed output derivations like many 2nix do.
<rekado>the python-build-system is a bit frustrating to me. There are a number of packages that do twice the amount of work because extensions are compiled in the 'build phase and then *again* in the 'install phase.
<rekado>(call-with-input-file (current-filename) (lambda (port) (read port) (((@ (system vm loader) load-thunk-from-memory) ((@ (system base compile) read-and-compile) port #:from 'wisp)))))
<vldn>is it possible in a system definition? like to import guile-wisp to get around the "no such language wisp" error?
<nckx> jeko_: My guess is you're just entering the shell without giving it any commands to execute, so it waits for them forever. Share the script.
<mrvdb>Is someone working on rust for the powerpc64le platform? rustm (bootstrapping compiler) is apparently not supported and everything upwards for rust depends on it. (and many things seem to depend on rust)
***clararussell[m] was kicked by litharge (You are banned from this channel (by nckx))
***litharge sets mode: -o litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!clararuss@* litharge
<nckx>ericson2314: Our list? Like others, I see only drawbacks to sharing a standardised ‘store layer’ with anyone, but very interested in reading the discussion!
<ericson2314>nckx: what drawbacks? I have a big long email being drafted but I ma not sure that is a good way to convince anyone of anything :/
<ericson2314>I am worried that there are those of us that are obessed with layering and modularity, and there are those of us that don't really care at all, and converting someone from either camp to the other is very hard
<nckx>I'll still read it with interest, even if I'm not convinced :)
<nckx>There are plenty of people who care when given good arguments.
<ericson2314>the tittle sounded good, but then the body of that one got really...unexpected to me from a quick glance
<ericson2314>we need something which isn't an arecane ad-hoc binary protocol
<nckx>Arguments I can see: we don't have to maintain (which is to say, occassionaly notice and continue to ignore) the C++ daemon, the daemon core project will do this. Bugs & security issues will get found & fixed. We'd be able to describe ideas in English and maybe even see them implemented.
<drakonis>frankly, what i want out of a daemon rewrite is to free it from the shackles of the current execution model
<nckx>ericson2314: Not a point where Guix competes, though. Until you get commit access it's the same here.
<drakonis>it is a lot easier to get things merged, no?
<ericson2314>Our governance situation is finally starting to improve, but tbh my "ulterior motive" if there is one, is I think we need multiple interoperable implementations to have more effective community competition with less swithcing costs
<drakonis>so if i want to make grafts better, i'd have to throw out most of the work done
<ericson2314>yeah it would be pretty interesting to go more "harvard arch" and *only* put drvs in the db, and entirely in there
<drakonis>i want to get rid of sqlite and use a sexps object format on disk
<drakonis>then store a schema that gets loaded by the daemon on runtime
<nckx>Another fair warning: ‘community competition’ is pretty far from the Guix model of one coherently managed project, and the culture around here in general. Selling it might not have the effect you intend.
<drakonis>if necessary, build another database persistence layer on top of it for cuirass/hydra
<nckx>I know what you mean, but it's worth pointing out nonetheless.
<drakonis>i have this nagging feeling that i'd rather throw out most of the work done on guix's internals and start over
<drakonis>and none of this would ever be accepted by the nix community because they have a very particular view of how to do things
<drakonis>ericson2314: but would you really do it in scheme?
<ericson2314>nckx: right I see I am sounding like some neoliberal with all this competition and "switching costs" bussiness
<ericson2314>and guix is more about the warm embrace, monorepo of boundless integration, etc.
<drakonis>to be fair, we've had working multiple repos for years
<ericson2314>nckx: that is how it sounded to *me*, writing it! :)
<nckx>ericson2314: Also, I was deliberately avoiding ‘monorepo’ because it's not quite what I meant. If you've ever tried to build Android… And yes, we have channels, but it is very much the Linux kernel module model (for lack of a better example on short notice): we get carried away on Refactoring Friday, you downstreams better be ready to follow.
<rekado>silicius[m]: there are several ways to extend Guix. Channels are the most “institutional”; you could also use GUIX_PACKAGE_PATH or -L or ./pre-inst-env on a modified source checkout.
<drakonis>i'm not sure if this is the kind of work that nix would strive to continue
<drakonis>linj[m]: regarding the hardening options, i don't think shepherd offers any of these out of the box, so you'd have to implement them
<pinoaffe>for me one of the decisive reasons that made me go for guix instead of nix was that I didn't like the fact that nix had it's own purpose-built language for configuration rather than an embedded dsl in a general purpose language
<pinoaffe>also guix seemed "cleaner" in many regards
<drakonis>however, having a way to interop is far more beneficial to nix than to anyone else, because it will inevitably lead to fixing nix's internals
<rekado>personally, I’m often repulsed by the low quality of Nix packages in areas that I care about. It would be terrible if people just gave up on packaging things well just because there’s a nix package where someone installs a binary and runs patchelf on it.
<drakonis>plus there's the ways in which guix diverges from nix
<drakonis>and these are definitely not going to play well
<ericson2314>drakonis: again, how do "scheme principles" effect the store *interfaces*
<ericson2314>people should definitely continue to repackage things because you want a coherent, integrated set of packages
<drakonis>that was specifically aimed at the daemon
<Cairn>My confusion has barely started. I haven't even dived into the (arguments) expression yet...
<yuu[m]><ericson2314> "then why have packages in with..." <- see point two https://news.ycombinator.com/item?id=16491797 i remember reading another writeup on this; can't find it rn. but it's basically because packages are 1st class citzens since guile is an actual language that makes that feasible. and iirc easier to navigate the same repo since everything is guile, ...
<ericson2314>yuu: I don't think "first class" means anything in this context
<ericson2314>Guix having packages in the same repo feels to me like putting GCC and Linux in the same repo
<yuu[m]><nckx> "I'm not as familiar with Nix..." <- nckx: not so much different tbh, I was surprised they have similarities. probably Nix Flakes were based on Guix channels and manifest to some extent. Guix channels/manifest just doesn't seems as flexible to me in regards e.g. arbitrary inputs
<yuu[m]>John Ericson: i'm not saying it is good. that's just what i read on this. if i can find the other link which i think ludovic wrote i'll send it to you
<nckx>ericson2314: It's like putting Linux and all its drivers in the same repository, which they do.
<yuu[m]>John Ericson: although i'm not familiar with nix's source, i seem to sympathize in that case. also it is not the first time i see you criticizing flakes ("Our community is in limbo as in waste-of-time projects like Flakes") and until now I could never see your actual point; i suggest if you come up with that again, make it clear that is about the repo/source code, and not functionality per se if that's the case.
***LispyLights is now known as Aurora_v_kosmose
<cizra>1. Could I get a confirm/deny on Guix System's support of LUKS-encrypted root? The manual describes it as something straightforward, yet my system (BTRFS on LUKS2 on disk, no LVM) confuses the bootloader. Perhaps the LUKS2 module is missing from GRUB?
<cizra>2. does Guix decrypt LUKS2-encrypted root a) using Grub, or b) is it decrypted by the initrd? Or c) both? If a, how is the decrypted filesystem passed to the kernel? If c, does this mean I need to enter passphrase twice?
<cizra>Why not redownload the installer image too, while we're at it. Thanks for the tips, folks. Tho I'd prefer to not type the password twice... On other distros, the kernel and initrd are unencrypted in ESP (tho signed for Secure Boot) and decryption is done by initrd. I wonder if I could cheat the Guix system by moving the kernel/initrd out, and just have Guix decrypt the FS once?
<lilyp>unmatched-paren: you could probably still use the 1.0 disk as long as you run guix pull after starting the cow-store :)
<lilyp>cizra: I'mma give you the tip that I give everyone: Start with the smallest working system and add enhancements later.
<lilyp>It's much simpler to get what you want once you have a running Guix System
<acrow>vagrantc: directory exclusions have been added to the debian-copyrighter.
<lilyp>though in the particular alley of cheating the crypto no one really worked that out yet, so contributions are definitely welcome :)
<cizra>lilyp: Definitely! I can enter the PW twice until I get the basics to run fine.
<nckx>I should have been more specific, sorry. Your ‘guix system’ command (without --debug= for both our sanities) should print something like ‘View error log at’, followed by a file name, usually ending in .gz. Is that so?
<yuu[m]>nckx: ah i forgot to remove that. it's because i was (list) in the let to not need `(dependencies (list ..` but just `(dependencies`. but that didn't make sense. your solution worked, but then i had another issue and just commented dependencies for now
<nckx>yuu[m]: Eyy, I see you commented that out. Why? Different error?
<nckx>grep abnt2 $(guix build xkeyboard-config)/share/X11/xkb/symbols/br says it should work.
<nckx>tricon, apteryx: Just yesterday I got trapped in a ‘M$ has done so much for free software, it's unfair how they are treated, they've changed’ conversation. That would have been a nice link to drop whilst I made my escape.
<podiki[m]>i have not tried tempel (or really yassnippet beyond those for guix commit messages)
<shcv[m]>I'm having trouble getting channels to "stick"; I create the appropriate channels.scm file, run `guix pull` and it updates both channels, but then running describe afterward only shows the main guix channel. Any ideas?
<shcv[m]>rekado: `type guix` points to .guix-home/profile/guix; but I have a `(simple-service 'variant-packages-service home-channels-service-type (list (channel ...)))` in my home config that should add the channel...
<shcv[m]>I also ran into that problem on another machine that wasn't using guix home, but it's broken at the moment
<yuu[m]>actually it doesn't seem to tmpfs on /mnt/tmp, but on /tmp and /dev/shm. but still oom `ERROR: In procedure apply-smob/1:` `ERROR: In procedure scm_flush: No space left on device` `guix system: error: cannot close compressed log file (gzip error = -1)`
<wnklmnn>Hi I'm trying to get gitk added to my guix home configuration. I've seen that gitk is in the 'gui' output. trying to add (list git "gui") or (specification->package+outputs "git:gui") to the packages list does not seem to result in gik being available. the regular git command still works fine. is there anything i'm missing?
<rekado>shcv[m]: you should not have guix at .guix-home/profile/guix
<rekado>it should be .config/guix/current/bin/guix