IRC channel logs
2022-12-19.log
back to list of logs
<the_tubular>Can I expect all "base" package to compile correctly ? <vagrantc>the_tubular: there will be some sharp edges <vagrantc>though that's only ci.guix.gnu.org ... bordeaux might have better results <KarlJoad>How does Cuirass choose which things in a channel are build jobs that need to be built? Is it public-facing modules inside the channel? <vagrantc>hrm. infrastructure issues at Debian, i definitely won't get to scoop guix on releasing guix :/ <Fare>I'm trying to install guix on a new laptop, but at startup I get a "Sherpherd crashed" message :-/ <vagrantc>only 909 commits since the tag in master ... (e.g. since version-1.4.0 diverged from master) <Fare>oh — is there a known "stable" commit I could guix pull --commit=xxxx to? <vagrantc>it's probably no more known that master really <Fare>I also tried to run guix in a chroot, and guile dies with a segfault right after loading srfi-9.go (!) <Fare>on a usb stick backup of the same installation (same /gnu/store and /var/guix) guile runs just fine(!) <Fare>this "deterministic" build does not run very deterministically :-( <apteryx>cbaines: interesting, patman works with your instance of patchwork <kori>where is the machine record defined? <Guest30>kori: the `machine` record type is defined in (gnu machine), and `machine-ssh-configuration` in (gnu machine ssh) <kori>I assume that's automatically imported when `guix deploy` is run? <Guest30>I haven't gone out of my way to overly familiarize myself with guix's deployment functionality, but all of the shell commands are defined under the `(guix scripts)` module <Guest30>Taking a quick glance, it looks like your assumption is correct: <Guest30>`Line 111 (deploy.scm): (module (make-user-module (append '((gnu) (gnu machine))` <kori>ah, yes. i assumed that would be the case because i just tried (load)ing a file into "guix repl" that was supposed to evaluate to a list of machines, but it kept failing, and i figured out quickly that the machine record type was undefined. it confused me a lot :) <Guest30>definitely an understandable point of confustion, it's pretty misleading that deployment *.scm files have a special import silently added with the command-line, but renders the code invalid as a standalone file when pulled from the repl <Guest30>might be worth adding a note to the docs at the very least <apteryx>vivien: re qtquickcontrols, yes it's OK <kori>personal opinion: i think `guix deploy` maybe will/probably should subsume `guix reconfigure`. though im not sure how similar the two mechanisms are internally. <kori>(the same way guix shell subsumed guix environment) <apteryx>I agree it's seems it should be generalize (abstract away the local vs remote part) <kori>apteryx: that's basically what i'm working on unentangling right now... I want to have a single file that defines all my machines, with shared utility functions/variables (like keys, common packages, etc) and it's a bit tough to deal with having to do guix deploy/guix reconfigure separately <kori>though I havent tested whether guix deploy will reconfigure the deploying machine itself via the network (I hope not) <kori>time to test that right now :) <kori>apteryx: I guess an (environment-type) could be added that would fix that? (environment-type localhost)? something like that? <apteryx>you might have to add a special case for the 'local' machine to avoid it going through SSH <kori>"fix" as in, a hack to make it work. <apteryx>I'm not very familiar with the guix deploy code to advise what would be proper; I'd need to spend some time looking at it <kori>>guix deploy: error: failed to deploy daishibyo: SSH authentication failed for 'daishibyo.lan': Access denied for 'publickey'. Authentication that can continue: publickey,password <apteryx>but if it works as a first shot, why not <apteryx>(the "best" way to do it can be figured out at a later point) <kori>let's test my theory first of whether guix reconfigure expects a file that evaluates to an (operating-system) definition. a theory, because who needs to read the code? <apteryx>while guix deploy expect a list of machines record objects <kori>i should actually get familiar with the development workflow of guix... thank you for putting up with me, though :) <kori>the way I was gonna do it (and what I had mentioned before, which I think... lechner linked me their config as a suggestion), was gonna be to set up the config file as a guile module, and just have a config.scm file that would just be the %operating-system, to "trick" guix system reconfigure :) (but this kinda feels like overengineering it) <Guest30>could you clarify what you mean by "be the %operating-system"? do you mean that the `config.scm` file evaluates to an operating system variable? <Guest30>From my understanding, that is the typical and intended implementation method for `/etc/config.scm` <kori>config.scm would just be a file importing the configs module and the %operating-system symbol, and there would be a separate machines.scm file that would import the configs module, and evaluate to a list of machines <kori>but ideally I wouldn't need to make a module at all and just `guix deploy` a single file <kori>(unrelated note: biggest thing I'm struggling with right now is making a slimmed down kernel for my x220. compiling all the modules every update is a big pain. I still haven't grokked customize-kernel or how to make a guix package... but i'll learn) <Guest30>i see, you're planning to implement your config in a module with all your configuration, with the relevant symbols for `system reconfigure` and `deploy` separately <Guest30>regarding kernel recompilations, is there a reason you're not using binary substitutes to save yourself some time? <kori>I am using a nonfree kernel on my x220 due to the non-free wifi driver <Guest30>cpu microcode, graphics drivers, and wireless comms are the great gatekeepers of a full FOSS stack <Guest30>have you messed with Linux Kconfig before on other distros? <kori>I used to use crux a long time ago :) <Guest30>i'll spare you the gentoo docs then lol, that was my crash course years ago <Guest30>i think i saw some customize-kernel examples earlier, let me see if i can pull them back up <kori>yeah I meant, how to use the procedure directly <kori>i know how to configure + compile + copy the bzimage, but that's not The Guix Way™ <Guest30>found it, courtesy of the guix ci infrastructure configurations: <apteryx>there's now a thing called 'customize-linux' <apteryx>although it has received limited usage because it's very new, may have bugs <kori>apteryx: yes, that's what I was talking about <kori>customize-linux, the procedure <Guest30>nah my bad, I knew there was some work on git regarding that procedure but jumped the gun with the link above once I saw the kconfig variables. these changes are hot off the presses (the docs aren't even regenerated yet), but take a look: <Guixer>Hi guys:-) i built my new package with 'guix build my-package' and it returned a path in the store <Guixer>can I now use pre-inst-env on it without relaunching build command ? <AwesomeAdam54321>Guixer: If you mean doing './pre-inst-env guix build my-package' I don't think it'll rebuild it, it'll just return the already built store item <rekado>Guixer: pre-inst-env has one job: to prefer the Guile modules from the current directory over those that your current version of Guix ships with. <rekado>so the packages that would be built with “./pre-inst-env guix build” can wildly differ from those built with “guix build” <Guixer>alright, in the meantime i realise i don't know where i should be to have this ./pre-inst-env script <Guixer>the thing is a package i was trying to build took loooong times everytime i tried, and it just succeeded for the first time <Guixer>i would like to try this new built package <rekado>Guixer: in a git checkout of the Guix sources <rekado>if you don’t have a git checkout of the Guix sources <Guixer>then guix build -f ~/my-file.scm <rekado>ah, that’s different from what you wrote above <rekado>in this case there’s no difference <Guixer>so i was thinking i could do a sort of pre-inst-env to get a shell where my newly built package would be available before actually installing it <rekado>you’re evaluating my-file.scm and build the package that this file evaluated to <rekado>if you intend to contribute this to Guix eventually, please consider getting yourself a copy of the Guix sources and adding the package there <rekado>that’s the only reason to use pre-inst-env <rekado>to test this you could also run /gnu/store/…-your-package-…/bin/foo directly <Guixer>just calling the bin without setting up the environment won't work because dependencies right ? <xd1le>Guixer, maybe you just want guix shell -f ~/my-file.scm ? <civodul>ACTION prepares to send the release announcements <Guixer>`guix shell -f ~/my-file.scm` did the job instantly, cool <xd1le>Unrelated question for myself, is there some sort of guile package for the guix guile modules? <xd1le>Well I guess there is not since I cannot see any, but maybe there is a way to use them? i.e. in a separate guile project <AwesomeAdam54321>xd1le: Guix builds a guile program for use with the scripts/guix program <AwesomeAdam54321>It can be built using `make guile` in a copy of the Guix repo and the scripts/guix with `make scripts/guix` <xd1le>AwesomeAdam54321, hmm, can this guile program be exported as a variable under (gnu packages) or so? <xd1le>I guess we're maybe running into circular dependency issue here.. <xd1le>In particular the (guix monads) and (guix gexp) modules look like very useful generic guile libs <PurpleSym1>Hm, is the default gcc-toolchain (version 12) is spitting out /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /tmp/RtmpUOvsh4/file177195de57.so)` when trying to use r-brms. gcc-toolchain@10 seems to work. <PurpleSym1>Are these (gcc-toolchain@10 and gfortran) supposed to work nicely together? <xd1le>ah.. that probably wouldn't work anyway since looks like this variant of guile is made to only work for guix, since it ignores the guile load paths <xd1le>AwesomeAdam54321, yes kind of almost.. It's just, it then ends up being a guix program instead of a guile program, which may not be the end of the world. But the bigger issue is, I assume this guix repl will be using whatever guix the user has.. it's not like guix can be used to manage it. If that makes sense. <civodul>PurpleSym1: IIRC you're supposed to pick the same version of gcc and gfortran <civodul>which is why gfortran-toolchain matches gcc-final (GCC 10) <PurpleSym1>Well, I didn’t even install gfortran-toolchain manually 😕 Must be propagated somewhere. <xd1le>At the end of the day there's always good old copy and paste, just I was looking to see if there's a more 'ideal' method. <PurpleSym1>Looks like it links against libR.so, which in turn links against libgfortran.so.5 from gfortran@10. <PurpleSym1>Not sure why gcc-toolchain@12 is the default (without -next suffix, since we don’t have default versions) when everything in Guix seems to link agains gcc@10 😕 <civodul>PurpleSym1: if you're not using gfortran, it's fine to use gcc-toolchain@12 <civodul>problems occur when gfortran gets into the mix <civodul>that's annoying, not sure how to improve on that <civodul>building the web site on bayfront.guix takes ages <civodul>because there are no substitutes for guix itself, apparently <rekado>turns out the old kernel (5.15.19 from the old live USB Guix System image) also cannot access the SSD when booting linux. <sepi>Are there here-docs in guile, also is there some kind of string interpolation? <rekado>that’s a relief because it means that there is no regression <rekado>I’m sure once any of these kernels have booted they would be able to access the disks. <rekado>I guess this means that some more kernel modules must be added to the initrd? <rekado>sepi: no, but this has been a hot topic over at #guile for the past weeks or so <sepi>rekado: Thanks for the reference. <civodul>rekado: which machine fails to boot? <rekado>I’ve been working on it (on and off) since … February 2022 maybe <rekado>wanted to use it replace my i686 netbook “server” <rekado>it boots fine (though *very* slowly) from USB, but just doesn’t boot from SSD (via SATA PCIe card) <rekado>in other aarch64 news: I’ll be getting the two replacement disks today or tomorrow. Will take two of the nodes down this week and replace their disks. <PurpleSym1>civodul: Just make @10 the default and if anyone feels lucky or knows what he is doing, he can always install -next@12 – like we do with Haskell. <civodul>PurpleSym1: we could do that, but that'd be a regression for everyone but Fortran hackers <PurpleSym1>Well, I’m not using Fortran. R links against libgfortran. So every shared library in the R world links against Fortran too. <civodul>ok so i guess i misunderstood the context <civodul>could you send all the details to bug-guix? :-) <rekado>in all my default R manifests that I’ve written for RStudio users here I’ve always defaulted to GCC 10 because of fortran. <rekado>perhaps it’s enough to update the gfortran package/ <PurpleSym1>But would that work, rekado? The default gcc used by Guix is still at version 10, so using gfortran in package definitions would possibly break. <civodul>PurpleSym1: there's no risk of inconsistency in package definitions because gfortran matches gcc-final (both at 10.x) <civodul>the only risk is when referring to "gcc-toolchain" by name, without specifying a version <PurpleSym1>True, but if we updated gfortran to version 12, which was my interpretation of rekado’s suggestion. <sepi>Is define-configuration only used to define configuration formats for serialization or is it a more general purpose facility to help generate config structures for services? <bost>Hi. `guix system init` is reports: <bost> error: failed to evaluate directive: (directory "/var/lock" 0 0 1023) <bost> guix system: error: chmod: No such file or directory <bost>chmod is defined in the (guile) module, so I wonder how's that even possible? <gabber>i'm trying to get my cuirass installation to build stuff from my personal channel and i'm getting a somewhat weird (?) error message. maybe someone here can help me with that? it says: "(exception misc-error (value #f) (value "no code for module ~S") (value ((bootloaders))) (value #f))" in my channel i define my own (gabber packages bootloaders) module which imports (gnu packages bootloader), but these are the only two mentions of <gabber>the string "bootloader". what am i missing? <apteryx>bost: seems like the file it tried to chmod didn't exits? <apteryx>sepi: about define-configuration, I'd say the later, given /no-serialization exists <civodul>i've been waiting for the web site for finally be updated for hours <civodul>apteryx: i'm running the mcron job manually, but the thing is that on bayfront it ends up building 'guix' <civodul>on berlin the web site was built long ago it seems <civodul>thing is the web site mcron job must run within an hour <civodul>and in this case, due to lack of substitutes, it had to build 'guix', which would typically take more than 1h or thereabouts <civodul>so it would time out before it's done, and it'll start over just after that <bost>apteryx: Could be. The full command I run is `guix time-machine -C /mnt/etc/channels.scm -- system init /mnt/etc/config.scm /mnt` and when I have a look then /var/lock/ exists however /mnt/var/lock is a link to /run/lock and /run/lock does not(!) exist. <civodul>and that code has been untouched in several years <bost>apteryx: I created the /run/lock manually with `mkdir /run/lock` and I'm running the `guix ... system init ...` again... <bost>apteryx: HA! And it seems like it wors!!! Thanks for the tip. It's not chmod what was missing it was the directory on which it should operate! <bost>apteryx: so I now I have Guix natively installed on my laptop and it boots... into the guile scheme prompt! :facepalm: <civodul>anyway knowledgeable about that? :-) <drakonis>huh, wingo blog post updates are there too <civodul>(i was referring to the encoding issue for our post) <drakonis>if you change the feed encoding, will it immediately propagate to the aggregator? <civodul>the feed is missing <?xml version="1.0" encoding="utf-8"?> <civodul>but Haunt seems to be emitting it these days, hmm <civodul>i'll refrain from closing as "wontfix" :-) <drakonis>i wonder what's it going to take to get another hn hellthread going with 300 comments <drakonis>because it'll keep guix in the front page for a couple hours <apteryx>bost: ouch; that repl is intimidating ^^ <Guest30>civodul: looks like the guix site uses a custom atom feed generator function[1], while haunt has its own set of feed builders that handles it[2]: <Guest30>we could just add the root tag to our `atom-feed-t` function, or refactor the guix site to use haunt's feed builder directly. thoughts? <cnx>congrats on the release! the poster is the sickest i've seen for any distro btw <lechner>Congratulations to the 1.4.0 release, everyone! It was amazing to see the community come together. The release once more put Guix on the map as a great alternative to more established libre operating systems. Our work at Guix is special because we collectively try to put an end to the configuration zoo. It is a game changer for those who see the light. Thank you! <gabber>wow! nice artwork published with the new release (both the poster and the chiptune) <bost>yeah, really nice artwork <bost>So all the geeks, congrats to the 1.4.0! Now, could you give me some pointers please, what to do when my GuixOS boots only to the repl? <civodul>bost: what do you mean "boots to the repl"? something's preventing it from booting? <civodul>maybe there's an error message above the REPL prompt? <bost> populating /etc from /gnu/store/<hash>-etc... <bost> ice-9/boot-9.scm:1685:16: In procedure raise-exception: <bost> In procedure symlink: File exists <omlet[m]><bost> "yeah, really nice artwork" <- But distrobox i think is priority add <bost>civodul: the backtrase is: <bost> In gnu/build/activation.scm: <bost> 253:2 2 (activate-etc "/gnu/store/<some-hash>") <bost> 1 (symlink "/run/current-system/profile/etc/ssl" "/etc/ssl") <bost> 1685:16 0 (raise-exception _ #:continuable? _) <drakonis>civodul: a shame that nobody commented yet <jonsger>drakonis: all busy installing Guix :) <apteryx>cbaines: perhaps you know about my above question? <civodul>bost: did you run "guix system init" on top of another distro? <apteryx>civodul: yay, thanks for pushing the release past the finish line! <CamilleLouise[m]>"I'll help anyone interested on how to earn 80k or more in just 72hours from the crypto Trade, if interested send me a direct message via WhatsApp by asking me HOW for more details on how to get started <drakonis>omlet[m]: something is very broken wtih your client, it keeps pinging yourself every time you send a message? <drakonis>maybe its because you keep using matrix features? <bost>civodul: I started the installation from USB and then in the end when I was asked if the proposed system configuration is OK? I dropped to console, changed it a little, ran the `guix time-machine -C /mnt/etc/channels.scm -- system init /mnt/etc/config.scm /mnt` and rebooted. <CamilleLouise[m]>"I'll help anyone interested on how to earn 80k or more in just 72hours from the crypto Trade, if interested send me a direct message via WhatsApp by asking me HOW for more details on how to get started <drakonis>lfam: does that not ban the entire matrix bridge? <lfam>I right-clicked on the name and chose the "Ban" option. It was the simplest option of all of them <lfam>I tried doing something more complicated earlier, but it didn't work <omlet[m]><drakonis> "omlet: something is very..." <- i use element (matrix) <lfam>drakonis: Let me know if I should undo it <lfam>It doesn't seem to have removed this person anyways <omlet[m]>Only i not speak good english without translate <vivien>I tried to run git apply but it does not create the commit, so the commit will have wrong author and date information I guess <sepi>string-append accepts a string but gets a #<computed-file>. I thought the computed file would be replaced by it's store path. <sepi>Sorry, it's on line 112. Something went wrong with pasting :/ <rekado>sepi: you can do #$(string-append …) <drakonis>do we have enough people to justify channels for other languages? <acrow>The 1.4.0 announement message was really well done! <rekado>drakonis: do you mean one for en_US and another for en_GB? <rekado>sneek: later tell civodul Thank you for your persistent hard work to push this release over the finish line! Excellent announcement, too. <drakonis>though arent these just the same language but with different swearwords? <drakonis>oh, cant forget about the aussie variation <sepi>rekado: Ok, that was an issue :) Now I have another one where guile doesn't really tell me the location <drakonis>rekado: i did mean for the occasional foreign language speakers with a limited grasp on the channel's main language <podiki[m]1>congrats on the 1.4.0 release everyone! and special props to civodul for herding these cats <mirai>when using define-configuration, can a serialize- procedure retrieve another field from the same configuration record? I'd like to serialize a field 'foo' but it requires knowing the value of field 'bar' from the same record. <nckx>Slighty more awake congratulations to everyone who made 'The Guix Release' happen. It's a Christmas miracle. <nckx>drakonis, lfam: No, banning by IP is the best way to deal with matrices. Thank you both! <nckx>I guess the t.me days are coming to an end. Pity. <lechner>Never mind Texas; don't mess with the French! From French government official Eric Freyssinet on the Birdsite: "Any attempt to remove my tweets that link to my other social media accounts, not violating any law, would actually make #twitter an editorial media, and no longer a social media platform, with civil and criminal liability for *any* illegal content therein." <nckx>lechner: A pervasive myth in the US. Wonder if it's actually true in EU. <nckx>Hey, all: shall we request a release announcement (wallops) from the Libera gnomes? <nckx>Global announcement. Like XFCE had last week. <rekado>sepi: I wonder if it should be (package wordpress) or rather (file-like wordpress) <sepi>rekado: in the docs it says: When a high-level object such as a package or derivation is unquoted inside a gexp, the result is as if its output file name had been introduced. <rekado>sepi: yes. What I wrote above is probably wrong. Shouldn’t do #$(string-append …) when inside you have a package value <rekado>I didn’t see that wordpress-configuration-wordpress is meant to return the package value <rekado>so #~(begin … (string-append #$(wordpress-configuration-wordpress) "hello") …) should be fine <sepi>rekado: does wordpress-configuration-wordpress not need an instance of the package as argument? <sepi>afaik it's a getter created by define-configuration <rekado>efraim: the rust derivation you asked me to build finally failed. 2 test failures in 1.60. <sepi>rekado: I see, your argument was a different one, ie putting the ungexp on the getter <rekado>sepi: FWIW the cups configuration uses a “file-like” type for the cups package, not “package”. <rekado>it shouldn’t make much of a difference though <sepi>rekado: the reconfiguration seems to go though now but with a weird error: guix system: warning: exception caught while executing 'eval' on service 'root': <sepi>Wrong type to apply: "SHELL=/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash" <Guest30>sepi: could it be an issue with running the getter inside the gexp? Could you try `let` binding the package in the config outside of the gexp scope? <mirai>sepi: are you ungexp'ing something that returns a list <mirai>you will need to quote it, '#$(map ....) <sepi>mirai: not that I know of. I'm ungexping either a package or a configuration <ngz>Out of curiosity, is there any status regarding the Rust packaging revamp ongoing a few weeks ago? I lost track of it. <sepi>Guest30: at this point I'm unsure about many things. I would be surprised if this code was the actual problem <sepi>mirai: I'll be afk for about 1h but I'm very interested in any ideas you have about my problem. <nckx>drakonis: Now I've got ‘turn turn turn…’ in my head… Anyway, request put in. Which doesn't mean it will happen. <nckx>ngz: I don't think much has moved since the main author took a break. If it has, it was under my radar. <mirai>sepi: instead of 'package' type, try 'file-like' instead. <mirai>sepi: though I doubt that's your actual problem here <haugh>Congrats on the nice release, everyone. I think this software is going to be a big part of my life for a long time. <nckx>lechner: At the top left, where it says ‘master’. There's a ‘tag’ tab in the dropdown. Unless you mean something more specific. <ngz>nckx: Ah, that's not great. I hope the main author will get some steam back, or Someone© will resume the project. It sounded very promising. <nckx>I think it needs JS though. <nckx>lechner: Does it do anything for you? <nckx>ngz: It sounds like you might understand/look forward to it more than most, and might help get it merged? :) <nckx>lechner: OK, never mind. I got it to work but it doesn't link to commits :-/ <ngz>nckx: Alas, I wish I could help, but my understanding of the Rust ecosystem is way too limited. <lechner>nckx / Yes, that did work! you are a Git power user. Where did you acquire all those talents? <rekado>sepi: it might help to look at the generated derivation files <rekado>there should be one that matches your shepherd service <nckx>lechner: I honestly don't know/remember, sorry. That was just in a dusty corner of my brain :) <lechner>Hi, for https://issues.guix.gnu.org/58658#3 I have to update go-golang-org-x-sys. The repo previously had no release tags, but now I see four commits since release 0.3.0. Should I switch the Guix package version away from the commit arithmetic to a pure release tag? And if not (which would be my preference) may I package the four unreleased commits, as well? Thanks! https://cs.opensource.google/go/x/sys <ecbrown>just finished reading release notes for 1.4.0. way to go guix! <nckx>I haven't the f(r)oggiest clue what it's about and I'm OK with that. <nckx>‘Because guix relies on pivot_root, it doesn't work in initramfs.’ Somebody sure is doing something. <patdk-lap>why am I getting wallops about this channel? <olasd>Because libera.chat enables wallops for all users by default, and libera.chat staff announces major releases of on-topic projects as wallops. you can opt out by setting /mode patdk-lap -w <patdk-lap>if I was in this channel, it would be on topic <nckx>patdk-lap: Can we help you with anything on topic? <patdk-lap>-Scrooge/Wallops- After 18 months of hard work, the Guix team is pleased to announce version 1.4.0 <patdk-lap>yes, attempting to not be spammed by channel I'm not a member of <paddyez>very nice. What is it for? Thanks for posting to #wikipedia-de chan <kori>paddyez: it was sent by libera staff, if you disable wallops (/mode patdk-lap -w, like olasd said), you should not get these announcements anymore <kori>sorry paddyez, meant to highlight patdk-lap <patdk-lap>yes, but then I also will not receive noticed that I do want <Scrooge>umode -w will disable project announcements but network announcements will still go through <paddyez>I am not here to learn how to quiet any messages. I now want to know what it is supposed to tell me... <kori>paddyez: yes, sorry, my bad <paddyez>well is it just another linux distro is it smaller? Why should I care? <drakonis>"Dependable. Guix supports transactional upgrades and roll-backs, unprivileged package management, and more. When used as a standalone distribution, Guix supports declarative system configuration for transparent and reproducible operating systems." <Scrooge>There are links in the /topic here that can probably help with what the project is. <paddyez>Is it better than alpine and still better for docker/buildah images? <drakonis>i think you might be approaching it incorrectly <drakonis>its probably best to look through the website and documentation <paddyez>what do I have to do to test it in docker/podman? <haugh>Where we're going we don't need Docker <drakonis>you might as well just install the standalone package manager or run it in a vm for the full experience <vagrantc>either you're interested and you want to investiage more, or you're not interested and you don't ... maybe you're somewhere in the middle, and that is why this is so complicated? :) <haugh>VM was definitely the smoothest introductory experience I tried. All virtual networking, zero firmware snags. <nckx>drakonis: Does Guix even run in Docker/Podman/cawntainurz? <nckx>I thought those were for running Debian forks. <nckx>That's more than I expected. Ta. <nckx>drakonis: For packs only, I thought. <nckx>Which are kind of ‘dead ends’ (useful, but you get what I mean, if not, tough luck, still tired). <drakonis>i havent had the opportunity to make a image that runs directly on docker <paddyez>I do not understand what it is from the first three paragraphs of the website <drakonis>you can output a docker image and use it as a rootfs <nckx>Must be my Docker service added in the last minute that is somehow not working right. Imagine that. <haugh>Guix is such a massive paradigm shift for Linux that I don't know if it's possible to quickly give someone an impression of its full implications. paddyez, FOR ME, the thing that got me interested was the ability to "roll back" an entire operating system to a safe, working state, and to record a history of these "generations" that I can freely navigate. <vagrantc>i like guix because of the commitment to free software, it has some reproducible builds support built in by design, and you can have reasonably safe user-defined packages without requiring root access ... and if an upgrade goes badly, you can trivially roll back to the previous generation <vagrantc>also, guix shell allows you to trivally try some packages in a one-off environment as needed <vagrantc>weirder featurese include that individual user accounts on the same machine can have different software installed, even different versions, at the same time <vagrantc>paddyez: people who like guile/scheme/lisp, although i like it despite that <nckx>paddyez: Good question. I'd say people who are interested in practical reproducibility of software environments, and declarative configuration (‘systems as code’ that goes beyond telling Ansible which knobs to tweak on a prebuilt image). <lechner>paddyez / any user can install what they like, and whichever version thereof---concurrently with other users <nckx>vagrantc: You should have been fully indoctrinated by now; what went wrong. <vagrantc>paddyez: if nothing said so far doesn't really make you interested ... it might not be your piece of cake. it is a bit weird from other mroe conventional systems <paddyez>So, to be more precice can I profit from this system in maybe in the AWS cloud? <vagrantc>nckx: i must have some innate form of immunity? <nckx>Maybe, but there's little support for it out of the box for cultural reasons. Most of us don't give two whits about AWS cloud. <nckx>sepi: Let's not assume the worst about people, even if they make a poor first impression. <sepi>mirai: Ok, I'll see if I can interpret them in a usefull way :) <paddyez>My needs are secure, rootless,... versioning of specific users might be helpfull. <nckx>paddyez: Guix requires a daemon to be running as root to perform most package management operations, but unprivileged users can install/remove/build software. They can also have completely disjunct package sets & versions, if that's what you mean. <nckx>No, slim is not a design goal. <nckx>The footprint is larger, on average, and we're OK with that. <vagrantc>it is very space hungry, as it may have differernt versions or permutations of libraries to build different pieces of software <nckx>‘Very’ is in the eye of the beholder, but fair point if that's yours. <haugh>One of the things I love about Guix is this developing idea of "The System Layer," that is, an organized approach to the processes which run "between" the Kernel and Userland. Before I found Guix, the most cohesive approach to this concept was systemd so, in a way, Guix represents my salvation from that tyrannical (imo) systems paradigm. <vagrantc>it has some surprises, like rebuilding software whenever anything anywhere in the dependency chain changes <vagrantc>which leads to N permutations of, say, "git" even of a particular version, just because something used to build git changed <nckx>Yes, other distributions often forget to do so. <nckx>If you've ever run ‘revdep-rebuild’: Guix does that for you. Saves typing. <kori>paddyez: to use Modern Cloud Analogies™, Guix System is not the OS that you put in the containers. Guix System is software that would replace ansible, terraform, packer, nomad, etc. all in one go, pretty much... <vagrantc>nckx: other distributions rely on ABI working correctly, which is arguably and demonstratably unreliable <vagrantc>also, i love guix because the all the typos really boost the numbers of commits i make <nckx>Features aside, that's the real reason I use Guix: I lived the ‘let's rebuild X… OK, let's rebuild Y… rebuild just a bit more… ah, there we go, bug fixed™, the disc sectors have been refreshed!’ life and it took me some time to detox. I'm never going back. <vagrantc>now if someone would just get obsessed over "sentences should end with two spaces." and rubbed the lamp i would be free <vagrantc>i'll grant you three wishes... er... guix lint issues <vagrantc>this reminds me of my guix lint RFC that i had everything working except the test suites, and that nckx found dubiously correct <nckx>Could you refresh my RAM? It is very leaky. <lechner>modern computers do that automatically <vagrantc>oh, the next in thread is even uglier but fixes two more issues <vagrantc>stalled out on civodul's comment "LGTM! Bonus points for a test in ‘tests/lint.scm’. :-)" <nckx>Test-driven development, but the test is chasing you with a knife. <lilyp>test-driven development is better than development-driven tests :) <vagrantc>i could just push without the bonus points, but that obviously never felt quite right <vagrantc>i know, i should submit to guix-patches and let some wise parenthetically savvy soul procrastinate on fixing it <nckx>What's your main hurdle? <vagrantc>i was also thinking there must be some better way to handle multipple decorators than wrapping it in more and more (string-replace-substring ... X (string-replace-substring Y ... (string-replace-substring Z ... )))) <vagrantc>given that there are several more it might be worth adding <vagrantc>ACTION switches networks, hopefully without disconnecting... <lilyp>a decorator is a function that wraps another function to somehow extend it – it's similar to advice in emacs in that both essentially implement aspect-oriented programming <vagrantc>at least, i heard them called that somewhere before ... but honestly, i'm just using other people's words :) <nckx>Those definitions don't seem compatible. <nckx>In Texinfo, those are ‘command’ — yes, I'm not saying it makes more sense, they just are. <nckx>I often ‘forget’ that & use the term mark-up. <vagrantc>ACTION defers gracefully to people with more opinions <nckx>My shed with opinions, let you show you it. <haugh>On a scale of "would pay good money for the privilege" to "would rather insufflate fire ants," how is the texinfo workflow once you're actually experienced with it? <nckx>…there's a workflow? I just edit it as plain text. <nckx>I find it no better and no worse than, say, Markdown, and slightly more pleasant than HTML. Let's not mention Docbook. <vagrantc>i tend to just write plain text until someone complains that it should have more magic thrown in <nckx>Actually, better than Markdown, I don't have to remember what ** does. <nckx>And it doesn't confuse formatting with meaning. <nckx>But that's the format, not the workflow. <haugh>well I suppose tooling (syntax highlighting, markup shortcuts, etc) might be relevant but I was more talking about the read/edit loop. Please bear in mind I'm not an emacs user, but the other day I wanted to install the dev manual on my Debian box and I, uh, did not have a good time <haugh>When I edit markdown, I usually do it with a hugo server running, even if I'm not shipping it to one of my hugo sites. It's just a great read/edit loop to save the file and watch it rendered. Does emacs (or anything, really) provide something comparable for texinfo? <palmer221[m]>I'll help 10 people how to earn $56,000 in just 72hours from the crypto market. send a FRIEND REQUEST and DM to know how <nckx>haugh: Simply installing the rendered manual was a bad time? That's… not good. What happened? <omlet[m]>Now the objective is dde package for guix <haugh>nckx, all I needed to do was makeinfo the guix/doc/guix.texi and install-info the zip, but I had no clue how big the texinfo ecosystem was and nearly drowned in the manual <nckx>Could you not use ‘guix shell -D guix’, and ‘make’? (You might consider this cheating, or missing the point, dunno.) <nckx>omlet[m]: I don't know what dde is, so don't understand the joke :) <drakonis>there's a patch on the bugtracker for that <omlet[m]>I think its more security in comparation use flatpak for all <omlet[m]>vomo the guix has not yet been able to package the full plasma kde, I assume it is difficult for the guix community to add more desktop ambiebtes, it is better to package window manager <vagrantc>the more complicated a desktop environment, the more complicated it is to package... <nckx>ACTION reading about Distrobox. <omlet[m]>vagrantc: This is the reason for choose window managers <nckx>Ah, so it'll allow users to run either Trisquel or Hyperbola on Guix System. <omlet[m]>nckx: With distrobox its possible run fedora without kernel or hardware implementation <nckx>I forget if Fedora is FSDG-OK. <omlet[m]>nckx: Distrobox only use the actuality kernel <omlet[m]>Only its necessary create trisquel pureOS parabola and others freedom distros <omlet[m]>obviously avails who if the distrobox is accepted <vagrantc>i would guess the problem is if distrobox out-of-the-box entices you to install non-FSDG distros... although if it just gives you a framework to install whatever, i would guess that is fine <omlet[m]>For now the more freedom in distrobox its fedora (its all why not have hardware) <omlet[m]>The distrobox help for download and configuration the fedora without hardware problems <nckx>vagrantc: I can't get it to list anything, but ‘create’ defaults to Fedora. <Guest30>i'm looking through the sources, it's essentially a collection of shell script wrappers for docker/podman that forward system X11/audio and plays nicely with running on a lot of linux distros <nckx>(Then barfs with ‘Error: open /etc/containers/policy.json: no such file or directory’) <Guest30>even has a handler to forward the guix store into the container: <omlet[m]>nckx: Distrobox create --image xxxxx:xxxx --name xxxx <Guest30>confirming that fedora's `fedora-toolbox` image is hard-coded default: <omlet[m]>I think fedora in container its all freedom <apteryx>hmm. find-team-by-scope can return a regexp object. bug? <apteryx>reproducer: (find-team-by-scope '("guix/status.scm")) <zamfofex>Congratulations on the 1.4 release! (!!!) 🎉 <apteryx>OK, it's the scope that contains regexps <lilyp>btw tis jus me or aren't the regexps being pretty-printed? <apteryx>OK, I think I misread the original output, find-team-by-scope return a team record <apteryx>fun, I added a 'get-maintainer' command to teams.scm and with some contribs to patman we can now 'patman' in the guix tree and it will add the '--cc' automatically :-) <nckx>Guest30: I just ran it (what could go wrong?), haven't looked at the code. The package definition sure is surprisingly... vanilla. <apteryx>now if teams had a way to invoke guix lint, that'd complete it <nckx>zamfofex: Not taking credit for anything, but thanks! 🥳 <Guest30>nckx: i suppose there's not much build work to do when upstream is just a bag of shell scripts <Guest30>licensing due dilligence, distrobox is packaged on debian bookworm `main`[1] meaning source licensing checks out: <nckx>I meant more the traditional Adjustment of Assumptions, FHS and otherwise. <jas4711[m]>hi! successful guix 1.4 installation here. however guix pull + guix system reconfigure on first boot fails: guix system: fel: aborting reconfiguration because commit 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 of channel 'guix' is not a descendant of 989a3916dc8967bcb7275f10452f89bc6c3389cc <jonsger>jas4711[m]: thats "on purpose" because the installation image is build from "version-1.4.0" branch and you pull to "master" branch <Guest30>nckx: just for clarity, #59410 isn't my patch, i'm just along for the ride learning what distrobox is <lechner>Hi, would this channel welcome another bot? A work in progress, it but would eventually try to assist with references like this: bug 60203 <Guest30>nckx: upon review of the code though, you're absolutely right, I didn't realize the package def was using `copy-build-system`, no shot those shell scripts full of hard references make it into the store in a functional state <nckx>ACTION needs to go to bed, TTYL perhaps. With or without guest nick :-) <jas4711[m]>jonsger: how do I stay on the 1.4.0 branch instead? if that is what people are expected to be doing? will that branch be maintained going forward? <jas4711[m]>doing 'guix pull --branch=version-1.4.0' now fails: guix pull: fel: aborting update of channel 'guix' to commit 989a3916dc8967bcb7275f10452f89bc6c3389cc, which is not a descendant of d241517d2cadac3122301b6260c0dfc9f3b383d6 <jonsger>nope, that branch will not be maintained and don't receive any updates. So you usually want to switch to master... <Guest30>omlet[m]: if you're still here and motivated to get this merged, i'd recommend taking another pass through the patch you submitted to ensure that all hard-coded paths come out conforming to how guix does things <jas4711[m]>jonsger: is there any secure way of switching branch? I guess this would hit everyone installing from 1.4 images? <civodul>jas4711[m]: hi! people are expected to stay on 'master' rather than 'version-1.4.0' <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, rekado says: Thank you for your persistent hard work to push this release over the finish line! Excellent announcement, too. <civodul>jas4711[m]: so someone who installed 1.4.0 will run 'guix pull', which jumps to 'master', and that'll be fine <jonsger>stay is maybe the wrong word, they need to switch to master... <jas4711[m]>civodul: I just installed final 1.4 image and guix system reconfigure failed <civodul>actually 989a3916dc8967bcb7275f10452f89bc6c3389cc is the parent of 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 (the two commits in the error you pasted above) <civodul>so after installation, you *have* to run 'guix pull' before you can run 'guix system reconfigure' <rekado>lechner: the SOAP interface returns truncated emails sometimes. <rekado>I reported this upstream, but ran out of steam discussing this. <fjl>Is there an irc channel dedicated to texinfo? I'm fighting it today and looking for help, and was not able to find anything other then mailing lists. <civodul>jas4711[m]: but then somehow 'guix system reconfigure' is running from the older commit, 989a3916dc8967bcb7275f10452f89bc6c3389cc <jas4711[m]> commit: 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 <vagrantc>curiously, an install i did from 1.4.0rc2 had this is the guix system describe output ... channels: guix: repository URL: /home/ludo/src/guix/+version-1.4.0/ <Guest30>fjl: looks like they only officially have mailing lists, you could probably try asking for help in #emacs though <jas4711[m]>guided graphical installation using final 1.4 image, selected gnome+cups+openssh and then booted and logged into gnome and started a terminal <jas4711[m]>okay - 'guix describe' gives different output depending on when run under 'sudo -I' or not <jas4711[m]>typing 'sudo -I' is in my muscle memory so I didn't reflect what could happen here <jas4711[m]>avoiding 'sudo -I' in the workflow solves my problem. guix pull + sudo guix system reconfigure /etc/config.scm works <civodul>jas4711[m]: ah good, thanks for checking! <civodul>vagrantc: ouch, "/home/ludo" showing up in 'guix describe' would be pretty bad <jas4711[m]>civodul: so problem resolved, although I'm curious what is breaking by doing 'sudo -i' <vagrantc>civodul: i guess i'll check if fresh installs do that too <Mystified1234>Hi Guys, Just installed guix, I've been trying to install this for a couple of years , but finally been able to install it with the new iso. Thanks for the great work. But I'm a dumb ass, I did not read the iso correctly, so I've installed the 86 version not the 64, so I 'll reinstall Guix with the 64 bit version. <vagrantc>ACTION wonders if it would be plausible to switch architecture in-place <vagrantc>it's plausible, though perhaps only for the ambitious 
