IRC channel logs
2025-07-13.log
back to list of logs
<fractalization>hey, I'm trying to package a rust package that requires newer features in rust, but the latest version on my system is 1.82. 1.85 was marged 4 months ago, according to https://issues.guix.gnu.org/77149, and I have not been using guix for 4 months, does anybody know why this could be? <fractalization>srry, I'm new to irc and I think if somebody responded it got hidden bc I was trapped in the help screen? Will need to try a different client lol <jakef>does anyone develop lua projects using guix? does guix support it well? <jakef>(asking as someone who knows nothing about lua) <Kolev>What is the code for the installer, and can it be used for other programs, like a G-Golf Adwaita installer? <Rutherther>sneek, later tell fractalization: I believe rust 1.85 has been merged to rust-team branch only and that rust-team hasnt been merged to master since. There have been a lot of updates to the rust packaging on that branch as well <dodoyada>aren't rust packaging changes coming 'soon'? <Rutherther>I dont know what you mean by coming and by soon. They already are done... And when they will be merged to master, I do not know <Rutherther>Since there isnt even request to merge it for qa, I doubt it will be soon though <nomike>I'm still working on that prusa-slicer update, which was challenging at times. But I finally got it working. I've already did some code cleanup and I'm now cleaning everything up in three git commits. <bavier>nomike: in your commit message, you can refrain from repeating '[source]' etc when there are multiple changes; just write them as multiple sentences. Otherwise lgtm. <futurile>nomike: if you have comments about the commit format, seems to be a good discussion about it on guix-devel atm <luca>Is there anywhere where I can read more about shepherd's logging capabilities? As far as I know all it does is print everything to one log file, but I assume there's more to it <ekaitz>luca: in the shepherd documentation? <luca>right, of course. I was searching for guix. Thanks! <andreas-e>Hello Guix! Is it just me, or do others also suffer from incredibly slow download rates from bordeaux? Since yesterday it is between 30 and 40kB/s. <PotentialUser-81>andreas-e: I'm not suffering from any such problem, even though lately most of my connections have been on public WiFis: I've suffered slow download speeds, but not THAT slow <futurile>PotentialUser-81: you need the sddm service module which I don't think is in your config <andreas-e>PotentialUser-81: Thanks for the confirmation! <andreas-e>I wanted to say the same, (use-service-module sddm) <PotentialUser-81>futurile, andreas-e: If I try to explicitly do that, it complains about xorg-server bering provided more than once <PotentialUser-81>Apparently `%desktop-services` defines `gdm-service-type` (I had assumed it was `gnome-desktop-service-type` that defined GDM) <PotentialUser-81>All I needed to do was `(modify-services %desktop-services (delete gdm-service-type))` <apteryx>how is video acceleration in Guix working these days? Is mesa transparently handing off to vdpau/vaapi or similar? Or do hi still need to have e.g. libvdpau-va-gl installed in my user profile? <nomike>futurile, thanks for the advice (it was regaring the guix-devel discussion about the commit format). I haven't read all of that yet, but as fas as I understand it's more like a generic question about how we want the format to be as there is a discrepancy between documentation and what we're actually doing. <nomike>Let me ask some more specific questions (https://paste.debian.net/1385623/): At the "inputs" section of my package update, I'm downgrading "opencascade-occt" and independently I'm adding "webkitgtk-for-gtk3" and "webkitgtk-with-libsoup2". The question is whether I should have two lines prefixed with "[inputs]: " or whether I should combine both changes within one "[inputs]: " clause. <futurile>nomike: I put it into one line, just something like [inputs]: downgrade opencascade-occt, add webkitgtk-for-gtk3 and webkitgtk-with-libsoup2 <futurile>nomike: honestly, I do what I think it easiest to read and understand <futurile>nomike: then if the reviewer asks for it to be some other way I just do that heh heh <nomike>And secondly: Downgrading an input is something less common. Another commit in my patch includes a new package "opencascade-occt-7.6.1" and I've included a comment in the code, explaining that prusa-slicer has a hard dependency on that specific version as they state all newer versions have a bug with the calculation. The comment includes a link to the commit and in that commit a source comment further explains this and links to an <nomike>So while that downgrade is somehow explained in the package for opencascade-occt, I feel like I should add something to the commit message of prusa-slicer, to explain why this input was downgraded. <futurile>nomike: yeah, that's a bit more problematic I think. <futurile>nomike: is there a specific team looking after the package you're dealing with? <futurile>nomike: basically I think the commiter will want to decide whether there should be a package variant, or the other package should also be downgraded <futurile>nomike: I think you'll have to flag that to your reviewer <futurile>nomike: since it's only one package it's probably not that big a deal <futurile>nomike: at the very least there should be a comment within the three packages that are now 'linked' as they have to be kept in sync <futurile>nomike: so there's some others in the archive like that - but it's normally something which is a sys package and then some lib that builds from it - if that makes sense <nomike>prusa-slicer is a 3D printing slicer tool within engineering.scm. The current version is 2.7.1 which is from 2021 and is barely usable nowadays as it's as far as I know before they switched to their new modular config system. So there are no new config updates for that version and current 3D printers are not supported. <nomike>So I don't think there is someone maintaining that package. <nomike>But yes, I will write commit comment, file an MR on codeberg and see what the reviewer has to say. <lockbox____>Could also just make a package specifically to be a dependency to prusa-slicer <lockbox____>Since yeah they've expressed no desire to update from that version since they'd have a ton of rippling changes to make since they rely on buggy behavior aiui <futurile>nomike: according to etc/teams.scm engineering.scm is looked after by the 'electronics' teams - there's 3 people in it - perhaps one of them will respond if you add the electronics team tag <nomike>futurile, thanks. When I submit a PR on codeberg the relevant people receive a notification automatically as it looks like :-). <futurile>nomike: oh yeah heh I'm behind the times - still thinking in terms of email patches - that's going to shorten my howto notes a ton =-) <ekaitz>nomike: I confirm, I got the notification <nomike>BTW: Something that's odd: `(define foo (package (inherit bar) (name "foo"))` works fine. If I want to create a hidden package I have to write `(define foo (hidden-package (package/inherit bar (name "foo")))`. Is this intentional that one has "(inherit)" and the other "(package-inherit)" and that the nesting is different, or is this due to historical reasons? <futurile>nomike: I think I know there's a difference but I can't remember what it is <futurile>it's a bit of an odd thing because it's not real inheritance, you're messing with the record fields really <futurile>people have various things to say about it on guix-devel <identity>(package/inherit pkg) is (almost) the same as (package (inherit pkg) (replacement (package-replacement pkg))) <identity>it should be called package/replace really <nomike>Cool. I'm mostly doing learning by doing on this one. On a PR I was told to make a package hidden, so I changed "package" to "hidden-package" and was then very confused why guix complained about "Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f)'." which is totally unrelated to what I'm doing right now... <nomike>I searched for other packages looking similar and copied what they are doing, but I didn't find anything specific about that in the manual. Shouldn't this be documented somewhere? <orahcio>Hi, somebody can help? Is there a more Guix-like way to provide a string with the bash package's path? https://paste.debian.net/1385760 I gave a simple string to the initial-session field, maybe use (file-append bash "/bin/bash") instead