<southerntofu>FYI now software heritage doesn't timeout? maybe it was a problem on their side
<the_tubular>Dumb question, regarding substitutes, how does GUIX handles runtime dependencies and build time dependencies?
<nckx>If no substitute for X exists, Guix will transitively build or substitute all of X's inputs, then build X. If a substitute for X does exist, Guix will fetch it, and then recursively fetch *or build* all its references (i.e., substitute each for X and reread).
<nckx>Inputs sort of maps to ‘build time dependencies’ in your question and references are generally ‘runtime dependencies’.
<dstolfa>nckx: i've been thinking of hacking up a `guix bisect`, which uses time-machine to put you in the right commits in order to make it easy for people to diagnose issues when they want to report them, do you think it'd be worth doing?
<southerntofu>do i need to be subscribed to guix-patches to open a thread there and receive the debbugs address?
<southerntofu>does my mail server need to support DKIM/DMARC/SPF? (not sure if it does, i'm not running it)
<dstolfa>nckx: i'm not 100% sure on the interface yet, but the idea came to me yesterday when i was bisecting guix kernel for jupyter, had to clone the repository on the server instead of just using time-machine to test 1 package
<dstolfa>nckx: believe me i'm not happy about this either, and you'd think that 32 core machines with distcc, 192 gigs of RAM and ramdisks to compile things would help, but no, it's still as painful as ever
<nckx>(‘1MiB’ == ‘That's enough so that's not it.’)
<nckx>southerntofu: The branch gets updated infrequently (when someone gains or loses commit access), but if pulling from your local checkout ever mentions an unknown key, remember to update your keyring branch from Guix upstream.
<apteryx>that'd be 'guix pull --url=$your-git-repo-url'
<the_tubular>I mean, I'd need to login trough the builder daemon right ?
<the_tubular>Even if I give a github url, it won't be able to fetch it, as it's not logged in correct ?
<raghavgururajan>sneek, later tell nckx: Regarding 'second-run', you need a running polkit-agent, which depends on DE. Could you try `guix install lxqt-policykit` and `lxqt-polkit-agent &`, before starting bitmask?
<the_tubular>Can I login trough git and make guix use that config ?
<apteryx>I haven't tried; perhaps try searching the guix-help mailing list, I think someone (Chris Marusich?) had a patch for adding some kind of private git repo support as a git-fetch/impure procedure.
<sneek>nckx, raghavgururajan says: Regarding 'second-run', you need a running polkit-agent, which depends on DE. Could you try `guix install lxqt-policykit` and `lxqt-polkit-agent &`, before starting bitmask?
<nckx>MysteriousSilver: I'm just barging in but I think they mean add a ‘/’ after the last G in PKG_CONFIG.
<nckx>If there are multiple PGK_CONFIG typos on a single line anywhere, add a ‘g’ after that ‘/’. Or add one anyway just to be safe.
<nckx>(Is this the new Audacity standard? That bodes well.)
<nckx>raghavgururajan: OK, I'll do that. I thought the whole point of the service was to take care of the polkit stuff, but I think I get it: it installs static polkit files but has no way of knowing which polkit implementation(?)/front-end your desktop requires and forcing lxqt's would do bad things on other DEs. Correct?
<raghavgururajan>nckx: So the interaction is like this, bitmask <--> polkit-agent <--> polkit-daemon (with configured policy file of bitmask). The service-type takes care of the last part. polkit-agent is user's choice. User can use gnome-polkit or kde-polkit or lxqt-polkit. Its like choice of pinentry for gnupg.
<raghavgururajan>nckx: Now, I am thinking to patch the bitmask source to start lxqt-polkit-agent, if is there is no polkit-agent already running. I am choosing lxqt here because, bitmask's GUI (systray) is qt-based.
<nckx>That's OK, let's not waste anymore time on it.
<pazho>Hey all, if anyone else is wondering about the question I asked yesterday about setting up an environment for emacs (with ld-wrapper), I sort of solved it using 'guix environment --ad-hoc -e '(map cadr ((@ (guix packages) package-inputs) (@ (gnu packages emacs) emacs-next)))' make pkg-config gcc-toolchain'
<maximed>pazho: not sure what you're trying to do exactly, but "guix environment emacs" should give you an environment where you could build emacs in (via manual ./configure && make)
<maximed>likewise, "guix environment guix" if you want to hack on guix
<pazho>maximed: yeah i know but it seems to pick the 'ld' executable from binutils rather than ld-wrapper in my case; which I have to then fix by editing PATH
<maximed>pazho: I haven't seen that before. You could perhaps try "guix environment --pure emacs"; it will first clear all the old environment variables
<boeg>So say I use emacs and sly to develop common lisp software, and I would like to run the software, as i work on it, inside a guix container. Can I do that? Can I maybe run emacs on my host but have it start sly inside the guix container or something like that?
*raghavgururajan is eagerly waiting for the guix website and manual to rebuild
<Noisytoot>nckx, (hd0) seems to be the installer USB, as (hd0)/home and (hd0)/etc are empty, and (hd0,msdos2) seems to be an EFI system partition (and running that command boots the installer USB)
<nckx>Well, hd1 then, it was meant as a placeholder but that wasn't clear.
<apapsch>just noticed the flag needed-for-boot? in file-system. docs say "the file system is mounted when the initial RAM disk (initrd) is loaded". the activations are also run in initrd, though are they run after all (needed-for-boot? #t) file systems are mounted?
<Noisytoot>ls only prints (proc), (hd0), and (hd0,msdos2)
<podiki[m]>Hey #guix, any maintainers in here that have contributed to any of the Haskell stuff in Guix? As discussed, was thinking it would be good to have a haskell-updates branch to deal with changes to the build system (and ghc versions, etc.). This is on the guix-devel list too, but wanted to chime in here
<raghavgururajan>nckx: Do you know how to checkout master as a worktree in ~/guix/master instead plain checkout at ~/guix, while cloning the guix repository?
<roptat>raghavgururajan, I clone guix as ~/guix/master, and then from there I create worktrees for other branches
<roptat>as in "cd ~/guix/master; git worktree add ../core-updates core-updates"
<boeg>I'd like to be able to use *my* emacs with the environment inside a guix environment (--container) to work on common lisp software with sbcl and sly that is isolated from the host. If --ad-hoc emacs, i can run emacs inside the environment, but it doesnt use my configuration. Is that possible? Or is there some other way to achieve what I want?
<dstolfa>boeg: you can probably --expose=$HOME/.emacs.d
<dstolfa>unless you're using emacs daemon, in which case you'd have to expose (or share maybe?) the directory that has the emacs socket, but i don't really see the point of running just the emacs client in a container
<boeg>yeah, i am using emacs daemon on the host, but in this case, i will just be running a full emacs inside the container ... was my thinking anyways
<apteryx>is someone knowledgeable with libGL.so and friends? Is there a reason we link to Mesa intead of first looking for the system provided ones? It seems to cause some issues to link to Mesa on foreign distribution that do not use Mesa.
<nckx>apteryx: Because that's how most build systems link against it, since it's just another library. But I'm in the ‘libGL is really a user-space hardware driver’ camp: it would be *better* to look it up at run time. Do you have any idea how well-respected LIBGL_DRIVERS_PATH is?
*nckx remembers this discussion from Nix(!) and it was never resolved AFAIK.
<apteryx>nckx: I mean, we're going out of our way to prevent it being dlopen'd (see how it's patched in qtbase for example). There must be a good reason.
<apteryx>for qtbase, the comment says "Use the absolute paths for dynamically loaded libs, otherwise the lib will be searched in LD_LIBRARY_PATH which typically is not set in guix"
<nckx>Depends on your definition of ‘good’. It's *valid* to say that this way is more Guixy, while also leading to lower performance or simply broken programs on foreign distros.
<nckx>Noisytoot: Do you know which resolution is used in BIOS mode? You could try typing ‘set gfxpayload=WxH’ at the UEFI-mode grub command line, then returning to the menu to boot the installer.
<apteryx>what would be nice (if technically possible), would be to 1) look for system provided libs (in LD_LIBRARY_PATH / or where does it look normally?), and if no opengl libraries were found, fall back to Guix's Mesa ones.
<Noisytoot>I don't know. Is there a way to find the resolution?
<nckx>apteryx: LD_LIBRARY_PATH yes, but that's a huge and error-prone hammer because it will override *everything*, or maybe LIBGL_DRIVERS_PATH but I don't know how common that is. Still, probably better to use the latter when patching stuff.
<drakonis>its a requirement for swapping out mesa for libglvnd in mesa's deps
<podiki[m]>I've been hoping we can get in a newer mesa, the current one is a bit old with how fast mesa moves (esp for anyone relying on drivers it provides)
<podiki[m]>the patch there builds fine for me, but gotta sort out some other library updates. I think irfus had another patch linked in here, but didn't apply for me
<podiki[m]>drakonis: so need mesa to be build with libglvnd? (which that patch does too)
<apteryx>is it expected that mesa can't run on top of the nvidia proprietary drivers? I've had someone try a guix pack of a Qt-based application, and they got errors like: 'libGL error: No matching fbConfigs or visuals found' and 'libGL error: failed to load driver: swrast'. Retrying the non guix-pack application version reportedly even caused unrelated system crashes and they had to reboot.
<podiki[m]>I don't want to get off track on the non-free here, but nvidia and mesa/gl requires fanagling in my experience (see Arch wiki)
<podiki[m]>yeah, seems hacky to me, but then again if you have multiple graphics cards and gl systems, maybe can't avoid some of that?
<podiki[m]>I'm going to go back later today to that Mesa 21.1.4 patch to see if I can figure out libepoxy or whatever needs some changes
<apteryx>I think the problem to solve is "simply": allowing to load the GL drivers from /usr/lib or /lib (or wherever they are supposed to be at) first, and falling back to Mesa's implementation otherwise. The ABI is supposed to the same, whatever flavor of libGL.so you are using, IIUC.
<apteryx>and allowing to load these drivers without also allowing to load all the other libs thare are there (that's where it gets fun).
<apteryx>dejavu, but my memory is failing me: WARNING: loading compiled file /run/current-system/profile/lib/guile/3.0/site-ccache/guix.go failed \n In procedure load-thunk-from-memory: incompatible bytecode version
<apteryx>I'm trying to run a simple Guile script making use of the Guix API from my user
<apteryx>without pre-inst-env. Guile is installed in my profile (guix isn't).
<roptat>apteryx, is it needed? I thought it was part of the derivation, so it would be independent from the guix version?
<apteryx>roptat: I haven't carefully assessed things, if it clones the repo and uses doc/build.scm from that, we're good (in (hydra berlin) from the 'maintenance' repo)
<lfam>I could use the docker methods if I had to, but I'd like to avoid it. My whole reason for trying to use Guix with these programs (which I want to use at work) is to give myself a software deployment story that I can understand and use fluently
<nckx>Noisytoot: After setting that variable on the command line, simply return to the menu (I don't know which key, but I guess Esc), boot Guix.
<nckx>It sounds like you're typing things manuall?
<darth-cheney>I have one other question while I'm here. I am on a truly dinky little laptop and every time I reconfigure my system (always trying to get that sweet, sweet config) it takes forever to rebuild everything -- like hours
<lfam>POWER is definitely a better option if you have work to do
<apteryx>I understand why it's popular (err, phones), but as a workstation, I don't see why one would pay big $$$ for ARM compared to a similar amount for POWER, especially given the power ecosystem is more free (thanks Talos)
<vagrantc>POWER also requires a lot of power, so if you're operating on a wattage budget (e.g. solar) power maybe not a great option
<lfam>I think the ARM workstations are important because they let you develop for low-power ARM, which is widely deployed for industrial use
<jackhill>I'm attracted to their idea of supporting processor diversity
<vagrantc>i seem to have a thing for that too ... even though practically speaking ... it's a lot of effort :)
<jackhill>:) I finally got my Apple PPC64 G5 to be stable with Void. It apparently wasn't happy about the quality of power coming out of my UPS, so it would randomly power down. So now I can port Guix to it (after my other projects)
<vagrantc>i think efraim was even working ona 32-bit guix port...
<jackhill>yes, I think I have those mails flagged :)
<dstolfa>jackhill: what's the use-case for running both at the same time? is it common? if so, one might argue that maybe they shouldn't provide the same virtual service and lsh could provide "lsh-daemon"
<dstolfa>it's a relatively simple change that you can do locally, but if it's a common use-case, maybe it makes sense to do it upstream
<jackhill>dstolfa: my use case making config changes on a remote host, and using the second one as another way in in case I mess up