IRC channel logs

<luke-jr>isn't there a straightforward step-by-step guide to build Guix from nothing yet? :| (can't find one at least, and the bits and pieces don't work)

<elevenkb>How often do y'all's reccommend running guix pull?

<nckx>Such a guide would be very welcome.

<nckx>elevenkb: Me? Daily.

<nckx>Other opinions are surely available.

<nckx>‘guix pull’ only makes much sense if you're installing and/or upgrading packages afterwards, or at least looking over the available updates.

<nckx>luke-jr: #bootstrappable is currently the best place to discuss that.

<nckx>luke-jr: Never mind, I see you're in there.

<luke-jr>nckx: it describes a process, but there's no step-by-step instuctions, and actually trying to build Mes seems to always fail

<User86>Hello

<User86>Is there anyone?

<char[m]>What's up

<User86>All good?

<User86>I'm new to Guix, to the GNU community actually

<char[m]>Guix is pretty neato. Have you installed it yet?

<ChocolettePalett>I want to contribute to "GNU/Guix", but my only email (electronic mail) address is "GMail" so I'm afraid of Richard M. Stallman disappointing in me if I do contribute using such an address

<User86>Sorry, I don't know what neato means. Yes, l already installed it, only my network card was not recognized, but everything is fine, l use the etherlink cable

<User86>Sorry for my English, I'm using a translator

<ChocolettePalett>User86: Mine wasn't recognized as well, but I don't consider it a major problem because you can buy a USB Wi-Fi adapter that has Free—as in freedom—drivers for GNU/Linux

<char[m]>ChocolettePalette: You can just make a new email with some other service.

<podiki[m]>ChocolettePalette: there is no email address discrimination here; plenty of contributors use gmail

<User86>ChocolettePalett: I handn't thought of that possibility, a WI-Fi adapter will help me a lot, thanks

<char[m]>Also RMS is involved with guix to my knowledge.

<apteryx>ChocolettePalett: please let not be your email provider an impediment to contributing to Guix ;-)

<apteryx>char[m]: not to my knowledge

<apteryx>(not directly at least)

<podiki[m]>apteryx: just a heads up for your elogind branch, i'll be committing the mesa-updates to master so you'll want a rebase/merge for fresh subs after

<podiki[m]>(since I assume all the login managers and such, and more, will be rebuilt)

<apteryx>podiki[m]: alright, thanks for the notice

<User86>User86: Know any email address that is "GNU"?

<podiki[m]>apteryx: I expect a bunch of rebuilds on master since there were some failures in last mesa-updates build (failures of retrieving substitutes or something, not actual build issues) as well as from updates to master in last few days

<xelxebar>Ew. Think I might have figured out the ibus-anthy issue I've been having.

<apteryx>hm, login is broken when attempting to use the latest elogind: dbus-daemon[121]: [system] Rejected send message, 1 matched rules; type="method)

<xelxebar>Running `ibus read-cache` shows an Anthy component with exec command `libexec/ibus-engine-anthy --ibus`, but running that directly errors: ModuleNotFoundError: No module named 'anthyprefs'

<next4th>xelxebar: oh, that's a good finding

<xelxebar>Yeah, it's mysterious to me, though, why nobody else seems to be having this issue.

<next4th>maybe python is installed along with ibus, ibus-anthy or haven't use it at all...

<apteryx>nckx: hi! in your recent (2022) commit e315d9a8024, you wrote that using /etc/dbus-1/service.d is still necessary, but it looks like this shouldn't be necessary given a fix in 2019: 33f9778bc83

<apteryx>is it really not working? It should honor but etc/dbus-1/service.d and share/dbus-1/service.d since that commit, if I understand correctly

<bumble[m]>hey would anyone here recommend a fanless sbc for using with guix?

<apteryx>s/service.d/system.d/

<ryan77627>Heyo, I have a bit of a weird question. I'm trying to create package definitions for xdg-desktop-portal-hypr and am a bit stuck. I want to combine the meson and qt builders since you need to build this project in two steps. I can compile the desktop portal but cannot compile the qt helper app since I cannot find a QT install, no matter how I try to define it. Maybe someone can take a glance at my

<ryan77627>definition and make out what I was trying to do; point me in the correct direction?

<ryan77627> https://paste.lcomrade.su/Rit8T7RN is where the example can be found. thanks :)

<xelxebar>ryan77627: Would it be feasible to create two "subpackages", one using each build system, and combined the products in your desired package?

<ryan77627>xelxebar: It would, I was going back and forth debating whether to do something like this. I may try that, might be easier. Is there a general convention that packagers use in cases like this? I guess I'd make two non-public packages and then make a public "meta-package" of sorts that just inherits the outputs of the two others... something of that nature?

<xelxebar>Yeah, just define your subpackages and define-public the end result one.

<xelxebar>I'm not really sure about conventions, though. It does seem like there should be a way to combine build systems objects.

<ryan77627>Yeah. I've seen it done both ways. Guess it's just a personal preference

<xelxebar>Looking at all build-system defs, I definitely don't see anyone combining others together: grep -Frh '(build-system' gnu/packages | sed 's/^ *//' | sort -u

<xelxebar>All just vanilla defs

<ryan77627>Hold up I'll get an example, I was basing mine off others, i am not good enough at guile/scheme to come up with that myself ;)

<ryan77627>Idea is roughly based off what was done here: https://issues.guix.gnu.org/63765#17-lineno13

<xelxebar>Ah, they're running cmake and then manually importing build steps from the python build system.

<xelxebar>That's actually kind of reasonable. Not working in your case, though?

<ryan77627>Nah, biggest issue is QT doesnt get defined properly and I am having trouble importing it to actually build the QT app.

<HiltonChain[m]>Have you seen (guix build qt-utils)?

<ryan77627>HiltonChain[m]: Funny to see you here, I'm actually the one that made that original PR eons ago. Got busy with real life. I have looked at it, probably have tried things with it at one point or another but my efforts have been scattered so I do not know what I've tried anymore.

<HiltonChain[m]>I think you can add qtbase to native-inputs, then reference it by #$(this-package-native-input "qtbase")

<HiltonChain[m]>qtbase-5*

<HiltonChain[m]>Ahh, qtbase-5 and "qtbase"*

<ryan77627>Damn... and just like that it built... Thank you for that! I've got to ask, where does one learn all the variables available and how to do this? Have you just been doing this long enough to pick up on it or are there things other than the guix handbook and scheme manuals I can look at? I'm relatively new still, been running guix for ~3 months now

<xelxebar>Okay, some more headway on the ibus-anthy issue. So ibus-engine-anthy essentially just calls share/ibus-anthy/engine/main.py, but the missing module 'anthyprefs' seems to sit under a different directory share/ibus-anthy/setup/anthyprefs.py.

<xelxebar>Running PYTHONPATH=~/.guix-profile/share/ibus-anthy/share ~/.guix-profile/libexec/ibus-engine-anthy --ibus no longer throws an error.

<xelxebar>However, the package still seems to contain non-guixified config paths. `ibus-engine-anthy -x` complains about not being able to find /usr/local/ibus-anthy/engine/default.xml.

<next4th>um, ibus-anthy/engine/engine.py has sys.path.append for its 'setup', no idea why that doesn't work.. oh PKGDATADIR is /usr/local/share/ibus-anthy, that explain your error too.

<next4th>xelxebar: it's in share/ibus-anthy/engine/_config.py

<HiltonChain[m]>ryan77627: What do you mean by "variables available"?

<xelxebar>next4th: Yeah, I tried manually copying ~/.guix-profile/share/ibus-anthy/engine to /usr/local/share/ibus-anthy/, but ibus-daemon still doesn't seem to start ibus-engine-anthy.

<xelxebar>And manually running ibus-engine-anthy still doesn't get Anthy to show up under the input methods.

<ryan77627>HiltonChain[m]: I never knew #$(this-package-native-input "package") was a thing. Maybe it was in the manual and i just read over it, but stuff like that. I guess figuring out the logic behind doing stuff like this just comes with time though

<xelxebar>I've gone ahead and created an issue: https://issues.guix.gnu.org/64941

<next4th>okay thx, i could debug ibus-anthy afternoon if you're not in a hurry :^)

<xelxebar>That would be an immense help! Thank you.

<nparafe>Hi there. "guix install Icecat" produces version 112.5 instead of 112.13 that is listed in guix packages website. Why is that?

<HiltonChain[m]>ryan77627: Ohh it defined in (guix packages) but not documented in the manual

<ryan77627>Ahh, so that's really one of those things you just get with experience I'm guessing. I have a long way to go still, but this is fun :)

<next4th>nparafe: i have 103.13, well you need 'guix pull' first to update the available packages database

<next4th>typo, icecat 102.13.0-guix0-preview1

<nparafe>Thank you for replying next4th. I also typed incorrectly 112.xx instead of 102.xx.

<next4th>no problem 🥳

<nparafe>After installing icecat I typed "guix pull" but icecat didn't updated...

<nparafe>Ah I need to install it again...

<podiki[m]>pull doesn't update anything but guix and guix's package definitions, not actual packages installed

<nparafe>Ok. Now I got it right. Thank you both for helping.

<podiki[m]>welcome!

<podiki[m]>mutter broke on mesa update but fixed now, so hopefully no disruption to gnome dependents

<xelxebar>Okay, confirmed that ibus-anthy is working at guix commit 6bbfcc359a111c257d4a9ea788027baddf4e7d64, so it's probably not just me.

<next4th>xelxebar: i pushed a fix just now

<xelxebar>next4th: Holy crap. That's fast! Checking.

<next4th>seems that data -> 2021 thing forbiden the regenerate of '_config.py', well i guess it better not ship those files in the release tarball..

<xelxebar>Pulled and building!

<xelxebar>next4th: Anthy on master HEAD working! You're a wizard. Thank you so much.

<lilyp>Is ibus now finally working without the dance?

<xelxebar>lilyp: time-machine dance? Yeah.

<lilyp>no, I mean restart dance

<next4th>no, i guess ibus still have cache issue..

<xelxebar>Yeah, still have to clobber the cache, but ibus-anthy is actually working now.

<fries>hi

<fries>guix chat

<fries>i heard of something called "antioxidant"

<fries>an "in guix cargo replacement"

<fries>do any of you have more information on that

<fries>that sounds very intresting

<ardraidi[m]>Hello Guix

<ardraidi[m]>I've submitted a few patches (64348, 64387, 64412) about a month ago, but there's no activity on them.

<ardraidi[m]>They're in 'gnu/packages/arcan.scm', which doesn't seem to have any maintainers team assigned.

<ardraidi[m]>Is there something I should do for them to be picked up?

<grim`>good morning! Continuing with the series of patches I want to make. Today I would like to contribute some fonts. Would any of you be kind enough to help me undestand if font packages ought to be in the guix repos? I'm a bit concerned about the licenses

<grim`>What do you think about this repo? https://github.com/powerline/fonts

<grim`>as you see the fonts seem to have adequate licenses but sadly they have different ones

<xelxebar>grim`: Wow, powerline fonts are already packaged? That's surprising. Looks like they're under silofl1.1 and asl2.0 so I'd say it's worth packaging!

<grim`>Well the package is just using the `font-build-system`. I'm not sure if you where expecting the package to build them 😕

<grim`>If its okay to have the package grab the ttf and otf files and installing them, yeah, it's packaged

<grim`>This is the list of licenses i have for the `font-powerline` package:

<grim`>(license (list license:silofl1.1 ;build artifacts (i.e., the fonts)

<grim`> license:asl2.0

<grim`> license:expat

<grim`> license:bsd-3

<grim`> (license:x11-style

<grim`> "http://dejavu-fonts.org/")))

<xelxebar>grim`: Oh, I see. It's just a bunch of patched font files sitting in a repo. Googlo Noto and friends are not built from source either, right?

<xelxebar>Probably worth sending a patch.

<grim`>ups. I've sent a few fonts but it seems that someone already packaged one of them. It was not there last time I've checked... How could I close the issue I've sent? Is it possible?

<grim`>xelxebar: Yeah. Nothing is built from source

<grim`>can I send a revised patch saying that the font was already packaged?

<grim`>I was about to send the following packages which are font collections `font-nerd-fonts`, `font-font-awesome`, `font-open-fonts` and `font-powerline`. I've done my best to fill the license but some are simply non existent on guix, as far as I know. Could someone tell me if its okay to send this packages to Guix? All of them should be composed for various freedom respecting licenses.

<nckx>grim`: You can close bugs by sending any mail to NUMBER-close at debbugs dot gnu dot org. Of course, please also explain why you're closing, for the humans amongst us.

<grim`>Great. I will do that with the one I sent for `font-iosevka-comfy`.

<nckx>grim`: As long as the licences are free, they are acceptable. (guix licences) isn't an exhaustive list of allowed licences. It's not even a complete list of licences actually used.

<nckx>apteryx: Hmm… Let's see if it comes flooding back to me…

<grim`>Okay. Good to know. I was also wondering if it is okay to have packages which just install fonts without building them from source. Like in the case of repos such as `github.com/kiwi0fruit/open-fonts` where the fonts are already availeable as .ttf files

<nckx>If there is a source, we'd really prefer to build it ourselves. Otherwise there's no guarantee (let alone convenient way) for users to modify the font, i.e. to actually exercise their freedoms.

<nckx>In practice there are packages in Guix that don't meet this standard, but it's not what we'd like.

<nckx>(You can hear me squirming, can't you :)

<grim`>I understand that but in the case of very big font collections it can take too much time to fetch the original sources of each one and know how to build them. Wouldn't it be preferable for the time being to offer the collections so newcomers don't feel like they are missing out by using Guix? I would also prefer to have them packaged from source but I'm a muggle with font wizardry 🥴

<nckx>Also: <Could someone tell me if its okay to send this packages to Guix?> Please, don't hesitate to send packages in good faith. Do check the licences yourself, but nobody's perfect.

<grim`>Will do then :)

<nckx>👍!

<ardraidi[m]>grim`: nerd-fonts is a mess when it comes to licensing. Some of my patches were rejected recently because of that. See #57149 for example.

<grim`>Alright. I will leave nerd-fonts out then

<grim`>thanks ardraidi[m]

<nckx>I don't really understand this paragraph: https://issues.guix.gnu.org/57149#1-lineno71

<nckx>As in, there is no data, only some (binary?) diff?

<ardraidi[m]>No idea. My patches are Emacs packages (#64771) which use nerd-fonts. I told myself I'll dig into it. Eventually...

<podiki[m]>howdy guix

<podiki[m]>i did the mesa (and some friends) updates to master last night, let me know if anyone has anything break (i fixed gnome already)

<efraim>mesa on powerpc-linux is broken, its unlikely anyone except me might have noticed ;p

<podiki[m]>efraim: taking a quick look on CI it is from wayland-protocols not building, but the log is just a failed download i think

<podiki[m]> https://ci.guix.gnu.org/build/1660701/details

<podiki[m]>or did you build locally?

<grim`>Should I package `python-fontmake` under `gnu/packages/python-xyz.scm`?

<HiltonChain[m]>How about putting it into (gnu packages fontutils)

<nckx>ACTION agrees.

<viaken>Trying to build a customized installer image, I (define foo (operating-system (inherit installation-os))), but when I tried to (services (cons (service (openssh-service-type)) (operating-system-services installation-os))) it threw "more than one target service of type 'shepherd-root'".

<viaken>Does instatiating an OS definition create some sort of shepherd-root singleton?

<efraim>podiki[m]: powerpc-linux, not powerpc64le-linux. I have an iBook G4

<HiltonChain[m]>viaken: You may use (operating-system-user-services os) instead, since (operating-system-services os) is (operating-system-user-services os) + (operating-system-essential-services os)

<podiki[m]>efraim: oh. Actually breakage in Mesa then?

<apteryx>ACTION attempts to dig why share/d-bus/system.d D-Bus service files are apparently not picked up despite the code having an includedir for it in 'dbus-configuration-directory' from (gnu services dbus)

<apteryx>it's hard to introspect the problem when login is broken though...

<viaken>HiltonChain[m]: That'd be it! Thanks!

<grim`>HiltonChain[m]: will put it there

<HiltonChain[m]>I think it could be named to fontmake? without the python- suffix, since it's not (actually I'm not sure...) used as a Python library.

<HiltonChain[m]>prefix*

<efraim>podiki[m]: possibly. I don't know if anyone is actually testing it. there was only 1 test failure

<podiki[m]>efraim: we have/had some tests disabled before e.g. on i686 too. we can disable the test on powerpc, if you think that's the right way to go. conditional on arch shouldn't cause rebuilds for everything else (we can test, otherwise graft and/or fix on next update)

<podiki[m]>efraim: up to you, happy to help get things fixed!

<grim`>HiltonChain[m]: I've just sent the patch as `python-fontmake`. Should I send a fix removing the python part?

<sneek>nckx: wb :)

<HiltonChain[m]>Are those propagated-inputs necessary?

<HiltonChain[m]>I think they can be moved to inputs

<grim`>Already sent the patch removing the prefix

<grim`>HiltonChain[m]: if you are talking about fontmake I'm not sure right now. I packaged it long ago. I think used propagated inputs to avoid an error during the testing phase but I could be wrong

<grim`>HiltonChain[m]: I have to go now. The fontmake issue has the following ID 64957 if you think the native inputs are not requires we can look further into it. Cheers every one! Thanks for the guidance.

<cel7t>I installed Guix on a Debian box and ran an `install wayland` with it, however it ended up pulling libX11 as a dependency. Any idea why this happens?

<podiki[m]>cel7t: i don't know off the top of my head, but see https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-graph.html for how to look at dependency trees

<podiki[m]>nckx: I think you updated kitty in the past, have you looked at all since then? (there is now some go requirements :( )

<HiltonChain[m]>cel7t: It seems to be wayland -> graphviz -> libx11

<nckx>podiki[m]: No, I use feet now.

<nckx>Uh, foot. I have no idea why I typed that.

<podiki[m]>hahah

<podiki[m]>probably faster than using kitty power to get around

<podiki[m]>seems newer mesa broke kitty build but I didn't get far yet on fully updating kitty. i guess I'll go for last version before go was introduced and see if that works...

<apteryx>ah, the problem may be "policy" files rather than service files

<apteryx>IIRC guess our dbus-daemon is hard-wired to look at a fixed place, probably wouldn't consider includedir for that purpose for security reasons

<apteryx>and that fixed place is its sysconf configured directory under /etc/

<cel7t>Thanks Hilton Chain podiki

<podiki[m]>cel7t: welcome! you got the fish and how to fish :)

<pjals_fox>guix's ungoogled-chromium supports webhid, right?

<nckx>sneek: Thank! Have a botsnack.

<sneek>:)

<sneek>Welcome back nckx

<nckx>sneek: Long time no see!

<elevenkb>Hey there I'm interested in contributing code to GNU Guix but I have trouble deciding what to work on.

<elevenkb>Is there a link on begginer friendly projects?

<podiki[m]>Kabelo M'sobomvu Moiloa: no list exactly, but you can browse the issues on https://issues.guix.gnu.org/ look to update packages, contribute new packages, fix broken ones that don't build, etc.

<klm`>I can't get libfive to run. guix shell libfive -- Studio # doesn't work. this too: guix package -p foo -i libfive

<klm`>It appears GUILE_LOAD_PATH etc are set correctly, but I can't get passed the "no code for (libfive stdlib shapes)" error

<klm`>Oh, I see my libfive package definition is outdated. I'll try the newest one.

<klm`>The latest libfive works, sorry for the noise!

<Altadil>I can’t access issues.guix.gnu.org with Tor Browser anymore. Has there been a change in its configuration that blocks Tor ?

<nckx>Altadil: We have never deliberately blocked Tor nor is this likely to ever happen. What happens?

<Altadil>I get "The connection has timed out". The Guix website itself is still working fine.

<klovanych>Hello, is there already patch for emacs 29 version submitted ?

<nckx>klovanych: The ‘emacs-next’ package is version 29.

<nckx>I don't know what's blocking it from becoming the default, if anything.

<nckx>But I've been using emacs-next-pgtk for ages without issue.

<klovanych>nckx: thanks, will try with 'emacs-next' for now, then will probably switch to default one as soon as it will be updated.

<klovanych>in the release notes it is 29.1 and in emacs-next it is 29.0.91 don't know if there is any difference.

<maudefi>part

<apteryx>if I 'guix system build' some operating system, does the 'etc' directory under the resultant store output the one that gets mounted as /etc ?

<nckx>apteryx: Not mounted, no.

<nckx> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/activation.scm#n233

<podiki[m]>nckx: on updating kitty: oy! newer versions want to build some binaries with go (and that whole mess) and documentation with sphinx and some themes that use node in some way...

<apteryx>nckx: thanks. interesting. I've never wrapped my head around that /etc/static thing

<apteryx>so that /gnu/store/...-system/etc is the static part?

<apteryx>hm, not directly according to 'ls -al /etc/static' on my live Guix System

IRC channel logs

2023-07-30.log