<Luk6655>There is possibly a much gentler way to get to know it. Install on top of another distro in a user's folder. Use it for package management. Spend some time using it, getting to know the language etc, then try the os. But the promise of versioned system config is an enticing one for me.
<KE0VVT>Luk6655: Guix on Fedora isn't nice, either. It triggers loads of SELinux errors.
<Luk6655>I see, I'm a Debian (and more recently Ubuntu) user mostly so if I fail with the os I can choose the alternative.
<Luk6655>It appears the gdm-locking x11 is not a guix thing either. It is just gdm.
<oriansj>vagrantc: I could but it wouldn't save a step
<oriansj>as the steps result in building all packages from source
<ajarara>Is building for every arch in `guix build --list-targets` done implicitly somewhere (CI?) for incoming contributions?
<podiki[m]>ajarara: I believe only accepted patches or ones on certain branches (merged by committers) are built by the CI, there may be an unofficial ones that builds everything submitted to guix-patches, but I'm not sure
<podiki[m]>but the CI for the master branch does build for every system, some more successfully than others
<oriansj>I'll have to update the procedure in the next test cycle
<KE0VVT>apteryx, oriansj: wget is included in the installer image, yes.
<oriansj>well that gets steps for a guixsd setup down to 12
<allana>Hi #guix! Quick question, say that I have a default profile and a configured guix home. Is it safe to remove all packages from my default profile? I'm trying to manage all of my user's applications in guix home, but I sometimes experiment with unfamiliar software using imperative installations that affect my default profile. Right now it seems that if I just "guix home reconfigure ..." it's not enough and I need to also "guix upgrade
<allana>..." in tandem. I have been holding on to this question for a while now, so I don't have any specific examples of actual problems.
<lilyp>allana: All packages that you're currently managing with guix install etc. would need to be transferred to guix home and managed declaratively
<allana>I probably have dual packages installed in both my default profile and guix home.
<mange>I also try to do all my experimenting with unfamiliar software using guix shell, to avoid polluting my profile unnecessarily. It doesn't work for everything, but it works for most things.
<lilyp>"dual packages" cost little, they're but an extra symlink
<klm>rekado_: I see - it seems guix-patches is quite active. Thanks for the link, that's a nice and tidy UI.
<lilyp>klm: #:tests? #f smells eww, you'd either want to clarify that there are no tests or try to run them
<lilyp>recursive checkouts are not great either – even if there's just two packages and they're probably forks for solvespace you can append "-for-solvespace" to the package name and hide the package
<klm>lilyp: That's a copy-paste from another cbuild package, I good to know tests should be run. Let me fix that.
<lilyp>deletion of bundled sources goes into a snippet, not a build phase
<lilyp>"free (GPLv3)" is gratuitous information; all Guix packages are free
<klm>lilyp: That is great feedback, I wasn't sure how to handle that. recursive #t didn't feel right since it downloads all the submodules - not just the two I needed as well. I will fix that too and update the ticket
<klm>lilyp: haha true :-) also, copy-paste from the website. Will fix that as well.
<klm>lilyp: I should remove the line `tests #f`, right? Not `tests #t`, they're on by default I presume?
<lilyp>the default is #t for native and #f for non-native builds – you'd brick the latter if you set #:tests? #t
<klm>lilyp: So that's `(define mimalloc-for-solvespace ...` right above the define-public solvespace package definition?
<klm>lilyp: Oh, I see. So never `#:tests #t`, good to know. Thanks
<klm>lilyp: And also, are all these 3 changes one single commit or multiple? Sorry for the question bombardment :-)
<lilyp>also "right above" is debatable; if there's no package at all currently, that's fine, but if like in ffmpeg-for-stepmania the package already exists elsewhere, moving it close and inheriting should be preferred
<lilyp>(close to the package it inherits from, that is)
<lilyp>also, I'd try building against upstream mimalloc and perhaps submit a package definition for 2.0.6
<klm>lilyp: Yeah, I was just looking at that. Solvespace 3.1 is like 4 commits behind the official mimalloc 2.0.6 so I think I'll try that (instead of 2.0.5-74)
<klm>lilyp: Thanks so much for your feedback, very much appreciated!
<Luk6655>I'm getting a failure to build gdm on guix system. Error is (in the build log) polkit-object-1 required by accountingservice not found
<Luk6655>Has anyone seen this? It may be just my system, because it worked yesterday, and gdm wasn't updated since tgen
<Luk6655>I have no idea what's going on, I reverted to barebones system, I run gc to delete everything, and after redownload gdm still fails to build complaining it can't see accountingservice. I think this is a guix bug.
<Luk6655>Just a sec, typing those is not that fast
<jessicata>The "guix build /gnu/store/8bxis71d7lpk7mrwb3w2qn7qi8g4zr7r-gdm-40.1 " command worked for me. However my "guix system reconfigure" tries buildding "/gnu/store/68m0z092hr98v9z5rxs9jkcb8xw9966w-gdm-40.1.drv" which fails.
<Luk6655>I tried the original again and it seems to have succeeded, but what now? Am I OK doing reconfigure until there is another commit in guix channel?
<vldn>yeah mh.. the guix build command pulls the sub into the store, but reconfigure still trys to build the newest from the channel
<Luk6655>Let's say i force a specific commit of a channel and leave it like this, will it keep using it?
<Luk6655>I mean in channels.scm, if I set a specific commit for the guix channel, does this kind of guarantees this problem doesnt happen again?
<vldn>maybe a dependency updated thats why the sub is generated new and sadly not built to the end.. but i don't know.. i don't know how the sub avaiability is working too :( if everything is still the same since the last built i think it should give us the suceeded gdm and not just the last builts if it's the way it's working
<vldn>if you pin the channel to a commit you pull this specific git channel commit
<Luk6655>Jeez, I think I start seeing disadvantages of this system
<vldn>if there is something that can not build due to failure or subs are not avaiable anymore, or could not be built like gdm this time then there is no guarantee nope :D
<vldn>but with some logic guile could check the site like we did and get the commit for you
<Luk6655>I'm trying to figure out how was that successfull build built, based on which commit?
<Luk6655>I thought as long as there are the same inputs(the guix channel commit) there should be no variability in the build process, is the issue here that sometimes it works, sometimes fails for the same commit?
<vldn>and now needs a new inputs thats not there till someone like you finds out that it doesn't built anymore
<Luk6655>vldn: Im just starting with this system, I was planning to start slow... Rather than go deep into troubleshooting various failures, but it seems that's all I've been doing last few days
<Luk6655>vldn: well, you say this, but **all** dependencies are in the guix channel, last commits are yesterday(that one i suspect) then 2 weeks ago, so if I pin the commit to prior to yesterday it should just work, unless what I mentioned before happened
<Luk6655>Oh well, at least I don't have to throw out all of the config I wrote, because that's what I have been doing trying to "fix" this.
<davidl>Luk6655: a robust "rebuild everything" is a very computation-costly task. It should be possible though, that when you change a package, you search the package graph for all dependent packages and rebuild those locally, if anything fails, you should perhaps submit related patches.
<Luk6655>davidl: computationally costly? If there were commits daily, then agreed, but every few days? Not so much. Pushing this testing on unsuspecting users is not ideal. A sort of compromise could be had by having a dev and a prod branch in the main channel.
<vldn>yeah guix system could be more user friendly from the start
<vldn>with a bit more scripts and manual i think it's not soooo hard
<Luk6655>Is there an example somewhere that shows the syntax of channels.scm that pin guix to a commit?
<davidl>costly - if you trigger a full rebuild of every package for every commit it takes a lot of computational power and time to complete. I agree it would be nice with a stable channel. I don't know how viable it is to maintain. though. To trigger rebuilds on dependent packages only is more viable, and I wonder if it's viable to do some of that effort by the submitter - to invoke some script like "rebuild-dependents.scm" before submitting patches
<efraim>i'll check master, but I think it was core-updates
<efraim>I mostly checked with --with-inputs=openssl=openssl@3
<Luk6655>Also to correct something I said before, it appears there have been a lot more than 3 commits since my yesterday's working setup. Just that those were all commits with old dates that were probably approved for merge yesterday. So definitely much more than 3...
<mubarak>pashencija[m], Cairn, After so may tries I was able to install GNU Guix successfully. UEFI didn't help. yesterday I changed the partition table to MBR and I enabled toggled bootable flag on. In the past I remember when I installed Guix 1.0 I didn't have to set the root partition as bootable and the system boot successfully after rebooting from the
<apteryx>help to fix that would be more than welcome
<podiki[m]>apteryx: great getting the lightdm service finally done! a nice addition
<apteryx>podiki[m]: yes! I'm a bit annoyed the session switcher doesn't work (top right menu is not populated for some reason), but otherwise it works great and the VNC integration works too.
<podiki[m]>I used lightdm a while back (on Arch), might try it out again on next reconfigure
<podiki[m]>in other "lots of packages" news, I managed yesterday to get peroxide packaged and working; it is a forked and stripped down version of the protonmail bridge, much more manageable package list
<podiki[m]>(i.e. only ~1300 lines of go packages, not 3k)
<bdju>can anyone try to update the minetest package to latest stable?
<bdju>looks like it's not as simple as changing the commit. wasn't able to use --with-commit= to install a newer version
<rekado_>daviid: if you have any ideas about why g-golf doesn’t work on Guix, please do share
<rekado_>your messages seemed to indicate that you think this is somehow our responsibility to fix, but I don’t think we can do much here because we don’t know how it’s supposed to work.
<lilyp>rekado_: From my experience with Guile-GI, I suspect it might have something to do with GI_REPOSITORY_PATH and grafts
<chris314>Hello, It's my first post here. Hope this is not off-topic. I currently have a lenovo T400 with libreboot and I would like to buy a new laptop and install gnu guix on it. Do you know of a model that works with the linux-libre kernel?
<lilyp>chris314: all the RYF laptops work, plus there's h-node if you know how to navigate it
<rekado_>lilyp: FWIW guile gi works fine in the same environment.
<raingloom>I think systemd has targets for shutdown and suspend and such. As far as I know elogind isn't integrated into herd that well.
<chris314>@luk6655: Yes, that's what it seems to me.
<chris314>I bought a T500 from Minifree (which is the base of libreboot) and the version I received has some elements that do not work with the linux-libre kernel. On the tehnoetic site (recommended by RYF), there is also a T500, so I doubt that everything works with the linux-libre kernel...
<Luk6655>raingloom: I'm just reading that elogind can read such scripts if they are in /lib64/elogind no doubt that folder will be different, but hopefully the functionality can be used.
<raingloom>There might be an elogind config option that lets you run custom code, but if there is, it's not exposed by the shepherd service.
<podiki[m]>nckx: any tips/best examples for service writing? i packaged hydroxide (protonmail bridge) and it would need a service: create some files/folders for configs, cache, that I think need to be just root (or some special user) controlled
<podiki[m]>(gnu services configuration) was mentioned for the configuration record making
<raingloom>"freedom" is not some abstract thing that's good by itself. A libre ISO that doesn't boot on someone's old netbook because it's missing some proprietary firmware will by definition restrict the actions the user can take.
<raingloom>But if someone can now install Debian instead of Windows, I'm pretty sure we'd all agree that's a good thing.
<raingloom>It's bad that non-free firmware is necessary for some hardware, but putting your head in the sand and ignoring it won't make it go away.