IRC channel logs
2026-02-14.log
back to list of logs
<folaht>Is system crafters the usual forum board for guix questions? <bjc>the mailing lists are the normal place. i don't think there's an official web forum <folaht>I notice that guix is very developer oriented. I want to ask newbie question for casual use. <folaht>Like how to change my XFCE theme to make it look like Manjaro. <bjc>there's a guix subreddit, too, but i don't know how helpful that'll be <bjc>it's not official, but people do read it <eikcaz>I see git-reference lets one pull just the base repo, or jump straight to the nuclear option of pulling recursively. Is there any way for more fine-grained control? <eikcaz>it seems iree has multiple llvm-project clones if you let it recurse... <ekaitz>sneek: later tell efraim idk what to do with the make-mesboot0's configure scripts failing with gash <apteryx>mra: could the transitive distributable? result be computed at build time and stored in the sqlite guix database? <apteryx>or in the .narinfo, and then a substitute server would know when not to consider/serve them <mra>apteryx: i do think that it could be computed at build time. you don't need it ahead of time, since you can't distribute an un-built derivation. and you have all of the data of the distribution at build time <mra>i'm not familiar with the sqlite guix database, but maybe that would be the correct place to store the data? using environment variables in the .drv files is a major hack, since this isn't data for the build daemon <mra>i also realised that another potential use-case for propagating non-distributability (at least for nonfree packages) is if you want to create a metapackage which may contain packages whose license terms don't permit binary redistribution <Kolev>Hi. It's been a day and `guix pull` is still stuck at `substitute:`. <Kolev>Haven't pulled in a year or more. Trying to do system updates. <anemofilia>Hey Guix, I've made a PR about three weeks ago providing support for plugin declaration and better support for abbreviations in home-fish-service-type, but it got no attention so far <anemofilia>Thought maybe it was a good idea to talk about it here, to gather some attention (and possibly someone interested in reviewing it) <apteryx>mra: since the goal is to avoid distribution from the publish side, having that information in a .narinfo seems like it'd make sense <futurile-afk>anemofilia: you could try looking at the home-fish service and see who committed it, if there were any reviewers etc. See if someone who uses fish is able to look at it basically <Rutherther>Kolev: then it likely got stuck and you should cancel it <mange>Rutherther: Any chance you'll have some time to look at my PR for conditional service extension some time soon? https://codeberg.org/guix/guix/pulls/6041 While I'm not in a hurry, I also know it's harder for me to make changes once I've paged it out. <mange>Or let me know if you're unlikely to and I can try to find someone else to review it. :) <htgoebel>Good morning. My today's learning topic is "docker containers with guix". <htgoebel>All the example I found in the source, manual and cookbook create a docker container images containing a complete system. Are there any examples for creating an image running only one process, e.g. the database server or the http-server? <mange>htgoebel: I don't know of an example, but I assume you want something like "guix pack --format=docker your-package --entry-point=/bin/whatever"? <htgoebel>csantosb: This creates a container including shepherd and using shepherd to manage services inside the container. shepherd in PIP 1 and the entrypoint. <htgoebel>mange: IC. Toally different commands. I will give this a try <mange>The example in the manual is "guix pack -f docker --entry-point=bin/guile guile" in (guix) Invoking guix pack. <htgoebel>mange: And makes sense, since "guix system container" means to create a system :-) <futurile>htgoebel: there's a thread about creating guix containers on -devel at the moment, maybe Simon Josefsson's projects will have some ideas I think he uses them for testing various things <htgoebel>futurile: Thx for pointing to this thread. Anyhow it seems to be about images containing Guix - which is not my aim. <folaht>Hello guix channel. I've got a question. I've recently moved from Manjaro to Guix and uhmm... I didn't do a decent job of backing up stuff. All I did was copy my home folder. I now have the issue of not having all my firefox bookmarks and passwords exported. Is there still a way to export/import these? Can I install firefox via flatpak and replace the .mozilla/firefox folder? I will assume that's where the passwords and bookmarks would <folaht>be located and not somewhere outside the home folder. <folaht>All I did was copy my home folder to a USB-stick and simply destroyed my OS in favor of Guix. <futurile>folaht: so do you have the `.mozilla` directory from your original Manjaro install then? <futurile>folaht: and you've placed it in your $HOME, so ~/.mozilla/ <-- is the one from Manjaro? <folaht>No not yet. I don't know what it will do since I've only got icecat. <folaht>guix doesn't have firefox except for flatpak, no? <futurile>folaht: OK, well I would move the .mozilla that icecat created to something (e.g. .mozilla-icecat), and move the Manjaro one to .mozilla and see what happens. <futurile>folaht: yup, your choices for a full 'firefox' are either nonguix channel or flatpak. <futurile>yarl: morning - yeah I was referring to your 'workspaces modules' trick, if it worked/you wrote a script for it I'd be interested to see it <yarl>futurile: yeah well that's not perfect <yarl>I'm still thinking about it <yarl>so, we are talking about the GUILE_LOAD_COMPILED_PATH hack in pre-inst-env, right? <yarl>I think it's ok if you only work on guile code and never run make in this worktree <yarl>The problem is that you are implicitly linked with another worktree, that's too much responsibility. <yarl>The goal is to be able to work on multiple worktrees, but then they're all linked to the same "compiled" worktree <yarl>But that becomes problematic then. <yarl>What ff you want to upgrade one of them? <yarl>I think a copy based solution is far superior <futurile>yarl: yeah, and my worktrees do land-up being at different points I guess <futurile>yarl: though, I wonder if that's just because it's such a pain to compile everything, I do it a lot less than I should heh <yarl>The problem is to get the list of files to copy, I'm not sure about that. The docs stuff is completely unknown to me and takes long to compile so can't be ignored. <yarl>I tried in the new worktree to run "./bootstrap && ./configure && make --touch | sed [...]" but I got problems with documentation related files. <yarl>And I am not sure if I can trust this anyway. <yarl>I think it would be really nice to be able as soon as you see something you want to hack on to edit right away in a new worktree and run the thing without having to wait for a long compilation. <futurile>yarl: totally agree, it's one of the reasons I have trees for weeks - I land-up waiting to have 10-20 patches stacked because the compile time is so long (also I'm lazy) <yarl>I think it can make you hesitate to work on a problem. That' the case for me. <futurile>agreed, just getting into a state to 'start work' is slow <yarl>problems with s/documentation/translation/ related files <folaht>futurile, I moved it. My issue is that I can't run any flatpak apps really. <folaht>So I started icecat and of course I just get the icecat setup from Manjaro which only contains a few passwords. <folaht>I installed three flatpak apps and I'm unable to run any of them. <untrusem>folaht: you might need their to write their application id to run flatpaks from shell <folaht>Okay, that allows me to run them from terminal. That's a step up. <roptat>sarg, pushed after updating the documentation, thanks! <folaht>Okay, I've been able to run firefox on flatpak with all my old passwords and bookmarks. My new problem is that the export buttons don't work. <folaht>They pretend to export to a file, but they don't. <folaht>Alright, I solved it with flatseal <jab>I know it's a bit of a pipedream, but I really wish guix would support OpenBSD. Actually, I wonder if guix started to support cosmopolitan libc, then I guess it could support OpenBSD. And guix would be able to start using pledge! <futurile>nmeum: it can be generally be difficult to get services reviewed. I don't have/know a Samba server for example. You could try asking on guix-devel, or see if anyone on guix-help using this application so would be willing to do a review. <nmeum>futurile: I see, thanks. note though that you don't need a samba server to this, it's a service for a webdav server. it can be tested with any http client: the PR also has a system test which does just that, you can run it with make check-system TESTS="sogogi" <futurile>nmeum: acknowledged - adding a system test is great <nmeum>my hope would be that, review-wise, it's sufficient to run the system test and manually look through the scheme code once for obvious mistakes. if I can make it easier to review somehow, feel free to let me know :) <gr1n>Hi! I've been using guix for some time and would like to contribute updating some of the packages that I use daily, I tried to do so for a Rust package but I'm not sure where to begin <futurile>gr1n: I would start by doing some reviews so you understand the rules. <futurile>gr1n: and potentially don't just start with Rust, the Rust build-system is a bit odd due to Cargo - so it helps if you understand it's foibles <gr1n>I know Rust and Cargo, I thought that updating a package would be the easiest first step <kestrelwx>Have you seen the article in the cookbook manual for Rust packaging? <futurile>gr1n: yeah the 'build-system' in Guix that deals with Cargo is what I mean <futurile>anyway, either way you can just go through PRs and then see the section in the manual about package rules - so it's pretty easy to start <gr1n>I'll check PRs! I did check the cookbook but it's for new packages and I couldn't see how to do it for an already existing one <gr1n>seems like there are some steps missing there <futurile>gr1n: there's a 9 part series on packaging, I should get back to it <yelninei>generated/hurd/release/32/libphobos2.so.0.112.0: ELF 32-bit LSB shared object, finally <gr1n>I did read your posts but Rust seems like a special thing? <gr1n>I changed version and checksum in rust-apps and I'm changing the cargo-input for bottom in rust-crates <gr1n>but going 1 by 1 is very tedious <futurile>gr1n: yeah the cookbook has some specific information about Rust packaging - because the flow is a bit different - there's also a blog post as it's a new way of doing it <gr1n>now that I got it to build, it fails because the latest rust version in guix is 1.88 and some of the deps need 1.89 <futurile>gr1n: yeah you can see in etc/teams.scm there's a rust-team (which you can join); teams do their development on a team branch; so rust-team updates everything there and then it's folded into master <gr1n>It works! it was pretty easy once I understood <gr1n>I'll check how I'm supposed to do the commits and PR <gr1n>thanks so much for your help futurile <roptat>hey, I think I found a path to update the default JDK to java 9! (instead of current java 8). I'm rebuilding all of java, and I don't have too many failures (I was able to fix everything by updating a few packages until now... fingers crossed) <ieure>roptat, That's good news. Seems like a pretty old version for a default, though, are there major issues with the newer (24.x) JDKs? <roptat>at least in java 11, there's a lot of APIsthat were moved out of openjdk, so that's a lot of packages to find and add <roptat>the major issue with java-9 is the module system, I had to rebuild openjdk9 with itself first. The second one is removal of support for generating java 5 bytecode, which can be fixed by updating packages, or having a few bootstrap packages build with java 8 <roptat>I'm having some issues with old xml packages... <roptat>oh, never seens that before: java.time.DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 0 in the reorder-jar-content phase (so the package built and created the jar file, but somehow there's an issue extracting or repacking it...) <roptat>ah the jar file has this metadata: 00-00-1980 04:08 META-INF/LICENSE <roptat>let's ignore the problem and try to update the package... <roptat>ouch, it tries to run maven for its tests <roptat>and the issue is not fixed at all <Rutherther>Kolev: when programs are stuck, just restart them. Chances are they just died but it did not propagate... <Kolev>Rutherther, I've restarted several times over the past few days. <Kolev>Computing Guix derivation... substitute: <Rutherther>that then seems to me like some kind of corruption that should happen like never, it always should show updating substitutes afterwards <Kolev>Uh-oh. And I don't know how to do that. <Kolev>Rutherther, thanks. Running. <Kolev>Is checking hashes going to take a long time? <roptat>it has to read the entirety of the store <roptat>running guix gc can help, because it reduces the amount of store paths it needs to compute hashes for <Rutherther>Kolev: that depends on how much you have in your store and how fast your computer is <Rutherther>then I have no idea what the issue is and I doubt it will get unstuck when it gets stuck on 'substitute:' <Rutherther>what is the command line of the guix-daemon process? <Rutherther>"pgrep guix-daemon", note the number, then cat /proc/<number>/cmdline <Rutherther>or maybe simpler, "ps aux | grep guix-daemon" and the command line is there as last argument <roptat>it could be stuck at substitutes: if the substitute server is unresponsive, but it shouldn't last more than a minute or two <yarl>Well, I'm not sure because if thats on the daemon side... <yarl>guix pull --debug=5 might give something? <Kolev>Oh, I only have 3 GB disk space free. <Kolev>kestrelwx, bordeaux.guix.gnu.org? <cbaines_>the substitute script probably won't be reliable if you're getting packet loss <cbaines_>I think it does try to do timeouts, but I don't think it works reliably <cbaines_>I've seen it get stuck quite a few times 