IRC channel logs
2024-11-04.log
back to list of logs
<Geryz19>i think i've almost solved my problem, now i only need to invoke latexmk without errors... <getstate>Does qa build dependent/consumer packages? <f1refly>I'm using texlive-scheme-medium, texlive-beamer and texlive-collection-latexrecommended. From outside the meta packages I also need texlive-csquotes and texlive-moderncv, but I'm getting a dependency error caused by conflicting texlive-etoolbox versions. What is the recommended way to resolve this? <makx>(admittedly i am not guix, but i like guix) <Rutherther>civodul: hi, since you are here. I noticed you applied my patch for ping and ping6 capabilities. I was wondering about putting there another message but forgot about it - according to Tobias capabilities are not supported on Hurd, so this could break Hurd. Is that not a problem then? <civodul>Rutherther: i checked that and it’s okay: in (gnu system images hurd), ‘privileged-programs’ is overridden <civodul>anyway my laptop is running with this change now and it works as advertised :-) <icepic1984>71174) and also provided a patch for this bug, but it seems like the patch was never picked up by qa. Did I do something wrong? <civodul>icepic1984: hi! it’s possible that qa.guix was swamped and never picked it up <cbaines>icepic1984, in this case QA doesn't look at bugs, only patches <cbaines>it's confusing, but #71174 is filed against the guix package, which corresponds to the bug-guix mailing list <cbaines>QA only looks at issues relating to the guix-patches package, which corresponds to the guix-patches@gnu.org mailing list <cbaines>icepic1984, so I'd recommend sending the patches to guix-patches@gnu.org, and mention they relate to the bug <civodul>cbaines: will it see it if the bug is reassigned to ‘guix-patches’? <icepic1984>Cbaines: And this is the "normal" workflow in case I submit a patch for a bug in future. Send the patch directly to guix-patches and mention the bug issue number in the description? <cbaines>civodul, as QA talks to mumi/debbugs, that should see that the issue is reassigned, however since the patches still come through patchwork which reads the guix-patches mailing list, I think QA won't be able to fetch the patches <cbaines>civodul, if we can change QA to directly fetch the patches from mumi/debbugs, then it should work <icepic1984>I like the appeal of mail driven development but boy is this a lot to learn when you come from gitlab/github land :) <civodul>icepic1984: yeah, this is a frequent topic for debate in the project! <simendsjo>I just tried Guix on an amd cpu/gpu, but I'm having problems. It goes to sleep all the time (some BIOS setting...?), and fullscreen video is sluggish. lspci shows only amdgpu is loaded. Do I need some manual configuration to set it up for x? <simendsjo>For reference, this is a Beelink SER7 with 7840HS cpu and 780M gpu. I have the latest BIOS patch. <thanosapollo>does guix use guix-forge for hosting? Has anyone set it up? <simendsjo>I got the amd gpu working, but had to include the non-free firmware :/ <simendsjo>cbaines: Thanks! I was going insane trying to find out what could possibly be putting my system to sleep! <Malveth>Hi. I installed Guix through graphical installer. I followed all the commands that were guided to me through graphical installer. I used ethernet to connect to network. I used Gnome as the desktop environment. Once installed and rebooted, I did not find any option for wifi in the system. Why is <simendsjo>Malveth: Is your wifi supported by non-free drivers? If not, Guix doesn't support it and you have to add it yourself (or use a non-free channel which has the driver) <apteryx>Malveth: research which chipset your wifi solution is using, and conult h-node.org to see if it's listed as compatible with free software only <apteryx>why is it that we have locales problems following a libc upgrade, and upgrading user profile but not the system one? <apteryx>The locales are typically installed as part of the user profile applications, and the glibc should be referred to by the runtime, captured in the graph of the running applications, no? <yelninei>Has there been any progress on the guile/libgc warnings on Hurd? The same problem is causing a test failure in automake for me by leaking the warning into stderr <yelninei> I've been working around the 'guix authenticate' error by adding GC_LARGE_ALLOC_WARN_INTERVAL=100 to the childhurds guix daemon, however this does not work for the guile that is driving the build <futurile>argh Sharlatan didn't pull from my tree, so they must have gone through each patch when I'd reviewed/reformatted/cleaned-up each one! <futurile>oh well, I do get to tell some people their patches made it in! <luminouspath>anyone have any idea why guix home might be trying to build a package when installing/building it normally just pulls the substitute? <luminouspath>I have a sneaking suspicion it's cause I have a custom channel and somehow a dependency is getting overwritten, and the hash is different, but I'm not sure how to check <Deltafire>luminouspath: sometimes it's because the build servers haven't built that package yet <futurile>luminouspath: if it normally works, the likely reason is that Guix hasn't built the substitute yet - try using guix weather maybe? <luminouspath>Deltafire no the servers have it, I can do `guix install` or `guix build` and it pulls the substitute fine <luminouspath>it's only when I try and do a `guix home reconfigure` that it decides it wants to build it instead <luminouspath>I had this bug earlier but I got around it by adding the dependencies to my home config one by one, running `recconfigure` for each change, and *then* adding the final package after the dependency substitutes had been downloaded <reedm>Does anyone know how to get the permissions right on a guix system container shared directory? <reedm>specifically, I'm trying to follow the guix cookbook example for a dabase container, and I want the data directory to be persistent. So I am running: sudo (guix system container postgres-container.scm) --share=$(pwd)/data=/var/lib/postgresql/data <reedm>I think I need to chown $(pwd)/data, but I can't figure out exactly what uid/gid to use <hapst3r>hi futurile, good to see you. Was just checking if inheriting =fill-column= for =erc-fill-column= works as expected. Will come around later, have a good one in the meantime. Also, let me take the opportunity to thank you (and the others involved) for organizing guix social, really appreciated even though I have been less active than I'd like to ;-) <Rutherther>reedm possibly the uid of postgres user. To know it you might have to check in the container what uid it has <reedm>Rutherther: I ended up doing something similar. Rather than chown on the host machine, I set the uid/gid of the postgres user on the container to be the same as the uid/gid of my user on the host via the postgresql-config part of the container configuration <reedm>i did need to change the sharing slightly to --share=$(pwd)/data=/var/lib/postgresql <Rutherther>reedm you dont need to do that, files can be owned by uids that are not mapped to users <reedm>Rutherer: could you elaborate? I'm not super familiar with file permissions, especially in the context of namespaces/containers <Rutherther>reedm that you can set uid of postgres to anything and then just chown it to that, you do not need to match with an existing user on the real system <futurile>jumpship: this looks like it's a Python script basically. It could be looking for qtmultimedia at runtime not at build time. For this you need a `propagated-input`. I've never packaged a KDE applet, the easiest thing would be to look in the Guix source code and find a similar package <jumpship>futurile still complaining qtmultimedia isn't installed after using propagated-inputs. I'll look through the applet definitions i can find again and see if I find any hints. Thanks for the help <PotentialUser-67>Previously, closing the laptop lid made the laptop enter deep sleep. Now, /sys/power/mem_sleep has only [s2idle]. <gabber>is the directory $TERMINFO points to linked to some absolute path? would it make sense to link said info somewhere like /run/current-system/profile/lib/terminfo? i am having troubles with curses with kitty since TERM is set in the ssh session but TERMINFO (obviously) is not. <gabber>i found a solution by setting TERMINFO="${HOME}/.guix-profile/lib/kitty/terminfo" in .bash_profile (: <Rutherther>gabber: does TERMINFO_DIRS also work or only TERMINFO? if terminfo works, you can add ncurses to your user profile and the env var will be set (you will have to relog) <Rutherther>oh wait, sorry, it won't. The only thing added to TERMINFO_DIRS would be share/terminfo, not lib/kitty/terminfo <gabber>Rutherther: thanks for the input anyways (: <gabber>to be honest, i am not 100% pleased with my solution <Rutherther>gabber: but still, I would suggest making a package that has lib/kitty/terminfo in native-search-paths to make it more portable rather than setting it externally. Maybe this is a bug and should be in kitty package itself. I am not completely sure how TERMINFO is supposed to be managed to say for sure, but it could be worth reporting <gabber>i guess setting TERMINFO_DIRS="$HOME/.guix-profile/lib/*/terminfo" could work and be a nice solution? <gabber>i think setting it on the target/profile side of things is the right place for the fix <vagrantc>anyone fixing to find some trivial things to fix: guix lint --checkers=description,synopsis ... fixing those do not even trigger rebuilds :) <gabber>vagrantc: changing description or synopses of packages does not trigger rebuilds? <vagrantc>gabber: not of the package, as the metadata is in "guix pull" not in the package itself <vagrantc>i mean, i know they don't trigger rebuilds ... and i *think* that is why <gabber>isn't it because these fields are just not hashed as part of the package-defining-hash (sorry for my clumsy wording - i am certain there's a better term for that) <gabber>if i am right i suspect that there just is no easy fix for the issue you addressed.. <vagrantc>well, sure, it's not included in the hash used to generate /gnu/store/HASH-PACKAGE <gabber>vagrantc: so how would guix figure out that a rebuild is necessary if the package (as it gets to reside in the store) is equal (by hash)? <Rutherther>gabber: what do you mean by that? changing description or synopses doesn't change the output in any way, so no rebuild is necessary <gabber>Rutherther: this is exactly what i mean <gabber>sorry, i misunderstood vagrantc's original statement <vagrantc>gabber: there is no rebuild necessary, there is nothing to figure out, other than the packages are the same. <vagrantc>i was proposing for people who want to practice submitting patches some easy low-hanging fruit findable with "guix lint --checkers=description,synopsis" :) <gabber>i understand that now (and am in fact intrigued by that very offer) <vagrantc>and I would be happy to review and push those changes in general <vagrantc>having just done a few typo fixes myself :) <efraim>there's also codespell, from python-codespell, to help find mispelled words <futurile>Q: anyone know of a package where one of it's transitive dependencies is a hidden package? I guess something in commencement ... <yelninei>futurile: maybe anything depending on glib? there is glib and glib-with-documentation <yelninei>or cairo and cairo-with-documentation which has a similiar circular dependency problem <futurile>yelninei: oh cool, yeah I'll look at those <podiki>yeah the cairo change was recent for the update i did this year <yelninei>specifically the glib one has been causing issues for me, because I cant add glib:bin into my home config (for things like gsettings) because it conflicts with other packages that propagate the hidden glib (because pkgconfig) <yelninei>the workaround is either to use the hidden package (whcih feels wrong) or have glib:bin in the normal user profile <futurile>honestly DAG's they're just weird - if the AI revolution is going to save us - I say it has to explain them to me first! <gabber>efraim: interesting! does codespell work well with scheme code? <gabber>futurile: which part seems especially weird to you? <futurile>gabber: how they *actually* interact seems a mystery to me often. Sometimes something starts building and then suddenly it's trying to build OpenOffice and I'm like "What?!". <futurile>ieure: best comment all day - I'm imagining it in a strong farming sort of voice <gabber>lol. i see. i guess the DAG answer is that *something* is somehow pointing to that package ;) <futurile>gabber: yup - and that's what I'll be asking our new AI overlords about ... when they get here - it's the least they can do =-) <gabber>futurile: out of curiosity: you do know about `guix graph` and such? <futurile>gabber: yes and I use it, along with guix refresh. I think mostly it's the point you're making "something" causes a link. In Guix generally it seems like we land-up with big trees. <gabber>maybe some people here know of cool tools to find answers in those huge trees we're cultivating? <noe>What would be the two packages with the longest dependency path between them <civodul>sneek: later tell noe tried a few pairs and found this relatively long path: guix graph --path libreoffice openblas <civodul>we should be able to do better than my intuition though <gabber>civodul: so even you do not have some fancy higher-level DAG traversing tool at hand?