<ns12>Let's say I build an image like this: "guix system image -t qcow2 my-os-config.scm --image-size=3G". If I subsequently change the contents of my-os-config.scm, do I need to rebuild the image? Or can I use "guix system reconfigure" from within the running image to change the OS configuration?
<zamfofex>I noticed package definitions change frequently unintentionally. I wonder if it’d make sense to create a tool to help figure out the reason more easily. Maybe even preemptively before making the change.
<zamfofex>And if there is already such a tool, I think it could be worthwhile to investigate why it isn’t used effectively.
<jpoiret>`guix refresh -l` should do the trick zamfofex
<jpoiret>if it's about updating packages that update dependents
<civodul>PurpleSym: i'm trying to avoid the ghc rebuild by introducing git/fixed, because firstname.lastname@example.org depends on the full git, not just git-minimal
<civodul>but it seems there are other things triggering a rebuild of git :-/
<PurpleSym>Maybe it would also work with git-minimal/fixed?
<jpoiret>efraim: are you looking for Xwayland on master or core-update-frozen?
<civodul>zimoun`: regardless, llvm-julia must be in llvm.scm or bad things can happen
<rekado_>zimoun`: oh, okay. I’ll look at R stuff on core-updates-frozen later today. I’m still building chromium on that branch. Want to upgrade my profile first before refreshing my checkout of that branch (and building things *again*…)
<civodul>71% of x86_64 substitutes right now on core-updates-frozen
<florhizome[m]>what should I set as XDG RUNTIME DIR for tests ? KWinFT builds fine elsewise
<PurpleSym>sneek: later tell zimoun`: Usually if python-build-system’s 'sanity-check fails the package won’t work properly afterwards. I’ve looked at a few failures and it’s a mixture between missing dependencies and non-python3-compatible packages. I’m very much in favor of just removing them.
<efraim>i'll leave xwayland alone, I see it's being worked on
<jpoiret>if a package is fixed in a commit upstream but there has been no release yet, what is the best practice? Creating a patch and applying it, or changing the origin to point to the upstream commit?
<setq>Is there some way to automatically update the environment variables after installing new software so that my application launcher (meta-key+! in Stumpwm in my case) can find the newly installed applications without needing to quit StumpWM and loging in again?
<civodul>efraim: re flatpak/gnupg, i suppose flatpak could propagate 2.3.32 or, better yet, not propagate gpg?
<jpoiret>setq: there is no general way to do that, the application has to support some kind of update of env vars itself
<jpoiret>ie shells can do it with "source", but not permanently
<jlicht>setq: in general, after the first few installs of software you use, the env vars are set up already; it is only when you do something that requires a totally new env var that you need to restart your session
<jpoiret>(but note that with profiles and symlinks, we often don't need to update env vars at all, it will just work™)
<apteryx>civodul: nice idea about adding a signal handler
<sneek>zimoun, PurpleSym says: I’ll look into the failing python2-* packages.
<sneek>zimoun, PurpleSym says: Usually if python-build-system’s 'sanity-check fails the package won’t work properly afterwards. I’ve looked at a few failures and it’s a mixture between missing dependencies and non-python3-compatible packages. I’m very much in favor of just removing them.
<jpoiret>setq: maybe your launcher hashes the binaries it sees on launch once, and you would need to trigger a rehash
<zimoun>apteryx, yes. It is leaves packages. “guix refresh -l” says they are their own dependants.
<zimoun>python2-factor-boy seems removed on core-updates-frozen. All the others fails on master and are still on core-updates-frozen.
<PurpleSym>Actually, looking at the numbers it’s just three packages less. But alot more failures on core-updates-frozen.
<apteryx>That's kind of expected; as more and more Python libraries drop Python 2 support
<zimoun>I propose to send a series removing the ones which fails because Python 2 support. And a list of python2- which fails because sanity check. For instance, some are scientific packages and I am sure people want to fix them instead of remove. :-)
<pukkamustard>hi guix! ocaml-dose3 does not seem to build on core-updates-frozen. Reverting the fix that was applied with 91b29aa37394b660117e1d79927621db1344b7fe seems to make it compile again. I don't know why...maybe something in python changed?
<zimoun>efraim, civodul: in fact, julia fails to build. A test is failing.
<PurpleSym>zimoun: I think we have Python 2 packages in guix-past already. Why not add them there if they are *really* important?
<zimoun>PurpleSym, this is what I suggested many times. But people finding them *really* important do not do it; and they are not enough important for me for doing it. So instead, they stay on master and I am doing the janitor once they are broken.
<rekado_>I’m all for moving python2 things over to guix-past
<rekado_>requires some extra work and time, though.
<civodul>hi pukkamustard! if the fix breaks things instead of fixing them, we can revert the commit
<awb99>I am testing enlightenment window manager. And I have a highdpi display. I managed to customize the enlightenment desktop for that. But application menus and application fonts still are very very tiny. Any ideas where I can tweak that?
<rekado_>python2-warpedlmm is mine. There’s no python3 variant.
<ekaitz>hi I need some package description suggestions... I'm packaging libresprite which is a fork of aseprite. Aseprite was a GPL software but now is proprietary and libresprite is a fork of aseprite from that moment. Should I mention that in the package descriptions? like... aseprite is stuck at the GPL version...
<rekado_>many of these are already pinned at old versions because upstream dropped support for Python 2 a long time ago.
<zimoun>at first, it should be distinguished if they fail because Python 2 unsupported or because sanity check phase.
<pukkamustard>civodul: then I think we should indeed revert 91b29aa37394b660117e1d79927621db1344b7fe on core-updates-frozen. On master it is a fix. On core-updates-frozen it becomes an anti-fix. Could somebody check?
<jpoiret>mbakke: i see you updated wlroots last month but it doesn't build with -Dlogind_provider option which is not an option anymore in 1.14
<PurpleSym>zimoun: Sanity checks failing might mean you have to *add* more python2-* packages to satisfy requirements though.
*apteryx sent the xwayland patch they + mutter wip to 51900
<roptat>zimoun, I'm on the very tip of the branch, 2b3046beca1b35e03f975fb95956f32eb46dee8c that was pushed less than 30 minutes ago :)
<fcw>vivien: I have already grepped. I am trying to package pgcli (https://github.com/dbcli/pgcli). Unfortunately, one of its dependencies (python-pendulum), does not have a setup.py(!), so the build for pgcli fails with: "no setup.py found".
<fcw>vivien: I declared python-pendulum in pgcli's propagated-inputs. When I try to build pgcli, it fails with "no setup.py found" because of python-pendulum. I will look into this. This is only my second attempt at packaging a Python tool for Guix.
<vivien>fcw, did you use pypi importer, guix import pypi pgcli?
<roptat>I don't think we have a poetry-build-system
<roptat>zimoun, ah indeed this is weird, after guix pull I get a backtrace too
<fcw>"guix refresh --list-dependent python-pendulum" shows that python-orator depends on python-pendulum. I wonder how python-orator manages to build without failing ...
<fcw>vivien: Yes, I manually typed a package definition into a text editor.
<roptat>fcw, I'd say an older version of python-pendulum used to build
<roptat>mh, someone updated it without checking it was still building...
<vivien>fcw, I would suggest you to start from the output of "guix import pypi pgcli"
<rekado_>I don’t understand an error. I’m looking at the build failure of python2-send2trash. It fails in the ‘setenv’ build phase — but neither the python-build-system nor this package has such a phase.
<apteryx>these xkbcomp warnings are annoying: [...]Warning: Could not resolve keysym XF86KbdLcdMenu5\nErrors from xkbcomp are not fatal to the X server
<zimoun>civodul, ’make as-derivation’ does not report an error. Weird bug this llvm-9 stuff.
<rekado_>I’m probably missing something obvious – could someone please point me at what that is?
<zimoun>ah yes, sorry the noise. I have missed it. :-)
<rekado_>apteryx: I only have the name of the test that failed
*rekado_ fixes more python packages that fail due to referencing ‘PYTHONPATH’
<apteryx>OK. I'll wait until we reproduce it again; as I'd prefer to report it upstream at the same time it is disabled
<vivien>Don’t worry for my meson patch, I’ll put the changes in a separate variable, but for now I test it.
<awb99>I have a highdpi display and am testing enlightenment. enlightenement really rocks. But all my fonts are so small. Text in applications is so small, and the menus in applications are small. I managed to configure the enlightenment desktop. But I cannot find a way to set menus and text size for normal apps. Any ideas?
<apteryx>awb99: what I do with ratpoison is use xrandr to set the DPI via --dpi
<samplet>jackhill: That’s what I’m looking at right now. See bug #51916.
<jpoiret>podiki[m]: yes, it's not there, which is pretty weird
<samplet>It works if you remove at-spi2-core from the gnome package, but I’m not sure that’s a good idea.
<samplet>(I’m not sure if it’s a bad idea, either!)
<podiki[m]>jpoiret: okay, I'll leave it for now. but that type of hidden dependency could drive a person mad :) I always wondered why my gnome-less system tries to build it. guess time for sddm or slim!
<podiki[m]>jpoiret: worth filing a "bug" report for later?
<samplet>podiki[m]: GNOME has a habit of bundling a couple of subpackages in each package (like one package might have two libraries and an application). Other distros (e.g., Debian) split them up, but it’s harder in Guix. Last I looked, that was the reason our GDM package is so big.
<jackhill>samplet: cool. Yeah, I don't know enough about what it does to make a judgement either
<podiki[m]>maybe I'll file something for future reference; gnome seems to be a packaging beast on guix
<samplet>The Debian trick is to build everything together and split up the outputs. Since everything ends up in “/lib” and friends, it’s easy.
<samplet>We would like to say “install this library here, that library there, and this other application over there”, but you configure the entire GNOME package in one go.
<podiki[m]>and gnome-shell depends on gdm, thoroughly confusing me
<samplet>podiki[m]: Right. That’s the same issue, IIRC. I think that GNOME Shell needs some library tucked inside of GDM, but the main part of GDM needs GNOME Shell. Since we can’t tease the subpackages apart, we have to do tricks to avoid the circular dependency.
<podiki[m]>the trick is so good mutter disappears into the magicians hat!
<podiki[m]>I'll file later as a "nice to do at some point" if it is possible to have gdm without gnome (mutter); otherwise I don't like it as a default login manager unless you use gnome anyway
<civodul>ah ha! Matrix users unanimously decide to leave the core-updates-frozen sprint
<jpoiret>turns out (spoiler) the default configuration of GDM shipped upstream does in fact depend on gnome-shell
<jpoiret>but it isn't a hard dependency theoretically podiki[m]
<jpoiret>so gdm shouldn't indirectly depend on gnome-shell
<nckx>roptat: By a ridiculous order of magnitude, but we got a bit of Germany from the Germans to say sorry for the war business and it's since an official language, and the local population of that tiny part does speak German.
<apteryx>I tried to use 'tini', but it said: [WARN tini (5027)] Tini is not running as PID 1 and isn't registered as a child subreaper.\nZombie processes will not be re-parented to Tini, so zombie reaping won't work.
<apteryx>not being root I don't think I can change that
<crodges>Hello everyone. I'm missing something basic here. When I install a package (using debian for example) there's usually a config folder for the app inside /etc/<package>. I installed synapse as root, where do I find the respective configuration files? I know that I'm not supposed to used /etc directly in guix. For services I know that I have to modify config.scm, but what about packages?
<rekado_>crodges: packages install *all* their files to their own prefix directory
<rekado_>so the stuff that would end up in /etc on a traditional distro would end up in /gnu/store/…-name-1.2.3/etc/
<jpoiret>oh, the fix is in the bunch of patches that timothy sent
<jpoiret>(how do you apply a bunch of patches with notmuch-emacs and magit?)
<rekado_>it would nice if we could avoid last minute surprises like this; a lot of this is caused by merges, of course. Maybe we could register a bug report and use the bug tracker as a core-updates merge checklist?
<crodges>rekado_: ok I don't see /etc inside my synapse install, only bin, lib and share. Even if I find it, where am I supposed to change configurations for a regular package that it's not on this etc?
<rekado_>crodges: this depends very much on the package
<crodges>rekado_ thanks. podiki[m] yes, and the signing keys. You're right, it can go anywhere. I think I just need to generate everything in a proper place. I am a little confused about which user should run synapse (synctl) and if I need to create a herd service for it
<rekado_>podiki[m]: before mothacehe’s work on cuirass this wouldn’t have been feasible. I think cuirass is *much* better suited for a more flexible and independent core updates workflow.
<rekado_>(I always build pigx to be sure that most common bioinfo tools build fine)
<podiki[m]>rekado_: certainly looks that way to me, let's discuss soon, make the next round easier :-D
<nckx>I was overexcited to finally have a real (paid) use case for inferiors. I understand they are a tech preview, and the manual makes no false promises, but I didn't realise that its ‘example’ use case is the only existing one so far. Is there no way to cast an inferior package to a regular one without writing much new code?
<rekado_>I’ll wait for ci.guix.gnu.org to catch up
<apteryx>if it's just a key couple packages I can help accelerate things
<jpoiret>by the way, does anyone use the greetd/seatd patchset?
<nckx>The need is for HPLIP 3.19 (‘a very old HPLIP’ that makes their tens of printers go brr instead of zonk), which itself needs an old CUPS, etc. So I can define custom packages (and even C&P from old Guix revisions) with some more effort, but I thought that inferiors' closure-like nature would be magic here.
<jpoiret>jackhill: I'll send my patches when I'm doing reconfiguring and they work properly (i can imagine libseatd not detecting elogind at runtime properly, and either patching that or wrapping wlroots compositors with an env var)
<nckx>civodul: Thanks! What does ‘work’ mean here? I'm using (cups-configuration (cups ancient-cups) (extensions (list ancient-hplip…)) …) and it gives the error above: guix system: error: Invalid value for field cups: #<inferior-package email@example.com 7c99d7884750>
<nckx>That error implies that there's nothing wrong with my inferior itself.
<civodul>nckx: oh i see; maybe things aren't well integrated somewhere
<nckx>It's just that the abstraction is not implemented where I thought it was.
<jpoiret>maybe the cups service wasn't made with inferiors in mind? since they're not really packages (i've seen (? package? p) (? inferior-package? p) in places)
<civodul>which makes sense, for instance you could write a wrapper for cups as a computed-file
<nckx>Is ‘it's wrong to expect 'package?'’ documented anywhere? Do you not think it counter-intuitive to the point of being unacceptably dangerous? There's probably a cute name for code/names that make people do wrong things over & over again.
<nckx>‘package? is not a good way to test for packages’ is one of those. I *do* understand why.
<nckx>No absurd decisions were made but the end result is absurd.
<jpoiret>nckx: Maybe we could document Guix best practices™ (for example for error reporting and such) somewhere in the manual. I feel like it could help people contribute faster to the project without going on a wild goose chase of "let's find some examples of best practices, oh, this is from 2019 and they way they do it has changed since, damn"
<civodul>vivien: but nowadays you should rarely need to fiddle with the monadic APIs
<nckx>civodul: <there are cases> Isn't that what we want here?
<jpoiret>civodul: I'd see one use-case for this, checking in service definitions for old package quirks and such. But maybe guix doesn't want to support the whole history of software quirks, and only guarantees the services it ships work with the latest versions
<nckx>It's cool to give users the tools to use /etc/motd as their CUPS package (and deal with the fall-out) but maybe it's a bit too (pointlessly) ‘empowering’? 😉
<M6piz7wk[m]>and it told me to format using /etc/forma...el which hugged up formatting in the whole repo -w-
<roptat>I don't know how to apply that patch, but I can still test the package inside it, don't worry
<roptat>could you resend a patch that you generate with "git format-patch"? You'll also need to check you package definition with "guix lint rust-shell2batch", and add your additional patch to gnu/local.mk (in alphabetic order, in dist_PATCH_DATA iirc)
<podiki[m]>(the manual is there for a reason though, and is pretty good)
<crazazy>Hey guys I'm wondering, how well does the `package` function sandbox things
<crazazy>like I want to try out guix, but like still have all the comfort of the nix buildign process
<crazazy>so I was wondering, with the whole "we're using full guile schme" thing, if I could just call out to an inferior nix process from my guix configuration, let nix do all the package building, and then have guix add the results that nix put in /nix/store in to guix's own /gnu/store
*M6piz7wk[m] is failing to figure out the git format-patch
<podiki[m]>jpoiret: I think I produced the same hash as the CI (but had pulled just before starting)
<jpoiret>we use (a slightly modified version of) the nix daemon crazazy
<roptat>M6piz7wk[m], "git format-patch -1" to get a patch for the latest commit you did
<podiki[m]>crazazy: I don't know, but there is build offloading, take a look at that?
<podiki[m]>(I'm spoiled with a desktop I built a few months ago, love the 12 threads)
<podiki[m]>oh? must have just missed the sbustitute info, will restart
<rekado_>yo, the GUIX_PYTHONPATH thing: I see that a lot of packages already use GUIX_PYTHONPATH, but they still wrap their executables with PYTHONPATH. Should they instead use GUIX_PYTHONPATH for the wrapper as well?
<mmarshall540>Thanks. Trying to install Guix System, I go through the guided installation accepting the defaults, and everything seems to go fine... After rebooting, I get the boot screen with the Guix logo and press return to boot Guix... But after a fair amount of text flying by (including the brief appearance of a login prompt), it ends up at blank screen with a flashing cursor. Nothing else happens, and I can't reach any other TTYs.
<jpoiret>GDM might be failing to start for some reason
<jpoiret>can you boot into grub, press e on the option you want to boot, and add "nomodeset" to the command line?
<apteryx>hmm, at least tho cogl suite passes with current mutter; so the clutter failures must be due to /bin/sh or similar
<apteryx>current mutter = mutter in wip-mutter, sorry for the confusion
<jpoiret>roptat: this has been the case for a while now
<apteryx>civodul: not sure if it helps, but I've scp'd what I'm inspecting at /tmp/whzlk50cwl90mii3sj1ifkzgp6v9l9w2-mutter-41.0.drv; you can grep for things like "ERROR: timed out" to see what python-dbusmock is doing. The handler I installed should print 'got-pid upon encountering SIGCHLD and 'waitpid-returned: iw waitpid returned (rather than raised).
<vivien>Flatpak is a pain, because to install a flatpak, you need a runtime, and the runtime is hosted on flathub (alongside proprietary flatpaks). So, if we could get these runtimes outside of flathub, that would be great.
<vagrantc>using flatpak did feel a little dirty, but i wanted to try a couple apps and ... may as well see this newfandangled flatpak thing and how it works
<vagrantc>it looks like you don't have to enable flathub, so in theory you could use a runtime from elsewhere ...
<vagrantc>guixflat ... a little apartment of your own
<samplet>I reconfigured on commit fc3e4ef0db1e6c4c83819e5b8d5a7571a3d656c1 with no other changes.
<mmarshall540>jpoiret: Success! Removed all references to desktop, redid the install and am now able to login at the console. Guess I'll experiment with installing a non-gdm display manager from here. Thanks for the help!
<notmaximed>civodul: ^ (the openat & friends patches) (I don't want to single anyone out, but it has been 8 months since the original patches without replies by guile maintainers, and you're both a guile and guix maintainer IIUC, and you were involved with the work-around in guix ...)
<apteryx>ah, nevermind, (exit status 255 or signal 127 SIGinvalid)
<darth-cheney>Am I correct in saying that I specify my other guile dependencies in the `inputs` section? If so, should I expect the referenced packages to be installed when I install my package on a fresh setup? Right now I cannot get the latter to work and I'm not sure why
<mmarshall540>jpoiret: The end of /var/log/gdm/greeter.log indicates the following, "/gnu/store/[...]-xf86-video-ati-19.1.0/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixMapDriverPrivate"
<civodul>apteryx: it's meant to be wrapped into something nicer
<kaelyn>So I just switched my main computer over to c-u-f and rebooted, after getting hit by a graphics card reset again (it included upgrading from a 5.14.8 kernel to 5.14.15, which includes some potentially relevant fixes). ^.^
<samplet>jpoiret: When testing in a VM, I could change VTs with GDM on X but not Wayland.