IRC channel logs
2025-11-20.log
back to list of logs
<achravso>Hi, does anyone use Calibre, or has anyone had the following issue where it starts up and doesn't load via PyQt? <apteryx>sneek: later tell roptat do you have a clear roadmap to packaging gradle? I've seen some package in one of your repositories, but wondering how usuable it is, or any unresolved issues that remained? <apteryx>juli: are you roptat, by sheer luck? <csantosb>Morning all ! There is something weird with this guix-cuirass-bot, right ? See #4291 for example. <csantosb>Sometimes it is more than useful, sometimes it just gets crazy. <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, rlb says: - I should have just tried it. Having configure autodetect and add -std=gnu17 when available is trivial, so I'll just plan to add that to main. <sneek>civodul, ArneBab says: thank you! <civodul>does that ring a bell to anyone here? <df0>ooh, looks like python-team branch has been merged <nckx>civodul: dir_index actually *causes* errors in extreme situations because hash collisions just throw -ENOSPC. But not -EMLINK… <nckx>But ext4 ‘only’ supports 65k hard links, so it's not impossible to actually hit that, I guess. <nckx>ACTION running ‘find /gnu/store -links +60000’ but not expecting much. <apteryx>would anyone have concrete examples of where having a /etc/localtime _copy_ rather than _symlink_, ala systemd, causes issues with software packaged in Guix? <apteryx>icecat and ungoogled-chromium used to be examples, I think, but in their latest versions it looks like they can figure out the timezone correctly? <gabber>are `guix time-machine -C channel.scm -- system image foo.scm` images supposed to be reproducible? <dariqq>Did something change on the blog atom feed? My client is getting denied <gabber>ieure: that's the output of a `guix describe --format=channels` for the main guix channel containing both a branch (master) and a commit hash. <gabber>ieure: we reproduced the same image, got 3 times the same store hash, but sha256sum differed every time <ieure>gabber, If the channels are pinned to a specific commit, I would assume it's reproduceable. But you're asking for something else, you're asking for bit-perfect determinism. Guix doesn't offer that guarantee. <gabber>i would have imagined these terms to mean the same thing <ieure>They don't, and this isn't really possible to solve at the Guix level, because some compilers produce non-deterministic output. <gabber>so, this works if we use the same substitutes to produce some artifact — because Guix does build reproducibly, but does *not* work if we use one of the non-deterministic compilers with a simple `guix build --rounds=N` ? <cbaines>there is an aim for Guix to build things with bit for bit reproducibility, in this case I'd imagine something about generating the image isn't reproducible <cbaines>in the "reproducible builds" sense, the aim is reproducible behaviour, but checking for this is infeasible, it's more practical to eliminate causes of non-determinism so that you end up with the same bytes <gabber>it is a very basic image — bare-bones.tmpl with only a dhcpcd and openssh services included. <gabber>i am able to reproduce bit-by-bit the same image from laptop and workstation, but i use the substitutes from my workstation on my laptop. the other machines (deb13 with guix in an lxc and guix on a vps) supposedly resulted in different hashes <cbaines>right, which suggests that the differences are coming from something to do with creating the image, maybe something with the filesystem for example <cbaines>diffoscope can be helpful when trying to work out what the difference is <ieure>cbaines, FS uuid seems a likely culprit, but there's probably other stuff as well. <gabber>i would be less confused if i was able to *never* reproduce the same image — but now i can do it *sometimes*. guess i'll investigate a bit <Phosphenius>When packaging, is there any preference `git-fetch` over `url-fetch` or vice versa? <gabber>Phosphenius: i prefer git checkouts, although both are fine <Phosphenius>gabber: thanks—I guess git checkouts allow for more flexible packages? <gabber>Phosphenius: i don't think it matters, really <gabber>but some repositories come with submodules and the like which you can flexibly include or not when you use git-fetches <ieure>Phosphenius, I personally prefer / think there is _mild_ consensus that going straight to the raw source in the repo is preferable to building from a tarball built from the same repo by an external process. <ieure>Phosphenius, ex. the source tarball build is where the xz backdoor was inserted, so I think there's a legit supply chain security argument to prefer the repo. <fluent>hi! having a weird issue with setting up a home service to run emacs daemon: just running "emacs --fg-daemon" works, the service runs in a guix home container, but doesnt work in a regular system after guix system reconfigure. emacs seems to be looking in the wrong dirs for native lisp. here is the code for the service and the error - https://paste.debian.net/1409659/ <Rutherther>fluent: you need to add emacs to PATH for the service due to a bug with wrappers and how emacs behaves with respect to $0 <fluent>Rutherther: sry im a bit clueless, how would i do that? cant find anything in the docs <Rutherther>fluent: set #:environment-variables to (default-environment-variables), with change to PATH where you prepend emacs. Adding emacs (the same version as in this service!) to home profile should work as well as that will put it to the profile and that's in path of both your environment and shepherd. <Rutherther>simendsjo: no, it does not mean such thing, guix will not garbage collect referenced paths like that <simendsjo>Rutherther: Just referring to the package with #$ will register a root so it wont be garbage collected? Without adding it as an input/home-profile-service-type? <Rutherther>no, #$ doesn't register a root. Roots are registered only explicitely and mostly by a few commands. It is a reference, though, yes, of course, it's a point of gexps to refer to other items of the store. So naturally it has to be treated as a reference by the daemon. <fluent>i do have a #:use-module (gnu packages emacs) in the same file i just omitted that from the paste <Rutherther>ungexp is as much of an input in this regard as inputs under 'inputs' in a package that is installed