<BitPuffin>Okay so a (possibly quite bad) solution I found to my problem yesterday with not being able to run executables built for typical distros was to install libtool and use `libtool execute program' but it doesn't help me run app images
<leoprikler>you could probably hack together a computed origin, but I'm not sure whether that'd be worth the price.
<Aurora_v_kosmose>Unless you use the GRUB device naming convention, it might work anyway using that.
<_tecosaur>Hey guys, I'm trying to work out how to package gitea. The frontend and backend can be compiled separately (which I'll need to do as one uses node/npm, the other Go) I just need to work how to put the compiled frontend files into the right place for the backend compilation.
<_tecosaur>I'm hoping someone may be able to help me work out how to get this to happen, and whether I need to use a native-input or propagated-input for this
<efraim>gnulib tests fail on findutils-boot0 on aarch64 on core-updates
***apteryx is now known as Guest14637
***apteryx_ is now known as apteryx
<BitPuffin>Aurora_v_kosmose yeah I was looking a bit at the menu entry definition but it seemed linux specific
<snai1>Hi, i would like to install pdflatex in guix, but i really can't figure out which package should install. Now i'm trying to installing it using tlmgr but for now i'm getting the error "Can't locate TeXLive/TLConfig.pm in @INC (you may need to install the TeXLive::TLConfig module) (@INC contains: /gnu/store/cw8d..." anyone here uses latex on guix? Thanks
<ngz>snai1: There is the full "texlive" package, but I think pdflatex is in texlive-bin package contains the executable.
<ngz>(my sentence doesn't make much sense, but I think you got the idea)
<cbaines>It seems that guile-ssh doesn't build on core-updates, something to do with the source files being read only
<n1to>What are the difference between the lgpl3 and lgpl3+ licenses in guix? I haven't seen lgpl3+ mentioned outside of guix. In the repl both have the same uri and comment.
<leoprikler>n1to: Whether the source has "or (at your option) any later version".
<n1to>ok. Thank you. Is there also a list of all conventional package outputs. The documentation only mentions lib and debug. I have also seen utils, static and python. Is this something that is determined on a per package basis?
<leoprikler>it's per package, but popular ones are "bin" "lib" "debug" and "doc"
<apteryx>rekado: interestingly, IIUC, the system tests (those where you can select a single test via make check-system TESTS=test-of-interest, uses its own mechanism and doesn't make any use of the test-driver.scm SRFI 64 test driver. Instead, it builds a manifest of system tests (handles the discovery itself) and run its with 'guix build -m $(top_srcdir)/etc/system-tests.scm'.
<apteryx>the system tests don't make use of srfi 64 at all.
<PotentialUser-26>Hi all! I was wondering if there is something similar to nix overlays in guix. I want to make something that basically has the same functionality as the rust overlay from mozilla (specifying which rust channel and which components to install, etc.)
<apteryx>rekado: yes, so that now I can do: make check SCM_LOG_DRIVER_FLAGS="--select=^transaction-upgrade-entry --brief=no" TESTS=tests/packages.scm, and all tests except those starting with transaction-upgrade-entry are skipped.
<raghavgururajan>inside let, like (let (("foo" (string-append (getbuilddir) "/bar"))))
<pineapples>raghavgururajan: Pardon the question but have you, by any chance, made an attempt to run your Telegram package under Wayland? I might be wrong on this but I have a suspicion that some of Qt software that has been packaged for Guix doesn't pick the Wayland platform plug-in found in the qtwayland package up for some reason. I hope that that issue won't affect your package as well.
<pineapples>raghavgururajan: I'll admit that I have a limited knowledge about the codebase of Telegram's desktop client, but I have to ask: isn't the sole purpose of gtk-integration to enable the client to better integrate with GNOME Shell? I don't think that what you're describing is possible
<leoprikler>yeah otherwise materialdecoration wouldn't make sense
<leoprikler>pineapples, do you have a QtWayland setup for testing?
<pineapples>leoprikler: Thanks, I'm currently running the next to last sequence of build commands. I'll report back as soon as something breaks down or I manage to successfully run my series of tests against telegram-desktop
<leoprikler>does that mean you're at make or at ./pre-inst-env?
<bdju>anyone have experience working with qmk on guix? I have a new keyboard that has to be programmed
<bdju>pineapples: sounds about right. was curious what works best between pip or cloning the repo directly or if someone had their own private guix package for it already maybe.
<bdju>I'm making an attempt with the pip route now. no luck so far, but I was trying on an arch machine earlier and had no luck there either, so can't say for sure guix is to blame here...
<pineapples>bdju: Did you try the qmk package from Arch Linux's repository?
<jsoo>I've been working on ghc for aarch64. I was working with the hope that I could cross compile it to aarch64 and use the cross compiled version to bootstrap newer versions. Is that possible? For some background, cross compiling ghc stage 2 compiler outputs a compiler that runs on the target host and targets the target
<jsoo>So in guix parlance, building with the --target flag would produce a derivation for the corresponding system
<bdju>pineapples: yeah tried both community/qmk and the aur qmk-git. I've never used qmk before now so not sure if the problem is me or something else, like maybe the default layout for the board has an issue
<leoprikler>jsoo: I doubt, that's fair game in Guix, but it might technically be possible
<jsoo>Hmm. Well it's possible to get a binary for aarch64 and bootstrap from there, too