IRC channel logs


back to list of logs

<raghavgururajan>leoprikler: I have sent v10 for the telegram-desktop patch-set, containing your suggested changes. :-)
<leoprikler>raghavgururajan: hime lgtm, nimf not so much (description is weird english)
<ekaitz[m]><raghavgururajan "Folks! In this license file (htt"> Looks like MIT
<raghavgururajan>ekaitz[m], thanks!
<ekaitz[m]>check here:
<ekaitz[m]>looks like the old-style MIT license
<ekaitz[m]>I just read diagonally so check yourself in detail just in case
<raghavgururajan>leoprikler: "Nimf is a lightweight, fast and extensible input method framework. This a fork of original nimf project, with special focus on Korean.". Is this okay?
<raghavgururajan>*This is a
<raghavgururajan>ekaitz[m]: Cool!
<leoprikler>yep, that sounds good
<raghavgururajan>Cool! I'll update and send v10.
<raghavgururajan>leoprikler, Like this?
<leoprikler>raghavgururajan: you'd put it below the define-module, but yeah
<raghavgururajan>ah okay
<leoprikler>also, since only gpl2+ has been imported so far, you should probably don't bind bsd-3 in such a manner
<raghavgururajan>leoprikler: Doesn't work :(
<raghavgururajan>Oh wait
<leoprikler>*probably not
<raghavgururajan>I am confused. Should I also do #:use-module ((guix licenses) #:select (gpl2+ bsd-3))
<leoprikler>IIUC you can do both, but the module previously did not have bsd-3, did it?
<leoprikler>I'm talking specifically about that one module, that only imported gpl2+ before your packages were added
<leoprikler>the other one, that only has gpl2+ and bsd-3 prior and after can stay as-is
<raghavgururajan>leoprikler ^ Is that okay?
<leoprikler>that is okay
<raghavgururajan>leoprikler: I have sent v12. Yeah, your concern about recursive is correct. Is there a way we can specifiy specific sub-modules to fetch?
<leoprikler>Nah, you'll have to use inputs and origins.
<raghavgururajan>I see.
<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.
<raghavgururajan>I tried origins in inputs. But for some reason it didn't work.
<leoprikler>raghavgururajan: did you copy the sources?
<raghavgururajan>The v1 has that thing for tdesktop
<raghavgururajan>For tdesktop, it worked. But too many sub-modules. So shifted to recursive.
<leoprikler>tg_owt only has two submodules
<raghavgururajan>Yeah, tg_owt it didnt work and not sure why.
<raghavgururajan>But let me re-try.
*leoprikler → bed
<raghavgururajan>sneek, later tell leoprikler: I have remove recursive for tg_owt in v13. :-)
<sneek>Got it.
***pucjug is now known as ghghgh
<Aurora_v_kosmose>We have to be subscribed prior to sending a patch to guix-patches in order for the bot to accept mails, right?
*Aurora_v_kosmose doesn't want to cause duplicates
<Aurora_v_kosmose>Oh well, I'll try again another day. It should've made it by then, so if it isn't in then it means it got rejected due to my forgetfulness.
***kmicu_ is now known as kmicu
<BitPuffin>I can't see a way to add non Linux entries to the boot loader config. I have a haiku installation on another partition I wanna be able to boot to
<BitPuffin>I guess I can just update the grub.cfg via script
<Aurora_v_kosmose>( Bootloader Configuration has some info on manual menu-entry definition
<Aurora_v_kosmose>Ah... you may have to extend that.
<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
<_tecosaur>What I've got so far:
<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/ 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)
<snai1>yes thank you i'm installing it to check
***rekado_ is now known as rekado
<raghavgururajan>Hello Guix!
<apteryx>raghavgururajan: hello!
<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"
<n1to>I see. Thank you very much.
<raghavgururajan>leoprikler: How do I do that delete-file-recusively based on what to keep
<raghavgururajan>Can you help me with a snippet?
<ngz>raghavgururajan: I did this in xmoto
<ngz>You may want to look at the package definition. There are other examples, of course.
<raghavgururajan>ngz: Thanks
<leoprikler>I think chromium-browser is also a (bigger) example
*raghavgururajan ---> Tea 🍵
<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.)
<leoprikler>PotentialUser-26: Guix has channels?
<raghavgururajan>Unbound variable: lset-difference
<raghavgururajan>do I need to import a module for that?
<rekado>apteryx: ah, I see. Individual tests vs test files.
<cbaines>rekado, do you know anything about generating client side certificates to access ?
<rekado>cbaines: yes, I know all about it :)
<rekado>log on to
<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>no code for module (srfi)
<rekado>(srfi srfi-1)
<cbaines>rekado, I guessed so, I remember you setting it up :)
<raghavgururajan>I tried that too
<raghavgururajan>no code for module (srfi srfi1)
<rekado>it’s all in /root/maintenance/hydra/cuirass-client-certs/
<raghavgururajan>oh wait
<rekado>cbaines: I’d be happy to have a simpler way to generate the certs, so feel free to change this as needed
<raghavgururajan>hmm. I still get Unbound variable: lset-difference
<cbaines>raghavgururajan, you were looking at xmoto as an example, right?
<cbaines>raghavgururajan, I'd look again at xmoto, and see if you can see why it doesn't have this problem
<raghavgururajan>cbaines: Yeah, I tried importing modules srfi-1 and srfi-26
<raghavgururajan>Just a sec
<raghavgururajan>Oh its metioning srfi-1 inside the pack-def. I was import at the top.
<snai1>thanks to everyone, i get pdflatex working on guix installing both texlive and texlive-base
<cbaines>rekado, does /etc/ssl-ca/private/ca.key have a passphrase (I'm being prompted for one when running
<rekado>cbaines: yes, the password is mentioned in the org file
<rekado>snai1: you shouldn’t have to install ‘texlive’ together with anything else. ‘texlive’ contains the complete TeX Live distribution, so adding ‘texlive-base’ is not necessary.
<rekado>I recommend against using ‘texlive’, because it’s huge and a pain to upgrade.
<cbaines>rekado, ah, I'd missed the org file entirely. I've successfully generated a certificate now though, thanks!
<cbaines>do you need to login to Zabbix to see things?
<cbaines>I tried as the guest user, but there didn't seem to be much there
<rekado>cbaines: looks like that’s necessary, yes
<rekado>seems redundant with the cert
<ekaitz[m]>hi, can anyone point me to a project that uses guix to build its source like with a guix.scm file inside of it to be run like `guix build -f guix.scm`? I can't find any as a reference
<PotentialUser-55>The 1.2.0 version is great. I'd like to thank you all for the progress of it. You're walking into the right direction.
***Kimapr_ is now known as Kimapr
<sldk>is it possible to have multiple origins/sources in one package?
<rekado>sldk: yes, add the origins to native-inputs
<profmakx>anyone have a clue why installing rust (when using guix as a package manager on arch) doesn
<profmakx>t link up cargo
<cbaines>ekaitz[m], maybe someone has a more recent example, but Mediagoblin does this
<ekaitz[m]>great example, thank you very much cbaines
<cbaines>rekado, how does one go about getting a Zabbix account? I'm mostly interested in just poking around.
<rekado>cbaines: I don’t know. We just all use the admin account.
<cbaines>rekado, ah, got it, missed your message
<raghavgururajan>leoprikler: I have sent v14. :-)
<pineapples>raghavgururajan: Thanks your work!
<sldk>rekade: do I have to create a new package and then add it to native-inputs or can I just use the url to download it? I tried the latter but I couldn't get it to work
<raghavgururajan>pineapples: My pleasure! :-)
<leoprikler>raghavgururajan: you forgot to CC me in v14, can you forward it?
<raghavgururajan>leoprikler, oops: Just a sec.
<leoprikler>either that or it hasn't landed yet
<leoprikler>What's the gist on libtgvoip?
<leoprikler>raghavgururajan: 👆️
<raghavgururajan>It was innitially a different project, but now tdesktop made a fork.
<leoprikler>Again a modified fork then
<raghavgururajan>UNRELATED: During build, are the values of 'source directory' and 'build directory' assigned to any variables?
<raghavgururajan>i.e. can i use something like (getcwd) to get the values of 'source directory' and 'build directory'?
<raghavgururajan>(getbuilddir) or (getsourcedir) may be?
<leoprikler>not in cmake-build-system at least
<leoprikler>you could do something like (add-before 'configure (lambda _ (setenv "_OLDCWD (getcwd))))
<leoprikler>meh, forgot closing "
<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.
<raghavgururajan>pineapples: Thanks for the heads-up.
<leoprikler>raghavgururajan: after configure, build dir is (getcwd), before that it's ../build
<leoprikler>assuming out of source
<raghavgururajan>AH thanks
<pineapples>For example, the Dolphin package does not detect the Wayland platform plug-in, whereas the Qt port of pavucontrol has no problem with that.
<raghavgururajan>ooo. got it. there is a variable NIX_BUILD_TOP
<raghavgururajan>pineapples: telegram-desktop has gtk-integration, it might even use wayland via gtk.
<leoprikler>raghavgururajan: I'm currently writing some (description) fields and other minor strings, so that you don't have to send a v15.
<raghavgururajan>leoprikler: Thanks a lot.
<leoprikler>Short question in that regard: is fcitx-qt5 a Qt5 frontend for fcitx?
<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>I do
<raghavgururajan>pineapples: Ah okay. During build it asked for wayland-client and wayland-protocols, apart from qtwayland. So I thoght it had a fall-back option.
<raghavgururajan>pineapples: Lets see if it works under testing. :-)
***amiloradovsky1 is now known as amiloradovsky
<apteryx>Is it possible to use the Guile meta switch without knowing the exact file name of the guile executable?
<leoprikler>apteryx: No, but there is a "This is not a bash script, it's actually Guile!" version.
<leoprikler>you can #!/bin/sh\nexec <full guile command>\n!#
<pineapples>leoprikler: How do I test the Telegram package out? I haven't had a brush with patch files for years so I don't know how and to what I'm supposed to apply them
<leoprikler>pineapples: you check out Guix locally, git apply/git am the patches, and inside a "guix environment guix" you run "./bootstrap; ./configure --localstatedir=/var; make"
<leoprikler>That takes some time.
<leoprikler>After it finished, you can "./pre-inst-env guix environment --ad-hoc glib telegram-desktop"
<leoprikler>(which takes an even longer time to build)
***ss2 is now known as ss2`
***ss2` is now known as ss2``
***ss2`` is now known as ss2```
***ss2``` is now known as ss2
<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
<pineapples>leoprikler: I'm at make
<pineapples>bdju: According to qmk's official documentation, qmk has to be installed prior to building and flashing your custom firmware: From what I see, you could either package it for Guix, or install it, using python's pip
<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
<jsoo>I'm not out of options yet
<efraim>IIRC there's an official aarch64 binary somewhere, similar to the ones for x86_64 and i686
<jsoo>efraim: there are for certain versions. If memory serves me right, older ones have some problems with aarch64 codegen
<pineapples>leoprikler: Strange. libchewing failed to be built but re-running the ./pre-inst-env command did the trick.
<pineapples>I should mention I'm installing qt5ct alongside the Telegram desktop client to test it out as well
<raghavgururajan>> pineapples‎: leoprikler: How do I test the Telegram package out? I haven't had a brush with patch files for years so I don't know how and to what I'm supposed to apply them
<raghavgururajan>Here is the diff file that you can apply over master.
<pineapples>raghavgururajan: I'm almost done building but thanks :-)
<leoprikler>interesting, libchewing might have some reproducibility issues
<pineapples>leoprikler: So far so good, Telegram has launched under Wayland; no Xwayland process is running in the background. This is a good sign
<raghavgururajan>thanks for testing pineapples
<pineapples>I see two problems: user-created stickers and built-in emojis are not rendered
<pineapples>I might be wrong but I think the package is missing ttf-opensans; fonts are a little off
<raghavgururajan>The latter is disabled during build, as there was run-time crash.
<pineapples>raghavgururajan: Wasn't there a way to provide the client with this font, instead of using the ones bundled with it?
<raghavgururajan>pineapples: Not sure.
<raghavgururajan>pineapples: Can you try "-DDESKTOP_APP_USE_PACKAGED_FONTS=OFF"?
<raghavgururajan>* or ON
<pineapples>Recompile it?
<pineapples>Perhaps it'd be a good idea to see if packaging and installing the missing font satisfies the client