<nckx>Don't forget to remove the trailing ‘rust’ for testing when submitting the patch. <nckx>Although don't feel pressured to submit the perfect patch right away. <unmatched-paren>i've just noticed that some of it didn't get sent (forgot to git add -A :p) <florhizome[m]>Has somebody spent time understanding ostree and how it could be compatible with guix? <nckx>Oh, like that. Maybe it hasn't arrived yet. Or you got lucky and made some other mistake and— OK, there we go ☺ <nckx>unmatched-paren: Just -v2 is fine since the previous -v2 was never public. <nckx>Let's do that. Send -v2 to 52149@ and if the botched ‘v2’ shows up too, I'll just close it. <nckx>It has a steep learning curve. <nckx>More like a hazing wall. <unmatched-paren>but i learned vi, so i do have some experience with learning curves i guess :) <nckx>unexpected end of input while searching for: ) <nckx>I blame your trolly nick. <florhizome[m]>I just was shown this „new os“ and the original approach (coming from a previous nix user) is, don’t have a package Manager at all, but have a custom tool for shells, build optimization with buildstreams and ostree for installation <nckx>unmatched-paren: vi is the ‘throw baby in the pool’ school of pedagogy. <unmatched-paren>i've never really needed to use git in an advanced way since i was always just using github/gitlab/codeberg/whatever which mostly does all the complex stuff for you <lfam>I recommend using `git add -p` instead of `git add -A`. That way you'll be sure to choose the right changes <nckx>I recently had to submit a GitHub PR and was genuinely pleading for a ‘just give me a git command to run’. It's surprisingly not-actually-that-intuitive once you've moved on. <lfam>And also I recommend using the --verbose option to `git commit`, so you can be sure you've selected the right changes <nckx>lfam speaks wisdom. I use -p as a matter of habit and it saves total ass. <florhizome[m]>I kinda expected magit to make things easier but it’s kinda confusing to see all the options <nckx><be the default> Do you want to be murdered by greybeards? Because that's how you get murdered by greybeards. <lfam>At this point I don't even recall what the default behaviour is <nckx>The default behaviour is whatever ^Rcommit, ^Rrebase, … pull up. <florhizome[m]>Let’s make a guix channel that just uses pijul so we can explore that :p <florhizome[m]>on topic, what’s the problem of guix download with git repos <florhizome[m]>guix spits out the correct hash in the build process after failing in the end <unmatched-paren>can someone please test to see if the 0.57.0 recipe that I submitted actually builds? it built for me but i want to check that i sent everything right <unmatched-paren>ofc you need rust 1.56 so you need to be in a dev environment with both changes applied <unmatched-paren>oh i forgot to add a copyright notice to crates-io.rs, i'll just amend it again... <jgart>nckx, trayer built! :) thnx again <jgart>for all those who attended the meetup today asmjit built successfully on my local machine <nckx>unmatched-paren: Unfortunately far less frequently than the ‘every 6 months or so’ from the manual. <unmatched-paren>is there a way i can use the rust from it without switching my entire system over? <nckx>florhizome[m]: So pijul is great & wonderful & reeks of sliced bread, fine, but what's its most serious drawback compared to git? And I don't mean incidental ones like ‘it's not git in a git-mad world’ or ‘there is no pijulhub.com’. <unmatched-paren>i guess i could symlink /gnu/store/blahblahblah-rustc-1.56.1/bin/rustc to ~/bin/latest-rust and do a similar thing for cargo <nckx>I dunno jgart. It's written in Rust, which is strike one. <lfam>Hopefully in the future we can do core-updates more frequently. We had some tooling problems that slowed our work down a lot <nckx>unmatched-paren: If by ‘use rust’ you just mean ‘install it so I can run it from the command line’, just ‘guix install -f’ like you ‘guix build -f’d earlier. <nckx>Guix… should not try to downgrade it, at least. <unmatched-paren>ok yeah i can do that, the only annoying thing is that reconfigure and pull then complain <nckx>I don't understand why pull would complain <nckx>or for that matter reconfigure. <jgart>do I need to use let to take a commit? <nckx>jgart: ? The tags are clearly releases? <jgart>the source URI should not be an autogenerated tarball <jgart>that's what the linter tells me <nckx>Are you using url-fetch instead of git-fetch? <nckx>The linter is correct, but use git-fetch, and a tag. <nckx>(commit (string-append "trayer-" version)) <jgart>the above is not up to date but that s-exps is up to date <nckx>OK, and I see what you mean. The GitHub ‘releases’ page is just a feature, like ‘wikis’, that projects can use to advertise their releases (really, whatever special commits they want). Plenty of projects use them but many others don't, while still doing proper release management themselves. ***mab is now known as bandali
<lfam>unmatched-paren: What do you mean by the latest c-u-f commits? Like, just the most recent 10 commits? Or commits fromthe last day or something? <unmatched-paren>...and now the rust.scm file isn't working because of a change that seems to have drastically shortened the bootstrap chain <jgart>Is there a way to write guile records without having to specify the name of the generated predicate, constructor, etc...? <patched[m]>Has anyone here tried running guix on the FSF membership card? <unmatched-paren>...actually i might not try to install latest rust, it's trying to compile loads of different rustcs <florhizome[m]><nckx> "florhizome: So pijul is great..." <- I have to try, tbh, and i need some Project for that probably^^ <jgart>rgherdt, so a macro that wraps the macro? <rgherdt>a macro that transforms into a define-record-type call, all that at compile time, so no overhead <jgart>chez and gambit iirc don't require the boilerplate <jgart>> A more convenient form of define-record <rgherdt>I'm more familiar with chicken, so maybe someone at #guile already has what you need. If there is something for chez, you could look the code up, since chez also uses syntax-case like guile <jgart>rgherdt, I like chicken's description of defstruct <jgart>rgherdt, (define-record-type point (fields x y)) <jgart>that's all that is needed to define one in chez <jgart>rgherdt, are you interested in packaging chicken libs for guix? <rgherdt>jgart: I could do that for some libs, sure. But I'm not using guix at the moment, that's on my todo list for 2022 :) ***ChanServ sets mode: +b *!*M6piz7wk*@*
***M6piz7wk[m] was kicked by ChanServ (User is banned from this channel)
***ChanServ sets mode: +o litharge
***litharge sets mode: -o litharge
<jgart>We packaged asmjit and argagg <jgart>I think Raghav will take those to finish packaging blacksmith for us <KE0VVT>Do I just need "texlive" and "noweb" to build the PDF? <podiki[m]>guix build not outputting anything usually means a dependency cycle, but is there any easy way to find it? (i have 1300 lines of packages...) <podiki[m]>the "answer" was to try to build each input in the package until finding where it hangs (had where package had input as itself....not sure how the importer did that) <podiki[m]>wow, I think I got taffybar building and working! <cehteh>shoudlnt a detection of such cycles be easily detectable? <podiki[m]>normally probably easier, but adding 53 packages at once made it less obvious too <podiki[m]>but at least the importers should not add as input the package in the same def; perhaps a bug to file <podiki[m]>perhaps is from some metadata; this is for the haskell importers <excalamus>I'm having trouble getting sound out of musescore. I'm using pulse audio on my system. If I play with the metronome enabled, I hear the click. However, if I just play the score, I hear nothing. <excalamus>this is on a new score. It looks like there is a piano set on the first staff by default <florhizome[m]>I don’t know exactly, but I’m willing to find out ;P I kinda just need a project for that. ***Myrcies is now known as myrcy
<rekado_>KE0VVT: I’ve said it before but: it is an unreasonable expectation to have the guix-daemon work with an SELinux policy that is several years out of date on Fedora. <rekado_>since I initially wrote it there have been no efforts to keep it up to date with new Fedora releases ***simendsjo is now known as simendsjo_
<attila_lendvai>so, guix lint is telling me that if i use wrap-program, then bash-minimal should be among the inputs. i see several packages that ignore this (in video.scm). i have sent my patch already when i realized this. should i care and resend my patch? <nckx>Care about lint warnings? Yes. <nckx>Care about fixing those packages? If you like. <attila_lendvai>nckx, ok, will resend then. there's another lint warning: "smplayer@21.10.0: source not archived on Software Heritage and missing from the Disarchive database". is there something i can do to fix this? <nckx>I agree it's not ideal in that respect. <nckx>Guix should send an archival request to SWH but IME it's rather hit or miss. Or at least, when and if this request is processed often seems to vary here. <rekado_>gc lock has been active since a couple of hours already <rekado_>I just wanted to copy a completed build from grunewald and it’s been sitting there since about 4 hours waiting. <rekado_>(that’s the weird build that involved all sorts of other builds, but then cuirass forgot about it even though it finished) <nckx>I feel a great kinship with Cuirass. <nckx>strace: Process 11501 attached → read(27, [nothing…] <nckx>That's assuming I'm tracing the right thing. ***bandali is now known as mab
<nckx>Weird! Could you ‘rm -rf ~/.cache/guix’ first, simendsjo_? <simendsjo_>nckx: Forgot to mention, but the same happens after clearing .cache/guix too <nckx_>And you have no ~/.config/guix/channels.scm? It would not change %default-channels. <jpl01>Let's say I clone a Guix channel that someone made using git, how do I specify in my channels.scm that I want Guix to use the local copy (cloned) of the channel instead of pulling from the orignal git source? <jgart>jpl01, maybe we need a cookbook entry for that detail... <apteryx>sneek: later tell civodul not sure if you or someone else would like to help with this, but I've started with the cross-built rust idea; it is a very rough first attempt for rust-i686-linux that currently reads as https://paste.debian.net/1221124/ and doesn't build due to not finding "binutils" for some reason. I'll investigate later on, but in case you want to pick it up while I'm AFK. <apteryx>the basic idea is simple: use the x86_64-linux rust input to bootstrap, and build rust 1.54 sources by passing --target=$triplet to the x.py script "build" and "install" actions. <simendsjo_>Regarding my `guix pull` as regular user gives `error: Git error: malformed URL ''` error, I found a workaround. As I'm the only user on the system and have root access, I put the channels.scm in /etc/guix, and use `sudo -i guix pull` to get all definitions. I symlinked `/var/guix/profiles/per-user/simendsjo/current-guix` to `../root/current-guix` <simendsjo_>and sourced that etc/profile. After this, I have access to the newest pulled definitions, including the custom channels. Perhaps not the prettiest or most correct solution, but at least I have a working system again (after I reinstall my packages) <jgart>and/or it has some foot guns <atuin>I have found that i have `"/run/current-system/profile/share/guile/site/3.0"` inside the %load-compiled-path variable. This is added into the env variable by the system profile. Is that expected? <atuin>there are not compiled files in that directory <jgart>hopefully someone is able to look at that in time and merges it with the rest of core-updates-frozen :) <jgart>how long did it take to build for you? <unmatched-paren>wait could it be merged to master if i _didn't_ change the `rust` variable but just added a new version? <KE0VVT>rekado_: Huh? I am using Guix System. <unmatched-paren>jgart: the reason there are two emails is that i didn't know how to reply when i was amending it to v2 <attila_lendvai>i'm writing a service (in a nonguix repo). i have geiser set up, i can C-c C-c the code from emacs, test stuff in the repl. if i want to actually test the service (i.e. look at `herd start myservice`), then do i have to git commit the changes, and go through guix pull? or is there a simpler way? <jgart>I've used it a bit. The out of the box experience is really nice. It comes with all the right things built in. <unmatched-paren>Unfortunately the tree-sitter packaging process will involve decyphering a cryptic .nix file :) <jgart>I'm way more productive with vi bindings though :( :) <jgart>nixpkgs has latest helix release packaged <jgart>it's a feeling of comfort when the target package is packaged for guix instead of only nix <unmatched-paren>it'll be much better in the long run if i put in the effort to make packages for things not in guix <unmatched-paren>if we just point people to other package managers when guix doesn't have something, guix won't be very successful <podiki[m]>has anyone here used guix packaging and/or shell to make their xmonad config? (or similar in haskell) <podiki[m]>currently using cabal for that, but wanting to move it into a more guix-y way (and to learn how to do this for taffybar that I packaged now) <ryanprior[m]>One of the packages I use (esbuild) requires a newer version of golang's x/sys package the last few months. Lots of other packages also depend on x/sys so I'd love to build them all to make sure they still work. <ryanprior[m]>Does somebody have a handy snippet to build all the packages that have foo in their dependency tree? <ryanprior[m]>Or could we maybe add that as a flag to build? Like in my case picture `guix build --check --dependees go-golang-org-x-sys` <fiesh>can elogind's configuration only handle the non-longpress versions of the key actions? systemd's got, e.g., HandlePowerKeyLongPress <fiesh>hmm I suppose elogid doesn't even have the longpress ones <podiki[m]>ryanprior: you can use guix refresh -l <package> to get a list of dependents <podiki[m]>then you can pipe that (maybe with some formatting change?) into guix build I would think ***xgqtd is now known as xgqt
***potatoal- is now known as potatoalienof13
<ryanprior[m]>Wait hold on. This looks like it's only one level of dependees. <podiki[m]>I think that may miss some indirect dependency chains <ryanprior[m]>It says "would ensure 655 dependent packages are rebuilt" <ngz>unmatched-paren: tree-sitter is already pending for review in bug#49946 I think <ryanprior[m]>Okay if I'm gonna do this I want to catch the whole big bunch of em. I feel like I've seen a snippet floating around for this, let me check the cookbook. <podiki[m]>yes, must exist as the CI for instance will do that if I understand correctly (updated a low level dep -> rebuilds of everything) ***n1ks is now known as niklas
***niklas is now known as Guest4140
<sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: not sure if you or someone else would like to help with this, but I've started with the cross-built rust idea; it is a very rough first attempt for rust-i686-linux that currently reads as https://paste.debian.net/1221124/ and doesn't build due to not finding "binutils" for some reason. I'll investigate later on, but in case you want to pick it up while I'm AFK. <rekado_>the lock has been held since the morning. <civodul>apteryx: i'm not a fan of having a big binary Rust blob, even if we compiled it ourselves <civodul>it also seems more work that can fit in the timeframe *civodul runs "vacuum" on the store database ***Guest4140 is now known as n1ks
<KE0VVT>2021-11-28 11:06:02 - [source/shadow.c:19] swaylock needs to be setuid to read /etc/shadow <jgart>I had ran the following on my tree: git send-email --to=guix-patches@gnu.org -7 <attila_lendvai>jgart, for multiple patches you need to send the first, get back the issue-id and then send the rest of the commits to that issue id <rekado_>I’m running a few important aarch64 builds manually on the new nodes. <rekado_>they keep getting pushed to the overdrives, which seem to have problems <rekado_>the Python build, for example, has timed out on the overdrive. <jgart>attila_lendvai, oh ok. I remember raghavgururajan telling me that's what he does <jgart>so it's always a two step process? <jgart>I feel like it's worked out before without having to first get an issue id and then sending the patch set... <jgart>attila_lendvai, I'm sure the two step method will definitely work that you suggested it just would be nicer to be able to send the patch set and email together in one go instead of having to wait for the email with the issue-id... <cbaines>civodul, has the vacuum finished now? <attila_lendvai>jgart, i'm new also, and i also find the patch submission and communication somewhat... cumbersome. *jgart reads > When sending a patch series (e.g., using git send-email), please first send one message to guix-patches@gnu.org, and then ... <jgart>yup, that two step process seems a bit tedious or I'm just lazy <lilyp>someone ought to write a mail client that automates this process <jgart>lilyp, does emacs automate it? <jgart>if so, I'd be interested in writing a script that calls a headless emacs-daemon/git send-email mode to send it on my behalf *jgart dreams of an elisp library/framework that causes emacs to barf all of its data for each mode (where it makes sense) to stdout/err so he can continue in "unix as ide" ignorance <attila_lendvai>jgart, i doubt it's worth it, unless you'll submit multi-patch issues daily <lilyp>I am aware of no such program currently <lilyp>but I think you could implement this in an emacs-based mua <jgart>I imagine it can also be implemented as a script in any language <lilyp>basically send the first message, than wait for a message from debbugs, parse that with Elisp, rewrite the headers and send the rest *jgart needs to get comfy with emacs-debbugs <singpolyma>lilyp: would be better to patch debbugs to ingest threads so the existing automated tooling can work <jgart>I'd prefer for the solution to not be emacs-centric <jgart>There's a growing number of guix users that don't use emacs <jgart>I use emacs but prefer to not be locked in to it for essential/basic tasks <jgart>Noisytoot, what's your workflow from the cli with debbugs? <Noisytoot>I sned patches using git send-email as it says in the manual <jgart>curl or wget based interactions? <singpolyma>The "easy" solution would be to use a mailing list. Maybe one with built in patchset tooling like sourcehut. But that's a pretty big change and I'm sure maintainers chose debbugs for a reason. But I wonder how hard it would be to fix debbugs to ingest threads, probably not an insurmountable problem <lilyp>jgart: whatever you build has to be built on top of your MUA <lilyp>so that means either a CLI MUA, something based on Emacs or something where you can plug other programs in like evolution-data-server <lilyp>for instance, I recently wrote a program to send mboxes over evolution, and I use it for my Guix workflow <jgart>I'll have to chat with Peter to see what he thinks we can do to add some feature on top <rekado_>singpolyma: debbugs *is* a mailing list. <KE0VVT>How do I get Swaylock to work? It complains about /etc/shadow. <singpolyma>rekado_: no, it's not, that's exactly what causes the issue being discussed :) <rekado_>bug-guix@gnu.org *is* a mailing list <singpolyma>A mailing list doesn't give me magic email addresses I must use for my replies <jgart>would be nice to fix/work on it at some point <rekado_>KE0VVT: you asked about SELinux. The policy file we include is not for use on Guix System. <lilyp>attila_lendvai: perhaps, though for system services you need to put in a conversion layer (i.e. make Guix write the shepherd.scm) <lilyp>the user services are more meant to manually tinker with your shepherd similar to how systemd-based distros allow user-controlled units, timers, etc. <attila_lendvai>...because currently my edit-copile-test cycle is measured in minutes <jgart>singpolyma, maybe starting an email thread to discuss it further and iron out the issues would be good. I can start it if you prefer. rekado_ If it is an issue with the current mailing list set up we should look into it to improve the experience of submitting patches for the guix community and new contributors. Not a pressing issue but I think one that probably shouldn't be ignored. Let's add it to the list as <jgart>regarding what singpolyma and I discussed above. Did the above message not come through correctly? <singpolyma>jgart: yeah, I haven't been in the debbugs source in awhile so not sure how hard the fix is, but it should be doable. May be worth discussing with upstream even <civodul>cbaines: vaccum's still running; it might take a long time, no? <jgart>singpolyma, I would be interested in organizing an effort to improve that. <rekado_>the GNU instance of debbugs is an outdated, diverged fork <rekado_>I don’t think there’s much of an upstream any more <singpolyma>Oh! So there's a chance upsteam has fixed it even. But I don't think they have based on my interactions with the Debian debbugs <rekado_>the person who maintained the GNU instance asked for someone else to take over some years ago. This hasn’t happened AFAIK <cbaines>civodul, ah, I see, I guess it might do, the process seems to be doing I/O, so I guess it's happening... <vagrantc>dstolfa: debian definitely uses debbugs still as the primary bug tracker <vagrantc>though it doesn't see a lot of development, it still does get some upstream changes here and there <dstolfa>vagrantc: i have very limited to no interction with debian, i was just going by what i overheard :D. good to know <rekado_>singpolyma jgart we’ve got a full copy of the GNU debbugs data (and we’re syncing it constantly). So if there’s something we can do with it to improve the experience I’d be happy to share the raw data. <rekado_>it’s unlikely that GNU debbugs will ever change; it’s more likely to be replaced with something new. <singpolyma>rekado_: you don't think we could get any size patch deployed into the gnu instance? <rekado_>I think it’s difficult because nobody feels responsible for it any more. <jgart>I've been looking into kiss linux a bit and some of it's project goals. The distro (about 2 years old now) is meant to be forked, even by a single maintainer, and as a matter of fact they list a healthy amount of forks on their website: https://kisslinux.org/wiki/forks Is this something that guix could ever embrace? I think it aligns with the the spirit of scheme's hackability. Schemers have always prided them <jgart>selves on having an extensible language. Do you feel extensibility and forkability to be mutually exclusive? <jgart>Maybe the above should go in an email thread 😄️ <rekado_>singpolyma: if you already *have* a patch it doesn’t cost much to try, of course. But I don’t think it’s a good idea to devise plans that involve GNU debbugs as a *project*. <vagrantc>jgart: interestingly, channels somewhat obviate the need for forks ... ***vup2 is now known as vup
<singpolyma>vagrantc: I was just going to say that. Yeah. Channels are like better forks <vagrantc>or at least, make it trivial to make a guix-derived distro (e.g. with a specific channel enabled by default) <singpolyma>rekado_: do you think there's actually an appetite in gnu at large to replace it? I love debbugs, but obviously should put effort where everyone wants to row <rekado_>singpolyma: from my interactions I think few people care either way. But there’s Emacs, one of the largest users of debbugs, so whatever would replace it would have to be careful not to break their workflow <rekado_>I found that with most things GNU there is widespread apathy that turns into very localized hostility right before things get serious. <singpolyma>Right. So if any effort is to be put a smallish patch to debbugs may still be the easiest path. Assuming it is indeed smallish <rekado_>if we can work with the debbugs data as is, though, I think it would be a good idea to extend mumi to cover all the existing features of debbugs there. (Excluding the mail-handling backend that produces the debbugs ‘log’ files from incoming mail.) <rekado_>civodul: now waiting for VACUUM to succeed to copy the outputs of /gnu/store/1xlkh39iwszfixmwjmlnjcsgkdb3h28y-python-3.9.6.drv :) <jgart>vagrantc, that's a good point and kiss linux has another project goal that presents a non-traditional (non debian) monolithic approach to package repositories: https://kisslinux.org/#003 See the linked section called "The Official Repositories". <jgart>What do guix users think of that philosophy for package maintenance? <jgart>Should the main guix channel, be a large monolith with "no clear end" and requiring a large number of maintainers/volunteers to keep it up to date or should it be a smaller core of packages and tools allowing users to then create channels dedicated to particular softwares/language ecosystems? <jgart>Why did GNU/Guix make the decision to go with the former? <jgart>What are the pros and cons of both approaches? *vagrantc is at a brief glance attracted to the idea of splitting guix into multiple channels <jgart>Does it make sense to have a Guix channel dedicated solely to the python ecosystem and it's maintenance? <vagrantc>jgart: that sounds harder, though, because the dependency graph of even a small set of core packages it likely to pull in python and various other languages <jgart>Just some thoughts that have been swimming around for a few days *vagrantc hopes vagrantc is using "dependency graph" correctly here <jgart>I think there can be some pros to the main Guix Channel being just a small core of packages instead of trying to package "the world" <vagrantc>jgart: because guix generally bootstraps everything as needed, that becomes harder to define, though. <jgart>harder but possible if we organize to do it? <vagrantc>of course... all you have to do is do it :) <jgart>I think it would be good to pay attention to the up and coming kiss linux and derivative forks community for the problems they're trying to tackle that they've found with previous distros and how they are approaching it. I think they have a few gems for user freedom and decentralization as well as a few warts. <jgart>one mistake is using github atleast for kisslinux <jgart>carbslinux (a fork of kiss) uses sourcehut, cgit, and github (mirrors) <jgart>and carbslinux is maintained by just one person <janneke>hmm it seems my grub-configuration's gfxmode does not find itself into grub.conf anymore <rekado_>channels become problematic at their boundaries where they connect with other channels <rekado_>it’s a lot easier to develop packages (and the package DSL) within the same channel <vagrantc>would be nice to split leaf packages into a separate channel, though ... guix itself takes a good long time to build <vdv>if i inherit a package and use a definition like (inputs ...) is it overwritten or is it appended to the origin definition? <vdv>make more sense that it is overwritten ... or am i wrong? :D how to append to the origin definition? <vdv>like adding packages to input or deleting specific packages <KarlJoad>When compiling vterm-module, my Emacs fails because libtool cannot find the "cc" tool. I have gcc-toolchain present. <zacchae[m]>I'm trying to add a static ip to my ethernet interface by adding a (static-networking-service ...), but guix system reconfigure is complaining that I have multiple "networking" services. I assume this is referring to the fact that %desktop-services has a network-manager-service-type. <zacchae[m]>I'd like to leave my network-manager-service, as %desktop-services is maintained/"just works". Any ideas on how to add an ip to an interface? <vdv>could you link your current config? @ zacchae <vdv>with ix.io or something else <podiki[m]>vdv: there are utilities for substituting keyword arguments, getting the package inputs to change/add/delete <podiki[m]>vdv: search for "subsitute-keyword-arguments" and "package-inputs" to see that in action <podiki[m]>e.g. (inputs `(("example" ,example) ,@(package-inputs originalpkg))) <ytc>is it possible to hibernate to encrypted swap partition in guix? <zacchae[m]>just updated it ^. Accidently put a version where I had commented the static ip line for debugging. <ytc>zacchae[m]: hello. i wonder if you've shared that file for me or vdv? <attila_lendvai>jgart, my impression is that there already are too few comitters to the guix repo, or at least there's little feedback to the patches that i'm sending, even when they are simple additions of standalone apps. <attila_lendvai>jgart, this would be better if there were various channels maintained by a larger group of people alltogether <ytc>guix repos are very outdated. i hope it will be better. :/ <rekado_>more recent stuff is on core-updates-frozen <rekado_>if there’s something outdated that you care about, please consider sending a patch to update it. It’s really not as difficult as it may seem. <attila_lendvai>ytc, it's one thing to be lagging behind the bleeding edge due to a lack of manpower, and another thing if it happens because guix is lagging behind with applying patches. i'm not saying the latter dominates, but it seems to be an issue from my admittedly newcomer's prespective. <podiki[m]>applying patches does require people though (review/check, push) <attila_lendvai>and what's worse is that old submissions seems to get forgotten until the submitter pings here-and-there <podiki[m]>different amount of work perhaps, but still needs people <podiki[m]>agree that things get lost easily, but the upside is that there is a lot of activity <attila_lendvai>podiki[m], i'm well aware of that. yet, it seems to be a bottleneck. <singpolyma>attila_lendvai: I think well over half of my patch series' get attention within 3 weeks. My bigger series I think are maybe too scary and I need to make them smaller <ytc>rekado_: even packages like i3-wm and pipewire are outdated. i know i can write my own package definition. but popular packages should be packaged by maintainers. <podiki[m]>you can also use a package transformation to build the latest <podiki[m]>but really once you get used to simple patches it is very quick to submit <podiki[m]>perhaps we need more people with commit access dedicated mostly to package updates and things that don't need as much review or time <vdv>@zacchae maybe this: (static-networking-service "eno1" "192.168.1.82" #:gateway "192.168.1.2" #:name-servers '("192.168.1.2")) ? <ytc>afaik guix couldn't hibernate to encrypted swap which is very important to me. i don't know the current situation so i've asked it recently. <vdv>with your ip and network device <vdv>ty will try podiki!!! <rekado_>ytc: ‘should’? Also: we’re using different definitions for the term ‘maintainer’. <vagrantc>i think the way to get more committers is to have more people submitting high-quality patches ... even if there's a backlog of unreviewed patches <rekado_>this is a collaborative effort. You are welcome to join. ***tomerparetsky is now known as tripfandango
<vagrantc>generally people who consistently submit good patches eventually get added as committers ... i *think* :) <podiki[m]>I've enjoyed the patching, I feel much more comfortable with it now and knowing the basic style ***tomerparetsky is now known as tripfandango
<podiki[m]>don't know when I would feel comfortable asking for commit privileges, but one day :) <vagrantc>but it can definitely be demotivating to submit a patch and not get review ... ***tomerparetsky is now known as tripfandango
<attila_lendvai>if it wasn't a monolithinc repo, then it would be much less stress to add commit rights to the leaf repos/channels <podiki[m]>I found it moving quicker once I've done some, and also working on what is needed (e.g. core-updates-frozen stuff is what needs priority) <ytc>rekado_: pipewire 0.3.40 is the newest version. you may think it's not necessary to be not that bleeding edge. then guix should not be advertised as a bleeding edge distribution. <vagrantc>attila_lendvai: there's nothing preventing someone from setting up a channel targeting leaf packages with unapplied patches ... <rekado_>ytc: we don’t do advertising. Maybe talk to the marketing department. <attila_lendvai>vagrantc, if it's not officially supported, and by default added to the channels, then it's just a wasted effort... <vagrantc>there's been a *lot* of work in the last few weeks to merge core-updates-frozen and i suspect once that happens a lot of the "out-of-date" packages will be resolved ... <attila_lendvai>i've been keeping quiet hoping that the merge will happen real-soon-now <attila_lendvai>maybe i should bite the bullet and rebase all my stuff to c-u-f, and contunie working from there <vagrantc>help testing core-updates-frozen would surely be appreciated <vdv>how to change the branch and give core-updates-frozen a test drive? <samplet>Is there a general consensus/trend on how much code (phases, etc.) a bootstrap package should share with newer versions? (I’m looking at https://issues.guix.gnu.org/51838#1 and I wonder if it’s a step in the right direction or not.) <samplet>It’s probably a case-by-case thing, but I thought I’d ask anyway. :) <vagrantc>vdv: guix pull --branch=core-updates-frozen ... i *think* <vdv>lets give it a try :D <vdv>2.6k new commits, fu** yeah :D <vagrantc>if you eventually want to switch back to master, you'd have to --allow-downgrades or something <vagrantc>might have a bit less substitute coverage <vdv>maybe i should spin up my substiute server again :) <vdv>let's wait how long my laptop needs :D <attila_lendvai>is there a format control string that prints 'foo as 'foo in the output? coming from CL, i was xpecting ~S to do that. <apteryx>civodul: have you looked at the patch? It's not about having a big binary; it's about cross-compiling rustc, which is supposed to be as simple as providing --target to its build system <ytc>rekado_: if nobody has packaged the new version of a popular window manager which is offered while installing guix for nearly one year, then sorry, i don't have the motivation to contribute. i know guix needs people's help. but it should be more organized. don't get me wrong, i know all these stuff is voluntary basis. in my opinion, everything would be better if some people were responsible for specific parts of the project very <apteryx>it doesn't work yet; I'll have more time to determine if it's viable or not tonight <vagrantc>apteryx: how can i cross-compile on a native distro then? wouldn't that basically still require a binary seed (that happened to be cross-compiled?) ? <vagrantc>but at least the cross-compiled seed might be available on the substitute servers then? <vdv>@ytc, do u know of the commit system via mail? i don't think it gets more simple than this... <vdv>you don't need a github account or something else, just make a patch and send it via mail :D <podiki[m]>ytc: guix doesn't have the people/coverage of a huge distro, generally things are updated when someone notices, so perhaps that package isn't used as heavily? in any event, try out package transformations, if that works then the patch will be trivial <vdv>and i don't think you should look at the whole distro depending on a version of just one package, it is really easy to bump that version of the package <vdv>run guix refresh pipewire @ytc <vdv>you see that the newest version would be 0.3.40, look at the definition of guix edit pipewire and edit it, or look at the other options of guix refresh <vdv>maybe it's good to know if you edit it with guix edit you need to include it locally in your config.scm <vdv>and save it in another place <podiki[m]>looks like pipewire has a change in build, complains about meson (change in build system?) <attila_lendvai>vdv, are these documented in the cookbook? because it sounds good, but as a newcomer i can't really follow <vdv>then change the arguments from #meson to #meson-next <vdv>it's a lot trial and error, i think it is documented <vdv>wait i will search a helpful page @attila <vdv>just inherit the version of original packages and get an updated package <ytc>thank you for your help, i know guix is very easy-going for these kind of stuff. but as a newcomer, i wish it was more appealing. <ytc>raghavgururajan: can you hibernate and resume from it? <vdv>because it is so different of traditional distros it is a bit hard @ytc <vdv>i'm a newcomer myself :) <podiki[m]>still new and growing, I find it worth the work and learning *attila_lendvai is making notes <vdv>i compare it too much to nixos, but i like it so far :) <podiki[m]>(as context, I only heard about guix maybe around 6 months ago, and now my main desktop runs it, with core-updates-frozen and submitting some patches to help; no Guile knowledge before, but common lisp helps for general scheme reading/writing) <KE0VVT>I can't read Nix code. It's hard. <jpoiret>raghavgururajan, ytc: you cannot resume from anything that's inside a LUKS partition for now <jpoiret>the early userspace does not try to unlock anything before trying to resume <ytc>i love emacs and scheme. i'm using librebooted x200. guix is perfect for me. i tried and tried and tried it but every time i end up switching parabola or gentoo. because it's much more slower and worse out of the box. <vdv>nix is a bit more straight forward @ KE0VVT but maybe it's just me and my use of nix xD <vdv>scheme and guile is a bit overwhelming on the first usage <vdv>nix and nixos is just "i define my system and service and go for it" <vdv>guix and guile ist like "do waht you want" <KE0VVT>vdv: At least Scheme is a language I can read. Nix was created out of thin air, and I have no idea how it works. <ytc>jpoiret: is it possible for me to resume from unencrypted swap to encrypted root partition? <jpoiret>yes, as long as the partition is readily accessible without anything special (no LVM, no LUKS) <vdv>at KE0VVT me neither, it's a big black box but i just use it do define my system and what my operating system needs, so just use man configuration.nix an search for the right definition and define it :D <KE0VVT>One thing I worry about is Guix System's lack of systemd-homed, which allows for encrypting the user's files on laptop suspend. <vdv>that's what i meant with a bit straight forward.. <jpoiret>although i would recommend against it, since swap space can contain sensitive information if it is paged out (some programs try to prevent that from happening for passwords, but not always i'd wager) <vdv>but it's a biiig blackbox and bash mashup <jpoiret>KE0VVT: what does that do exactly? how is it different from just having home LUKS-encrypted? <ytc>there are lots of power cuts in my dormitory currently, so hibernating to disk is very comfortable. <vagrantc>unecrypted swap with an encrypted rootfs kind of defeats a lot of the purpose of encrypted rootfs ... given that the kernel memory will get written to swap. <jpoiret>vagrantc: not if every program takes care of marking sensitive memory as non-pageable, but that's not the case in real life <ytc>vagrantc: yeah but shutting down the pc is still keeps my files safe. <KE0VVT>jpoiret: I don't know, but homed makes sure the keys are not stored in RAM. <vagrantc>jpoiret: if you suspend-to-disk, it will write out the kernel memory to swap *raghavgururajan is confused with sleep vs suspend vs hibernate <vagrantc>ytc: someone could extract the keys from the unencrypted swap partition and decrypt your disk at that point <jpoiret>vagrantc: yes, although you were talking about swap only, not hibernation. I agree that for suspend-to-disk, it is self-defeating <vagrantc>jpoiret: i think it's too dangerous to play the game if you go through all the trouble of using encrypted rootfs to not encrypt your swap... <jpoiret>sure, I agree that simply having everything under LUKS is the only solution <jpoiret>KE0VVT: yay, one more feature that systemd's responsible for *vagrantc is too used to suspend-to-disk not working at all <jpoiret>personally i use swapfiles to avoid having to use LVM <ytc>how can i switch to core-updates-frozen branch in guix? i'm thinking about to try guix one more time. <jpoiret>call me prejudiced but i think that the premise of "uh, weird that you have to input a password to unlock the system before the user actually logs in, that's confusing" is pretty bad. You do need that password otherwise your own system itself can be modified by an attacker (here let me install some remote shell server on your laptop that runs as <jpoiret>root). Once the system is booted up, it uses its own ACL so there's no need to encrypt the home directories <nckx>What's with the influx of entitled people lately? Did Guix get featured on HN again? <vagrantc>ytc: guix pull --branch=core-updates-frozen ... nobody contracticted me the last time i said it :) *nckx gives reconfiguring to c-u-f a second try. <vdv>which entitled person? :D <vdv>it worked @ vagrant but use it without substitutes-avaible <vagrantc>ytc: and then "guix system reconfigure ..." and "guix upgrade" etc. <ytc>vagrantc: sorry. i haven't noticed it. :) <vagrantc>good luck, hope it solves *all* your problems :) <ytc>is it a one time thing? or should i do that at every pull? <nckx>Per-pull. You can create a channels.scm to make it persistent. <vagrantc>there might be some way to make it default ... <jpoiret>ytc: what was preventing you from using guix on the master branch? <vdv>and if you need to downgrade run --allow-downgrades <ytc>jpoiret: my obsessions. <jpoiret>there is a way to make it default, by adding a channel named 'guix in your channels.scm that will replace the default one <vagrantc>though leaf packages that don't require lots of updates should be able to go into guix master <vdv>but if patching a few packages was too much work maybe patching breaking packages in core-updates-frozen could be more work.. <vdv>maybe just update the few packages manually @ ytc <jpoiret>if there are some things that don't work for you on master that aren't just solved by a newer version of a specific software on c-u-f, you might just experience the same on c-u-f <apteryx>vagrantc: yes, I was thinking it'd require substitutes, but that's better than a random binary bootstrap <unmatched-paren>hmm tree-sitter needs a new patch version of serde, but serde is used by a lot of things... would it be ok to introduce a temporary new package to prevent needing to submit this to c-u-f? <ytc>thank you. i have one more question. out of the box it takes very long to boot up. and if i remove the gdm service from startup services, will there be any problem? <apteryx>vagrantc: and if you have access to an x86_64 machine you could challenge the cross-compiled rust <ngz>Then just update rust-serde-1 to 1.0.130 on master will be enough. <ngz>What package relies on rust-serde-1? <vagrantc>wow, substitute available from ci.guix.gnu.org for linux-libre on aarch64! haven't seen *that* in a while! <vagrantc>apteryx: true ... it's an interesting approach :) <ngz>unmatched-paren: According to manual, the limit is roughly 300. <ngz>But again, what package relies on rust-serde-1? <vdv>did the definition worked @ zacchae? <raghavgururajan>> nckx: What's with the influx of entitled people lately? Did Guix get featured on HN again? <ngz>unmatched-paren: I think that's fine. Rust is a bit special. <lilyp>It's true, Guix 2.0 will be preinstalled on WSL. <vdv>i made a gist for wsl a few months ago :D <vdv>maybe they looked at it because it just needs busybox xD <lilyp>vdv: sorry, I was just joking <raghavgururajan>ytc: If you remove gdm, add some other display-manager. Else you cannot login. Unless you start X manually. <lilyp>Microsoft folk still fail to set up Guix even with that gist <vdv>i understood :D but the wsl thing wasn't a joked <vdv>if someone needs it :D <ytc>raghavgururajan: i want to manually start X. <ytc>could you please share it with me? <ytc>i've lost the previous messages, sorry if you have pasted it before. <vdv>would be interesting @ raghavgururajan *vagrantc switched to wayland using sway instead of figuring out the complicated hoops to jump through to start X.org from the console <vdv>i used to use the package sx instead of xinit with i3 -c $LINKTOCONFIG in $HOME/.config/sx/sxrc <ytc>vagrantc: yeah i would love to. but old thinkpads don't get on well with wayland. :) <vdv>and run sx automatically on tty1 login <vdv>intel just runs smooth on wayland <ytc>caps lock wasn't working for me for some reason. <vdv>maybe setting the input correctly in the swayconfig with input { ... } ? <vagrantc>i do have to configure sway's keyboard layout in sway's configuration <ytc>i mean, caps lock's led wasn't working. <vdv>it ignores setxkbmap because it's xorg stuff <vdv>maybe look into libinput for that issue <rekado_>on c-u-f why do we have this odd mix of pipewire 0.2 and 0.3 in different packages? <ytc>i have another machine with wayland, flatpak, pipewire, chromium, systemd. but on my thinkpad it's xorg, portage, icecat, openrc. they're completely opposite. :D <vagrantc>rekado_: they're both present in master too <vdv>or to make ytc happy make 0.3.40 the new default <vdv>i like bleeding edge like you :P <civodul>rekado_, cbaines: "vacuum" still running, so i'm not sure what to do; thoughts? <vdv>try to update sway to 1.6.1 meanwhile xDD <civodul>apteryx: wait, there's a Rust patch already? <civodul>i could turn off cuirass and see if it helps? <jpoiret>it needs the newer wayland-protocols, that's why it's there <vdv>wooop wooop @ jpoiret xD <rekado_>another thing to do on c-u-f (if it doesn’t cause world rebuilding): replace jack-1 with jack-2 wherever possible <ytc>what does "c-u-f" mean? <unmatched-paren>it's a branch for updates to packages that would require rebuilding loads of things *vagrantc wonders why sway wasn't updated on master... <jpoiret>vagrantc: i preemptively answered that right above :p <unmatched-paren>so that the CI doesn't have to keep rebuilding everything every time a core package is updated <civodul>rekado_: Cuirass turned off, crossing fingers... <jpoiret>unmatched-paren: and so that people don't end up having to locally build everything *rekado_ crossed fingers, typing hurts now <unmatched-paren>the tree-sitter error looks like something related to cargo workspaces <unmatched-paren>error: manifest path `/tmp/guix-build-tree-sitter-0.20.1.drv-0/source/Cargo.toml` is a virtual manifest, but this command requires running against an actual package in this workspace <unmatched-paren>command "cargo" "package" "--no-metadata" "--no-verify" failed with status 101 <unmatched-paren>builder for `/gnu/store/gcxcx0m2ws9kj3lbs2xs4grbi3dhjzxl-tree-sitter-0.20.1.drv' failed with exit code 1 <ytc>unmatched-paren: is it enough for me to read guix manual to catch up with guix devs and learn guix jargon? <raghavgururajan>vagrantc: I tried updating sway on master, but newer versions of it require seatd service. <ytc>raghavgururajan: thank you very much. <vdv>seatd is in the repos @raghav <vagrantc>Building the following 1519 packages would ensure 2767 dependent packages ... does that mean 2767 packages, or 2767+1519 packages? <cbaines>civodul, I do find it odd that it's taken so long, it does appear to be doing something though, it's not stuck <vdv>just add it to the inputs <jpoiret>raghavgururajan: only libseat, which can use libelogind as a backend <vdv>thats better @ jpoiret <cbaines>I'll try and VACUUM the database on bayfront to see how long that takes <rekado_>vagrantc: I’m embarrassed to admit that I never understood what this message wants to tell me. <vagrantc>rekado_: well, you're pretty new here, it's ok. :) <ngz>unmatched-paren: OOC, have you looked at the tree-sitter patch already? <ngz>unmatched-paren: you might be re-inventing the wheel. <raghavgururajan>ytc: Since you are using X200, you don't have to modify xorg-server-service-type in the snippet I sent you. <vdv>against all those emacs hypers xD <ytc>i always want to help and contribute to the free software projects on github or gitlab. but i don't know where to start. those devs have plans on their minds about the project but i don't know them. same goes for guix for example. how can i join that development network? <rekado_>ytc: Guix has a Contributing section in the manual. <jpoiret>you can subscribe to the mailing lists (guix-patches, bug-guix, guix-devel, etc...) and hang out on IRC <rekado_>contributing to Guix is perhaps a little easier than contributing to other projects, because you can add whatever package you feel is missing (as long as it’s free software). <rekado_>I’ll go ahead and say that I don’t recommend subscribing to guix-patches and bug-guix. It’s too busy. <unmatched-paren>vdv: i was surprised that there seems to be more viers that emacsers here :) <ytc>raghavgururajan: i actually have to, because it uses vesa driver by default. <rekado_>unless you intend to stay submerged in a deluge of Guix development. <vdv>i think there a hell lot of more emacsers here unmatched xD <vdv>but the vimers stay strong <jpoiret>rekado_: i said subscribe, not read every mail :p but yeah, reading guix-patches takes a lot of my time (and I don't even review patches! how do they even do it) <civodul>cbaines: yes, stracing the sqlite3 process shows it's doing something <rekado_>unmatched-paren: it took me three attempts to get Emacs <vdv>i used it a few days and it feels slighty more performant with daemon mode @ unmatched <jpoiret>you can assume that everyone here who doesn't explicitely says they use vim uses emacs :) <vdv>but vim is so much more lightweight <rekado_>the third attempt cooincided with learning dvorak, so I felt like a fish out of water anyway <unmatched-paren>i keep thinking 'ah it can't be that bad, i'll just install it and give it another shot' <rekado_>I don’t know about ‘lightweight’. Emacs isn’t particularly heavy. <civodul>jpoiret: glad i'm not the only one to find it overwhelming :-) <ytc>rekado_: same. the first thing i did after learning dvorak layout was switching to emacs. <vdv>maybe try vim with a few plugins a few days and you will new, emacs is a bit clunky compared to vim <cbaines>civodul, this issue just reminds me of the need to rewrite the daemon in Guile, that would enable for addressing some things with the Guix Build Coordinator as well <rekado_>a common misunderstanding of Emacs is that all these features mean ‘bloat’ <jpoiret>I had been a vimer for a couple of years when i made the transition 5 years age with spacemacs. I think that going vanilla emacs over the distros like spacemacs and doom is better to learn though, you're also less likely to fight against the ecosystem <ytc>unmatched-paren: compile it without toolkit support if you wish. <raghavgururajan>ytc: By default, yes. But in the snippet I pasted, it is set to use intel driver. <jpoiret>cbaines: just a small side project for the week-end i see <ytc>raghavgururajan: i'm using intel driver either. <rekado_>unmatched-paren: I didn’t suggest anything to the contrary. Learning a new layout, however, made my brain accept the weirdness of Emacs. <cbaines>jpoiret, not quite, but the sooner it's started, the sooner it'll be usable... <jpoiret>do you think we could also consider having non r-xr-xr-x permissions for files in the store as well? <jpoiret>i'm getting ahead of myself here i suppose, but it could be beneficial for things such as secrets, and embedding them in software (eg LUKS keys in initrd) <ytc>i don't want to seem selfish, but i'm glad that emacs filters people who are "extreme minimalist". <vagrantc>i think /gnu/store is assumed to be fully public ... but maybe it would make sense to have a store-like thing "e.g. secret store" that was restricted? <raghavgururajan>> rekado_: a common misunderstanding of Emacs is that all these features mean ‘bloat’ <raghavgururajan>I haven't used emacs extensively. It'd be great if emacs had baseline text-editing features and moved other features as installable modules (emacs-foo). <vdv>i don't think they are filteres ytc :D it's just a taste <vagrantc>i vaguely recall mentions of a "secret service" <jpoiret>vagrantc: well, it is assumed to be that way for now. I don't personally see a reason for files in there to REQUIRE having those permissions, but I'm far from an expert on the consequences this would have <rekado_>raghavgururajan: I never quite understood that. An extra .el file here or there doesn’t hurt anyone. It doesn’t delay startup times either. <vdv>but i'll could never use emacs without vim keybind or some plugin that adds the keybindings <vdv>the default is aweful <jpoiret>raghavgururajan: I agree. Many included packages aren't very satisfactory <vdv>nano is more used than emacs btw xD <jpoiret>vdv: so you say, but they do work pretty well imo, after going through the evil phase <vdv>yep, but without evil it's unuseable longterm xD <raghavgururajan>rekado: I meant emacs could have been like nano out-of-the-box and could be easily extended with emacs-packages. <rekado_>raghavgururajan: I’ve never used rmail. The fact that it’s included in the distribution doesn’t hurt me, though. <vagrantc>jpoiret: for one, guix publish would have to be thoroughly audited <ngz>raghavgururajan: that is not the point of Emacs. It shouldn't be seen as a mere text-editor. It is a consistent system including text-editing facilities. <ytc>vdv: i know. but i think they don't want to interact with emacs because of these reasons. which makes me happy because that keeps the aura of emacs safe. <jpoiret>vagrantc: yup! i don't think it'd be a blocker though, we'd just need to think about some new interface for it <vagrantc>jpoiret: i think it's such a core assumption in the design of guix that the store is publicly readable and basically read-only <vdv>that would be cool @ raghavguruajan <jpoiret>ah, i'm not saying we should add a writable permission in there, only remove some! <raghavgururajan>ngz: That's true. I think it would be nice if emacs was like nyxt. Focused on one domain. <jpoiret>raghavgururajan: but then i wouldn't be able to read guix-patches and reply inside emacs, right? <vagrantc>jpoiret: my guess is it would be safer to try some alternate approach <jpoiret>oh yeah, if we're only talking about having all those packages inside emacs source code, i agree with you <rekado_>raghavgururajan: I had to install my mua. <jpoiret>but you can still use emacs without those packages having any impact. Simply don't use them, and they won't even be loaded for the most part <rekado_>many packages that belong to the distribution are part of GNU Elpa. But for historic reasons a lot of packages come with the default installation. <vagrantc>i literally switched to using emacs after using vim for 12 years in order to use notmuch as a mail client ... and *then* started using it as a text editor after a while :) <civodul>cbaines: rewriting in Guile would unlock quite a few things, indeed <unmatched-paren>it is possible to turn vim into an emacsy kitchen sink kind of thing, i'd be surprised if there wasn't a vim-email-reader, vim-irc, etc. plugin lying around somewhere <jpoiret>it'd be possible, for sure, but here is where emacs shines: emacs lisp! :) <vdv>jep but why should i use vim for irc if there is irssi :D <vdv>(i get it for the git plugin in emacs.. :D but there a fugitive plugins for vim also) <unmatched-paren>jpoiret: yeah i do prefer elisp over viml tbh, but that's not enough to convert me <rekado_>civodul: I forgot the IRC handle of the person who worked on the Guile daemon. Have you heard from them in recent months? <vdv>just polemic.. it would be cool if there would be a tiny tiny emacs build and include the other things as addtional plugins <ajarara>after a (use-modules (guix gexp)) I can quote things into gexprs but can't unquote them. The reader macro for ungexp is read though: #$#~(plain-file "foo" "foo-contents") fails with `error: ungexp: unbound variable` <ajarara>I'm trying to get a store name for the plain-file <ajarara>#~(plain-file "foo" "foo-contents") returns a gexp just fine <unmatched-paren>the tree-sitter patch changes node so i guess we won't be getting it in master for a while <rekado_>unmatched-paren: it could be changed to have a custom node package <vdv>@unmatched-paren to the topic lightweight emacs, maybe look at zile? <unmatched-paren>rekado_: yeah, i'll try and adapt it, but i'm not sure how successful i'll be <rekado_>but I find that lightweight emacs clones are missing what I love most about emacs. *rekado_ builds c-u-f gtk on the new aarch64 nodes <vdv>but zile got the language and plugin compatiblity instead of mg i think, or is it wrong? <unmatched-paren>vdv: tbh i just generally prefer the modal vi style so i'll probably be sticking with that editor family for now <unmatched-paren>hmmmm the nvim-treesitter plugin does not use system grammars (it installs them somewhere in ~/.local/share/nvim), so those node patches might not actually be necessary for me <ngz>unmatched-paren: it still needs review, if you want to try it. <jlicht>missing some context; why would we not push node changes to master? <unmatched-paren>i'm compiling tree-sitter with the recipe from that patch right now :) *jlicht has been pushing node changes to master \o/ <unmatched-paren>really? i'd have thought node would be classed as a core package that must be updated on c-u-f <rgherdt>jgart: regarding your question about alternative ways of defining records... I was reading the R6RS standard and found out they have that interface you showed from tlsp <jlicht>I guess _technically_ it's getting close to that, but none of the important packages depend on node <rgherdt>(import (rnrs records syntactic)) (define-record-type point (fields x y)) <jlicht>with ungoogled-chromium-wayland being on of the exceptions <notmaximed>ajarara: it's the other way around: (gexp->script #~(system* "cat" #$(plain-file ...))) <notmaximed>That can be build and turned into a /gnu/store/... string by some procedure, but I always forget how <rekado_>unmatched-paren: you can run ‘guix refresh -l thepackage’ to see how many packages would be rebuilt as a consequence of modifying ‘thepackage’ <unmatched-paren>...and i think (think) i know why, the make-lua-lpe procedure in lua.scm _always_ uses `lua` as an input (not `lua-5.1` as would be expected for lua5.1-lpeg) *vagrantc somewhat foolishly tries building core-updates-frozen on the pinebook-pro <rekado_>latest release of weston still needs pipewire 0.2 <cbaines>civodul, VACUUM on bayfront finished, I ran a VACUUM INTO though. It did reduce the 5.4G file to 155M though! <cbaines>I'm going to run VACUUM without INTO now... <rekado_>what’s the difference between VACUUM and VACUUM INTO? <civodul>cbaines: beware, my sqlite3 process is still running <cbaines>VACUUM INTO basically copies the database to a new file <unmatched-paren>why is the nvim cmake looking in ALL the /gnu/store/blah-lua-something/(share|lib)/ directories for lpeg.so and lpeg.lua?! <cbaines>VACUUM is similar, because it writes the database out to a temporary file, then replaces the database with that file (but in a safe transactional way) <civodul>it's kinda weird that a concurrent "vacuum into" ran into an hour or so (?) while the other one is still running <unmatched-paren>it should be just looking in /gnu/store/blah-lua5.1-lpeg/(lib|share)/ <cbaines>civodul, I was testing on bayfront, did you try something on berlin? <rekado_>unmatched-paren: maybe it uses the Lua search path? <unmatched-paren>it's trying to look in snip/lua5.1/blah when it should be looking in snip/lua/5.1/blah! <unmatched-paren>ok if i update my patched-make-lua-lpeg procedure to write to lua5.1 instead of lua/5.1, it finds it! <rekado_>good progress! So where does it get the idea to look in lua5.1? Is this the output of some lua config command? ***stikonas_ is now known as stikonas
<unmatched-paren>nvim uses cmake to build itself, and checks for necessary lua packages before building, so i presume the problem is in some cmake script in the nvim source <unmatched-paren>i wonder if it's actually guix's lua-lpeg and lua-mpack packages that are at fault... those are so far the only two that don't work <rekado_>also check users of these packages. Do *they* need patching or are they fine with the locations pkg-config returns? <rekado_>looks like pkg-config should set the PC_ variables that determine the search locations. <vagrantc>hmmmm... if i run "guix time-machine" multiple times with the same revision, it still takes a long time to to do anything ... is it plausible to somehow cache the results from the first "guix time-machine" somehow to speed that up? <unmatched-paren>gnu/packages/lua.scm:730:2: warning: 'generic-html' updater failed to determine available releases for lua5.1-lpeg <rdrg109>[Q] I'm trying to perform the system installation in a laptop, and I've failed three times. I'm thinking in creating a post in the mailing list. Is there a log file that is generated in the installation that I can share in my post so that people can better know the steps that I followed (e.g. partition information, selected language, selected desktop eventironment, etc.)? <rekado_>vagrantc: I thought it would cache the inferior it built in ~/.cache/guix/inferiors <rekado_>rdrg109: how does it fail? Three times the same failure? <vagrantc>rekado_: all i see is a last_expiry_cleanup in that directory <unmatched-paren>apparently nobody currently uses 5.1 mpack, which explains why if this is an issue it wasn't caught <vagrantc>Computing Guix derivation for 'aarch64-linux'... \ is where it spends a lot of time ... it's reasonably fast once it gets past that <rekado_>vagrantc: hmm! I’ve got two cached inferiors there, probably from the last few times I ran ‘guix time-machine’. <vagrantc>rekado_: this is probably my third time in a row running this ... <rdrg109>rekado_: First time, the installation wizard showed me the succesfull message, but when my laptop booted, I was brought to the grub shell. Second time, again, successfull message, but "Operating System Not Found" is being shown (this time I answerred "Format the partition?" with "Yes" in the efi partition <vagrantc>if guix-daemon is passed --max-jobs ... will it just ignore the client? <vagrantc>i have guix-daemon --max-jobs=5 ... and guix time-machine --branch=core-updates-frozen -- guix system build --max-jobs=2 ... and it's building five things concurrently ... <unmatched-paren>i'll try building lua mpack the old fashioned way and seeing what it produces ***lukedashjr is now known as luke-jr
<vagrantc>should i pass max-jobs to guix time-machine ? <cbaines>civodul, I've now also done a VACUUM on the actual bayfront guix-daemon database, and yeah, it's now much smaller. I'd suggest letting the VACUUM on berlin run to conclusion, as it seems to do something at least