IRC channel logs


back to list of logs

<raghavgururajan>> ‎lfam‎: raghavgururajan: Hm, I don't see how that commit could break booting
<raghavgururajan>I was confused too.
<raghavgururajan>system reconfigure and reboot are at commit 5d8c2b742c7bc105536af56b08edb5d3349412a8. At 189003c83ee04e1819245c861c1ba31597db537d, system reconfigure gives those warnings and reboot fails.
<raghavgururajan>*are fine at
<dstolfa>raghavgururajan: could it be that this commit caused a rebuild and therefore manifests an issue from another commit? i haven't looked into it too much but it's the first thing that popped in my mind
<lfam>Changing the download URLs doesn't cause rebuilds
<lfam>Or rather, it doesn't change derivations
<lfam>Something else has gone wrong
<dstolfa>lfam: at least you'll have a good story to tell once this is debugged... "have you ever seen the system not boot because an url changed in an unrelated file?"
<raingloom>is there any particular reason go doesn't use gcc's include paths?
<iskarian>raingloom, what exactly do you mean?
<raingloom>iskarian: nvm i may have messed up something unrelated.
<raingloom>i couldn't find any search-paths field in the definitions for go, which i thought was the reason i could build a module that needs sqlite, but it turns out i messed up something. it seems to be building now.
<iskarian>ah, I'm glad! For better or worse, go is pretty self-contained (except for cgo)
<muradm>hi guix
<iskarian>hi :)
<iskarian> looks like the strings in gnu-build-system aren't internationalized with G_?
***MidAutumnHotaru5 is now known as MidAutumnHotaru
<apteryx>anything on the build side cannot be internationalized at the moment
<apteryx>this comes from (guix ui) needing many Guix, which would be too much to pass to the build environment, IIRC
<apteryx>many Guix modules*
<dissoc>can a package in channel B depend on a package in channel A?
<podiki[m]>yes (but see advice at end):
<dissoc>thanks. looks simple enough
<qzdl>hi guix
<user_oreloznog>Hello guix!
<abrenon>hi qzdl and user_oreloznog
<abrenon>MysteriousSilver: doing your stretching ?
<user_oreloznog>Hello abrenon!
<qzdl>hey abrenon
<loquat>Hello everyone, Arch/Sway user considering switching to Guix. I have a lot of questions since I don't have a lot of time to go through the whole manual and before I do I wanted to evaluate if Guix is for me.
<loquat>I am not a developer, nor a Lisp expert but I use vanilla emacs and am familiar with the syntax.
<loquat>There are a few things I'd like to ask, considering the fact that Guix is a source based distro and places system files differently than most common distros.
<loquat>The first obvious question is whether you recommend the switch. I'm pretty familiar with the terminal, I don't use GUI applications so much anymore and I'm pretty good with system configurations. I don't have much time unfortunately, does the system help automate some configurations or should I add everything manually?
<loquat>I've never considered source based distros because of the build times but here I don't know if my hardware would take that long to complete the updates (I have an I5 2520M with an SSD and plenty of ram). Since I also care about the environment, keeping the computer on to compile for hours even when I'm not using it goes against the environmental aspect (I update my systems every day), so if it's
<loquat>often hours I'd rather avoid. I have read that there are also substitutes. Are these downloaded from the Guix sever or is it something like the AUR?
<abrenon>the whole system itself is rather like the AUR
<abrenon>all packages are equals, there's no fundamental difference between a package you'd make and an official package
<abrenon>except the channel it lives in
<abrenon>then, the guix servers indeed hold substitutes for all official packages
<abrenon>allowing you to directly retrieve binary packages
<abrenon>which you can still challenge if you like by compiling locally and comparing the outputs
<abrenon>I'm pretty sure you can add other substitute servers but I've never needed it myself
<abrenon>about the help to «automate» configuration, I'm not sure what you mean but I'd risk a no: the (declarative) configuration of the system *is* the system, there's nothing else to configure
<yoctocell>loquat: if you switch to Guix System (the distro), you can declare you system config in a scheme file, no need to manually fiddle with stuff in /etc
<abrenon>so for instance you don't have a tool to install emacs, you simply say it's supposed to be there in your configuration, and once you apply the changes your system contains it
<yoctocell>there is also on-going work on Guix Home, for managing user packages and configuration files, i.e., "dotfiles" <>
<loquat>Yes I want to switch to GuixSD. Regarding Sway, are there any additional configurations to do beyond the Sway config file or I have to declare that in the Scheme file too?
<loquat>With Arch I used to set the auto login and auto start of Sway. Is this difficult to configure with Guix?
<yoctocell>there is a guix home service for sway, you will use scheme to configure it, but if you don't want to do that, you can just put your sway config in a separate file and tell guix home to symlink it to ~/.config/sway/swayconfig or something
<yoctocell>I am not sure what you mean with "set the auto login and auto start of Sway"?
<roptat>loquat, you don't *have* to use guix home, whatever is configured in your ~, you can copy from your previous system, and it should work in the same way
<loquat>ok thanks!
<roptat>the rest of the system, that's not user software, is configured with a single scheme file, usually /etc/config.scm
<roptat>that configures hostname, timezone, file systems to mount, packages to install globally for all users, system services (a display manager, xorg, ssh, dbus, ...) and that's about it
<roptat>you can install sway as a user with "guix install sway" and start it, and configure it the usual way. The guix configuration is really about replacing whatever you did in /etc. guix home is optional and lets you replace whatever you did manually in ~/.config
<roptat>if you're not sure you want to make the switch to the guix system, you can have a taste of guix by installing it on top of arch, it won't conflict with your system because it's using a very different hierarchy (but note that it only happens because it installs almost a whole system, down to the libc, alongside your existing system)
<roptat>then when you get a bit more familiar with guix, you can decide if you want to go all the way and install the full distro :)
<loquat>Yes, I will take some time to read the manual thoroughly then I'll make the jump. Does someone use those usb adapters from Technoethical or Thinkpenguin? Because I don't have another laptop to flash coreboot and Lenovo whitelist only a few wireless cards.
<MysteriousSilver>coreboot isn't required for guix
<loquat>Yes but my Intel card doesn't work with Linux-Libre.
<loquat>Flashing Coreboot I could use an Atheros card with the free driver ath9k.
<roptat>I used to have a technoethical adapter, until it broke (I mean, it was crushed by a piece of furniture during a moving), it worked well though it was not able to pick up signal as far as other proprietary cards I used before
<loquat>Do you mind telling me what you use now?
<loquat>I should seriously consider flashing coreboot at this point because I'm far from the modem where I use my laptop.
<abcdw>Hey guix!
<sneek>abcdw, you have 2 messages!
<sneek>abcdw, ix says: could you make emacs-service configurable to auto-restart? Apparently <restart?> defaults to false, so when it crashes it stays down until manual restart
<sneek>abcdw, ix says: nevermind, it is true by default... not sure whats wrong, probably a shep bug
<qzdl>hey abcdw
<abcdw>ix: It is and it worked for me, recently I missconfigured something and it was disabled after a few restarts.
***MidAutumnHotaru is now known as MidAutumnMoon
***apteryx_ is now known as apteryx
<roptat>loquat, I use ethernet :p
<roptat>(and my laptop has the correct wifi card internally)
<loquat>got it. unfortunately my house is not wired for ethernet.
<loquat>how far did the adapter work?
<abcdw>Dear maintainers, review and merge please, I have a lot more things to send to wip-guix-home and would like to finish it before next Guix release)
<civodul>abcdw: hi! sorry, i had missed your earlier reply in that thread
<civodul>i'll take a look (i'll be going afk a bit and i'm not 100% sure i can make it before then)
<abcdw>civodul: Thank you!) No hurry, just a friendly reminder)
<abcdw>ix: Better ping me in the mailing list or via email, I check it more frequently than IRC) andrew at domain
<emestee>can someone explain to me how guile load paths are supposed to interact with guix profiles?
<emestee>e.g. guix install guile-xxx - how is guile supposed to reach the xxx package?
<ix>It scans all the modules in your guix version (including channels) for exported packages
<ix>There is no namespacing.
<roptat>emestee, the env vars are generated in etc/profile of the profile, but only if that profile has a package that need that variable
<roptat>so you need to install guile *and* guile-xxx to get it to work
<ix>Oh guile, not guix, my bad
<emestee>roptat: oh so I need to use manifests explicitly to generate the profile is what you're saying?
<roptat>no, I never talked about manifests. If you use a manifest for your profile, then make sure it declares guile along with guile-xxx, if you don't use a manifest make sure to "guix install guile" to make it work
<emestee>ahhhhh never mind I just found the problem
<emestee>my profile wasnt actually being loaded correctly
<roptat>I see
<civodul>emestee: see also the bits about etc/profile and search paths at
<roptat>so I found a surprising fix for ant-bootstrap on core-updates:
<roptat>then, I had some troubles with icedtea, but I just found a fix for that issue from Now, it's complaining about a missing sys/sysctl.h, which indeed doesn't exist in glibc anymore
<emestee>ok I am clearly missing something trivial
<emestee>roptat: you said 'only if that profile has a package'
<emestee>roptat: I install guile-xxx in that profile, the package is added to the manifest, but GUILE_LOAD_PATH is not modified and no symlinks are added to the profile itself
<emestee>am I missing something
<emestee>in this case it's guile-irc, yes I know
<roptat>"guix install guile guile-irc" should do it
<emestee>it doesnt
<roptat>then make sure to source "~/.guix-profile/etc/profile"
<roptat>that's where GUILE_LOAD_PATH and friends should be defined
<emestee>it is sourced, but guix doesn't seem to update it
<emestee>guile-irc isn't added to GUILE_LOAD_PATH
<roptat>oh guile-irc is not installed properly
<emestee>ooooh? how so?
<roptat>it's not in a versioned directory
<emestee>so the package doesn't specify it correctly?
<roptat>is should be in share/guile/site/3.0/irc, but it's in share/guile/site/irc
<roptat>yeah, the package itself is broken
<emestee>le blergh
<emestee>i'll patch it i guess
<roptat>rekado_, ^ :)
<emestee>but actually it also doesn't install itself to the profile in share/guile/site/irc either
<emestee>oooh no it does
<emestee>i just didnt use the correct find(1) options.
<roptat>mh, share/guile/3.0/site/irc actually
<roptat>oh no, share/guile/site/3.0/irc I was right
<roptat>nevermind :)
<roptat>and the compiled files should be in lib/guile/3.0/site-ccache
<emestee>i'm having a moment of dissonance because every fiber of my being tells me "it's not a bug, it's you"
<roptat>it's definitely the package
<roptat>it uses $(GUILE_EFFECTIVE_VERSION) to get that 3.0, but it's never set in the generated Makefile
<roptat>emestee, I sent a pull request to fix guile-irc at
<roptat>unfortunately, that requires adding pkg-config, so there's no build option you can use to build that, you'll have to change the package definition
<emestee>thanks, ill learn somethign from this
<roptat>well, the issue was that made use of GUILE_EFFECTIVE_VERSION, but that was never set. I used GUILE_PKG macro in to make sure it's set
<hiruji>Hi all, I was wondering how to find the proper commit for time-machine to fetch Icecat 60?
<lfam>One failure after another with qtwebkit! Too bad it takes sooooo long to build
<lfam>So far I'm testing fixes for incompatibilities with current Python, ICU, glib, and bison
<efraim>testing qtwebkit for fun or you actually have something that depends on it?
<lfam>Trying to fix it on core-updates
<lfam>gqrx depends on it transitively, and I do use that package
<lfam>It goes "qtwebkit -> python-pyqt -> gnuradio -> gqrx"
<lfam>It might be nice to see if pyqt actually needs it
<efraim>I was going to say to see if we can make a pyqt with qtwebkit and make the default be without
<efraim>like with qtwebengine
<lfam>qtwebkit is not really "ready" at this point. We are using some alpha release and it seems no current full release is in the pipeline
<lfam>And people are warning about it on oss-sec
<lfam>Seems unlikely that gentoo doesn't have gnuradio
<rekado_>roptat: thanks for the patch. I applied it.
<lfam>I noticed that matplotlib was failing on core-updates, at least yesterday
<efraim>lfam: As of current master there's no substitute for kmail or orange, out of all the packages which transitively depend on qtwebkit. I'll try building those two, and then remove qtwebkit and see what breaks
<lfam>I'm testing the build of python-pyqt without qtwebkit now
<lfam>(on master)
<lfam>I'm doing it on CI so there will be a substitute if it builds successfully
<lfam>It's /gnu/store/klsqrkab3nhdcd0syw0a4bxh2aifpwbf-python-pyqt-5.15.2.drv
<lfam>Alright, pyqt built. Now I'm going to try building out to gqrx
<lfam>Let me know the results of your qtwebkit tests efraim. I confirmed that the basics of gqrx continue working when qtwebkit is removed from pyqt
<lfam>I can also do these tests on CI, in case you'd rather let it happen on a really fast machine
<efraim>my machine is pretty fast. I think it'll be more of manual checking to see what builds but isn't functional
<lfam>I read that many qgis plugins require qtwebkit
<efraim>still waiting on openshot to finish, otherwise everything built
<civodul>i was looking at and wondering why reproducibility data is inconclusive for ~30% of packages on x86_64
<podiki[m]>anyone have any experience with go packages? failing to build one because it won't find module io/fs (isn't that a core go module?)
<cbaines>civodul, it's because there's data lacking for
<iskarian>podiki[m], I can help you troubleshoot
<cbaines>I'll populate it manually
<podiki[m]>thanks iskarian . I managed to manually make packages for a few go libs (they aren't working with the importer)
<podiki[m]>but now it is complaining on build that: cannot find package "io/fs"
<podiki[m]>is there a core go lib I need to set as input?
<iskarian>ah, which ones? I want to take a look and make sure there's no new issues with the importer
<iskarian>it shouldn't be; can you share the package definition(s)?
<civodul>cbaines: oh i see; is this due to the lack of notifications coming from Cuirass?
<podiki[m]>Let me put it all in a paste, I think the importer doesn't like v0 packages?
<civodul>(substitute availability on ci.guix is certainly higher than then 68% shown there for x86_64)
<cbaines>civodul, build data would help, because the Guix Data Service could then query for substitutes in the same way it queries, where it looks up outputs for successful builds
<podiki[m]>the first two packages I would think could be imported, but importer didn't like
<podiki[m]>actually just the first one didn't work
<podiki[m]>(I still did second manually anyway)
<iskarian>podiki[m], I fixed the issue with importing ( hadn't crawled darkman yet and needed to be told to do so)
<podiki[m]>and sorry it is a mess, wip with pieces from other packages in comments that can be ignored
<iskarian>now let's try to build...
<podiki[m]>guix import go doesn't work
<podiki[m]>(and i didn't know if/how it worked with gitlab to import, so also did that manually)
<muradm>hi guix
<podiki[m]>iskarian: `guix import go` was the command for a dependency (had a typo earlier in what I pasted, but still doesn't like it)
<lfam>podiki[m], iskarian: I would check if our version of Go includes that library
<lfam>For some reason, golang.scm has been rearranged to put the actual Go compilers in the middle of the file???
<podiki[m]>darkman go.mod notes go 1.16 which is what we have
<podiki[m]>let me check though
<lfam>No, our default version of Go is 1.14
<lfam>We have 1.16 but it's not used by default
<lfam>"(define-public go go-1.14)"
<iskarian>podiki[m], also, there is no such module, just
<iskarian>And a recursive import of darkman correctly gets xdg
<podiki[m]>ok, so I need to use newer go probably
<cbaines>civodul, is now more representative, the unknown portion for x86_64-linux is down to ~6%
<podiki[m]>guix import to doesn't work for me
<iskarian>try --with-input=go@1.14=go@1.16 to use the newer go
<iskarian>ah, they changed the module name: it's now
<lfam>I re-ordered golang.scm
<lfam>efraim: Got any ideas of how to test the change?
<efraim>I assume you mean qtwebkit not golang
<podiki[m]>iskarian: sorry what do you mean about adrg/xdg? the page exists, is that not the right guix import go form?
<iskarian>Yes, but if you click on "source" and you look at the actual go.mod, it says "module"
<lfam>efraim: Yeah. Sorry to be confusing
<efraim>I'd switch everything to pyqt-with-qtwebkit and remove qtwebkit from pyqt and then switch everything back to regular pyqt one by one after getting people who use them to test out the change
<efraim>I guess we could just drop qtwebkit from everything and add it back as people complain but that's a bit too hostile for my taste
<lfam>I can add that pyqt-with-qtwebkit package unless you've already written it. And then I can start the process by testing gnuradio / gqrx
<podiki[m]>iskarian: so what are the proper guix import statements for adrg/xdg and darkman? sorry still confused over what it wants for future reference
<lfam>Yeah... that's what I would do if it was just me ;) But I learned my lesson with adb / fastboot
<efraim>I'm on my phone atm, it's all yours
<lfam>Okay, I'll do it
<iskarian>podiki[m], `import go -r` gets all of them, but it also imports a newer version of dbus, which may or may not be necessary
<iskarian>`guix import go` for just xdg
<podiki[m]>thanks! think I lost track of all the iterations I tried, thought I did that
<podiki[m]>maybe does need the newer dbus version, is failing with no error message. let me try with the imports version
<iskarian>podiki[m], unfortunately I have to go for now, but I'll see if I can't figure this out; I think the io/fs is almost certainly a newer go feature that requires go-1.16, but the build still fails with go-1.16, and it's not clear why
<podiki[m]>I'm not seeing a clear error message currently on my end, but let me keep trying
<podiki[m]>thanks iskarian! darkman is a nice little project for switching light/darkmode that I've used on Arch, is very handy. will submit once I get it working
<lfam>iskarian: I'm not sure exactly what is wrong, but the reason we haven't updated Guix's default Go from 1.14 yet is that, in general, Go 1.14 is the last version of Go that works in Guix
<lfam>Our go-build-system needs to be overhauled
<lfam>It's a pity that "how Go works" changes completely every few years but that's how it is
<podiki[m]>darkman builds with go 1.16 at least
<lfam>That's great
<lfam>I used to know the details of this stuff intimately... I've forgotten them
<podiki[m]>thanks again iskarian! I'll have to test it does what it is supposed to and clean up the imports a little
<podiki[m]>my eyes are already feeling better, so harsh at night without darkmode
<lfam>There have been discussions on our mailing lists
<podiki[m]>lfam: so for something like this, just having certain packages build with go 1.16 is okay? or should it be versioned separately?
<lfam>If it works, it works :)
<podiki[m]>(e.g. the dependencies build either way)
<lfam>I leave it up to you
<lfam>I burned out on "Go in Guix"
<podiki[m]>this was easier so far than what I tried with Haskell....(which I need to go back to)
<podiki[m]>Haskell versioning and all that is an utter mess
<podiki[m]>cabal/stack/hackage/stackage/ghc ugh
<podiki[m]>so many different ways for it to work, yet it often gives me trouble
<podiki[m]>did get a nice up to date cabal build of xmonad on guix working though, that was fine
<lfam>I guess I don't use any Haskell software so I don't know :) I wanted to use some Go software so I helped get Go working in Guix. Turns out I bit off more than I could chew
<bmk>Hi, I'm trying to just create a file using etc-service and when I try to reconfigure I get "ERROR: In procedure symlink:
<bmk>In procedure symlink: Permission denied
<bmk>" in the bulid log
<bmk>**build log
<podiki[m]>I don't know much haskell either, just enough to use xmonad and to try to use a few other things (which is where I ran into issues to get back to)
<lfam>bmk: It probably means that the directory structure that you want to put the symlink into does not exist. Or something like that. "Permission denied" has a lot of meanings that don't necessarily have anything to do with permissions
<roptat>bmk, maybe share your service definition? that would be helpful
<lfam>Hopefully that means they got it to work :)
<efraim>Could also be the file already existed
<podiki[m]>anyone have tips on gtk themes and stuff when not using e.g. gnome on guix? are there some expected env variables I should set up?
<podiki[m]>(e.g. lxappearance doesn't see themes, though I see them in my .guix-profile/share/themes)
<leoprikler>podiki[m]: perhaps its some gtk2 v gtk3 thingy?
<podiki[m]>if I link e.g. ~/.themes to ~/.guix-profile/share/themes it shows
<podiki[m]>but since I don't have Gnome installed, is guix not exporting some env variables or something like that? I don't see any gtk in guix package --search-paths for instance
<leoprikler>XDG_DATA_DIRS should be picked up tho...
<iskarian>lfam, Go 1.16 works with all our packages now except docker
<iskarian>& I'm currently working on improving our go build system to at least match Debian's. I might be able to get go to reuse built artifacts without having to do something silly like mocking a goproxy
<iskarian>podiki[m], what was the fix?
<lfam>iskarian: Wow, that's great news!
<lfam>So we should update the 'go' package to refer to go-1.16, right?
<iskarian>Well, I think docker is rather an important package, so we should probably update that, unless we want to manually make those build with go-1.14?
<iskarian>I don't have the expertise with docker to update it; it's quite involved.
<lfam>We could always leave docker at 1.14 for now
<lfam>I think it's important to try to keep up with upstream Go releases. They only support the previous release from current, which means we are using a totally unsupported version right now
<lfam>Oh no, I'm mistaken!
<lfam>They support the previous two releases, so we are still good
<iskarian>I agree. They are about to release 1.17 actually, and I've been testing rc2. It's not nearly as bad as the 1.16 upgrade; there's only a couple packages needing upgrades/patches
<lfam>Nevertheless, they don't really support those old releases in a meaningful way
<lfam>For example, with security updates
<jackhill>iskarian: thank you for working on this important work!
<iskarian>aha, The Go Ethos (tm)
<iskarian>jackhill, Happy to help :) It's been... interesting.
<lfam>For example, no fix for this in 1.14: <>
<bricewge>podiki: I use the following service to have a consistent theme between GTK2 and GTK3
<iskarian>The three big changes I'm working on for the go-build-system right now are: 1. build all packages by default, rather than just the main package, and provide arguments to control what gets built 2. reuse built artifacts
<iskarian>3. use external linking by default for projects using cgo to avoid depending on a single GCC version
<yoctocell>raingloom, have you seen my idris2 patch (based on your previous idris2 patch)? <>
<jackhill>thoughts on how to track down 'guix deploy: error: program `/gnu/store/3lig4b2i1qaisg9yx8nbl0xp8hgh40a7-guix-1.0.1-15.0984481/bin/guix' failed with exit code 1' when running 'guix deploy -v3 config.scm'?
<jonsger>lfam: why is the commit date so old (2021-07-27) from your latest commits on master?
<lfam>jonsger: I'm faking the date to work around my PGP key having expired
<jonsger>sounds like a proper work around :)
<lfam>It's much easier than dealing with an offline master key and all that :)
<cyrozap>That sounds like something someone would say if they had stolen lfam's PGP key and were making commits using it.
<lfam>We'll never know
<lfam>They'd also have to make lfam disappear and fake the date on their end too
<lfam>Whenever I get around to fixing the key I'm just going to make it never expire
<lfam>`guix environment --ad-hoc libfaketime -- faketime '2021-07-27 12:34:56' git rebase HEAD --exec "git commit --amend --no-edit --gpg-sign"`
<lfam>Works great
<raingloom>yoctocell: i think so! i haven't tried it yet, didn't have much brain bandwidth for Idris lately.
<raingloom>huge thanks either way for working on packaging Idris 2 properly UwU
<raghavgururajan>Any thoughts on this issue (
<yoctocell>raingloom: ok, no worries :)
<muradm>under (gnu tests) there are good test examples, is there any way to run a test from arbitrary location on current system, just like "guix package -L /some/path ..." includes -L with path? or these tests can only be run on guix source tree?
<civodul>cbaines: re, nice!
<civodul>18% non-reproducible is roughly the estimation i had in mind
<civodul>we can do better :-)
*the_tubular reproduces himself
<civodul>looks like we could fix ^(ecl|rust|julia)- and that'd give us a nicer figure
*civodul reported bug for crate reproducibility issue
<civodul>looks like a low-hanging fruit :-)
<ruffni>what's the easiest way to start a program (i.e. kodi) right after auto-login (doesn't matter which dm)? is this achievable just from config.scm?
<civodul>ruffni: i suppose you could arrange to have a ~/.xsession file that starts kodi
<podiki[m]>iskarian: I used the imported versions (after disabling some tests); must have been needing the newer go dbus
<civodul>i vaguely recall someone doing it in the past (was it davexunit?)
<podiki[m]>iskarian: and can confirm darkman works, though would really need a geoclue agent, which I don't think we run (the agent is in the package, just not a service for it)?
<ruffni>where in the operating-system s-exp can i create a file? there's no such thing as package's #:phases, no? ;)
<civodul>indeed :-)
<civodul>you could do that via a Shepherd service that depends on "user-homes"
<civodul>though that sounds a bit heavyweight
<podiki[m]>roptat: thanks, did not know about profile-service-type. will check it out
<ruffni>civodul: well. it sounds like a good way to dive into services ;) thanks for the pointer!
<lfam>Regarding qtwebkit, I see there is already a python-pyqt-without-qtwebkit package defined
<lfam>So, we might as well just start using that more
<lfam>And I filed a bug about qtwebkit failing to build on core-updates
<podiki[m]>ruffni: can't you do that also through things like .xinitrc or xdg autostart files?
<ruffni>yeah, ~/.xsession should execute automatically, though i don't know how to generate these kind of files from a (operating-system) block
<ruffni>i could create them with a one-shot service which requires user-homes
<yoctocell>ruffni: it's probably something that guix home should allow one to do
<yoctocell>it's basically guix system but for user packages and dotfiles in ~/.config
<yoctocell>it hasn't been merged to guix proper yet, though
<ruffni>i guess
<ruffni>is there a guix function to create files (like foo-file but not in the store)? or is guile's write the way to go?
<podiki[m]>I'm also intrigued by guix home coming up. right now I manage my dot files in org-mode files and use gnu stow, which I quite like
*ruffni is also stoked btw
<podiki[m]>so all my X set up, init, autostart etc., comes from one org file that tangles to .xinitrc etc
<podiki[m]>not sure how that will be with guix home, maybe the org files tangle to guile then? or to both for my non-guix system?
<podiki[m]>ruffni: what about the etc-service-type? that will create files in etc, and there should be options for once that always get sourced by X sessions (e.g. usually user files should source the system one too)
<ruffni>podiki[m]: that sounds interesting as well!
<podiki[m]>I'm just discovering profile-service-type from roptat's message earlier...
<podiki[m]>ah, I think I see! geoclue service doesn't add geoclue to system profile. if it is in the profile, that will give a geoclue agent autostart desktop file, to have the goclue agent (I was mentioning earler)
<mbakke>there is a commit on 'master' that touches 'ruby-2.7', which causes 6644 rebuilds when merged to 'core-updates-frozen' ... not sure what to do about it.
<civodul>mbakke: i think that's still okay, no?
<civodul>also, maybe we don't have much of a choice?
<mbakke>civodul: I suppose :-) we could revert it just to avoid the rebuilds, but it's still rather early in the cycle.
<civodul>mbakke: what makes ruby-2.7 deeper in the graph on core-updates? that's kinda unexpected
<mbakke>civodul: texlive
<ruffni>podiki[m]: extending etc-service-type would be an option if /etc/xdg (or anything related) were in $XDG_CONFIG_DIRS
<lfam>Assuming that affected packages do build successfully on core-updates, I think we have plenty of build capacity to handle these rebuilds
<mbakke>lfam: that's true; I mainly concider my own build capacity in these situations :P
<lfam>Right :)
<lfam>And I am only considering x86_64
<lfam>It's definitely an unusual case
<podiki[m]>ruffni: I do see /etc/xdg in xdg_config_dirs here