IRC channel logs


back to list of logs

<nckx>You need to add it to setuid-programs in your system configuration…
<lechner>mine ships as a symlink
<lechner>i added smtpctl instead
<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>*big long
<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>Eyy, Wine's broken \o/
<nckx>In a way that looks fun to debug :-/
<nckx>wine-staging, that is, at least.
<nckx>Previously reported:
<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
*nckx nods.
<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>(It's berlin.)
<nckx>7.7: ./configure: line 21454: /bin/sh: No such file or directory
<nckx>♥ that line number.
<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?
<lilyp>or is it already reset?
<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 😮
<lilyp>(big if)
<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…
<sneek>Yey! yewscion is back!!
<yewscion>sneek: botsnack.
<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>…somebody always asks something I have to say ‘yes’ to right before I go to bed :) Yes, lechner, but I use it like this:
<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?
<nckx>Anyway, 'night.
<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?
<raghavgururajan>Hello Guix!
<jgart>Hello RG!
<sneek>jgart, you have 2 messages!
<sneek>jgart, unmatched-paren says: first package merged from paren to guixrus!
<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 ?
<cocomeat4[m]>Been searching in the manual for about an hour
<the_tubular>Yikes, I printed the cookbook to take with me on the road and read, and some code blocks got cut off :/
<the_tubular>You add them to your config.scm cocomeat4[m]
<cocomeat4[m]>oh okay
<podiki[m]>take a look at system configuration in the manual too
<roptat>hi guix!
<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>guess what I just received? :D
<littlebobeep>roptat: omg wat?
<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
<rekado>is it a new one?
<roptat>rekado, yes
<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>roptat, woo :)
<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 :/
<jpoiret>one mistake and poof :p
<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
<unmatched-paren>how do i extract the platform (e.g. linux) from a nix-system?
<unmatched-paren>and also the architecture?
<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
<jpoiret>eg (target-linux?)
<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
<unmatched-paren>but surely there's a way to extract the arch from nix-systems?
<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 :)
<roptat>that's the goal at least
<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
<roptat>yeah, that would explain it
<jpoiret>maybe i should start properly reviewing patches
<cbaines>roptat, I've been going for a "hosted" approach, but the applying the patches and computing the difference against master bits are currently happening, at least for some patch series (like for example)
<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"
<roptat>pretty cool
<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
<roptat> only lists sbcl
<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
<jpoiret>is that cached?
<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
<jpoiret>but i hope not :p
<roptat>ah I see
<roptat>how do you compute the differences between two commits?
<cbaines>roptat, the approach is rather specific to the Guix Data Service, as it's done via the database
<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
<unmatched-paren>which #$... variable contains the build's target system?
<roptat>#$(current-target) maybe?
<roptat>er, #$(%current-target)
<nckx>I'd say (%current-target-system) if I didn't suspect you'd have tried that already.
<nckx>Note the procedure call.
<unmatched-paren>nckx: no, i haven't tried that yet
<unmatched-paren>it works
<unmatched-paren>thanks roptat and nckx
<nckx>Watch out, it's very literal: it's #f when not cross-compiling.
<unmatched-paren>ohh i see
<nckx>(or (%current-target-system) (%current-system)) ;; is common.
<unmatched-paren>nckx: yeah
<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 .`
*roptat is leaving
<roptat>see you later :)
<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>Hm, I didn't chase down the definition but search-patch mentions a ’load path’ explicitly:
<nckx>lilyp: Great.
<unmatched-paren>nckx: thanks!
<nckx>I thought wine was already building. Did you have to break it to heal the bone?
<nckx>(Did you merge them somewhat?)
*nckx gotta go too.
<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.
<raghavgururajan>nckx: o/ Long time, no see. How are things with you>
<unmatched-paren>nckx: i got it working by adding -L guixrus/packages/patches
<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?
<unmatched-paren>oh, aarch64 has substitutes, nvm
<unmatched-paren>but riscv64 still requires me to build 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>nckx: well, when i try to cross-build qbe to aarch64, i get:
<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?
<unmatched-paren>ah, i see
<unmatched-paren>yes, i am
<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>Instead of --target.
<unmatched-paren>nckx: thanks!
<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
<unmatched-paren>also that we rewrite it in rust
<nckx>We can negotiate rewriting the JS modules in Rust.
<nckx>Still a net win.
<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.
<unmatched-paren>nckx: ooh
<unmatched-paren>that's neat
<unmatched-paren>i have binfmt configured for riscv64 but not aarch64
<nckx>I use it a lot to quickly test did-I-break aarch64.
<unmatched-paren>i guess i should add aarch64 to my binfmt config
<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
<unmatched-paren>lilyp: then rewrite typescript in rust :P
<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
<unmatched-paren>*typescript 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.
<nckx>♥ stackoverflow.
<unmatched-paren>nckx: surely there has to be a scheme->javascript compiler?
<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
<unmatched-paren>lilyp: is guile adding native compilation?!
<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>ah, right, that protestware nonsense
<lilyp>yep, was a little overeager
<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?
<unmatched-paren>`git blame` says qemu package was last modified on 2022-02-20
<unmatched-paren>so i have no idea either
<unmatched-paren>because i've certainly reconfigured since then...
<nckx>It could be any transitive input too.
<unmatched-paren>good point :P
<unmatched-paren>seems like the CI just built qemu 20 hours ago, so it should have a substitute?
<nckx>A quick guix build that .drv tries to build it here. Hm.
<unmatched-paren>guix weather qemu reports:
<nckx>33%, is that… one output?
<nckx>OK, so
<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>But that ain't right.
<unmatched-paren>it's certainly making my fans whirr :)
<unmatched-paren>*its fans
<unmatched-paren>i'm not sure i have fans :P
<unmatched-paren>of either kind
<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.
<unmatched-paren>(even though a Web browser can only emulate _one_ architecture :P)
<unmatched-paren>nckx: heh, i meant that _I_ don't have fans, not the machine :P
<nckx>Ah, right.
<unmatched-paren>that's why i said "of either kind"
<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…
<unmatched-paren>berlin should be building them all at the same time, right?
<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.
<unmatched-paren>um, lists `doc` and `static` as outputs, not sure whether that means anything
<unmatched-paren>does that mean `these outputs exist` or `these were built`?
<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>OK, it's rebuilding, at least Cuirass has noticed the loss:
<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?
*nckx agrees.
<unmatched-paren>it's quite a complicated package
<unmatched-paren>*set of packages
<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?
<nckx>That should not be.
<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>It appears as a notification in Polari.
<unmatched-paren>sughosha: generally we use `...` for code blocks on IRC :)
<unmatched-paren>at least in my experience
<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.
<nckx>IRC is pretty texty.
<sughosha>Hm ok.
<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 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 ignores them 🐐
<unmatched-paren>ironic that the emoji you just posted shows as a box for me :P
<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
<unmatched-paren>neither qute nor foot display emojis properly
<unmatched-paren>nckx: nice, but it's nearly finished i think
<nckx>unmatched-paren is such a 👍 🐃 🐧
<unmatched-paren>it's on `build-user-static` 44%
<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.
<nckx>But no boxes.
<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
<unmatched-paren>or your home configuration i guess
<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.
<unmatched-paren>foot supports colours
<nckx>On Guix?
<nckx>I mean, Guix's foot, possibly on a foreign distro.
<unmatched-paren>there is coloured text in two of my three open foots
<nckx>No, colour fonts.
<nckx>I use foot myself. I'm not an animal.
<unmatched-paren>lesse here...
<unmatched-paren>i don't think we can do the /etc thing on guix
<unmatched-paren>so i guess we'll have to set the emoji font as a fallback?
<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.
<unmatched-paren>no, not in the package itself, in our foot.ini files
<unmatched-paren>like the example on the foot wiki:
<unmatched-paren>font=Terminus, Joypixels
<nckx>‘Our’ meaning us two, not Guix?
<unmatched-paren>i don't think there's a way guix itself could fix this
<unmatched-paren>i might be wrong -.o.-
<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>Thanks for the tip!
<unmatched-paren>no problem :)
<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)
<nckx>/me does something.
*nckx does something.
*sughosha does something
<unmatched-paren>naturally, running `guix home reconfigure` rebuilds fifty gazillion rust crates
<sughosha>Wow thanks 😃️
<unmatched-paren>sughosha: i think /some/ irc clients make text /italic/ if you surround it with slashes
<unmatched-paren>and *some* make it bold if you surround it with asterisks (*)
<unmatched-paren>nckx: thanks for the warning
<sughosha>just playing with irc
<sughosha>slash foritalic isn't working in Polari
<sughosha>^ Not bolded for me..
<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
<unmatched-paren>sughosha: i guess polari doesn't do that
<sughosha>Unfortunately :(
<sughosha>I like to see eye-candy text
<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 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?
<unmatched-paren>maybe the CI is only building out for it too?
<unmatched-paren>there's also :debug and :doc
<unmatched-paren>oh, wait: looks like it actually failed to build last time
<htsr[m]>I can't compile btrfs-progs for aarch64 because it cannot find libudev, does the support for arm is good in Guix?
<unmatched-paren>htsr[m]: sadly ARM support is a little wonky on Guix, apparently
<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>don't do HTML over IRC
<unmatched-paren>sughosha: ahh! yes, <> is a common convention
<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 — 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
<unmatched-paren>try searching through the logs for `arm`
<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>i feel pretty stupid for not having done this earlier :P
<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!
<sneek>attila_lendvai, maximed says:
<unmatched-paren>seems like qute will also need extra configuration
<nckx>unmatched-paren: I tried using the more generic XML approach from <> for Noto Color Emoji but I'm not having any luck.
<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
<unmatched-paren>i thin
*attila_lendvai removes it as recommended, thanks!
<unmatched-paren>strange about the fonts though
<nckx>(Think about the implications had that worked 😉)
<attila_lendvai>fair enough... :)
<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.
<unmatched-paren>attila_lendvai: can i see your home config.scm?
<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>attila_lendvai: ok! bye :)
*unmatched-paren still can't get qute to display font
*unmatched-paren still can't get qute to display emoji fonts
<tbss[m]>I have installed the nonguix
<tbss[m]>But the network doesnt working
<unmatched-paren>tbss[m]: shhhh we do not speak of the nonguix here
<unmatched-paren>ask #nonguix
<tbss[m]>unmatched-paren: I doeant search the group
<tbss[m]>In matrix
<yuu[m]>tbss: also in
<AceTheMercenary[><unmatched-paren> "tbss: shhhh we do not speak of..." <- yep
<AceTheMercenary[><tbss[m]> "But the network doesnt working" <- watch system crafters video for anything related to guix
<AceTheMercenary[>and also (obvsly) the official vids and doc is yop notch
<tbss[m]>AceTheMercenary[: Thanks
<AceTheMercenary[><AceTheMercenary[> "watch system crafters video..." <- he does have the "You-Know-What" (we don't speak of it here) video
<nckx>Then don't.
<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.
<raghavgururajan>God I miss Toronto.
<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’.
<nckx>raghavgururajan: Rad.
<nckx>I wish you luck.
<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>hi again :)
<roptat>I bought the plug, it didn't go poof :)
<tekakutli>wait, what plug?
<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
<tekakutli>good, it did sound like a banter prelude xd
<roptat>now I can't find the serial console :/
<roptat>ah found it :)
<roptat>it's ACM0
<unmatched-paren>how do i get the gcc libdir? i remember there is a procedure for it but i can't remember where
<unmatched-paren>*where it's defined
<roptat>you mean gcc:lib?
<unmatched-paren>roptat: ah, thanks
<unmatched-paren>i though there was some sort of procedure to get it
<roptat>in which context?
<unmatched-paren>in a build process
<roptat>in phases?
<unmatched-paren>i'm trying to get cross-compilation working for cproc
<unmatched-paren>i need to provide --with-gcc-libdir= to its configure script
<roptat>I think it's an entry in inputs
<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
<unmatched-paren>roptat: it's not called gcc-lib or gcc:lib, annoyingly
<unmatched-paren>uhm apparently it is gcc-lib
<roptat>am I cross-building an installer image for the overdrive? :/
<unmatched-paren>but i needed to add (list gcc "lib") to inputs
<roptat>isn't it an implicit input?
<roptat>or it's one of the annoying ones that are implicit when building natively, but not when cross-building?
<unmatched-paren>no idea
<unmatched-paren>(apparently it doesn't work actually)
<unmatched-paren>the clang package specifies it
<unmatched-paren>i'm not sure what the label is, so i'll explicitly specify it
<unmatched-paren>it works if i explicitly specify the label
<unmatched-paren>roptat: thanks! :D
<unmatched-paren>seems like cproc builds fine under an aarch64 qemu
<unmatched-paren>and cross-compiled to it too
<raghavgururajan>nckx: Thanks!!!
<raghavgururajan>nckx: Regarding GNOME 42. I am not sure.
<unmatched-paren>idea: guix lint could catch unused imports
<unmatched-paren>although it might be a bit slow since it would have to check every defined and used# variable in every module...
<roptat>it failed :/
<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 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> <- my improved cproc patch isn't appearing
<unmatched-paren> <- but my qbe ones are
<unmatched-paren>it's been ~7mins
<unmatched-paren>the email workflow is great, when it works :( when i send email to it generally work almost immediately, but for some reason i have to wait a long time before mail appears on
<unmatched-paren>s/ work / works /
<unmatched-paren>sneek: later tell civodul: I've sent a massively improved version of the qbe patch to the mailing list: and cproc, although at the time of writing the cproc package hasn't appeared on the mailing list.
<sneek>Will do.
<unmatched-paren>sneek: botsnack :)
***EMax`0Mancer[m] is now known as emacsomancer[m]
<unmatched-paren>ohhh the issue was archived so it did not accept mail
<unmatched-paren>that's a bit strange, but i guess there must be a good reason?
<emacsomancer[m]>I noticed some pipewire things in a recent update/reconfigure - is guix going to switch to default pipewire at some point?
<unmatched-paren>emacsomancer: One day...
<unmatched-paren>but obviously switching the sound subsystem is a lot of work :)
<emacsomancer[m]>how easy/hard is it to use pipewire on guix right now?
<unmatched-paren>no idea -.o.-
<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
<dirtcastle>except the kernel?
<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.
<jpoiret>emacsomancer[m]: pretty easy
<jpoiret>cuda nix™
<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.
<dirtcastle>jpoiret: that's really the state I'm in...
<jpoiret>maybe your argument boils down to "Why use any other distro when Guix is clearly superior?" then, well, right :p
<dirtcastle>hmmm yeah jpoiret
<AceTheMercenary[>jpoiret: Agreed why use any other distro! ha!
<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?
<jpoiret>yes, it's just a .scm file anyways
<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>noted. thanks for your time everyone!
<dirtcastle>does guix on a foreign distro require shepherd?
<unmatched-paren>i'm not sure whether guix home works on a foreign distro either tho
<dirtcastle>hmmm. so the foreign distro's init system have to used to manage guix too?
<unmatched-paren>never tried it
<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
<unmatched-paren>usually guix foreign distro packages are pretty outdated tho
<unmatched-paren>guix updates very often
<dirtcastle>just now checked what home is. It said you can use it on foreign distros
<dirtcastle>jpoiret: i used the install script.
<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>the_tubular: hello
<the_tubular>Hey atka
<the_tubular>How are you ?
<atka>I'm doing okay, yourself?
<atka>the_tubular: any guix progress
<the_tubular>Slowly but surely
<the_tubular>I started reading r6rs recommenced by someone here to get better inScheme
<the_tubular>How about you ?
<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>my tasks for the day
<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
<the_tubular>Yeah, that's not really the 'guix' way
<atka>I'd like to use guix native containers eventually
<atka>the_tubular: how so?
<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: 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>You are just using alpine's apk underneath
<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