IRC channel logs


back to list of logs

<djeis>Anyway, this just reduces the problem to the simplest guile expr to get an output path of a package.
<djeis>I think I might have a better solution to this tho.
<djeis>But it's unrelated, so I suppose we're done for now :)
<nckx>I'm very curious, since I'm also trying some things that didn't work.
<nckx>Do tell.
<djeis>Ah, no, didn't work the way I wanted...
*nckx too tired for this, → 😴💤
<djeis>I was thinking we could make a profile and use that in the env vars instead, but doing it that way complicates other stuff.
<djeis>Rather, we were implicitly making a profile anyway and I was going to try to get a symlink to it.
<vagrantc>hrm. not quite sure i understand the relationship between cl-containers and sbcl-cl-containers
<vagrantc>gnu/packages/lisp-xyz.scm:(define-public ecl-cl-containers
<vagrantc>gnu/packages/lisp-xyz.scm: (sbcl-package->ecl-package sbcl-cl-containers))
<vagrantc>oops... that's a different confusingly related package
<vagrantc>gnu/packages/lisp-xyz.scm:(define-public cl-containers
<vagrantc>gnu/packages/lisp-xyz.scm: (sbcl-package->cl-source-package sbcl-cl-containers))
<vagrantc>though they seem similarish
<pkill9>i wonder how many security holes guix has from building a malicious guile file
<pkill9>is privilege escalation possible through this?
<jacobk>How can I get the source code of a Guix package? I think I might have found nonfree software (GPL-licensed firmare missing source code) in Guix.
<jacobk>Specifically, I suspect the rtl8812au-aircrack-ng-linux-module package includes this file:
<djeis>jacobk: You can use the --source flag to guix build, IIUC.
<jacobk>ndeed it seems the same file is in the Guix repository's source.
<jacobk>s/ndeed/Thanks, i/
<jacobk>I guess I should open up a bug report then?
<jacobk>(bug report submitted, not 100% sure how the system works though)
***f1reflyylmao is now known as f1refly
<SamIaM>hey guys i am missing make command and if remember it is in base-devel but cant find it in repo
<Cairn>SamIaM, are you in the right channel?
<Cairn>base-devel's an Arch linux package IIRC
<SamIaM>Cairn: Yeah and sorry for no clarification, I wantto use suckless dwm and tryng to run make install command so thought the package would be named similarly in guix
<Cairn>dwm is packaged in Guix. Why do you need to use make install?
<Cairn>Have you run `guix install dwm`?
<SamIaM>Since I am pretty new seemed easier to git clone it from then mess around config
<SamIaM>I dont know C :(
<Cairn>That's why `guix install dwm` would be so easy
<Cairn>You're not making any modifications to dwm, it sounds like?
<SamIaM>wanted to test out few patches for ease of use for sure, so is it still doable as repo install? :D
<Cairn>Well, as one option, you could patch dwm in your own git repo, then use that repo as the source for the package rather than the usual source
<SamIaM>That would be great and I am hoping to build to that point as soon as possible :D So when I copy from git repo I would still need make command right?
<Cairn>Nope, guix will handle the whole building process for you
<Cairn>This is what you'll find useful
<SamIaM>Thanks a bunch will check it out :D
<Cairn>So, in theory, you should be able to type `guix package -i dwm --with-source=[your-repository]`
<Cairn>Oh, I guess, you could simplify that to `guix install dwm --with-source=...`, since install's just another name for package -i
<Cairn>I'm also new to this; trying to remember all the details.
<Cairn>Yep, I just cloned "git://" to the directory "custom-dwm" then I ran `guix build dwm --with-source=~/custom-dwm` and it worked.
<aristetix>Speaking of dwm, I can't get mine to install. It fails at stage 'validate-runpath' for some reason. I have it building with #:validate-runpath? #f, but using readelf -d shows that there is no RUNPATH on the executable.
<trevdev>o/ Hey Guix, anyone here use StumpWM?
<Cairn>It's wm night in #guix
<apteryx>nckx: fyi, turbovnc's vncviewer works after all. it was a java issue:
<trevdev>If I want to use stumpwm, but install modules in the user-space, what's the best way to go about that? I'm a CL novice. I can asdf the modules if I install them with root, but not with guix home
<Cairn>Good character limit for (synopsis)? Should I keep it under 50, or I can I go up to 70?
<lilyp>Cairn: if you need a new line, you should stop
<lilyp>other than that less is usually better
<SamSam>Cairn: Thanks a bunch will test it out :D
<SamSam>oh and just for future cases what package to install to hace make command?
<Cairn>SamSam: The issue with using make, that Guix doesn't place libraries where it normally expects. In my brief experience, make seems useless, not only because it normally won't succeed, but also since it's circumventing the entire point of Guix.
<Cairn>I recommend learning to work with Guix for all your package building needs.
<Cairn>But the make command is, of course, in the package called "make"
<Cairn>Which you can learn by typing "guix search make"
<Cairn>Heed my warning though! Use the package system; don't try to use make on its own!
*Cairn shakes finger
<SamSam>Haha noted and will do, thanks :D
<podiki[m]>trevdev: I'm using stumpwm, recently came back to it. for the contrib modules for now I just have the repo cloned somewhere in my home folder and point stumpwm to that
<podiki[m]>stumpwm is the guix package, though at latest git commit
<Spawns_Carpeting>is it normal for guix pull to not operate in parallel? it is only using a single core on my machine and taking a really long time
<Spawns_Carpeting>my main system is gentoo so I know that its not building as fast as it should be
<atka>afaik its just the way it is, it is annoying to see 15 threads sitting idle :(
<Spawns_Carpeting>awh yeah that's a shame. i have 24 threads that it could be using
<atka>the equivalent on nix I hear takes about 5 seconds vs 5 minutes for guix
<Spawns_Carpeting>at the very least some of these makefiles should support building with multiple threads "make -j$(nproc)"
<podiki[m]>building in general will use all threads, unless disabled for some reason (like reproducibility)
<podiki[m]>e.g. guix build or install where a package is being built locally
<atka>podiki[m]: can you elaborate on the reproducability aspect? does building with more threads affect the resulting binary in some way?
<podiki[m]>sometimes, apparently; I don't know the particulars but there are a few that are built with a single thread for this reason
<podiki[m]>maybe one of the webkits, qtwebkit or something? i remember it takes forever since it will only use one thread purposefully
<atka>very interesting
<atka>I wouldn't have expected that
<podiki[m]>i wouldn't have expected half the stuff with reproducibility problems, like date/time being encoded in there
<podiki[m]>or just general nondeterministic stuff going on
<podiki[m]>just a random one I found: (not much info there, but as an example)
<atka>cool, thanks
<podiki[m]>other times builds fail with too many threads
<podiki[m]>anyway, there are plenty of experts here on reproducibility, at least at other hours, that I'm sure can give you some interesting info
<Spawns_Carpeting>podiki[m]: i am using the guix VM image in qemu, and ran "guix pull --cores=24 --no-substitutes"
<Spawns_Carpeting>is there something else i need to pass?
<podiki[m]>I don't think you even need that, though I'm not sure what guix pull itself will do with more cores/threads
<podiki[m]>you can also run more jobs, though generally anything that needs building will use all threads it can
<podiki[m]> see cores and max-jobs, but like I said, default is to use as much as it can
<Spawns_Carpeting>i set --max-jobs=24 as well and its still only using 1 core and running 1 job
<podiki[m]>if you are talking just about guix pull, I don't know that it can do more
<atka>yeah that's the way it is, reconfigure will utilize them though
<podiki[m]>really those are for actually building packages (which is normally what takes the most time, if you aren't getting substitutes)
<Spawns_Carpeting> oh yeah i forgot to mention i disabled subsititues
<Spawns_Carpeting>oh i did mention that
<podiki[m]>the only time you'd want to use cores is to maybe reduce what it uses, and for max-jobs to build more at the same time if you are say have 24 cores and want to use 12 per
<Spawns_Carpeting>i will try not setting --cores at all
<podiki[m]>so yeah, guix pull is not where your time will be spent, it will be spent on the actual building
<atka>though pulling can still take minutes, doesn't guix build itself every pull?
<podiki[m]>yes, I wouldn't. maybe with 24 cores you could do like max-jobs=2 or something, so you'd be effectively doing like 12 cores each job
<podiki[m]>it would also download itself, if you have subs on and are available, but still needs to build a few things locally
<podiki[m]>on my 12 core guix pull with subs only takes a minute or a few at most
<podiki[m]>but upgrading/installing packages will take longer
*podiki[m] off for now, good luck! patience :)
<atka>thanks podiki[m] have a good one
<Spawns_Carpeting>thank you podiki[m] and atka
<conjunctive>Hi, looking to create a simple dev environment for Ruby & the ruby-pg gem. In the guix.scm file I've set the #:ruby argument on the ruby-build-system to a recent version (e.g. ruby-3.1), but after running guix shell and IRB I see "Ignoring pg-1.3.5 because its extensions are not built."
<conjunctive>I then tried using package-input-rewriting on ruby-pg to further override which ruby package was being used (e.g. ruby-3.1), but this only led to build failures (with #:deep? #t) or the exact result as before (with #:deep? #f).
<conjunctive>dthompson has a great blog post on packaging gems with Guix. The only part I'm missing is how to constrain the Ruby version and have extensions be built for it.
***Dynom_ is now known as Guest4076
<conjunctive>Updated a testing library dep and added a clause for it to package-input-rewriting, seems to have fixed it! Would be interested if anyone knows of an alternative approach.
<abrenon>hi guix
<sneek>Welcome back abrenon, you have 3 messages!
<sneek>abrenon, nckx says: I think this is supported by git-checkout (which would replace your entire origin).
<sneek>abrenon, nckx says: This ‘just’ checks out the repository on the host side, using any SSH authentication information present there. Kind of like local-file. That said, the functional store model doesn't play well with some kinds of huge data sets.
<sneek>abrenon, nckx says: This is long & mainly about channels, but:
<abrenon>nckx: thank you so much !
<abrenon>also, how large is "huge" ? I'm talking a couple hundred megabytes of text, here
<florhizome[m]>I might have asked this before in a similar way, what speaks against having Desktop environments as Home Services?
<pkill9>what do you mean what speaks?
<rekado>pkill9: “what speaks against doing this” = “why should this not be done”
<attila_lendvai>are there compiler macros in scheme? i.e. a macro that can optionally optimize a function call site. my highlevel goal is to have a (maybe-value v default) function that only instantiates its default value when needed.
<attila_lendvai>but at the same time retains a functional API
<antipode>attila_lendvai: I'm not sure what you mean, exactly, but (if you know how to) it's easy to, say, write a 'const*' macro that turns (const* #false) -> predefined-const-false-variable (const* #true) -> predefined-const-true-variable, ... and for other things expands to (const exp).
<antipode>That would be purely macro / expansion though, there is no interaction with the compiler and optimiser
<antipode>(where (define predefined-const-false-variable (const #false))
<attila_lendvai>what i want is, basically, a user-defined transparent optimization for a function call that can bail out, and that doesn't change the semantics of the function. (the equivalent of a so called compiler macro in CL; further web search suggests that it's not part of scheme, but some schemes provide it in a non-standard way)
<drakonis>attila_lendvai: i think mit scheme is an implementation that provides that
<rekado>I would like to change an existing service so that it does not automatically start.
<rekado>the system service provides an extension to the shepherd-root-service-type
<rekado>IIUC modify-services doesn’t let me directly manipulate the shepherd service
<rekado>do we really lack a simple way to modify a shepherd service?
<drakonis>attila_lendvai: you might like the new compiler backend being written for guile
<drakonis>i suppose we don't
<drakonis>modify-services only seems to work with a list of services
<attila_lendvai>drakonis, i don't get your reference, and the websearch is pretty empty. is there work to add the MIT compiler as a backend for guile?
<drakonis>ah, apologies, i should've said it was a prescheme inspired backend
<drakonis>not mit scheme
<drakonis>prescheme's design is fairly interesting
<drakonis>it should be more than capable of having compiler macros
<drakonis>i think, no promises.
<drakonis>still waiting to play with it
<drakonis> and
<drakonis>is this the one?
<drakonis>ericson2314: any updates?
<davidl>General idea: how about writing a script that does package-imports for low-dependency projects? Wouldn't it be easy, actually, to traverse packages on for example, look at package.json for each package, and if there are no dependencies mentioned, then attempt to build it, and if successful, it can be saved to a package module node-unsorted.scm? Then make a quick sanity check and add a bunch to guix master. Saving some time for
<davidl>everyone's next packaging project.
<ericson2314>drakonis: in general?
<ericson2314>Not yet
<ericson2314>I am hoping to shop it around a bit more this side
<ericson2314>also, an idea I'd like your feedback on
<apteryx>uh, why is (guix build utils) fair game in snippets but not (guix build union) ?
<drakonis>oh, do tell.
<ericson2314>I have been meaning to open a Nix RFC about exposing a no nix-lang "mini nix", what if I sent the message to the mailing list and opened the RFC at the same time, cross-linking then?
<drakonis>what does a mini nix entail here?
<ericson2314>I want to show the nix community guix could be interested in this, and I want to show the guix community that nix is serious about decoupling libstore and daemon --- this isn't some weird attempt to canibalize guix users or whatever
<ericson2314>a mini nix would have just those CLI commands which don't need libexpr or libflakes
<ericson2314>(old and new CLI)
<ericson2314>so you can do `nix daemon` and `nix show-derivation`, but no `nix eval` or `nix flakes`
<ericson2314>So it involves splitting the CLI stuff (I have draft PR)
<ericson2314>so that one can build a nix binary without those upper layers (which we regressed and lost)
<ericson2314>It also acts as an integration test to make sure that we don't get such regressions in the future
<ericson2314>nckx: ^ curious what you think about the "both messages at once" stuff too
<drakonis>that's something i'm not too certain whether the mailing list would care a whole lot about that
<drakonis>it is a very specific nix problem that guix has largely insulated itself from by not having to deal with nix changing
<drakonis>it would however be interesting if it worked as a daemon replacement
<drakonis>at least one that's sufficiently well understood
<drakonis>a temporary replacement
<florhizome[m]>rekado pkill9 yeah thats what i meant. Since guix home exists it would make more sense to have them in userspace imo
<drakonis>at this point i'm not even sure if you could get it to function with the existing one
<drakonis>existing "fork"
<pkill9>yea thats why i like sway, i can installa nd run it from my profile
<pkill9>not sure if that can be done with monolothic desktop environment like gnome tho
<drakonis>the delta between both has widened quite a bit
<attila_lendvai>drakonis, prescheme is interesting, thanks for the pointer!
<drakonis>for the port
<drakonis>we also have an irc channel for this kind of stuff over #guile-steel
<florhizome[m]>pkill9 yeah basically my question is why not^^
<Cairn>Morning guix. I'm getting an error in a package build I'm working on suggesting I "set the environment
<Cairn>variable GUILE_WARN_DEPRECATED to detailed". How should I do that within the guix build environment
<florhizome[m]>What kind of package is it? I know this Message from Go packages
<Cairn>Yep, it's a go package.
<florhizome[m]>but there you can ignore it, it's Not the actual error
<Cairn>Hm. Well I'm trying to get this package build to succeed, so I thought that info might be useful
<Cairn>Unless it's irrelevant and it's failing for a different reason
<florhizome[m]>Yeah it is usually
<florhizome[m]>I suggest looking at the Output above the Go env Output
<Cairn>I have an "uncaught exception" error, but I feel like it tells me nothing other than where the build failed
<drakonis>is ludo out on vacation or something?
<apteryx>that's personal information ;-)
<drakonis>i wanted to ask him
<drakonis>not about that, anyways.
<drakonis>havent seen him in a while
<apteryx>I'm sure they'll jump back into action soon
<apteryx>it's better form anyway to ask openly in guix-help, guix-devel, or here, so that hopefully the burden can be shared :-)
<examors>Hey Guix! Is there any way to identify shadowed package variable definitions? I have 'define-public'ed the same names multiple times (as a result of a series of recursive imports), but I'd rather not try to find them all by hand :P
***linj[m] is now known as linj
<pkill9>sometime I will set up sway so it launches applications ina container associated with the workspace you're on
<pkill9>so certain workspaces will be environments
<Cairn>Alright. So for a go project, do I need to package all the dependencies as well?
<yuu[m]>Cairn: afaik for using the any import/build-system you need to do that yes, since guix official tooling require full bootstrap
<Cairn>Hm. Can you submit multiple commits in the same patch? Or should I squash them all into a single commit?
<demitasse>do app images work on Guix? or only flatpaks?
<mgd>Hello, I've recently been getting an error saying error: unsupported manifest format when trying to install anything. I just want to understand what the error means
<pkill9>not by default demitasse
<pkill9>but I made a script to make them work
<demitasse>@pkill, awesome, thanks for sharing!
<two[m]>the string "while fetching ~a: server is somewhat slow~%"
<two[m]>is it "while we were fetching" or "while we are fetching"
<two[m]>* are fetching"?
<unmatched-paren>two[m]: think of it as "problem was detected while fetching ~a"
<unmatched-paren>where [problem was detected] is replaced by "warning:" I guess
<two[m]>so it's "were"
<nckx>English should follow its own suit then and ‘is’ → ‘was’.
<nckx>jacobk: I just popped in to say thank you for reporting the Realtek unfortunateness, because I forgot to say so in my reply. Thanks!
<gnucode>looks like XMPP supports adding in contacts addresses, email address, phone number, etc...
<gnucode>what program can I use on guix to do that? eg: I have cwebber 's JID. How would I add his email address to my XMPP contact I have of him?
<cwebber>gnucode: I'm she, not he
<cwebber>I happen to have the same JID as I do email
<cwebber>also I'm not sure what this has to do with #guix
<gnucode>sorry cwebber that's my mistake. I meant she.
<gnucode>I was just wondering if guix had packaged an XMPP client program that I could use as my generic contact book.
<gnucode>emacs' bbdb is really hard to get to work (my opinion) little documentation. and I routinely lose break my installs of whatever distro I happen to be using at the time. XMPP ( is the first contact manager that I trust. I suppose I could ask the guys.
<gnucode>sorry again cwebber
<cwebber>it's ok gnucode, thanks for the apology
<cwebber>I use dino currently, though I thought pidgin was nicer. dino interacts with gnome contacts
<cwebber>there's also an xmpp mode for emacs I think
<cwebber>doesn't look like it's packaged for guix
<acrow>nckx: Thank you for your assistance yesterday. This works to build mkcue from the debian sources. I'm interested in improving this. The way I eventually accessed the patches using find-files is very awkward and fails to build on the availability of the native input. Anyone care to comment?
<cwebber>but probably could be
<cwebber>I used to have emacs set up to send notifications to xmpp
<gnucode>cwebber I am on the dino train too! It's the most stable, easiest xmpp program that I have found! Well Chatty is pretty nice too.
<gnucode>I used to use jabbel.el, but the last time I tried to use it, bits of it were broken. I'd have to ask in #emacs if it even still works...
<cwebber>completely separate topic:
<cwebber>goaccess, which is packaged in guix, is incredible.
<cwebber>it can generate *amazing* static html metrics from nginx logs
<singpolyma>gnucode: you want to store other vcard details in your xmpp roster, basically?
<cwebber>(I have mixed feelings about metrics, it's good to anonymize them)
<singpolyma>There is a xep for that. I plan to implement it in cheogram Android eventually
<singpolyma>gnucode: wgreenhouse has a fixed version of jabber.el
<gnucode>singpolyma: yes !
<gnucode>singpolyma what's the XEP?
<singpolyma>gnucode: it's part of the vcard4 xep
<gnucode>singpolyma: how much $$ would someone have to pay you to start working on this ASAP ? or in other words, how much would a compentent developer charge to implement that XEP ?
<singpolyma>gnucode: hmm. Well, depends what "implement it" means to you. My intent is to make an optional Android contacts sync kind of thing. Think DAVx but using XMPP
<singpolyma>At the MBOA rate the whole thing would probably be no more than $10k? That's a guess
<florhizome[m]><Cairn> "I have an "uncaught exception..." <- Yeah go is not very helpful there. I wonder If this would be possible to improve
<Cairn>florhizome: I think this one was on me
<Cairn>Seems like that message was further inside where the actual message was caught
<Cairn>Turns out I just needed to fix my #:unpack-path
<Cairn>I've got about a dozen dependencies for this program which are unpackaged in Guix. If I'm gonna package them all, should I submit them as separate patches?
<rekado>Cairn: yes.
<rekado>Cairn: alternatively, make the branch available somewhere
<Cairn>Alright. =)
*Cairn cracks knuckles
<rekado>it will be easier on reviewers if you could chunk it up a little
<Cairn>That makes sense
<rekado>cnx: I’ll try to apply your patch later tonight
<pkill9>some day i will chop up my git commits, when i know how
<rekado>use ./etc/committer.scm
<gnucode>singpolyma wow! thanks for the honesty!
<cnx>thanks, rekado!
<MohammadSalehKam>Hello everyone
<MohammadSalehKam>Why gnome 42 does not packaged for Guix yet? Is there any problem with it?
<unmatched-paren>MohammadSalehKam: It's just a question of resources.
<unmatched-paren>Nobody has done it yet, and there aren't many people who would/could.
<pkill9>would guix accept an extension that lets you download the extensions from the chrome website?
<unmatched-paren>pkill9: interesting question... I'd think "probably not", since the vast majority of chrome extensions are nonfree
<vagrantc>pkill9: highly doubtful
<mroh>mbakke: Thank you very much for your superb blog posting! It touches my soul and speaks from your heart (to mine)!
<gnucode>mroh can you send me a link to mbakke's superb blog posting?
<gnucode>mroh: thanks
<mroh>gnucode: yw!
<gnucode>mbakke: I would encourage you to post some of that latest blog on the official guix blog post. There's a lot of good marketing materials there!
<acrow>vagrantc: Have time to dispense advice?
<ericson2314>drakonis: ah sorry just saw now
<vagrantc>acrow: i could fit it in :)
<ericson2314>drakonis: I think maybe I should talk to HPC use case more
<drakonis>they already are aware of the deficiencies here
<ericson2314>Sure they are aware of the problems
<drakonis>so much that there are some workarounds involving skipping the nix daemon
<ericson2314>But see how interested they are in interop as part to more solutions
<drakonis>ah, i see.
<drakonis>though i find that they might think guix will be the losing party in the bargain
<ericson2314>I need to understand that better
<ericson2314>Because I don't see how guix loses
<drakonis>make your case in #guix-hpc then?
<ericson2314>Everyone uses other daemon and guix daemon looses momentum?
<drakonis>no, that's not the problem
<drakonis>the problem is that it will restrict the ability to change the scheme based daemon
<drakonis>it is a distinct loss of flexibility and control as it will still be in a language they do not have full mastery of
<drakonis>or understanding
<ericson2314>Can make 100% scheme daemon
<drakonis>okay, sure.
<ericson2314>The standard is supposed to have things you must support, but not prevent one from supporting other things
<ericson2314>Unless those things are really nasty tech debt mis-features, I think it should be fine?
<drakonis>eh, we'll see how this goes
<drakonis>i'm not even sure if the nix folks would agree on it either
<ericson2314>Yes that is true
<ericson2314>But at least I know that community so I know what I'm up against :)
<tricon`>mbakke: i very much enjoyed your post. thank you.
<August18_2022>Hello people, has anybody tried to install GUIX without a graphical environment + display manager and setting up Xorg with Xinit (for startx command) afterwards. I am having trouble executing startx, although the dependencies are there.
<tricon`>August18_2022: I use said setup with DWM.
<tricon`>BRB, switching accounts.
<August18_2022>@tricon I wanted that too, after installation, I installed xinit and even dwm (just for testing) through the GUIX package manager
<tricon>August18_2022: here are my relevant configs:
<tricon>1. .xinit:
<tricon>2. startdwm:
<tricon>3. startx:
<August18_2022>Thank you, I will try to replicate that inside a VM again, but in the first paste, there are two »exec« calls, isn't it the case that after the first »exec« was executed, it wouldn't execute anything further in the script/file?
<yuu[m]>August18_2022: no
<yuu[m]>that's why &
<tricon>August18_2022: actually, i need to remove the first as it fails presently. that's just (supposed to be) my DWM status bar.
<August18_2022>Ah right
<yuu[m]>actually i think this is wrong
<yuu[m]>it should be exec whatever & otherwathever
<yuu[m]>hmm not really
<August18_2022>Well, in my scripts I only used the exec statement at the very bottom ^^
<yuu[m]>whatever & exec whatever
<yuu[m]>August18_2022: yeah that's wrong. fix that like the last line i sent
<yuu[m]>i personally use a; b; exec c
<August18_2022>I'd have to specify my own dwm-status script anyways, I think I'll keep my logic regarding exec in this case.
<pkill9>do lonux containers reuse loaded shared libraries?
<August18_2022>But thank you guys for helping me out so quick
<pkill9>or do they each load the shared library over and over?
<August18_2022>@pkill9 I suppose you mean LXC containers specifically right?
<pkill9>i think so
<unmatched-paren>pkill9: Reusing them would, I think, be the logical thing, but I know nothing about containers
<unmatched-paren>You don't lose any isolation by reusing them
<pkill9>it probably does then
<August18_2022>With LXC, I am not certain, but with flatpak & co. in case the libraries between programs are in the same version, they actually share them
<pkill9>ah ok
<pkill9>that's good
<August18_2022>True, but unfortunately I never had that situation when I installed a couple of flatpaks.
<August18_2022>I always had duplicates
<pkill9>different versions of libraries?
<August18_2022>Yes I think so
<pkill9>i just mean it's good that they share the loaded libraries if they match
<pkill9>because I want to try running multiple jnstances of programs in multiple containers
<pkill9>im gonna try out a workflow of an instance for each project
<pkill9>eg so you can change the program settings for each project
<pkill9>without worrying about messing them up for other projects
<pkill9>s/worrying about//
<florhizome[m]>> <> Hello everyone
<florhizome[m]>> Why gnome 42 does not packaged for Guix yet? Is there any problem with it?
<florhizome[m]>I just wanted to ask about this – first, gnome packages are stuck between 40.0 and 41.x, it would seem to make sense to try to have a consistent versioning for the core libs and DE, second do we have a core updates drop soon (the last one is more then half a year ago), and are there any ambitions to move to 42+?
<pkill9>or polluting non+project usage of the program
<pkill9>like run chromoum for a project and bookmark a bunch of things
<pkill9>without dealing with bookmark hierarchies
<trevdev[m]>I am trying to get stumpwm-contrib to work in the home environment. From what I have learned, I must get the asdf module source-registry.conf.d into the correct config folder `~/.config/common-lisp/`. This must happen for the module itself & all of its `input` dependencies.
<yuu[m]>yaeh is much faster... what is the problem with also super slow
<trevdev[m]>I can get `(directory-union)` to farm out all of the packages (and all of their output directories!) into one place. Is there some elegant way to single-out the registry stuff in the `/etc` output folder?
<trevdev[m]>I suppose I could just slam all of the package data into a user-folder that ASDF prefers like `~/common-lisp` or `~/.local/share/common-lisp/source` but that feels like overkill.
<trevdev[m]>Wait, I'm seeing `source-registry.conf.d` in `~/.guix-home/profile/etc/common-lisp` - this is what I need. I can be symlinked to the config folder.
<yuu[m]>how much storage does uses?
<dthompson>from time to time I ask this: has anyone ever gotten an error like the following from guix deploy?
<dthompson>guix deploy: error: corrupt input while restoring archive from #<closed: file 7f7578f2d930>
<unmatched-paren>dthompson: Probably a transient network failure
<pkill9>yes dthompson
<pkill9>yes often when my internet sucks
<dthompson>unmatched-paren: it's consistently reproducible. in fact I've been blocked from using guix deploy for like a year due to it. I just gave up awhile back and only now found the motivation to try again.
<dthompson>I'm going to try to debug it again. I was unsuccessful the last couple of times.
<unmatched-paren>could you perhaps post the full error log?
<dthompson>that's all the error info that guix deploy shows to me. there could be more hiding in a file that I don't know about somewhere.
<dthompson>I can come back with more info when I have it. I was just curious if someone might be like "yup, that's a known issue. see <some mailing list post>"
<unmatched-paren>i don't think there will be anything in /var/log/guix; it seems to only include guixd logs and derivation build errors
<unmatched-paren>dthompson: maybe post it on bug-guix
<dthompson>iirc the last time I updated my server I took my guix deploy config, extracted the OS declaration, and did a manual guix system reconfigure on the remote host.
<dthompson>yeah I should open a bug about this
<dthompson>I just find it odd that I seem to be the only one blocked by it
<lilyp>dthompson: this doesn't look like a deploy error, but a substitute error
<lilyp>it should normally go away upon second invocation
<dthompson>lilyp: unfortunately it doesn't. it happens every time. I can't reproduce it outside of using guix deploy. if I manually reconfigure on the remote host it works.
<dthompson>I'm getting a guix dev environment setup for the first time in a long time so I can attempt to dig in a little further when I have a chance.
<blake2b>dthompson: how about running guix pull on the deployment target? how is memory usage over there?
<blake2b>oh sorry, I just saw that the reconfigure was on the host
<dthompson>blake2b: I haven't done this in awhile but in the past I'd make sure that I have the latest version of the guix daemon running to rule out running an outdated daemon
<blake2b>like lilyp said, this is a typical error that occurs when there are network problems. but I know I've also experienced it from my own cuirass server when I was running too many workers, using up all the ram. are you running cuirass on the host?
<jackhill>examors: Thanks for your help yesterday. I think I've figured out that the recent xdg-desktop-portal update was causnig my problem: Not sure abotu a solution yet though :)
<blake2b>dthompson: did you run "guix pull" before you reconfigured? if not, i think you would have reconfigured with old definitions on hand (I could be wrong and reconfiguring fetches the current defs, but I don't think it does)
<dthompson>blake2b: yup I did that.
<dthompson>I've been guixing since 2013 ;)
<blake2b>I know you're one of the old-timers, I just thought I'd point out the obvious considering you said you havent done it in a while
<tricon>dthompson: that is a worthy flex.
<blake2b>Guix grandparents
<dthompson>blake2b: no it's good thing to point out. easy to forget!
<dthompson>tricon: lol not trying to flex. I've been super inactive for a few years so I'm a little rusty!
<dthompson>trying to get back into things
<dthompson>got my dev environment up to date again :)
<examors>jackhill: no problem :) there's something very strange going on though - /gnu/store/bp9j67p8ynif5p2vbjl7lg294f5aihxk-xdg-desktop-portal-1.14.4/libexec/xdg-desktop-portal is an ELF binary on my system, and I can run it.
*jackhill runs `guix gc --verify=contents,repair`
<jackhill>well, it's reparing some things
<jackhill>btrfs scrub doesn't report any error though
<lilyp>Guix knows things your filesystem doesn't :)
<jackhill>but xdg-desktop-portal didn't get repaired, and it's still data
<jackhill>haha! Maybe the computer I'm using is cursed!
<lilyp>actually, repairing grafts is broken
<lilyp>you have to roll-back, gc the portal and build it again
<jackhill>lilyp: mine's not empty, but I'll agree that it's corrupt.
<jackhill>giving that a go…
<lilyp>and with gc the portal I mean gc both the grafted and ungrafted one
<jackhill>how do I determine the other one?
<jackhill>found it!
<jackhill>(I ran the grafting again, and saw what the pre-grafted one was)
<jackhill>hazza! I gc-ed and fetched the substitute, and now all is well.
<jackhill>Thank you. I'll go ahead and close the ticket
<jackhill>probably a hadware problem and not a bug, right?
<lilyp>likely both
<lilyp>that grafts can't be repaired is a genuine bug, but an already reported one iirc
<jackhill>ah, interesting
<lilyp>that your store item is broken, that's probably the result of a power outage or similar
<lilyp>and with that /me → zzz
<jackhill>Träum süß
<tricon>before i go trouncing through code, has anyone seen this error before with a custom channel?
<tricon>Updating channel 'custom' from Git repository at 'ssh://'...
<tricon>guix pull: error: Git error: failed to start SSH session: Unable to exchange encryption keys
<tricon>i saw one exchange in the IRC logs re: it, but it had to do with newer crypto algos. this is attempting to use an RSA key.
<apteryx>turbovnc submitted for review if someone is into VNC