IRC channel logs


back to list of logs

***catonano_ is now known as catonano
<tune>xyce-parallels failed to build for me earlier
<tune>honestly not sure what it is or why I have it. likely a dependency of something
<tune>might be related to qucs which I am also not familiar with
***catonano_ is now known as catonano
<tune>why can't my sftp tab complete?
<tune>need it badly
*mikadozero submitted patch for manual sections `Invoking guix challenge` and `Invoking guix archive`.
<OriansJ>tune: did you do?
<tune>OriansJ: didn't try that... it works by default on some other distros like debian
<tune>what is guix doing differently?
<tune>not even using bash
<OriansJ>tune: guix does only what you tell it to do. For example did you install bash-completion
<tune>I am not using bash on any machines in question
<tune>does this still matter?
<OriansJ>tune: what shell are you using?
<tune>zsh. also fyi tab complete works in bash too. sftp specifically is a separate deal
<tune>and it's zsh on both ends here, same config more or less, and it's the login shell
<tune>best info I'm finding is that maybe guix uses different compile options than debian
<tune>hm neovim still segfaulting
<OriansJ>tune: compile options will not change the behavior of a shell in that regard.
<tune>it's for sftp, not a shell
<tune>sftp doesn't get affected by your shell as far as I can tell
<OriansJ>tune: sftp tab completion is done by your shell, not by sftp
<tune>found this, maybe it's not relevant
<tune>my shell tab complete works fine, but in sftp it prints a literal tab character, and similarly I think the arrows print control codes
<tune>same behavior if I switch to bash before running sftp. I really don't think the shell affects it
<OriansJ>and you have readline enabled?
<tune>no idea
<tune>but I am just running plain 'sftp' on both distros with different effects
<tune>no aliases or arguments for the tab completion. same shells
<tune>I installed bash-completion and I still get the same behavior in both zsh and bash
<tune>fyi I am using sftp interactively
<tune>I run sftp user@host and then it has its own commands like get and put
<tune>so I really don't think my shell affects it
<g_bor>hello guix!
<g_bor>tune: istm that openssh is not built with readline support.
<g_bor>I've just checked the package receipe from a recent enough guix.
<tune>so it is a compile option thing then?
<tune>can someone patch it to have that?
<tune>tab completion
<g_bor>I can have a look at that...
<tune>thank you so much
<g_bor>also, have anyone tried to update openssh recently? Istm it only has 12 revdeps, which looks too few to me...
***ym555_ is now known as ym555
***atw` is now known as atw
***travan|{or is now known as travan|{4
<Emacsite>Is there a Guix package for DeltaChat?
<phenoble>Hi #guix!
<phenoble>I have a question: is there a way to get the output of the log, stored in these *.drv.bz2 files deep inside the store, to stdout on a build failure? The manual says that --verbose is supposed to do that, but it doesn't.
<pkill9>wow guix pull was quick
***meiyopen1 is now known as meiyopeng
***groffer is now known as groffer_
***groffer_ is now known as groffer
<groffer>Hi, I cannot build lyx: CMake Error at CMakeLists.txt:607 (qt5_use_modules): Unknown CMake command "qt5_use_modules".
<groffer>using guix 1a50321752aa92dcb1acdc1d68bddb65dff0a874 on foreign distro; lyx 2.2.3 out gnu/packages/tex.scm:4297:2
***rekado_ is now known as rekado
<rekado>phenoble: on build failure Guix prints the location of these log files so that you can inspect them. Is this not sufficient?
<phenoble>rekado: You have to sudo bunzip2 the archive (or copy it somewhere else first), then open it in a texteditor. While I note the argument that this may be considered "proper" and "sufficient", I am wondering why --verbose could not just dump the log on stdout on failure.
<rekado>you can use bzcat instead.
<rekado>“--verbose” should simply not hide the build output. That’s how it’s configured.
<rekado>are you using a recent guix-daemon?
<phenoble>rekado: I didn't know bzcat, thank you.
<phenoble>rekado: I guess that depends on what you consider "build output". Me as a user'd expect the information on why the build of a package failed, to be shown on --verbose; if not by default. But that may be just me.
<phenoble>/ opinionated.
<rekado>when you use “guix build” it shows all output as it is being produced.
<rekado>build logs are long and often the error that proved terminal for the build is hundreds of lines above the final line.
<rekado>it’s not a good idea to paste hundreds of lines of output unprompted when a build fails.
<nckx>^ there's also bzless.
<phenoble>rekado: no, it's probably not always good idea, but still. Let's leave it there. Thanks for the input.
<phenoble>Hm, so I packaged some piece off github. It offers an optional python2 (TWO) interface, for which there's an install rule. The rule determines the site-packages directory from the detected python version.
<phenoble>guix detects python3 (THREE), and hence puts the python2 tool into ~/.guix-profile/lib/python3.7/site-packages
<phenoble>How do i specify which python version to use during a package build? I already provided ("python2" ,python) as an input, hoping that'd lead to a python2 environment.
<nckx>phenoble: Add ‘#:python ,python-2’ to ARGUMENTS.
<nckx>I think you can then drop the input.
<phenoble>nckx: #:python cannot be provided as argument to the gnu-build-system, if I see that correctly
<nckx>phenoble: What do you mean by ‘guix detects’ then?
<nckx>Guix doesn't do any Python detectin'.
<phenoble>nckx: I don't know if I phrased that correctly; my inexperience shows - apologies.
<phenoble>nckx: Well, within the environment make is executed, there certainly is a python binary available, from which the version is deduced.
<nckx>None taken. Re-reading what you wrote, I guess you mean the package's build scripts detect Python 3. I'm not sure why P3 is in the build environment to begin with.
<phenoble>nckx: Build environments from within guix should be as blank as they can get; i.e. completely independent from the host's environment, correct?
<phenoble>(..."functional package management", afterall.)
<nckx>phenoble: Absolutely. Now, there are some ‘default’ inputs for convenience (you don't want to pass coreutils to *every single* package after all) but I very much doubt Python 3 is one.
<phenoble>nckx: I have the answer: I have a '#:use-module (gnu packages python)'; if I omit that, make fails with "no suitable python interpreter found".
<nckx>‘guix environment hello -- python --version’ confirms that suspicion.
<phenoble>nckx: But I don't see a python2 module.
<pkill9>phenoble: yeah gnu-build-system doesn't take the #:python argument
<pkill9>the python-build-system does
<pkill9>i assume the package is a python package built using makefiles then
<pkill9>those are kinda annoying
<nckx>pkill9: As I understand it, it's not a Python package but just provides Python modules.
<phenoble>pkill9: no, it's a utility for use with gpg that comes with an optional python interface (
<nckx>And the gnu-build-system doesn't take #:python, that's correct.
<phenoble>The contents of the python subdirectory, is what needs to be copied. For this to work the built libraries need to accessible in the environment.
*nckx has to go runnin'.
<phenoble>Am I the very first one to ever explicitly desires python2 to be available during the build of a guix package? ^^
<nckx>Absolutely not. Try grepping gnu/packages. I'm also unsure what Python 3 is even doing there in the first place. Sorry for the shit answer.
<phenoble>nckx: anything helps, I'd be completely on my own in the dark without, thank you!
<rekado>phenoble: you wrote ("python2" ,python)
<rekado>the first part is just a label, it could be anything
<rekado>the second part is the value of the package bound to the name ’python’
<rekado>and that’s Python 3.
<rekado>if you want Python 2 you need to use that value instead.
<rekado>Python 2 is bound to the variable name “python-2”
<rekado>it’s defined in gnu/packages/python.scm
<phenoble>rekado: .. and that fixed that. Thank you!
<phenoble>I'm off doing a guile tutorial, then having a close look at the guix utils, and various package declarations. I obviously don't know what I'm doing right now.
<phenoble>Thank y'all.
***MinceR_ is now known as MinceR
***jonsger1 is now known as jonsger
<nckx>...I completely missed the missing -2.
<nckx>Glad you got it working! :-)
<montxero>where can I find public keys to guix substitute servers
<montxero>I wan that for the ci server
<nckx>montxero: I don't know the ‘canonical’ location, but the Guix source tree contains ‘’.
<montxero>nckx: please where can I find said tree. I don't want to download the source tarball just for this info
<nckx>It's installed under /gnu/store/…-guix-…/share/guix/ too.
<nckx>As ~/.config/guix/current/share/guix.
<nckx>s/As/Also available as/
<nckx>montxero: ^
<montxero>nckx: checking
<montxero>nckx: yay!
<montxero>next question, how do I change my default substitute server?
<nckx>montxero: Are you running Guix System?
<montxero>nckx: no I'm running it ontop debian, foreign I believe it was called when i went through the manual last year
<montxero>nckx: now I have authorised the ci server, would my guix automatically check there first when doing package-fu
<montxero>or am I doomed to doing everything with --substitute-urls= ?
<nckx>montxero: No. Edit the unit file for guix-daemon, add ‘--substitute-urls="..."’ (you can add more than one, they will be tried in order), then ‘systemctl daemon-reload’ and restart guix-daemon.
<nckx> *is* in the default list, though, so you don't need to do all that just for that one.
<montxero>nckx: When I installed guix, hydra was the defaualt and berlin was the fancy new thing up and comming
<montxero>nckx: unit file?? dyu mean the one at /etc/systemd/system/guix-daemon.service?
<nckx>montxero: Yes. And unless it hard-codes hydra & friends, I assume Guix's defaults are updated when Guix is updated. So just make sure your guix-daemon is up to date.
<montxero>nckx: okay.... no substitute urls list here.... I'll just run guix pull and see what happens
<nckx>montxero: I've never used Guix on a foreign distro, no idea how you keep the daemon up to date there.
<montxero>nckx: I've always wanted to have a pure guixsd... just uncertain about sourcing the right hardware
<montxero>what hardware dyu use if you dont mind my asking
<nckx>montxero: Just a random hand-me-down Acer laptop that happens to have an ath9k chip and Radeon graphics (I don't use anything that needs acceleration anyway).
<nckx>No fancy Librebooted Thinkpad (yet :-)
*nckx gots to go.
<inquisitiv3>Why is there 77 missing keys when I try to download the signing keys from
<inquisitiv3>Trying to install Guix using the installation script.
<phenoble>Hi #guix
<kmicu>(*^▽^)/ phenoble
<phenoble>mhh, the package cabal-install fails by proxy of failing package ghc-conduit-extra:
<phenoble>Data/Conduit/Attoparsec.hs:99:14: error:
<phenoble> • Couldn't match type ‘text-’
<phenoble> with ‘TI.Text’
<CornBurglar>I'm running into problems with Zathura installed with guix on GuixSD: error: could not open plugin directory: /gnu/store/n2s2dcvz9kiwwbsklsw496klb29mwr0z-zathura-0.4.3/lib/zathura
<CornBurglar>error: Unknown file type: 'application/pdf'
<CornBurglar>Any clues to what the issue is here?
<CornBurglar>I do have zathura-pdf-poppler installed
<inquisitiv3>Does Bash need to be configured as the default shell on the host to run Guix?
<inquisitiv3>I've currently set Fish shell as my default shell in Debian.
<nixo_>Hello everybody! Strange question but.. can I "migrate" guixSD from i686 to x64?
<nixo_>just moved my SSD drive from an old laptop to a newer one, but the old was 32bit
<pkill9>if you reconfigure it then it will automatically build a system based on your CPU's architecture
<pkill9>so I guess yea?
<mikadozero>inquisitiv3: You can use other shells.
<mikadozero>inquisitiv3: I have run other shells on a Guix SD system.
<nixo_>pkill9: ok that was my guess, I hope everything will run fine :)
<mikadozero>inquisitiv3: I have tried bash, zsh and fish in Guix SD.
<efraim>ugh, colord is really out of date but I don't want to touch the service ATM
<rekado>pkill-9[m]: I don’t think that’s correct.
<rekado>you’ll need a system that can build for x86_64, but an i686 system cannot do this.
<rekado>I don’t think it’s as easy as reconfiguring.
<roptat>hi guix!
<roptat>what should I put in my operating-system declaration to have more locales available?
<roptat>currently I think I have the content of glibc-utf8-locales, but I want the full list of locales
<roptat>nevermind, I found it :)
<nixo_>rekado: It's still compiling but trying objdump on some bin it seems they are i386... I think I should boot from usb and reconfigure from there
<daviid>is installing guix (the pkg manager) on top of freebsd as easy as o top of ubuntu, debian ... ? just curious
<daviid>I'd lke to recommend someone
<OriansJ>daviid: I wouldn't recommend it but that is largely because I never personally tried it and tried to remove the bugs
<OriansJ>Also guix tends to like to leverage Linux's containers to isolate it's builds
<OriansJ>Also I don't believe we have a freebsd build server yet; which would mean they would have to build everything from source if it worked
<daviid>OriansJ: thanks, I won't recommend it then, too bad, the person has marjor difficulteis understanding the basic pkg-config ldconfig 'problems' and can't use guile to compile chickadee ...
<OriansJ>daviid: sounds like they need a more hand-holding distro
<daviid>OriansJ: the best is whe we can recommend to install guix on top of their prefered distro
<daviid>it' too bad it's working out of the box on freebsd
<OriansJ>daviid: if I knew someone who used guix on freebsd on their daily driver; it would be a different story but generally it is far better to recommend for platforms after multiple technical people have hammered out their issues on the platform before we let inexperienced users assume it'll work perfectly.