IRC channel logs

2021-07-07.log

back to list of logs

<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’.
<the_tubular>I didn't get your last line
<Noisytoot>I though inputs were runtime dependencies and native-inputs were build-time dependencies
<nckx>That Guix doesn't deal directly with build-time/runtime dependencies, it deals with inputs and reference.s
<nckx>*s.
<the_tubular>Got it
<nckx>Noisytoot: Often.
<nckx>The danger is in thinking they're synonymous.
<nckx>southerntofu: Weird.
<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>not explicited in http://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
<nckx>I think if it supports ‘run’ it's simply too cool to object to :) Probably better as an option to guix pull, I think, unless I'm missing some application outside of it.
<nckx>dstolfa: ☝
<nckx>southerntofu: No.
<nckx>That would be weird.
<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
<nckx>sneek: sneek! sneeeek. sneek? botsnack!
<sneek>Welcome back nckx, you have 1 message!
<sneek>nckx, raghavgururajan says: Any luck with bitmask? :)
<sneek>:)
<nckx>Not really, see my messages above.
<nckx>dstolfa: It does sound very cool.
<nckx>southerntofu: No.
<Noisytoot>sneekL botsnack
<Noisytoot>sneek: botsnack
<sneek>:)
<dstolfa>oh sneek is back!
<nckx>southerntofu: Of course, if they are configured, they can't be *broken*, but if they're not it's OK.
<dstolfa>sneek: botsnack
<sneek>:)
<southerntofu>well i received no ack from the server (no rejection) and no debbugs mail, it's been a few hours?
<southerntofu>hmm i need to check
<nckx>Which subject, southerntofu?
<nckx>Is it here? http://issues.guix.gnu.org/
<dstolfa>nckx: will look into what would be needed to hack it up while i wait for $WORK tests to run next time :)
<nckx>I love how https://imgs.xkcd.com/comics/compiling.png is still relevant, compiling's just been replaced by ‘our policies mandate a full CI run before every push’.
<southerntofu>nckx: > Subject: Adding package aparte (rust XMPP TUI client)
<nckx>Hmm, so no.
<nckx>southerntofu: Sometimes the GNU mail server goes out for drinks. I wouldn't worry just yet (unpleasant as it is to be left in the dark).
<Noisytoot>How can I fix /gnu/store/<long hash>-grub-2.04/sbin/grub-install: error: filesystem `btrfs' doesn't support blocklists. when installing Guix System?
<southerntofu>i'm ok with servers doing their thing :) i'll worry tomorrow if it hasn't appeared yet :)
<nckx>Noisytoot: That means you're pointing a BIOS GRUB at a partition instead of a full disc, or at least it thinks so. The fix is to not doing that.
<nckx>*do
<Noisytoot>I have (target "/dev/sda") in bootloader-configuration
<nckx>Or, maybe in addition to that, maybe because it's been years since I've switched to UEFI: pointing it to a drive with far too little free space before the first partition.
<nckx>And this is a BIOS machine?
<Noisytoot>I think it supports UEFI but I booted it in BIOS mode (so the installer generated a configuration file for BIOS)
<dstolfa>nckx: for me, a lot of the time it really is "compiling" heh
<dstolfa>or "building VMs"
<nckx>Oh god are you responsible for Chrome.
<dstolfa>no but i build llvm like 4 times in 1 run of tests
<nckx>Noisytoot: How much free space do you have before sda1?
<nckx>(fdisk -l if unsure.)
<nckx>dstolfa: O…K.
<Noisytoot>nckx, according to fdisk -l, sda1 starts at 2048
<nckx>1MiB. Hm.
<nckx>Let me try to think back 5+ years…
<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.’)
<southerntofu>( at least according to internet.nl my mail server is fine: https://internet.nl/mail/thunix.net/552610/ )
<nckx>Noisytoot: Doesn't it say something about an unusually large core.img, too?
<Noisytoot>I don't think it did
<Noisytoot>I've lost the screen with the logs now. Where does the installer put logs if installation failed?
<nckx>Oh oh Sir Sir I think I know Sir: is this a GPT-formatted drive?
<Noisytoot>yes
<nckx>Do you have a BIOS boot partition?
<Noisytoot>I think /dev/sda1 is the BIOS boot partition
<nckx>Could you pastebin your fdisk -l just to make sure?
<nckx>dstolfa: ccache not an option?
<dstolfa>it is, i use it but the problem is that these are 4 different versions of llvm
<dstolfa>so uh, it's not very helpful
<nckx>o7 Godspeed then I guess.
*Noisytoot installs curl on the guix installation image
<nckx>There's also wgetpaste but curl is 175% cooler.
<southerntofu>i'm trying to guix pull --url from my local tree where i've applied changes, i get guix pull: error: Git error: cannot locate remote-tracking branch 'origin/keyring'
<southerntofu>does that ring any bells?
<southerntofu>following steps from https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
<Noisytoot> https://x0.at/kGM1.txt
<nckx>Noisytoot: If sda1 is your BIOS boot partition it should be marked as such, not ‘Linux file system’.
<nckx>NB. I am not talking, at all, about your /boot.
<nckx>If you know that then we are good and you just need to tweak the type and try again.
<nckx>Type #4 in util-linux fdisk here.
<nckx>southerntofu: You need to checkout a local keyring branch in your local repository.
<southerntofu>ah makes sense, if it's trying to checkout the local copy of it..
<southerntofu>ah yes as explained here https://guix.gnu.org/manual/en/html_node/Building-from-Git.html thanks
<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.
<southerntofu>thx
<southerntofu>should i run indent-code.el against the files i just edited? i edited two files and indent-code.el has changed 34474 lines (git diff | wc -l) so that osunds like a big ptch for not much?
<nckx>southerntofu: Only against the packages you've added. I think it supports a second package name argument.
<southerntofu>it does, indeed
<nckx>Let us know if you experience any bugs with that script, it's not highly dogfooded (…fed?) since many—but not all—main contributors use emacs.
<nckx>E.g. indenting non-public (define)s was broken for the longest time due to a typo nobody noticed.
<southerntofu>i'll see if the package still builds with those changes
<nckx>That would be a far bigger bug than I meant, but yes, please do, it should be instantaneous since the hash shouldn't change.
<nckx>Noisytoot: Any luck?
<Noisytoot>nckx, It is still running. I am going to sleep now, I will check it tommorow
<nckx>Good night & good luck.
<Noisytoot>Thanks
<the_tubular>I'll try booting guix using uefi after I'm done working, I had problems the other day
***bandali_ is now known as bandali
<apteryx>hmm, how does opengl works with Guix on foreign distribution?
<apteryx>We seem to patch the dlopening of the libGL.so to that of our mesa package in the sources; would that work fine on any setup (including those using the proprietary nvidia drivers, say?)
<the_tubular>Can you guix pull from a private git repository ?
<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?
<sneek>Got it.
<apteryx>interesting discussion regarding libGL.so: https://github.com/NixOS/nixpkgs/issues/9415
<apteryx>the_tubular: ah, you mean it needs authorization (e.g, your SSH identity?)
<the_tubular>Yes, apteryx
<the_tubular>I guess you could login trough wget
<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.
***zap1 is now known as zap
<tissevert>hi guix
<MysteriousSilver>Hello guix! I tried to compile a package myself, it reports i'm missing a package called conan. I couldn't find it in the repos so i installed it through pip command.
<MysteriousSilver>Now how do i add the packages installed via pip to the PATH?
<tissevert>hi MysteriousSilver
<tissevert>you shouldn't mix locally / user -installed packages with guix packages
<tissevert>there should be a python-conan package and if there's not, you should probably make it beforehand
<tissevert>I'm sure it's still possible to tweak a build to include directories at an arbitrary location but I'm pretty sure it's not the right way and I wouldn't even know how to do it : )
<vivien>Are there downsides to resuming a suspended continuation in another POSIX thread in Guile?
<MysteriousSilver>tissevert: oh, ok. i couldn't find a python-conan in the repos
<tissevert>yeah, I've seen that which means maybe the easiest way is to package it too
<MysteriousSilver>i also thought of making a derivation but i don't have any experience with guile
<tissevert>you can probably get started by reading at the existing python-.* packages
<MysteriousSilver>hmm, okay
<tissevert>for instance guix edit python-anndata should take you to an editor
<tissevert>open on the python-anndata package
<tissevert>which, I notice is using something called «pypi-uri» to retrieve the code
<brendyn>MysteriousSilver, guix import pypi conan
<tissevert>so I assume this must be a pip package
<tissevert>hey, there's even an importer ! I should've expected that
<brendyn>However it appears to be a package manager
<brendyn>I wonder if it will try to download stuff
<tissevert>conan ?
<brendyn>yes
<brendyn>C/C++ package manager
<tissevert>aow : / that sounds like trouble
<brendyn>for sharing native binaries D:
<tissevert>yep, sounds like I've-invented-the-best-package-manager-and-it-does-a-lot-of-side-effect-in-your-home-dir kind of trouble
<mothacehe>hey guix!
<MysteriousSilver>brendyn tissevert: thanks, i'll try making a derivation
<brendyn>MysteriousSilver, what package are you packaging?
<MysteriousSilver>nah, one of the program required conan as a dependancy
<MysteriousSilver>s/program/program that i tried to install
<brendyn>thats what im asking
<tissevert>so probably it means the guix packaging won't be that easy and will generalize the work done by conan
<MysteriousSilver>oh, audacity
<tissevert>audacity requires conan ? what ? but there already is an audacity package ?!
<MysteriousSilver>it was a custom build of audacity which had conan as build dependancy
<tissevert>ahhhh
<leoprikler>but why?
<MysteriousSilver>i've never compiled stuff locally before, wanted to know how it is done :D
<leoprikler>Oh, nothing against you, it was meant as "but why require conan as build dependency"
<MysteriousSilver> https://github.com/audacity/audacity/commit/8aca9d02de3c69f718dd12822edb5393c58d29bf
<leoprikler>Like, I know Windoof programmers spam everything with vcpkg, but usually you can avoid that if you set things up normally like a reasonable Linux user.
<leoprikler>okay, but shouldn't that fall back to pkg_check_modules as stated in the commit?
<leoprikler>minus the typo
<leoprikler>okay, yeah, they typo'd hard on PKG_CONFIG
<leoprikler>fix that and it ought to work again
<tissevert>typos ?
<leoprikler>PGK_CONFIG is probably false ;P
<tissevert>ohhh ^^'
<tissevert>how did you spot that ? I was searching for PKG_CONFIG, so of course I found only the correct ones
<tissevert>oh, the typo is there from the start in the message
<tissevert>ok, I should just learn to read ^^
<leoprikler>it's a common brain bug to assume stuff to be correct even when there's typos in it
<leoprikler>I probably just read the commit message with more attention than it deserved :P
<leoprikler>on a somewhat related note, given the recent drama around Audacity, we might have to move to a fork for 3.0.3
<apapsch>It seems uids and gids are not deterministic. I have mysql files residing on a separate disk. After swapping the system disk with a new one, mysql files belong to sshd
<leoprikler>apapsch: indeed, they are not
<leoprikler>they are generated from your system config and /etc/passwd, so they will honor what's already there
<leoprikler>there have been discussions of changing that behaviour in the past
<apapsch>So I should preserve /etc/passwd?
<leoprikler>if you want to mirror the user accounts between two machines, that sounds like a good idea
<apapsch>leoprikler: thanks, will look into it. though it would be easier if the whole root disk could be ephemeral :-)
<apapsch>do you have a link to the discussions of the past?
<leoprikler> http://issues.guix.gnu.org/issue/45571
<leoprikler>Does jbranso have commit access?
<leoprikler>seems not
<MysteriousSilver>(not guix related) tried compiling the package and i get a no such file found error, missing dependencies?
<MysteriousSilver>`../source_subfolder/src/common/cairo.cpp:24:10: fatal error: cairo.h: No such file or directory`
<leoprikler>use an ad-hoc environment with cairo and pkg-config, then add `pkg-config cairo --cflags` to your includes.
<leoprikler>Or do whatever your build system tells you to find cairo
<MysteriousSilver> http://ix.io/3scl
<leoprikler>hmm
<leoprikler>how does your cmake setup search for cairo?
<leoprikler>oh, wait, this is audacity again
<leoprikler>did you fix the pkg_config bug?
*MysteriousSilver shrugs
<MysteriousSilver>no experience with C
<leoprikler>oof
<leoprikler>okay
<leoprikler>first sed -i -e "s/PGK_CONFIG/PKG_CONFIG" **/*.cmake
<leoprikler>then exit whatever environments you're already in and enter a plain "guix environment audacity"
<MysteriousSilver>`sed: -e expression #1, char 23: unterminated `s' command`
<leoprikler>oops, add a between G"
<leoprikler>also do this in the source of course
<leoprikler>then after that all is done: cmake -B build -S ../audacity -G Ninja
<MysteriousSilver>where should i add `a`
<nckx>Morning, Guix.
<sneek>Welcome back nckx, you have 1 message!
<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>It can't hurt.
<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?
*nckx sighs in the general direction of DEs.
<leoprikler>nckx: due to telemetry and a bunch of other questionable things, there is now an ongoing fork war, so yay
<nckx>Heh, I was just reading more about it.
<nckx>Poor sods. http://audacity.com/
<nckx>(Well, probably not literally, of course.)
<nckx>Despite the emoji commit messages I like them already <https://github.com/tenacityteam/tenacity/commit/d28166652c33d9f81ac63ef3767852985049462b>
<nckx>At least unlike the Freenode drama we can now take our time to see how this pans out, so I'm not worried :) Fork wars are the tastiest wars.
<leoprikler>The emoji commit messages are the best imo
<tissevert>: )
<leoprikler>telemetry deserves the poop emoji
<nckx>Why would you not just rebase, though.
<nckx>Otherwise, agreed ☺
<leoprikler>To make a point, I guess? Also, if feature commits are woven into harmful ones, reverting the cherry-picked harmful ones might be easier.
<leoprikler>not to mention the good ol' "disguise this bug in a bunch of indentation changes"
<tissevert>nckx: hmm perhaps not the tastiest wars https://github.com/tenacityteam/tenacity/issues/99
<nckx>Yeah, 4chan launched an harrassment campaign.
<tissevert>I didn't know that : (
<maximed>sneek: later tell vivien: Using a delimited continuation made in one thread and using it in another _should_ work I think
<sneek>Welcome back maximed, you have 1 message!
<sneek>maximed, Noisytoot says: Where's the code that generates ~/.guix-profile/etc/profile?
<sneek>Will do.
<maximed>sneek: later tell vivien: IIUC, fibers sometimes does that when parallelism is enable (as part of ‘work-stealing’)
<sneek>Okay.
<raghavgururajan>Hello Guix!
<munksgaard>Hi!
<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>I gave you lxqt-policykit as an example to test.
<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.
<raghavgururajan>WDYT?
<vivien>maximed, thanks
<sneek>Welcome back vivien, you have 2 messages!
<sneek>vivien, maximed says: Using a delimited continuation made in one thread and using it in another _should_ work I think
<sneek>vivien, maximed says: IIUC, fibers sometimes does that when parallelism is enable (as part of ‘work-stealing’)
<raghavgururajan>import lxqt inside vpn.scm cause circular dependency. So polkit-gnome it is.
<MysteriousSilver>ok, so i cloned a different audacity version and now compiling it gives this error: http://ix.io/3scQ
<MysteriousSilver>any idea why?
***brown121407 is now known as smarton
***Guest3 is now known as Volodumur
<roptat>which package provides pdflatex?
<roptat>I mean "I can't find the format file `pdflatex.fmt'!"
<ruffni>roptat: i think it's texlive (at least for the pdflatex binary)
<raghavgururajan>How to restart services that doesn't have name?
<roptat>well, there's texlive-bin for the pdflatex binary, but that doesn't seem to work
<raghavgururajan>For example, polkit-service-type is in config.scm. It is running. But it doesn't show up in `herd status`.
<roptat>I don't want to use texlive as a package dependency
<raghavgururajan>So I am unable to do `herd restart polkit`.
<roptat>raghavgururajan, I think that's because polkit is not a shepherd service
<raghavgururajan>Ah I see.
<raghavgururajan>roptat: Can you make a service-type be managed by shepherd?
<roptat>if it extends the shepherd-service-type
<raghavgururajan>I see.
<nckx>raghavgururajan: I can't get the systray icon to show up. Literally: ‘No systray icon available. Things might not work for now, sorry...’
<nckx>Sway is compiled with ‘tray: YES’.
<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
<maximed>(to minimise variables)
<pazho>maximed: Yeah I tried that too
<Noisytoot>nckx, It installed, but it doesn't boot
<Noisytoot>The reason I used BIOS when my system supports UEFI is that the UEFI one doesn't decrease the font size, so the graphical installer looks weird
<nckx>I don't understand what ‘decrease font size’ means or what you expect.
<nckx>What happens when you try to boot sda?
<nckx>Noisytoot: ☝
<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>nckx: Systray seems to only work on composting WMs.
<raghavgururajan>Cool! I;ll rebase my checkout and push.
<Noisytoot>nckx, With the BIOS image, the font size is quite large, then it decreases. That doesn't happen with the UEFI image, which breaks the graphical installer
<Noisytoot>When I try to boot sda, I get: ERROR: No boot disk has been detected or the disk has failed.
<nckx>raghavgururajan: I still had 1.5 comments, see mail, but otherwise OK.
<nckx>Noisytoot: You could probably boot the system from a live GRUB such as the Guix installer's using ‘configfile (hd0,…)/boot/grub/grub.cfg’.
<nckx>I'm just pointing that out, of course it's not a fix.
<nckx>I've never encountered your problem before.
<dstolfa>nckx: what is the idea behind `guix git`? as in, would it be in the spirit of `guix git` to add a `guix git bisect` to it, or would it be a separate thing?
<pazho>boeg: If you meant 'environment' rather than 'container' then there's guix-set-emacs-environment and emacs-direnv
<nckx>dstolfa: Intuitively, I'd expect ‘guix git bisect’ to operate only on a local git checkout above $PWD.
<dstolfa>nckx: alright, `guix bisect` it is then :)
<nckx>Running ‘guix whatever [--]bisect’ without needing a local checkout is IMO a killer feature.
<boeg>pazho: thanks I’ll check that out
<nckx>dstolfa: Yeah, sounds good. I'd put it under pull if it modifies /home/nckx/.config/guix/current/bin/guix but I don't see the advantage of that.
<dstolfa>nckx: yep, will hack on it a bit as i get snippets of time and will see how it works :)
<dstolfa>thanks
<nckx>Thanks for this very cool feature idea.
<raghavgururajan>nckx: Thanks!
<raghavgururajan>nckx: Is this good? https://paste.debian.net/plain/1203674
<raghavgururajan>Seems polkit rules are different from polkit policies.
<nckx>Sure. Why not include ‘client’ though? I don't see the advantage of using the vague ‘application’, which could be a server or combination or something else.
<nckx>Yeah, I meant to add ‘I defer to you on the awkward "permission rules" wording’, which was meant to be revised. I forgot :)
<raghavgururajan>s/.application/cliebt
<nckx>Yes please.
<nckx>Also, it's → its.
<nckx>Matter of taste but ‘needs’ does not require emphasis IMO.
<raghavgururajan>Cool!
<nckx>…and I'm closing the tab because that's quite enough bikeshedding.
<nckx>Thanks!
<raghavgururajan>👍️
*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)
<nckx>So it doesn't even see your internal drive.
<nckx>Pfrt.
***xgqt_ is now known as xgqt
<nckx>*I* would: boot the installer again, mount your sda at /mnt, run ‘grub-install --{recheck,no-floppy,root-directory=/mnt} /dev/sda’ and see what it prints.
<nckx>Make that boot-directory=/mnt/boot
<nckx>no-floppy is also obsolete, so that can go too.
<nckx>Me old.
<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"
<Noisytoot>Installing for i386-pc platform.
<Noisytoot>Installation finished. No error reported.
<raghavgururajan>roptat: I see. But the core files still exists in ~/guix/master right?. where you setup hooks?
<roptat>yes
<raghavgururajan>Ok.
<roptat>if you clone as ~/guix/master, ~/guix/master/.git contains everything
<roptat>and I didn't need to configure the other worktrees (I had to configure master though)
<raghavgururajan>Yeah, I was wondering if I could administrative files (branch/worktree independent) in ~/guix and have branches checkedout as worktrees in sub-dirs.
<raghavgururajan>*could have
<nckx>Noisytoot: And it still doesn't boot? Something fishy (and not directly Guix-related) is going on, but perhaps you've booted other BIOS GRUBs on this machine before?
<nckx>raghavgururajan: What are administrative files?
<nckx>For example.
<roptat>raghavgururajan, maybe if you clone as ~/guix, and checkout a new orphan branch there
<raghavgururajan>Where you place hooks and stuff, that are applied across branches/worktress.
*raghavgururajan tries --bare
<roptat>ah maybe
<Noisytoot>nckx, It still doesn't boot. I've booted other operating systems using GRUB before, but I don't know if it was using BIOS
<nckx>raghavgururajan: But hooks are placed in .git, which is global by definition.
<nckx>Your worktrees don't have .git/s.
<nckx>You can also have as many unstaged files as you want, wherever you want, just don't check them in.
<raghavgururajan>Yes, I want the .git to be in ~/guix without any checkedout files.
<vagrantc>worktrees have a .git file that points to it's corresponding .git directory
<mothacehe>nckx: just reviewed your file-system check series, nice work!
<nckx>vagrantc: My / was a bit too subtle, true. It's a plain text file, a low-tech symbolic link.
<nckx>.git not .git/.
<nckx>mothacehe: It was born of pain. Thanks for the review!
<mothacehe>hehe that's the feeling I had
<mothacehe>hope you recovered your data
<raghavgururajan>Success
<raghavgururajan>just a sec
<vagrantc>nckx: sure :)
<nckx>mothacehe: I did!
<raghavgururajan>I did, [1] git clone raghavgururajan@git.savannah.gnu.org:/srv/git/guix.git --bare [2] `cd guix.git` [3] `git worktree add -B master master` [4] `git worktree add -B staging staging` [5] `git worktree add -B core-updates core-updates`
<raghavgururajan>My tree now looks like [1] ~/guix.git [2] ~/guix.git/master [3] ~/guix.git/staging [4] ~/guix.git/core-updates
<nckx>An interesting layout.
<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
<boeg>dstolfa: ill try it out
<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.
<boeg>dstolfa: seems to be working, thank you
<dstolfa>boeg: yay!
<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.
<Noisytoot>nckx, The UEFI graphical installer seems to expect the resolution/screen size to be larger than it is and wraps around: https://x0.at/UlOq.JPG
<raghavgururajan>nckx, roptat: Never mind! The trick didn't work.
<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>Probably, I just don't know how.
<nckx>Noisytoot: Check fbset. You can switch to a different VT with C-M-Fn. F2 is the manual, F3-F6(?) are free.
<nckx>You can install & run it there.
<nckx>It can even change the resolution on the fly but I don't know if that will work or if the installer will like it.
<Noisytoot>-bash: fbset: command not found
<nckx>Then you didn't install it.
*Noisytoot connects to wifi and installs fbset
<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.
<nckx>I agree.
<nckx>This doesn't affect only proprietary libGLs, though, does it?
<nckx>Because then why bother.
***lh is now known as hupfer
<apteryx>ah, I understand why LD_LIBRARY_PATH=/usr/lib is a bad idea; it'd lead to all the libraries from the host taking precedence over those provided by Guix.
<apteryx>(wrote that before reading your reply, nckx :-))
***hupfer is now known as lh
<Noisytoot>With UEFI, it's 640x480
<nckx>It's good to have independent thinks, even better when they agree 😊
<nckx>Noisytoot: That's what I guessed based on your screenshot.
<nckx>Which means that the installer *probably* still handles 800x600, which isn't bad. I don't know if handling 640x480 is realistic without rewriting a lot.
<nckx>If you manage to fbset yourself out of it I hope support for it can be added to the installer though.
<nckx>Oh, maybe better: kmscon also supports setting a font size, so you could keep the 640x480 even on buggy machines and just shrink the font to, say, 10 or 8.
***lh is now known as hpfr
***hpfr is now known as lh
<civodul>mothacehe: hey! am i right that build products are not retrieved by the Cuirass "remote server" when a build fails?
***lh is now known as hpfr
<civodul>one example is: everything gets built up to (@@ (gnu packages commencement) guile-final) excluded, which fails, but then none of its prerequisites are available on berlin
***hpfr is now known as lh
<mothacehe>civodul: hey! the dependencies of guile-final are not registered as cuirass jobs I guess. It means that if the build of guile-final fails in some dependency nothing will indeed be fetched.
<mothacehe>fetching the build products is nothing more than calling "ensure-path" on the derivation outputs
<mothacehe>with substitute-urls set to the machine that performed the build
<nckx>…QEMU isn't falling for my attempts to limit it to 640x480…
<Noisytoot>and it's 1024x768 with BIOS
<drakonis>hmmm
<drakonis>swap all of the mesa deps to libglvnd for foreign distribution interop?
<drakonis>rather, migrate to libglvnd to have working gl in foreign distributions?
<podiki[m]>drakonis: I don't know about libglvnd stuff, but have been testing newer mesa with irfus
<podiki[m]> https://issues.guix.gnu.org/49339
<podiki[m]>noticed some libglvnd changes in their patch (still waiting for other updates on mesa-dependent stuff), maybe coordinate there?
<drakonis>oh nice
<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)
<apteryx>OK, so I take it as "expected". Thanks!
<apteryx>it's a bit disappointing that it makes our guix pack much less universal for GUI applications.
<drakonis>you should check how other distributions do it
<drakonis>but as far as i'm concerned, mesa has to be replaced with libglvd
<apteryx>they let the linker dynamically open the opengl libs from /lib or the likes
<podiki[m]>as one who has suffered (minimally, compared to others) with nvidia, i'm happy to be moving away
<apteryx>in Guix we can't allow things to look in /lib or /usr/lib as that'd mean the libraries on foreign distributions would now 'contaminate' the run time of Guix.
<apteryx>reading https://github.com/NixOS/nixpkgs/issues/9415, it seems non-trivial to fix. It requires people copying their system gl libs somewhere else, massaging their rpath, and adding these modified versions to their LD_LIBRARY_PATH (IIUC).
<podiki[m]>drakonis: so then we definitely want mesa build with libglvnd support I take it?
<drakonis>yes
<drakonis>well, i'm still trying to get a new gpu
<drakonis>but being able to use guix on other distributions and still get graphical applications is nice
<podiki[m]>it is so tough out there. I finally did with some luck
<podiki[m]>looks like nix has a helper thing: https://github.com/guibou/nixGL
<podiki[m]>seems like a wrapper, to launch things with whatever driver/gl libs you want at the time
<apteryx>podiki[m]: I heard about it, but it's not so nice as it requires to know which lib you are targetting at build time
<apteryx>not a suitable option for guix packs
<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>s/thare/that/
<apteryx>drakonis: I'm reading up on libglvnd; seems it was created expressly to fix this problem?
<drakonis>yes
<drakonis>so you have side by side libgl implementations
<apteryx>have you already thought of how it could work with Guix?
<drakonis>nix does an incredibly elaborate setup to achieve what it does
<podiki[m]>we have libglvnd in guix, how does it work now?
<drakonis>the other distributions take the easy road and simply build packages against libglvnd
<apteryx>drakonis: has nix already solved that libGL problem? I see issues still opened about it.
<drakonis>then libglvnd is configured accordingly to find the libgl implementations it needs
<drakonis>yes it has
<dstolfa>drakonis: what are the issues about then?
<apteryx>drakonis: for example https://github.com/NixOS/nixpkgs/issues/9415
<drakonis>this issue is 6 years old now
<drakonis>it is largely related to running it with standalone nix, no distribution
*apteryx grabs lunch
<drakonis>i distinctly remember having issues with libgl on nixos until they actually used libglvnd
<drakonis>which this issue predates
<drakonis>it was opened a year before the first libglvnd release
*raghavgururajan had discussion of guix in #cat-v (oftc.net) and couldn't stand the irrationality.
<dstolfa>raghavgururajan: what did you expect? it's an echo chamber that considers "GPL harmful software" lol
<raghavgururajan>dstolfa: I didn't know that. I started with why screen is bad and tmux is good, as their site mentions it. Then it went on to guix. xD
<dstolfa>raghavgururajan: http://harmful.cat-v.org/software/
<dstolfa>these people are best avoided IMO
<raghavgururajan>Atleast in #suckless (oftc.net) I get some fair arguments.
<Noisytoot>Why is dynamic linking useless?
<dstolfa>Noisytoot: it's... not.
<Noisytoot> http://harmful.cat-v.org/software/ says it is
<dstolfa>yes, cat-v is, for the lack of a better word, harmful.
<dstolfa>i didn't link cat-v because i agree with it, i linked it because of how ridiculous and misinformed its claims are
<southerntofu>i agree with the "all software sucks" quotes but disagree with most harmful statements :)
<sneek>southerntofu, you have 2 messages!
<sneek>southerntofu, nckx says: Your message arrived 8 more hours after you said ‘it's been a few hours’.
<sneek>southerntofu, nckx says: Subscription is not a factor in that, though; you just got unlucky.
<Noisytoot>nckx, fbset 1024x768 fails with "/etc/fb.modes:6: syntax error", with https://x0.at/_kCX.txt (the output of fbset when using BIOS) in /etc/fb.modes
<nckx>Oh boy we're discussing cat-v now oh boy.
<southerntofu>thanks sneeky bot :)
<Noisytoot>cat-v are correct that Adobe Flash is useless and harmful
<dstolfa>nckx: well, raghavgururajan mistook them for sensible people :P
<nckx>Good thing nobody uses it then.
<dstolfa>Noisytoot: they're throwing shit at a wall and seeing what sticks. a stopped clock is correct twice a day
*nckx runs all their critical enterprise Flash code in Gnash.
*apteryx chuckles
<nckx>Noisytoot: Does it have a trailing newline? (I know, I'm really grasping at straws; I also can't support fbset itself.)
<nckx>I'll try it in a VM.
<Noisytoot>nckx, yes
<nckx>A bloody slow VM.
<Noisytoot>does it use kvm?
*nckx was just thinking: did my /dev/kvm permissions go bork again.
<nckx>Anyway, we managed to get to a prompt (great job), let's saunter on.
<raghavgururajan>How frequent does guix manual gets rebuild for web?
<nckx>Hourly.
<nckx>Make sure you're looking at the ‘devel/’ manual if you're expecting something to change. And note that the job sometimes breaks.
<nckx>No bitmask indeed.
<raghavgururajan>Yep, I was lookit at devel.
<raghavgururajan>*looking at
<roptat> https://guix.gnu.org/manual/devel/en/ is still from july 4
<apteryx>roptat: it must be the same problem we had during the last release; the workaround was to build it with one core, correctÉ
<apteryx>?
<nckx>lfam was debugging *something* related to broken manual builds.
<na2th>how do I install a package I obtained via guix copy?
<roptat>apteryx, yes
<na2th>(hello everyone o/)
<apteryx>roptat: we should apply the workaround to the build recipe for the time being
<roptat>sure
<apteryx>so somewhere in doc/build.scm
*apteryx tries reproducing the problem with 'guix build -f build.scm'
<apteryx>seems easy to trigger! got it on the first try
<apteryx>mmap(PROT_NONE) failed / builder for `/gnu/store/f8fdzi1hp7b3ln2zz6z87p3cj3gf0ac5-guix-translated-texinfo.drv' failed due to signal 11 (Segmentation fault)
<apteryx>so now we know which gexp to look at
<apteryx>translate-texi-manuals is in (guix self)
<nckx>Noisytoot: The slowest VM in the west is up. fbset -xres <W> -yres <H> works.
<apteryx>roptat: so setting parallel-jobs to 1 in the builder expression should do it
<roptat>I guess ^^'
<nckx>…although QEMU's ‘Best Fit’ doesn't shrink the window to match so maybe it's not changing the ‘physical’ resolution.
<apteryx>roptat: hmm, it didn't :-/
<roptat>oh?
<apteryx>oh wait, forgot the pre-inst-env
<Noisytoot>nckx, that runs (with no output), but doesn't do anything
<nckx>If neither this nor GRUB gfxmode work I'm out of ideas. Sorry.
<apteryx>roptat: nevermind, it seems to work (albeit slowly) :-)
<nckx>Well, besides building a custom installer image with the kmscon service tweaked to use font size 10 or 8.
<roptat>apteryx, yeah...
*Noisytoot tries GRUB gfxmode
<nckx>It's great that Guix makes that ‘easy’ but it's horrid if it's needed.
<apteryx>roptat: the "fix" looks like this: https://paste.debian.net/1203703/
<apteryx>hmm, wrong issues url
<roptat>apteryx, looks good
<apteryx>should be 47428
<Noisytoot>adding gfxpayload=1024x768 to the linux... line in GRUB doesn't do anything
<nckx>No, it's a variable.
<nckx>…for GRUB. Not a command-line argument for Linux.
<nckx>‘set gfxpayload=1024x768’ at the GRUB command line (‘c’, I think, at the menu).
<apteryx>roptat: pushed, thank you
<roptat>thanks!
<apteryx>I think we'll have to reconfigure berlin before it becomes effective though (so that it gets a new 'guix' with the fix)
<lfam>Thanks for taking care of that
<apteryx>np! sorry it took so long
<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)
<roptat>I think that's what it does
<roptat>we'll see I guess :)
<apteryx>but that module goes on to load other guix modules such as (guix self) (which is where the fix lives
<apteryx>(@@ (guix self) translate-texi-manuals)
<apteryx>re my earlier question I think it's caused by my user profile guile being at 3.0.5 while the system one is at guile 3.0.7.
<apteryx>I bet the Guix modules are found from the system and built for 3.0.7 and I'm trying to use that from 3.0.5.
<apteryx>strangely though using ./pre-inst-env my-script doesn't resolve it
<lfam>Is there a way to specify the version with `guix import pypi`?
<lfam>Normally I wouldn't care but I'd like to package this: https://pypi.org/project/Av1an/
<lfam>However, the latest release only offers a wheel
<apteryx>doesn't look like it, lfam
<Noisytoot>nckx, it boots with the correct font size, but it boots to Guile, probably because I misspelt a UUID or /gnu/store path
<lfam>That project also doesn't seem to be making tags for recent "releases"...
<Noisytoot>Is there a way to boot as specified in grub.cfg, but with that variable set (to avoid retyping /gnu/store paths or UUIDs)?
<nckx>Er
<nckx>I think you're overcomplicating things for yourself.
<lfam>I've been looking into these video encoding / measurement suites and they all seem to want you to use docker
<lfam>Annoying
<dstolfa>lfam: docker works pretty well in guix, so maybe that's fine as a workaround for now?
<dstolfa>also hi!
<lfam>Howdy!
<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?
<nckx>*y
<dstolfa>yeah, that's fair lfam
<lfam>If I'm really pressed, I can just encode and transcode "by hand" with ffmpeg, or use a commercial tool
<lfam>Docker is like a weird middle ground that isn't satisfying
<lfam>I might not use this program anyways. They are starting to add Rust dependencies and that's still a no-go for me at work
<Noisytoot>that works
***MidAutumnMoon9 is now known as MidAutumnMoon
<na2th>so people, how do I install a package already in my store, but not in my profile? I was able to build texlive from a patch submitted to Guix
<na2th>but the whole thing is so huge I had to do it in another machine
<na2th>(could not get offloading to work properly)
<na2th>I then used guix copy to send it to my machine
<na2th>I can see it in my store
<dstolfa>na2th: hmm, if you just do a `guix install`, it should compute the hash, realize that the package already exists in the store and just symlink it
<dstolfa>if it is indeed the same package
<na2th>dstolfa: do I need to run this from the checkout which I used to build the package?
<na2th>I tried it, and it started downloading a *load* of things
<dstolfa>yes, you'd do a `./pre-inst-env guix install ...`
<dstolfa>are the hashes different maybe?
<na2th>perhaps... but both machines have cloned the same repo, and are at the same commit
<lfam>It is possible to do `guix package --install /gnu/store/...-your-built-package`
<jackhill>lfam: yes
<jackhill>I did that the other day
<lfam>That method of installation loses some information, for example about the name of the package, etc
<lfam>You could consider it to be an extra-lossy method
<lfam>I would do what dstolfa suggests, though, if it can work at all
<lfam>The way to check "is it the same package" is to compare the derivations
<na2th>hm, I am not too concerned about losing information; I just want to test the package and see if I can find bugs in the patch
<jackhill>oh, I missed that lfam wasn't asking the question :) Yes, I agree that there are cleaner methods :)
<lfam>`guix build --derivations foo`, or `guix install foo --dry-run` and see if the names of the derivations are the same
<na2th>I will dig into it and see what I learn
<na2th>thank you all!
<lfam>The derivations are the actual "build script", created from the package definitions and given to guix-daemon
<roptat>na2th, texlive has grafts, so you probably copied the result, but guix doesn't know it's what it wants until it has built the ungrafted version
<vagrantc>i hear rumours linux 5.13 will run on the hifive unmatched board with the right configuration
<vagrantc>so riscv64 is getting less and less theoretical...
<lfam>I'll be making the kernel configs for 5.13 the rest of this week
<lfam>I got lazy and didn't do a single ounce of advance work
<na2th>roptat: it does has grafts. What should I do about it?
<lfam>vagrantc: Is there anything we should do about that now?
<vagrantc>lfam: i should check if the pinebook-pro patch(es) are still needed
<roptat>na2th, a solution would be to copy the result of "guix build texlive --no-grafts" too
<vagrantc>lfam: i wanted to experiment with having all the linux-libre packages depend on a single source package or something
<lfam>That would be nice
<lfam>It can happen in between upgrades, too
<vagrantc>it would be a much more efficient use of substitute server build resources
<na2th>roptat: I just ran this command on the server, it only lists the package I copied
<lfam>I'm viewing my work on the kernel packages as limited to making kernel configs and upgrading. The actual package machinery (and it is a machine) is something I'm ignoring
<roptat>mh, then your guix is downloading the replacement packages it will use to graft? in your local machine, what does "guix build texlive --no-grafts" do?
<vagrantc>lfam: that's fair, thanks for keeping that going! :)
<lfam>Hey, it works, more or less :)
<lfam>As we know, it doesn't always work
<vagrantc>i forget where the discussion stopped with bumping the timeouts on building the linux-libre source tarball
<lfam>IIRC, I couldn't figure out how to do it
<lfam>And, I wanted to try babysitting those builds to ensure they succeeded, but I realized that we totally lacked the resources to build them
<lfam>That should be improving really soon
<lfam>If not already
<vagrantc>yeah, having proper builders would help :)
<lfam>cbaines got a honeycomb running on the Bordeaux build farm, so we have the knowledge to deploy the honeycombs that rekado ordered on the Berlin build farm
<vagrantc>nice!
<na2th>roptat: my local machine lists a bunch of distinct packages, and gives a distinct hash for texlive
<na2th>I will try guix package --install /gnu/store/...texlive soon and see what happens
<roptat>if it's a distinct hash, something's wrong, did you apply the same patch on the same revision? did you use ./pre-inst-env in both cases?
<na2th>I must have used ./pre-inst-env in both cases, otherwise I would have obtained a distinct version
<na2th>I will clone the repo again and run things starting from ./bootstrap
<na2th>perhaps there is some noise from compilations in other branches?
<lfam>It is possible to accumulate some bogus state when using pre-inst-env in the work tree. If you're uncertain, you can do `make clean && ./bootstrap && ...` again
<roptat>I don't think so
<roptat>ah, you mean you switched branches? then maybe
<apteryx>civodul: oh, interesting; guix pack --target=aarch64-linux -S /usr/bin/guile=bin/guile -RR guile says "guix pack: error: cross-compilation not implemented here;\nplease email 'bug-guix@gnu.org'"
<maximed>apteryx: aarch64-linux-gnu? I think you need the -gnu. At least, some packages expect it
<maximed>nix systems != autotools triplets
<lfam>That's true
<lfam>--system and --target take different arguments
<maximed>Also, it seems that "guix pack" doesn't support cross-compilation (at least in c-compiler-compiler)
<apteryx>maximed: I managed to build guile@3 with --target=aarch64-linux
<apteryx>does that mean it's an acceptable value?
<apteryx>perhaps we need a --list-targets option ;-). Even the autotools reference in our manual is not useful, unless I missed something
<maximed>apteryx: projects using autotools have a "config.sub" that automatically turns aarch64-linux into aarch64-linux-gnu
<maximed>(or aarch64-unknown-linux-gnu maybe?)
<apteryx>I see
<maximed>as long as you're only building packages using the autotools, it shouldn't matter if you write aarch64-linux or aarch64-linux-gnu
<maximed>But some packages are pickier (I don't have an example currently in mind though)
<apteryx>thanks for the clarifications. Is there a definitive place to look at to see all the possible GNU triplets in existence?
<maximed>"guix build --list-targets" output: ‘Supported cross-compilation targets: TRIPLET description ... Unsupported targets with limited suport: mingw-bla-bla ...’
<maximed>?
<maximed>apteryx: not that I know of
<maximed>One problem with such a thing would be that, say, aarch64-pc-gnu is in principle a perfectly reasonable triplet -- except the Hurd doesn't suppport aarch64
<maximed>but having a list of supported triplets in the manual may be useful
<apteryx>maximed: seems that would be useful yes (that --list-targets command)
<darth-cheney>hello all, I'm trying to run the latest Squeak VM (squeak.org), which comes as just a linux binary download
<darth-cheney>But when I try to run the binary I get "No such file or directory", which doesn't make sense to me since I'm looking right at it
<drakonis>that refers to the linker
<maximed>darth-cheney: "strace the-binary"
<darth-cheney>There must be something I'm missing or not understanding about running binaries in guix?
<drakonis>also patchelf
<drakonis>it's good
<na2th>lfam and roptat: I am running guix package --instal /gnu/store/..., I will see how that goes; when it finishes running, I will also clean the tree and see if I can get the same hashes as before
<darth-cheney>maximed: one sec, gotta install strace
<lfam>The VTK packages that inherit from VTK 9 are all broken. Another inheritance failure
<lfam>I'm fixing VTK 8 now
<maximed>probably, if you run "objdump -x the-binary", you'll see the linker is wrong
<maximed>(Correct for LFS distros though)
<darth-cheney>aha I see, so really this needs to be built with guix packaging
<lfam>Or you can make the necessary files available in the expected locations
<lfam>It's possible to plant a new symlink forest
<darth-cheney>sounds like the kind of thing I would do, forget about, then have bite me in the ass half a year from now
<lfam>Yeah, maybe :)
<darth-cheney>I have been in talks with some guys about packaging the opensmalltalk-vm for guix, but the build process there is really complicated
<lfam>On Guix System, I've seen people use the extra-special-files service to do it, and at least that way it's managed in your config.scm. On other distros, you'd have to do it "by hand"
<darth-cheney>and I am a guix novice, so probably not a good idea as my first packaging attempt :)
<lfam>It's all up to you :)
<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
<maximed>It shouldn't rebuild _everything_
<apteryx>don't 'guix pull' in between
<civodul>maximed: i'm not sure about --list-targets because the list of targets is open ended, but we could at least have a warning for likely bogus triplets
<darth-cheney>not everything but there seems to me some kernel stuff that gets rebuilt each time?
<lfam>Hm...
<apteryx>civodul: sure, it's opened ended but we could word it that way; known, supported targets: x, y, z, ...
<lfam>darth-cheney: Are you choosing a kernel package in your config.scm? Or do you use the default?
<apteryx>that's already be more useful than sending users scrambling on the net for valid gnu triplets
<apteryx>that'd*
<lfam>And, what kind of CPU architecture are you using? Like, x86_64 / amd64, i686, aarch64, etc?
<lfam>Also, I assume that you intend to use "substitutes". That means, use pre-compiled binaries when they are available...
<darth-cheney>lfam: It's an amd64 (but dinky) and yes I'm using substitutes
<darth-cheney>I'm also using nonguix for some wifi capabilities but I'll say no more about that
<apteryx>that may explain part of it (you'd be missing substitutes for the kernel, which is an expensive piece of software to build)
<lfam>Assuming you are using the linux-libre kernel, substitutes do seem to be available: https://ci.guix.gnu.org/search?query=spec%3Amaster+system%3Ax86_64-linux+linux-libre
<darth-cheney>ok that must be it then
<lfam>Also, `guix weather linux-libre` gives a positive result
<apteryx>lfam: they aren't using linux-libre
<lfam>But, if you are using their kernel, then our build farm won't provide a substitute
<lfam>These distros kernels are really expensive to build. They support just about everything
<darth-cheney>Ok I'm just going to have to deal with it for the time being. Getting a Reform laptop soon which has open wifi drivers so hopefully won't have to deal with this
<tricon>darth-cheney: Reform looks hot.
<darth-cheney>tricon: I'm trying to stay patient.
<lfam>It might be worth it to find or write a more minimal kernel config. It will reduce build times significantly
<lfam>Right now, you're building in support for hardware you'll probably never use
<tricon>I picked up a PineBook Pro that I am really enjoying. Don't have Guix on it yet, though.
<darth-cheney>lfam: yeah I could probably freeze on some commit somehow too?
<lfam>I don't recommend that, but it would help to avoid building things. Basically, every kernel update fixes a huge number of bugs
<vagrantc>drakonis: the reform might have you rebuilding a lot more unless aarch64 substitute support starts working a lot better :)
<lfam>And adds new bugs of course
<vagrantc>er, ...
<vagrantc>darth-cheney: ^^^
<tricon>Anyone know what the meatiest aarch64 CPU is that is generally available?
<darth-cheney>vagrantc: that brings me to another question -- is there a way for some community to host its own substitutes?
<lfam>Nothing is readily available currently, due to the semiconductor shortage. But it's probably this: https://shop.solid-run.com/product/SRLX216S00D00GE064H08CH/
<vagrantc>darth-cheney: anyone can run guix publish, sure
<lfam>This is way more powerful, but accordingly more expensive: https://store.avantek.co.uk/ampere-altra-64bit-arm-workstation.html
<darth-cheney>I think Lukas and others at the MNT forum have been talking about making a system config for Reform, and I assume MNT would end up hosting some substitutes
<darth-cheney>aha ok
<lfam>Beyond that, the only things available are 5+ year old cellphone chips
<vagrantc>darth-cheney: i've been meaning to do that for a subset of packages i care about on aarch64 (and maybe armhf), but haven't gotten around to it yet.
<lfam>There's not much middle ground between "old and slow" and "datacenter"
<tricon>lfam: Both of those look appealing. I appreciate the info. I'm hopeful for a aarch64 desktop someday.
<lfam>Things seemed to be looking up before the pandemic
<lfam>I suppose that an in-between option is the Rockchip RK3399
<vagrantc>the pinebook pro is not too bad ... it's got a couple cores that are medium speed rather than slow
<vagrantc>yeah, any of the rk3399 aren't too bad
<lfam>It's just a bit sad when you compare it to cellphones
<tricon>lfam: Yeah.
<vagrantc>cellphones have other sadnesses :)
<tricon>vagrantc: Exactly!
<lfam>Yeah, I know :) I just mean that the cellphones are several generations beyond anything that's available for SBCs or desktops
<apteryx>What is the appeal of ARM when compared with POWER ? As a personal workstation?
<lfam>I think it's the Pi-factor. ARM gained popularity first, by starting cheap
<lfam>It's an effective way to build a userbase
<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
<lfam>But, that's a special use case
<lfam>ARM has taken over from MIPS as a networking platform
<darth-cheney>What do you all think about riscv
<lfam>The future is bright!
<lfam>Alright, g2g
<jackhill>The GPU/VPUs commonly used in Arm SoCs have reverse engineered drivers that don't need non-free firmware. I don't know of anything equivelent yet in POWER.
<jackhill>and Arm workstations are still cheaper than POWER workstations :)
<jackhill>there are power concious POWER chips, but they're not used in workstartions yet (maybe with https://www.powerpc-notebook.org/en/ some day)
<darth-cheney>I implemented the riscv 32I instructions (with a simulator) in Squeak, was a nice proof of concept
<apteryx>sounds fun!
<vagrantc>jackhill: powerpc-notebook.org doesn't look like it will run ppc64el/powerpc64el
<vagrantc>and the other powerpc platforms are bit-rotting a bit...
<jackhill>vagrantc: is it big-endian? It's one of the NXP netorking/MCU SoC right?
<jackhill>and maybe an older ISA version?
<vagrantc> https://www.powerpc-notebook.org/faq/ suggests that it misses some features used by other ppc64le distros
<jackhill>ah, thanks
<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 :)
<darth-cheney>are any of you all rcirc users?
<efraim>I have powerpc-linux merged in core-updates
<efraim>riscv64 is looking much better on core updates, I'll probably refresh the wip branch tomorrow
<efraim>Although for the powerpc it takes about 70 hours to build from the bootstrap-binaries to hello
<apteryx>any reason it's that slow?
<efraim>The machine is about 15 years old and guile compiles very very slowly
<apteryx>I see :-)
<jackhill>efraim: cool on both fronts. I assume this is guix on a foreign distro and not guix system for powerpc?
<apteryx>very cool indeed!
<efraim>Yeah, the base distro is Debian sid
<jackhill>that was going to be my next question, thanks
***jonsger1 is now known as jonsger
<vagrantc>efraim: riscv64 is actually working on core-updates ... i think my last attempts failed at various -boot0 variants of utilitis (findutils, maybe?)
<vagrantc>efraim: or rather, *is* riscv64 working on core-updates
<efraim>I made it to python-boot0 but dmesg started showing problems
<jackhill>Is it possible to run both openssh and lsh servers at the same time? Currently they both provide ssh-daemon, so I can't have both services in my operating system definition at the same time
<leoprikler>perhaps, but they conflict in shepherd
<leoprikler>iiuc
<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
<apteryx>that's clever
<apteryx>perhaps you could also run multiple instances of openssh? I wonder if this could work.
<apteryx>on different ports
<jackhill>an interesting idea, I hadn't looked into it
<dstolfa>seems like you should be able to pass in (openssh-configuration (port-number num)) to the service it might work
<apteryx>we also have a wireguard service, although it's not perfect yet for dynamic IPs (we should add some automatic refresh for IP changes)
<jackhill>but it's also a good excuse to experiment more with lsh, since I haven't used it before