<nckx>You need to add it to setuid-programs in your system configuration… <nckx>You know what, never mind. <nckx>You want a setuid sendmail, add a setuid sendmail 😛 <nckx>smtpctl doesn't enter into it one bit. <lechner>i'll check with the folks at opensmtpd <nckx>They only support OpenBSD, I think. All the rest is kept at bay with the big log ‘portable’ stick, and I doubt even those folks can help you with a less conventional distro like Guix. <nckx>It's a big stick, but it's not a log. <nckx>‘Make smtpctl setgid’ might be great advice on *BSD. ***rekado_ is now known as rekado
<bjc>is the documentation build broken for anyone else? i just did clean bootstrap in ‘guix shell -D guix pure’ environment and couldn't get it to build. had to comment it out to get on with things <nckx>The dependency management is not great (which is to say: subtly incorrect, I guess). Was it complaining about missing Texinfo translations? Simply touch'ing those file names usually ‘fixes’ that. <nckx>In a way that looks fun to debug :-/ <nckx>wine-staging, that is, at least. <lilyp>The page doesn't load for me, but could that have anything to do with the fact that wine itself is ahead of staging? <nckx>That's my guess. I'm currently ‘building’ (as in: waiting for it to fail horribly) 7.7. <nckx>7.7 is the official Wine emojo. <lilyp>the wine package itself built fine for me for a long while now, it should be stable <lilyp>I didn't put any effort w.r.t. staging tho – are people even using thatß <nckx>Yeah, my opening message was due to me not realising I had one machine still ‘stuck’ on wine-staging, not wine. <nckx>-staging used to be, y'know, newer, but I've stopped bumping it and if anyone took over I guess they also gave up. <nckx>I'm not going to put much effort in if 7.7 fails, as I expect it to, with some inscrutable toolchain error. <lilyp>I took over regular wine for some 6.x iterations, but didn't bother with wine-staging because it appears to me as its own package wherein changes from the main package don't carry over <lilyp>Back then I thought that nothing we do to wine would really shake wine-staging. Did an input change or a make-flag blow things up? <lilyp>It could also be one of those "I hate your cheapo hardware" build failures, which we also experience with webkit for example. <lilyp>At least that's what first comes to mind when I think of ld not being able to close a file. <nckx>Honestly, I'm not super motivated to track down what causes a linker to throw EINVAL or whatever when closing an obsolete file… And this hardware ain't cheap — it's Dell! <nckx>7.7: ./configure: line 21454: /bin/sh: No such file or directory <nckx>That's about it for me, it was a mistake anyway — I wanted wine, not ancient -staging. <nckx>If nobody complains that wine is too old I think we should remove the latter. <nckx>I'm not going to interact with #54257 but like why are they even installing an older unofficial version of Wine. My guess is, they didn't mean to. <lilyp>I think they thought wine-staging means bleeding edge and ignored the version? *nckx git resets --hardly. <lilyp>could you paste your WIP patch just in case? <nckx>It was merely a version bump + hashes. <nckx>Already reset, sorry, I would have saved you the effort but it wasn't more than that. <nckx>I never bothered to patch sh. <lilyp>Well, maybe they fixed it with 7.8 :) <nckx>You're looking at a different page than I was if that exists. <lilyp>it was released three hours ago, so... <lilyp>if this succeeds it will be our fastest wine update <nckx>That's a lot of changes since 7.7 😮 <nckx>I think I might have come close or beat that, but only because it would have built and worked from the get-go (and not a major update, so there's surely still a record to be had). <nckx>See y'all on the flip side of Linux 5.17… <nckx>…huh, it booted. I wasn't really expecting that after ~4 months of not updating. <nckx>…OK. Yay. Early bed time for me. 'Night Guix o/ <lechner>Hi, is anyone using filter-dkimsign with opensmptd. I am not sure my daemon locates the filter executable, which is installed by another package: dkimsign: sh: line 1: /gnu/store/3r78ppn17ckiqm6fm7g1xh8fanf18azp-opensmtpd-6.8.0p2/libexec/opensmtpd/filter-dkimsign: No such file or directory <nckx>So with opensmtpd-filter-dkimsign in my system (packages …) list. <nckx>I guess your error is what one gets with a relative file name? <lechner>nckx: yes. i'll try the absolute like you. thanks! <lilyp>the wine builds are started; hopefully they don't fail early or else I'll get cold feet <podiki[m]>we (the royal we) never updated wine-staging after the big jump in wine 7.x; I guess it is equivalent to having a wine-next <podiki[m]>not sure how relevant it is with the big wine updates, I think staging may have been more useful when wine hasn't put out a new version in a long time (and with all the dxvk etc stuff) <luke-jr>is there a way to apply patches to a build without modifying its input hash? <luke-jr>eg, on my Gentoo system, I have a script that goes through and destroys any ELF files after unpacking, just to be sure they don't get used by or into the build by accident <podiki[m]>are you looking for package transformations? --with-patch to build a package with a patch without defining a new package with code <podiki[m]>but otherwise I think the answer is no, by design: the hash must capture everything goes into a build to make sure you know if it is the same or now (reproducability) <podiki[m]>so if you include a patch or not, or add/modify a phase in the build procedure, all that must change the package hash <podiki[m]>if you mean the source hash, that is different and is only for the source, not the patches or anything else you do after the download <EMax`0Mancer[m]>what is needed to get kdeconnect-sms working on guix? arch's kdeconnect-sms seems to work, but on guix when I try to open any sms message thread it freezes. is there some additional packages i should be installing? <sneek>jgart, apteryx says: the -f deb pack bug should be fixed with 96dbcd7443 <jgart>apteryx: re -f deb pack: cool! <cocomeat4[m]>Hi, new to guix and I can't figure out how to manage system-wide packages ? <the_tubular>Yikes, I printed the cookbook to take with me on the road and read, and some code blocks got cut off :/ <podiki[m]>take a look at system configuration in the manual too <roptat>what's the url to download a patchset from mumi again? *the_tubular doesn't know <rekado>roptat: /issue/12345/patch-set/3 for the third patch set of issue 12345 <roptat>that's an overdrive (aarch64) for the guix build farm :) <roptat>although it came with an american power plug and I don't have a spare european one, so it'll have to wait until I can buy one <roptat>I mean, it was donated by someone who bought it on ebay, so it's not new, but it's not one of ours <cbaines>from what I remember, the power supply might have to be manually switched to the right voltage, so maybe double check that before turning it on <roptat>it's on the right one, but unfortunately it was delivered with a US plug, not a EU plug :/ <unmatched-paren>jgart: "unmatched-paren says: first package merged from paren to guixrus!" <- haha, you haven't spoken in this channel for a while :P <roptat>rekado, /issue/12345/patch-set seems to work (although it gives me every patch, not just the last patch-set?) but /issue/12345/patch-set/0 or /issue/12345/patch-set/1 gives an empty result <jpoiret>i heard patchset detection can be a littley wonky <jpoiret>unmatched-paren: i think we only have predicates for that <unmatched-paren>jpoiret: ok... the package i'm writing doesn't support hurd anyway -.o.- <jpoiret>it takes a string as an optional parameter, otherwise it's %current-{target,}-system <roptat>I'm trying to build a script to automate testing patch sets <jpoiret>roptat: how do you think you will manage with recompilation times? <roptat>like it would get the patch set, compute the packages to be rebuilt between master and the patch-set applied and build these derivations <roptat>it's not meant to be fully automated, just manually input the bug number and wait for the results <jpoiret>so you're gonna be applying on top of your local copy? <jpoiret>okayyy, right. Maybe there's a git workflow for that that i'm not aware of that could help as well <roptat>./pre-inst-env guix apply 12345 :) <jpoiret>so you can revert the patches and start doing something else <jpoiret>we really are in desperate need of a proper build system though <jpoiret>`make clean-go` just kills productivity :p <roptat>but you don't need to do it that often <jpoiret>maybe it's because i was working on record definitions often <jpoiret>maybe i should start properly reviewing patches <roptat>cbaines, can you extract the set of packages that differ between master and the patch? <roptat>or, can I use that to get the latest patch-set of a series more reliably than mumi? <cbaines>roptat, yep, so if you follow the link through to the Guix Data Service comparison, then click on "Compare package derivations" <cbaines>roptat, as for finding patch series by debbugs IDs, you could try using the Patchwork search, but that's not ideal <roptat>hm, although your comparison doesn't contain dependent packages, right? <cbaines>roptat, it should do, it should just contain difference <cbaines>even if it's something like a build system that's changed, the effect should accurately be captured <cbaines>roptat, right, that's the only version change, but click on "Compare package derivations" and you'll see all the packages where there derivations are affected <cbaines>roptat, although, note that the page is paginated, so you need to remove the result limit and tick "All results" to get all of the derivations, maybe filter for a system and target to cut down the number <roptat>that doesn't seem to be enough, with no limit, it cut after 40 <cbaines>jpoiret, there's some caching in NGinx, I'm not sure about that specific page <cbaines>roptat, you'll need to tick "All results" as well <jpoiret>right, it just seemed like the request was taking a bit so i was wondering if it computed that on demand <roptat>how do you compute the differences between two commits? <cbaines>but in general terms, all the derivations for all packages are computed, then the derivations from both of the revisions for each package are compared <roptat>I don't want to compute derivations for all packages though, it's too long for what I want to do <roptat>but I don't know how I could compare packages from two commits otherwise... <cbaines>unfortunately, I think computing all the derivations is the only rigerous way <roptat>like, fold-packages is fast, but running package-derivation through all of them takes time <cbaines>you can get so far by looking at the package graph, but it's going to be misleading sometimes <roptat>yeah, that's not what I want to do <nckx>I'd say (%current-target-system) if I didn't suspect you'd have tried that already. <nckx>Note the procedure call. <nckx>Watch out, it's very literal: it's #f when not cross-compiling. <nckx>(or (%current-target-system) (%current-system)) ;; is common. <unmatched-paren>is there some environment variable for searching for patches? i've added a new patch to guixrus but it doesn't seem to be finding it with `-L .` <lilyp>nckx: btw. I've got wine and wine-staging building now <lilyp>I'll clean some things up and then submit my series <nckx>I thought wine was already building. Did you have to break it to heal the bone? <nckx>(Did you merge them somewhat?) <stfnbms>After installing a new Emacs package (emacs-dictionary, for example) through Guix, the package is not immediately visible to Emacs. I have to restart Emacs for it to be found. That is inconvenient, since I run EXWM. What can I do? Also, this seems like wrong default behavior. <unmatched-paren>though it does display a warning guix/packages.scm:859:7: warning: resolving 'guixrus/packages/patches/qbe-makefile-add-target.patch' relative to current directory <janneke>stfnbms: M-x guix-set-emacs-environment RET ~/.guix-profile RET may help <unmatched-paren>how do i test cross-building my qbe package to riscv64 and aarch64 without building the world? <stfnbms>janneke: No, sorry, that does not help. <janneke>stfnbms: oh, hmm. then i guess emacs sets some path variable after startup that guix-set-emacs-environment doesn't update (it does update exec-path) <stfnbms>That variable is load-path, I think. <stfnbms>It should be updated by Guix when installing a new Emacs package, I think, but is not. <unmatched-paren>can i run a cross-build in a qemu environment somehow without spinning up a whole guix system? <cbaines>does anyone know where sshd logs to when it doesn't start? <cbaines>shepherd says it's started it, and maybe it tried, but I can't see it running <lilyp>nckx: okay, I spoke too soon; wine64-staging still fails <stfnbms>janneke: Manually running “add-to-list 'load-path” and “load-library” for an Emacs package newly installed through Guix (after looking up the path) works. It would be nice if that could happen automatically. <nckx>unmatched-paren: You can avoid that (IMO odd) error with $PWD/… if it bugs you. I don't really grok the qemu question. What would it save you? Cross-builds by definition run on (say) your x86 laptop, they just poop out a riscv64 binary/s at the very end. <nckx>Hi raghavgururajan! I'm all right, thanks :) Spent all day yesterday updating my Guix Systems to 2022. You? <unmatched-paren>while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/2byi3bm0xg1lk8jspn1zgyr2s0y083zj-qbe-0.0-1.2caa26e-checkout.drv', but I am a `x86_64-linux' <nckx>That's not a cross-build. <nckx>Sounds like you're using --system? <lilyp>the issue is now more subtle though; it fails to copy over the wine32 stuff thanks to an incorrect assumption about input labels (i assume) <nckx>For fun, --system takes a ‘nix system’ (e.g., aarch64-linux, I think?) and --target takes a ‘GNU triplet’ (e.g. aarch64-linux-gnu) as argument. <nckx>It would be too easy otherwise and we'd gain too many users . <janneke>stfnbms: yes, great that you found a way though <unmatched-paren>nckx: then we'd have people demanding that we package nightmarish JS modules and that we integrate guix with $HIP_NEW_CONTAINERIZATION_TOOL, and we can't have that :P <nckx>We can negotiate rewriting the JS modules in Rust. <nckx>unmatched-paren: By the way, side note: --system= on a properly configured Guix System (with qemu-binfmt-type and the right platforms) would actually transparently spin up QEMU for you. Not a VM, per-process, transparently. It's quite nice. <nckx>I use it a lot to quickly test did-I-break aarch64. <nckx>And I should add riscv64. <nckx>Which apparently is a real (Guix) thing now? <lilyp>I wonder why people haven't started rewriting Rust in Typescript yet <lilyp>Typescript in Rust in Typescript <nckx>Wrong way. Typeless Rust. The future can't wait for you to get your types right. <unmatched-paren>"mutually recursive dependencies hahaahaahHAHA try bootstrapping this" -- javascript people <lilyp>still saner bootstrap than scala <lilyp>though tbf the java world was "just bundle this huge junk of jars with your application, it'll be fine" at the *start* of the millenium <lilyp>s/junk/chunk/, though both work :) <nckx>A murder of crows, a junk of jars. <unmatched-paren>nckx: how about we also replace borrow checking with garbage collection for ease-of-use reasons :P <nckx>‘Garbage borrowing’ is already how I write JS when forced to. <lilyp>there is a javascript scheme interpreter <lilyp>but we all know the superior experience is ecmascript in guile <lilyp>which we can soon compile to native code! <unmatched-paren>a true JS garbage collector would just delete all your code :P for some reason no JS engine provides that <lilyp>actually, there was a JS module that did that <lilyp>got pulled from npm for malware tho <lilyp>it also only worked in russia <unmatched-paren>reconfiguring after adding aarch64 to my qemu-binfmt config, but for some reason it's building qemu? how long does qemu take to build? <nckx>A while. I don't know why it's rebuilding (there's no per-architecture QEMU package). Update? <nckx>It could be any transitive input too. <nckx>A quick guix build that .drv tries to build it here. Hm. <nckx>33%, is that… one output? <nckx>‘guix build /gnu/store/j5v9xlzsfk87vixc9m7kgmmyy6rqbarl-qemu-6.2.0.drv’ on berlin starts building QEMU. <unmatched-paren>the qemu build on my laptop is at `45%` so far, so it shouldn't take toooo long to finish <nckx>Which I've cancelled because Cuirass can be a sensitive flower when you ‘guix build’ things (or at least was). <nckx>Sure, it takes a while but in the end it's just a full-system emulator for a half-dozen architectures and hundreds of machine variants, not like, a Web browser. <nckx>unmatched-paren: If you don't have fans and your machine is whirring, ehm, good luck. <nckx>So berlin is missing the :static and :doc outputs, it has the big qemu:out output, but your machine wants one of the others so has to build QEMU from scratch… <nckx>unmatched-paren: And yet you make whirring sounds when excited. Curious. <nckx>unmatched-paren: The way outputs work, and why they exist in the first place: yes, by definition. <nckx>Yes, but neither of those store file names exist on berlin. <nckx>They must have been built (you can't build only a subset), then either GC'd (ruh roh) or not copied back from the build node for some reason. <nckx>Only /gnu/store/f5grv376xfn7bbz7h8dk50aqi5xjqfy7-qemu-6.2.0 [still] exists. <nckx>Let's see if restarting the build prods things back to reality. <nckx>unmatched-paren: Sorry, to be clear: it means ‘they were built’. But they shouldn't be GC'd, so the assumption is also ‘both’. <nckx>I was afraid it would just check its database & say ‘yup, already built’. <sughosha>Hi all, I am trying to update GNOME packages to the GNOME 42 by this command:<br><code>guix refresh -ru -s non-core -t gnome</code>. I don't know what specifically what packages are supposed to be upgraded and also whether I should <code>-s non-core</code> or not. Also I would like to know if someole is already working on getting GNOME 42. I would appreciate any help :) <unmatched-paren>sughosha: i don't think guix refresh will be enough to update GNOME, sadly <nckx>raghavgururajan: ☝ maybe? <unmatched-paren>sughosha: btw, why do you have html tags in your message? just curious :p <sughosha>unmatched-paren Because I see every time some message from ChanServ in HTML. I thought that would work 🤪️ <nckx>Hmm? Which message(s), sughosha? <sughosha>Something from #guix itself, giving a link for code of conduct. I don't remember exactly. <nckx>That should definitely not contain HTML. I'll take a look. Thanks. <sughosha>Oh ok.. Then same as Matrix.. But in Polari if I type it shows as is without any decoration. Not sure.. But I look forward for an example :) <nckx>There shouldn't be any decoration. <unmatched-paren>IRC doesn't have a way to split messages across multiple lines, but some clients allow you to do it (and send multiple messages at the same time when you send a multi-line message) <unmatched-paren>i think some of them might merge adjacently displayed messages from the same person into one? <nckx>‘Some clients’ is a common phrase. :) <nckx>There's nothing wrong with configuring your client to format `codez` prettily, but the problem is users who don't know it's not an IRC protocol feature might rely on that happening, creating an unreadable mess for everyone else (including those chatting in an emacs buffer on the Linux console). *unmatched-paren checks https://ircdocs.horse to see if irc allows multi-line messages (pretty sure it doesn't) <nckx>People's clients highlighting their nick is about all you can rely on. Don't assume much more than that. I also assume people have UTF-8 because it's 2022 but some weirdos look at me funny even for that. <nckx>unmatched-paren: Oh, qemu 'toots are ready if your fans are still spinning and you just want them to stop. <unmatched-paren>for some reason my fonts have been a bit messed up since i started using guix system and i haven't bothered to ask how to fix it <nckx>unmatched-paren is such a 👍 🐃 🐧 <unmatched-paren>nckx: aargh, now you can say whatever you want in emojis and i won't be able to see it /o\ <nckx>unmatched-paren: Here foot shows them in an old-fashioned monochrome font. I don't know which one. Clearly not Noto, which I have installed & HexChat uses. <unmatched-paren>i think i remember seeing in the logs someone mention UTF font problems <unmatched-paren>have you got any font packages installed or font-related stuff in config.scm <nckx>In my system packages I have: font-abattis-cantarell font-dejavu font-google-noto font-hack font-libertinus. Nothing in guix package -I font. I don't use Guix Home. <nckx>font-google-noto gives me the mojies. <nckx>But not in foot, hm, I hadn't noticed that. <nckx>Maybe it doesn't support colours. <nckx>I mean, Guix's foot, possibly on a foreign distro. <nckx>I use foot myself. I'm not an animal. <nckx>No, but you can (and I do) use .config/fontconfig/conf.d/ etc. <nckx>unmatched-paren: In the package itself? If it could be done without creating a hard reference, maybe, for lack of a better solution. <nckx>‘Our’ meaning us two, not Guix? <nckx>font=Hack:size=7.5,Noto Color Emoji <nckx>(I am very particular about the aliasing of my font yes OK.) *unmatched-paren adding font-google-noto to their home packages list <nckx>Oh, fair warning: it's huge. <sughosha>Just curious, is the italic text above, saying "adding font-google-noto", possible only for some special people in the channel? <nckx>sughosha: Type (in full) <unmatched-paren>naturally, running `guix home reconfigure` rebuilds fifty gazillion rust crates <unmatched-paren>sughosha: i think /some/ irc clients make text /italic/ if you surround it with slashes <unmatched-paren>sughosha: note that /this/ and *this* aren't part of IRC itself, just people have a long tradition of making text _look_ bold and italic like that in text-only land, so some clients will actually display it as such <sughosha>By the way I have one problem facing from one or more months, every time I install any package from Guix, it doesn't download pre-built binaries but instead build on my PC locally. Even after passing `--no-grafts`. I also checked for such packages in https://ci.guix.gnu.org and they seem to be already built. <sughosha>One specific package to mention is `webkitgtk-with-libsoup`. <unmatched-paren>senpai doesn't seem to prettify *this* and /this/ either, but i think irssi does <unmatched-paren>nckx: this webkitgtk-with-libsoup problem sounds like a similar issue to the one i had with qemu? <htsr[m]>I can't compile btrfs-progs for aarch64 because it cannot find libudev, does the support for arm is good in Guix? <sughosha>nckx: I had misunderstood the welcome message from #guix to be HTML. The links were inside "<>" and I assumed them as HTML tags 🤐️ <lilyp>as for text highlighting in Polari, just code that up in Javascript, how hard could it be? 😜️ <htsr[m]>unmatched-paren: Okay thanks, but is it possible to use Guix System on arm or should I use an host distrib? <nckx>The <URL> helps most clipboard and other ‘clever’ linkification. The number of times I've opened and had to edit a link to https://issues.guix.gnu.org/1234) — or with a trailing full stop — is too damn high. <nckx>Anyway. Don't buy alcohol-free beer. I bought some by accident, and it just exploded all over me in a torrent of fungus. It's a preservative for a reason. Now I'm all sticky. This was a PSA. <unmatched-paren>nckx: that happened to me so many times too! (the link thing. not the beer.) <unmatched-paren>htsr[m]: i don't know, i believe there is one person who's mentioned using it on arm multiple times but i can't remember who <nckx>htsr[m]: It's possible, but the experience is much less smooth than x86 for various reasons (popularity, speed, the absolutely horrible boot loader situation, …). <nckx>guix system image --list-image-types has some ARM boards. <nckx>The fact that each one has their own type (vs. ‘efi-raw’ for x86, boom, done, the rest is for use cases) says enough. <nckx>I think the Pinebook Pro is used by enough people to usually work :) *unmatched-paren has only just realized that they can use local-file in their home config instead of embedding their config files as strings <unmatched-paren>nckx: btw, after installing google-noto and making the change in my foot.ini, emojis now appear in full colour in foot \o/ <attila_lendvai>there are some font issues since i have reconfigured home services for the first time. e.g. ebook-viewer doesn't display any text (and does't print any errors either, unfortunately) <sneek>Welcome back attila_lendvai, you have 1 message! <attila_lendvai>oh my, this is getting deeper: sudo: /home/alendvai/.guix-home/profile/bin/sudo must be owned by uid 0 and have the setuid bit set <nckx>attila_lendvai: You should have /run/setuid-programs/sudo and it should come first in $PATH. <nckx>/home/alendvai/.guix-home/profile/bin/sudo will never be setuid. <unmatched-paren>attila_lendvai: sudo should be installed in your system config, not your home config *attila_lendvai removes it as recommended, thanks! <nckx>(Think about the implications had that worked 😉) <nckx>Well, I probably made a mistake in replacing JoyPixels somehow. The example (which I copied wholesale) even mentions NotoColorEmoji, no spaces. I tried with & without spaces (and removed that hunk in case it causes a loop) with no change. <attila_lendvai>unmatched-paren, i need to run soon, and i haven't sanitized it yet, so maybe later. it doesn't have any magic, AFAICS. it has a XDG_DATA_DIRS for flatpak that may interfere, but it only adds as a suffix. and installs a bunch of packages (apparently quite randomly, as the result of some copy-paste, see e.g. sudo...) *unmatched-paren still can't get qute to display font *unmatched-paren still can't get qute to display emoji fonts <tbss[m]>unmatched-paren: I doeant search the group <yuu[m]>tbss: #nonguix:libera.chat. also in #guixspace:matrix.org <AceTheMercenary[><tbss[m]> "But the network doesnt working" <- watch system crafters video for anything related to guix <AceTheMercenary[><AceTheMercenary[> "watch system crafters video..." <- he does have the "You-Know-What" (we don't speak of it here) video <nckx>yuu[m]: Yet another Guix Matrix channel? Interesting. <nckx>Oh, it has only 15 members. <raghavgururajan>nckx: I see. I am not bad. I am getting baked/fried under hot weather here in Chennai. Got a new (first) IT job, which is bitter-sweet. Bitter as it hinders my focus on free software stuff. <yuu[m]>nckx: that's a space, which serves for listing related matrix rooms and bridged stuff like irc. <nckx>I am next to clueless about Matrix. <nckx>‘Spaces are a new feature. Give feedback.’ <nckx>So… it's a list of channels… but the list itself has users sitting in it? Hm. <nckx>raghavgururajan: Well, still congrats. I've never been to Toronto but I'd definitely prefer its weather to Chennai :) <nckx>Any plans/desire to return? <raghavgururajan>nckx: My VISA expired. I do plan to go back after gaining experience in my career track, so that I can get a job in Toronto. <yuu[m]>nckx: yes. matrix spaces are matrix rooms themselves, but it lists rooms and other spaces instead of providing a chat. they are analogue to discord servers. <yuu[m]>analogue in a way, but actually more flexible. <nckx>I've never been on Discord. Anyway, thanks for the link! I've ‘joined’. <yuu[m]>nckx: glad you joined. be welcome! <nckx>raghavgururajan: Someone asked in here earlier if anyone is working on GNOME 42. Would you happen to be, or to know? <roptat>I bought the plug, it didn't go poof :) <roptat>sorry, the power plug for a machine. earlier today I was warned that it would go poof if I don't carefully select the right voltage <roptat>now I can't find the serial console :/ <unmatched-paren>how do i get the gcc libdir? i remember there is a procedure for it but i can't remember where <roptat>you can create a phase like (lambda* (#:key inputs #:allow-other-keys) ... (assoc-ref inputs "gcc-lib"))) <roptat>although I'm not sure what it's called exactly <roptat>am I cross-building an installer image for the overdrive? :/ <roptat>or it's one of the annoying ones that are implicit when building natively, but not when cross-building? <unmatched-paren>although it might be a bit slow since it would have to check every defined and used# variable in every module... <roptat>and I don't have an aarch64 system from which I could build the installer image <jgibbons[m]>When I guix pack -f docker, I have little control over what tag the resulting image gets. It is usually defined by the names of the first few packages in the manifest or package list. Is there a way to specify the desired tag without defining a package with all the things i want as propagated inputs? <jgibbons[m]>For example, I have a manifest of minetest and all the minetest mods packaged into guix. The resulting docker image is tagged something like minetest-minetest-advtrains minetest-basic-materials. How can I simply tag it "minetest"? <jgibbons[m]>I want to do all this prior to calling it docker load. That way I don't have to call docker image tag . <unmatched-paren>odd, i sent patches to two debbugs.gnu.org threads but only one is appearing <unmatched-paren>the one that's not appearing is sent to a closed thread, could that have something to do with it? <unmatched-paren>the email workflow is great, when it works :( when i send email to lists.sr.ht it generally work almost immediately, but for some reason i have to wait a long time before mail appears on debbugs.gnu.org ***EMax`0Mancer[m] is now known as emacsomancer[m]
<emacsomancer[m]>I noticed some pipewire things in a recent update/reconfigure - is guix going to switch to default pipewire at some point? <roptat>for people who had (have) an overdrive, do you know if you can boot from USB? <dirtcastle>installing guix on top of other distros beats the whole point of guix isn't it? would love to hear your input on this <jpoiret>dirtcastle: no, why would you think so? <roptat>installing guix on top of another distro gets you almost all of guix, except the system <jpoiret>guix-managed software, even on another distro, has all the advantages of, uhmmm, guix-managed software <jpoiret>doesn't matter if it's on guix system or not <jpoiret>sure, if for you guix's biggest pro is being a FSDG distro and shipping linux-libre, then you're going to be missing the kernel <nckx>roptat: It does. Booted a Ubuntu Live system & inited guix from there. <nckx>*cuix system, of course. <dirtcastle>having 2 package managers when guix is more reliable <dirtcastle>coz it has roll back and all. when other doesn't have as many features as guix/nix. what's the point of doing it? <jpoiret>well, maybe you have to use another distro for _reasons_, but you want to use guix for specific software <jpoiret>or you don't consider guix to be as stable as you'd wish for a system, etc... <nckx>Roll-back applies equally to user profiles & packages. <jpoiret>maybe your argument boils down to "Why use any other distro when Guix is clearly superior?" then, well, right :p <jpoiret>also, using guix system is more involved than just using guix as a package manager <jpoiret>the latter can be used with just a CLI like any other package manager, while the former requires you to write some guile <dirtcastle>I decided to use guix with artix linux. learn guix on the side. read the manual. learn lisp. and use artix when I don't know how to do what I want with guix and when I'm in a time constraint. idk. is this ok to rant like this here? is there an offtopic channel. <dirtcastle>jpoiret: I can still write config and all right inside another distro? <unmatched-paren>dirtcastle: you cannot write a system config inside another distro (well, you can, but if you reconfigure you're basically turning it into a guix system) <unmatched-paren>dirtcastle: generally #guix is pretty liberal about offtopic discussion as far as i have experienced ***bandali_ is now known as bandali
<dirtcastle>hmmm. so the foreign distro's init system have to used to manage guix too? <unmatched-paren>dirtcastle: the foreign distro will have to manage the guix daemon, i think? <jpoiret>foreign distros that package guix often have the relevant service files for their init system <dirtcastle>just now checked what home is. It said you can use it on foreign distros <jpoiret>then you'll have to write the service file yourself, but it's usually pretty simple <the_tubular>dirtcastle, you know if you absolutely need something that isn't packaged for guix you can use docker or podman too. ***bjc` is now known as bjc
<atka>I'm doing okay, yourself? <atka>the_tubular: any guix progress <the_tubular>I started reading r6rs recommenced by someone here to get better inScheme <atka>still mainly running it on servers, diving into mcron today for the first time <atka>need to set up a btrfs raid array and mcron a ddns script <the_tubular>Ohh nice. Yeah it seems that most doc I find is for running guix on a personal computer. I would like to read on server side stuff <atka>I bookmarked r6rs as well <atka>looks like a good resource <the_tubular>I also printed the cookbook, as PDF and a couple code blocks got cut ... <atka>the_tubular: I want to start running it on my personal computer but need to order a wifi card compatible with linuxlibre <atka>server is easy in that regard, no need for blobs for wifi/video etc <the_tubular>Definetly, but I find configuring services harder on server side, less documentation <atka>yeah, most of the services are through docker <atka>I'd like to use guix native containers eventually <atka>other than using guix native containers <the_tubular>Well depends how you done it, you created an Image or you just pulled something ready on dockerhub ? <atka>I have not created the images no, but using official images that work with either podman or docker is kinda the way these things are done <atka>and I'm not about to package and maintain services and dependencies for guix at this point <atka>all container images need is a runtime and a kernel <atka>I usually use alpine as the host but guix working ok in that regard <nckx>guix substitute: warning: guix.cbaines.net: host not found: No address associated with hostname <nckx>(And indeed, it's gone.) <nckx>Maybe it was never meant to be used; I can't honestly remember why or when I added it. <the_tubular>That's what I meant, it's not really the guix way atka <the_tubular>Best case scenario would be to download the package using guix and put them in a container after <nckx>All evaluations on berlin were failing due to running out of psql connections (that was the symptom, at least). I restarted cuirass and postgresql and it seems to be back up. <the_tubular>Completely unrelated, 1.3.0 is getting old. Is there any plans to release 1.4.0 soon ? <singpolyma>the_tubular: the version numbers are basically arbitrary <atka>the_tubular: you have no idea what you're talking about