IRC channel logs


back to list of logs

<Minall>Hello guix!
<Minall>quiliro: Kiel vi fartas
<civodul>lewo: oh i see
<civodul>lfam: bah, could you grab again debugging info like last time?
<Minall`>quiliro: Kiel vi fartas
<lfam>The shepherd run directory thing went away when I exported XDG_RUNTIME_DIR in my login shell init files
<lfam>Yeah I will send /var/log/messages soon, civodul
<lfam>It sometimes works, sometimes doesn't
<malaclyps>So I think I understand now that the way to use shepherd to run per-user services (like, for instance, syncing a directory), is to run it *as* that user on startup, as another instance separate from the system (init) shepherd. My question is: does it make sense to have the init shepherd be in charge of starting this per-user instance? Does anyone do it this way? Or is that crazy?
<poet>Hello #guix. Let's say I want to download gnuastro, but before I do, I'd like to see what dependencies are required, and how large each package is. How command would I use?
<poet>What, not how^
<lfam>poet: You can check what it will do with `guix build gnuastro --dry-run`
<lfam>If you want to install it in a profile it will do more work so use `guix install gnuastro --dry-run`
<lfam>There is also `guix size gnuastro`
<lfam>Finally you can examine the dependency graph with something like this: `guix graph gnuastro | dot -Tsvg > graph.svg`. That requires the dot program from graphviz
<poet>lfam: Those are exactly what I'm looking for, however, it presents another question: 'guix build gnuastro --dry-run' tells me "14.6 MB would be downloaded," but 'guix size gnuastro' tells me 'total: 117.3 MiB'
<lfam>poet: You probably already have most of the gnuastro dependencies, like glibc
<poet>lfam: Ahh okay, good. Thank you. =)
<poet>lfam: Oh I didn't even see the graph thingy! One second...
<lfam>Note there are different types of dependency graphs besides the default:
<poet>Okay, thank you... but where would I get dot? It isn't on guix or apt-get...
<poet>lfam: Wow, this graphing feature is pure badassery. I love it. Thanks! =)
<lfam>poet: Did you find the thing you were looking for above? I missed your message
<poet>lfam: Yes, I found graphwiz. Thank you.
<lfam>Cool :)
<pinoaffe>I'm trying to add support for the faber build system to guix and trying to use it to build boost-python, but when guix tries to run faber it returns an exit code of 127, which doesn't happen when I run it manually - anyone know how I could debug this?
<pinoaffe>oh, I forgot to mention, my tree is at
<allana>Hi, say that I have installed a package with an additional output, "doc". Is there an easy way to access that output?
<allana>I am not seeing anything obvious in the guix docs
<civodul>Hello Guix!
<roptat>hi guix!
<desttinghim>I'm getting an error when trying to run cargo related to SSL
<desttinghim>I have nss-certs installed, so I'm not sure why it's not finding the certs
<roptat>mh... do you have SSL_CERT_FILES and SSL_CERT_DIR in your environment?
<civodul>"SSL_CERT_FILE" (singular)
<roptat>oh yes, indeed
<desttinghim>Yes, I do
<desttinghim>Looks like there is a message on the mailing list with the same issue, no reply
<civodul>desttinghim: could you try "ltrace -e getenv cargo ..."?
<civodul>from the 'ltrace' package
<civodul>that would tell us what env vars it's looking at
<desttinghim>Alright, installing ltrace
<desttinghim>How much do you want to see?
<desttinghim>The full output is too large to put on
<efraim>civodul: I have a patch ready for qt-5.12.4 for staging. I bundled the python-sip and python-pyqt updates with the patch since they depend heavily on the qt version. sound good?
<efraim>we also unfortunately have 5 of them which don't build, but they have no dependants so I figure it can be worked out later, it's been delayed enough
<desttinghim>civodul: tried with a different rust crate, looks like it might have something to do with git
<desttinghim>Or wait, nvm. That's not it
<civodul>desttinghim: so there are that many "getenv" calls?
<civodul>what about getenv.*SSL or similar?
<desttinghim>No getenv calls
<desttinghim>SSLv23_method(0x7f80e4b281a0, 0x7f80e4b986ed, 0, 128) = 0x7f80e4baa860
<desttinghim>This looks like a relevant part
*jonsger wonders if thunderbird really needs this:
<desttinghim>Looks like there's an issue on github for it
<desttinghim>Looks like the rust openssl crate doesn't automatically find the system's root certificates when vendored
<desttinghim>Which is probably what's happening, since cargo enables the vendored build flag
<desttinghim>No wait, looks like it has a build option to enable it
<pinoaffe>is there a way to have guix do some of the build phases, dropping you in the resulting environment?
<roptat>pinoaffe, mh... maybe try guix build my-package -K, and when it fails, you will have the environment in /tmp/guix-build-my-package
<roptat>go there, run guix environment my-package --container and source environment-variables or whatever it's called
<roptat>that should be pretty close to what the build environment looked like
<ng0>desttinghim: you basically need something like this at build time when it is vendored:;a=blob;f=alacritty/Makefile;h=0a7f7b004d38e79e2b7a5813ee781f6782899f4f;hb=HEAD#l308
<ng0>since cargo does not (yet) pass through environment variables, but openssl-sys + openssl crate take this variable
<ng0>unless the situation with guix is playing in a different set of problems than I am
<civodul>pinoaffe: see also
<civodul>mbakke: i stumbled upon the 'ungoogled-chromium-source' origin, and i don't understand how it can work
<civodul>namely, how can the 'uri' field be a promise?
<civodul>oh got it, computed-origin-method
<civodul>mbakke: i think it'd be best to use 'computed-file' rather than abuse 'origin' here :-)
***abbiya_ is now known as abbiya
<civodul>oh, 4 Ghostscript CVEs yesterday
***abbiya_ is now known as abbiya
<xavierm02[m]>Is there some simple way to guix environment such that there is a python binary that runs python2?
<xavierm02[m]>Oh. My bad. I forgot the --ad-hoc
<xavierm02[m]>When I guix import a python package, is there some way to have it also generate the define-public part? And to have it use names with python2 instead of python?
<mbakke>civodul: the same pattern is used in IceCat and Linux-Libre sources, so computed-origin-method is in good company :P
*mbakke brushes dust off his mail client
<xavierm02[m]>I get an error
<xavierm02[m]>error: Could not find suitable distribution for Requirement.parse('flake8_polyfill<2,>=1.0.2')
<xavierm02[m]>even though I gave python2-flake8-polyfill in propagated-inputs. How can that happen?
<xavierm02[m]>I had the same thing with pytest earlier but setting #:tests #f fixed it
<mbakke>xavierm02: can you share the package definition?
<xavierm02[m]>It's the python2-pep8-naming package
<mbakke>xavierm02: I think you need to set #:python python-2 in the (arguments ...) field of each package.
<ng0>efraim: progress is a hard front
<roptat>xavierm02[m], the define-public part can be generated with the -r option of guix import pypi
<ng0>broad ticket on defining a stable rust ABI, closed
<ng0>"there's too much active resistance in the language team" oof.
<roptat>xavierm02[m], all of your packages are actually built as python3 packages
<xavierm02[m]>I tried building python-pep8-naming as a python2 thing and it still doesnt' work
<xavierm02[m]>as a python3
<xavierm02[m]>i mean I removed the 2s everywhere
<xavierm02[m]>And I couldn't manage to get the argument #:python to work
<xavierm02[m]>I found a package-with-python2 function which can probably help ehough
<jonsger>uff, Thunderbird build system is really hard
<xavierm02[m]>I know I'll probably fail, but I'll probably learn a lot of stuff on the way :)
<roptat>our flake8-polyfill is exactly 1.0.2, so it should work...
<jonsger>but I really want to see it in Guix...
<roptat>xavierm02[m], what the version of flake8-polyfill on your version of guix?
<civodul>mbakke: oh indeed! sacrilège!
<civodul>i'll have to send email
<xavierm02[m]>I seem to not be the only one having this problem
<xavierm02[m]>"(arguments '(#:tests? #f)) ; one test fails; can't find virtualenv" in python-check
<Sisyphe[m]>is there a way for git-fetch method to download repository via ssh links ?
<roptat>only http and https I think
<civodul>yeah, in theory it could do SSH, but currently we don't provide any hooks for authentication
<civodul>i'd like to fix that in Guile-Git
<xavierm02[m]>Ok. So many python packages seem to set PYTHONPATH or change the 'check phase to call pytest themselves.
<Sisyphe[m]>ok thanks
<Sisyphe[m]>but then the only way to provide auth for https is embedding username and password in the download link ?
<null_radix[m]>hello! does anyone know for writing scripts, if there is an equivalant of nix's "#!/usr/bin/env bash" for guix?
<roptat>#!/bin/sh works
<roptat>although, that might not work if you have non portable constructs in your scripts
<null_radix[m]>yeah im actually attempting to write a guile script
<civodul>looks like we lost Robert on Haskell maintenance :-/
<civodul>we really need more active committers doing review
<null_radix[m]>aww :(
<null_radix[m]>im still waiting on this one to get reviewed...
<roptat>I think I can commit to review anything ocaml and coq related
<jonsger>every time I do some review (it's not often), I'm kind of regret it. For me it would be much more fun, too just checkout the patches from a branch and test it then...
<xavierm02[m]>Ok python2-pep8-naming builds. It needed both python2-flake8 and python2-flake8-polyfill to be happy (and now I'm defining the python3 package and using package-with-python2 to get the python2 package)
<civodul>null_radix[m]: i'd ping rekado and nckx who provided initial feedback :-)
<civodul>roptat: nice, thanks
<civodul>though that's only a small fraction of what we receive :-)
<roptat>sure, but that's what I really know
<civodul>if i reviewed only what i know, i wouldn't review much ;-)
<null_radix[m]>thanks civodul :)
<null_radix[m]>yeah i don't want to be a pain in the ass, im sure there are plenty of things to review
<civodul>in many cases, there are simple C/Python/... packages that don't require special expertise to review
<roptat>I think I managed to find a way to split mariadb
<xavierm02[m]>roptat: Thank you for your help!
<mbakke>roptat: nice, what was the trick wrt mariadb?
<roptat>I have an out (50 MB), bin (150 MB), pkgconfig (very small) and include (3 MB) outputs
<roptat>so for every users of mariadb, you need to put out, pkgconfig and include which is not great
<civodul>in hindsight i think the bin/lib outputs were misguided
<civodul>i think we really need "devel" vs. non-devel, like other distros do
<roptat>so out and include have no reference to other outputs, bin refers to out and include, and pkgconfig has references to all others
<civodul>in this case, you'd have .pc and .h files in the same output
<efraim>for bin and out I would assume bin would be the main
<roptat>civodul, I tried .pc and .h in the same output, but the binaries retain a reference to the .h files, and the .pc retains a reference to the binaries
<roptat>I can't have the libs in another output than out because of the way the cmake build system is made
<civodul>binaries refer to .h?
<roptat>there's a mysql_config binary that refers to the include directory
<mbakke>roptat: 'ceph' has a lib output and uses cmake-build-system
<roptat>maybe this mysql_config needs to go to the dev output then
<roptat>This script reports various configuration settings that may be needed when using the MariaDB client library.
<mbakke>roptat: we can patch the pkg-config file to avoid needless references -- I think the only consumer of that is actually 'r-rmysql', the rest use mysql_config
<roptat>but if we put mysql_config in a dev output, we're good
<roptat>that will leave us with out, lib and dev
<mbakke>sounds great
<efraim>384 more crates in my stash :/
<roptat>ok, I'll try to get this working
<efraim>if I can get rust-serde in I'll be pretty happy
<mbakke>efraim: pheeewww.... how long until we can run nush on alacritty? :D
<efraim>mbakke: i'll look at the Cargo.toml and see what I've already done
<jonsger>we don't have rust cbindgen yet on guix or?
<jonsger>uff doesn't look so lightwidth
<xavierm02[m]>pipenv built!
<efraim>I don't think I have anything from copypasta or winpty, missing about half of alacritty_terminal, so a while to go still
<civodul>efraim: thanks for the Qt upgrade BTW
<civodul>efraim: also, it'd be nice if you could write full sentences for Rust package descriptions :-)
<civodul>i know, i know...
<efraim>civodul: I'll work on the descriptions. Sometimes upstream is really terse
<efraim>unfortunately I think I'm nearing the end of what I can upload as single packages
<civodul>sometimes it admittedly looks like a lost cause
<jonsger>+1 for nice descriptions :)
<efraim>for 'guix refresh rust-antidote' i'm getting Wrong type (expecting string): #f, likely from (string-append "" "ant…" …)
<roptat>ok, building again mariadb, this time I expect to see out (150 MB), lib (50 MB) and dev (3 MB)
<roptat>out should refer only to lib, lib to nothing and dev to both
<efraim>if we can figure out a good way to do optional dependencies in guix then rust packaging would be less circular
<efraim>jonsger: I think I have most of rust-bindgen dependencies already, just not uploaded
<jonsger>ups I need <- looks a lot more friendlier
<efraim>most of ripgrep also
<efraim>for cbindgen I think I'm only missing numtoa
<jonsger>efraim: you are working on cbindgen?
<efraim>i was working on rust-qtlreaper but there's a lot of overlap apparently
<efraim>once we get rust-serde in then it should be a lot easier
<jonsger>clap is also missing
<efraim>i have clap
<efraim>actually, my clap doesn't compile independently but works as in input
<jonsger>fine for me :)
<efraim>s/as in input/as an input/
<jonsger>efraim: you also work for this genenetwork thingy?
<efraim>jonsger: yeah
<jonsger>"Guix is in our genes" :P
<Sisyphe[m]>I 've already mentioned it there but anyway, maybe it might help you package your crates: (an upcoming version handles local crates with Cargo.lock)
<jonsger>efraim: are your definitions somewhere online?
<civodul>Sisyphe[m]: it'd be nice if we could borrow from your project to improve "guix import crate"
<civodul>did you use "guix import crate" BTW efraim?
<Sisyphe[m]>civodul: no problem
<Sisyphe[m]>however I can't really help with "guix import crate" since I'm a scheme beginner, plus Carguix relies heavily on already existing crates so I would expect a lot of work to be done to port it all to scheme
<efraim>civodul: only most of the time, I've been getting more failures than hits recently
<civodul>efraim: like "guix import" would fail altogether, or would provide incomplete dependency info?
<efraim>guix import: error: failed to download meta-data for package 'blake2-rfc'
<efraim> but it clearly exists
<civodul>not great
<roptat>it failed... trying again
<roptat>and again, because the libs didn't install in the lib output...
<roptat>I wonder if the plugins (14 MB) should be in the lib or out output?
<null_radix[m]><efraim "guix import: error: failed to do"> yeah i ran into that too, its caused by the package having incomplete infor
<null_radix[m]>> <> guix import: error: failed to download meta-data for package 'blake2-rfc'
<null_radix[m]> * yeah i ran into that too, its caused by the package having incomplete info
<civodul>this particular issues seems to be easy to fix
<civodul>i'll try to look into it later today
<null_radix[m]>you can fix it by changing this the "and-let*" to "let*"
<efraim>null_radix[m]: worked for me for importing rustfix
<null_radix[m]>i'm slowly working on adding a --recursive option to `import crate`
<Minall>Hello guix!
<null_radix[m]>slowly as in im learning guile first... 🤣
<Minall>I'm using the newer kernel, using xfce, I'm unable to see the internet applet that I had in a lesser kernel... What can I do?
<civodul>i got this:
<civodul>/gnu/store/v23vp9w424lnwz09ll1qrmqywinkzzlx-qtbase-5.11.3/bin/uic: error while loading shared libraries: cannot open shared object file: No such file or directory
<civodul>did we disable RUNPATH validation on qtbase?
<civodul>ooh, old kernel i guess
<Minall>I'm unable to share internet from my laptop to a pc using ethernet, in other distros I have no probmlem... What can I do?
<civodul>hmm that's on a 3.10.0 kernel, isn't that supposed to work efraim?
<Minall>civodul: xf86-video-intel is already installed by default right?, my system has intel, but xorg uses the fallback modules, I don't have problems though, is just, since my system is intel, I assume I should use intel.
<civodul>Minall: i think it's by default, yes
<efraim>I think so, rekado made sure iirc
<Minall>Does guix by default detects and installs driver modules?
<Minall>I see that on my installation, it installed all the 'default driver modules' including of couse intel. But xorg isn't using intel, should I worry?
<civodul>efraim: it fails for me on a CentOS 3.10 kernel
<civodul>the comments in qt.scm says it should work on 3.10 though
<Minall>I'm using guix system with xfce, everything works normally, after a full upgrade, with the newer kernel, I'm unable to see the network applet on xfce, what can I do?
<civodul>Minall: a solution is to email with all the details, and to reboot into an older generation of the system in the meantime
<Minall>civodul: What details can I add?, all other things are working normally. I can connect to the internet normally using nmcli, so I can work here normally
<Minall>civodul: Well, I have to use nmcli since the network never automatically connects, is this normal of xfce?
<Minall>civodul: Also... I'm unable to share internet... I have to fix that too
<Minall>I can send an e-mail, but I don't know the details...
<quiliro>Saluton Gikso!
<civodul>saluton quiliro!
<civodul>Minall: you'd send the output of "guix describe" for the guix you used to reconfigure, as well as your OS config and a description of what you see and what you'd expect instead
<Minall>civodul: Ok, so its the output of : guix describe, config.scm and the problem...
<Minall>Ok, I'll send it. BTW, I'm unable to share internet on guix, in other distros I could, maybe is the kernel or something, any idea?
<roptat>that was a bad idea: the library has a reference to the plugins
<civodul>roptat: bah, splitting is hard
<civodul>Minall: no idea!
<roptat>the plugins retained a reference to out, but that was <out>/lib/groonga/plugins, which doesn't exist... I hope it came from a default value of LIBDIR that also lead the libraries to be installed in out in this round...
<jonsger>efraim: nice name: rust-yaml-rust :P
<Minall>When installing an emacs package of guix, do I have to do extra configuration?
<quiliro>Minall: why should the kernel have anything to do with sharing internet, a which is auserspace funtion
<Minall>Not sure, I'm just blank, since I could share internet in other distros, I'm not sure why on guix I can't, since everything works normally
<roptat>how did you share network?
<Minall>with nm-connection-editor, I could enter to the ethernet profile, and change IPv4 method to shared, In other distros that was enough to get it working, with guix it doesn't seem to work
<Minall>I can do the same on xfce, and even If I install gnome, but it doesn't work
<quiliro>perhaps the other distros have NAT...and you have not started that service
<quiliro>i am not sure how to do it though
<roptat>I've always done it manually
<roptat>with ip, setting a masking forward with iptables and echoing 1 to the right file in /proc or /sys...
<Minall>How should I enable NAT, I think everything should be preinstalled, since it is from the environment
<Minall>roptat: If you can give me a little manual of how to do it, I can do it manually
<roptat>maybe there is some log from nm?
<Minall>I hope,
<Minall>But, where to find it?
<roptat>/var/log/messages if you can't find a specific file
<roptat>oh no, there's still a reference from lib to out...
<roptat>but it's a very weird one
<roptat>so I guess INSTALL_PLUGIN_DIR is not handled properly
<hackyhacker>Hello I tried editing my config to use sddm instead of gdm as my login manager but it doesn't work
<hackyhacker>so what I did was in my /etc/config.scm I put in services a new service
<hackyhacker>I only have one service in there now but I get this unreadable error from guix system reconfigure
<hackyhacker>wrong type argument
***niten` is now known as fniten
<bavier>hi guix
<quiliro>hi bavier
<quiliro>how can i install pdftex or pdflatex for exporting org-mode files to pdf?
<roptat>the libs also retain a reference to the prefix and to MYSQL_SHAREDIR, which is used as relative to the prefix
<Minall> how can i install pdftex or pdflatex for exporting org-mode files to pdf?
<bandali>Minall, they usually come with texlive
<bandali>can’t remember guix’s various texlive-* package names off top of my head
<Minall>bandali: Is there a packae that I can install that can give me the functionality without installing texlive?... Since texlive is heavier
<bandali>Minall, texlive-base perhaps ?
<bandali>have a look at their definitions with guix edit texlive-base or texlive etc
<Minall>bandali: I'll install it, thanks!
<bandali>you’re welcome :)
<quiliro>texlive-base did not produce pdf output with org-mode
<quiliro>will ask on #emacs
<quiliro>! LaTeX Error: File `grffile.sty' not found.
***tilpner_ is now known as tilpner
<quiliro>after installing texlive-base
<xavierm02[m]>quiliro: I think you have to install the full texlive
<xavierm02[m]>I have several versions of several texlive-<something> installed, and when I "locate grffile.sty", it only find texlive-texmf (which is a dependency of texlive if I recall corectly)
<quiliro>thank you
<xavierm02[m]>Or you could try to package grffile :-)
<quiliro>i thought it was already if it was referenced
<quiliro>xavierm02[m]: texlive-texmf no existe
<xavierm02[m]>quiliro: It's texlive-texmf-<some date>
<xavierm02[m]>But don't install this, install texlive
<quiliro>'guix search texlive-texmf' shows nothing
<xavierm02[m]>texlive = texmf + texlive-bin, which is what you want
<quiliro>'guix search texmf' shows nothing
<xavierm02[m]>it was texlive-texmf-20180414 but guix search that doesn't find anything
<xavierm02[m]>I think they were changing things about texlive
<xavierm02[m]>just install texlive
<quiliro>ok...when i did, i got this:
<quiliro>derivation to be constructed: [...] /gnu/store/q27fr3j8q4g55dviym3gidbhbqcbpgl1-texlive-texmf-20180414.drv
<quiliro>it is downloading texlive-20180414-texmf.tar.xz
<quiliro>how is that possible if that package does not exist
<quiliro>it is 2.4 GiB
***flor_ is now known as flor
<quiliro>what is the diference between emacs-org-re-reveal and emacs-org-reveal
<quiliro>emacs 26.3 is finally out
<gnu_srs>FYI: I managed to build guix natively on Debian GNU/Hurd. What's next?
<quiliro>gnu_srs: is Guix System GNU/hurd
<gnu_srs>quiliro: I should probably build packages, but guix build hello gives: guix build: error: failed to connect to `/usr/var/guix/daemon-socket/socket': No such file or directory
<quiliro>gnu_srs: can you report to ?
<bavier>gnu_srs: before building anything, you need to start the guix-daemon
<gnu_srs>I'll just write a short mail there. The path to get it built is a little hairy.
<gnu_srs>quiliro: I sent that mail to guix-devel where I'm subscribed.
<vup>yay i finally got alacritty working
<quiliro>gnu_srs: nice
<vup> if anybody wants this crazy thing
<nckx>vup: Cool! Any chance you're interested in upstreaming this?
<Sisyphe[m]>I've just compiled alacritty too but now I hit a problem
<Sisyphe[m]>is there a way to have application using libgl work with proprietary driver (I don't use GuixSD) ?
<vup>nckx: at some point certainly, but for it to be acceptable it probably needs quite some cleanup, so maybe starting with some smaller things like ripgrep or exa is better
<vup>s/is better/is probably better/
<vup>also what would be the recommended way to handle crates where multiple versions are needed? What i did was creating multiple packages and putting the version in the name of the package variable, but that doesn't really feel clean
<nckx>Sisyphe[m]: I really don't know the answer to that, but note that discussion of proprietary sophtwarez are not for #guix (or other GNU project channels).
<Sisyphe[m]>nckx: duly noted
<nckx>vup: That's how it's usually done, actually (common alternatives are ’foo-for-bar’ or ‘foo/feature’ etc., but they start to feel even less clean beyond very simple use cases).
<roptat>finally sent my dkimproxy service patch :)
<nckx>roptat: Huzzah! My ‘~/start-more-stuff’ script can finally die! \o/
<roptat>well, it's sent for review, not pushed
<nckx>(It was already dead inside, of course, forced to roam the earth etc.)
<roptat>don't kill that script just yet
<nckx>I was just looking forward to it.
<roptat>mariadb is still resisting, but setting CMAKE_INSTALL_PATH to the lib output seems to be a smarter move than anything else I've tried to far...
<nckx>Running core mail server components through nohup, it's the Unix Way™.
<vup>I see, I might start looking into upstreaming stuff in the next couple days then
<nckx>Renaming variables alone won't cause rebuilds, so worst case we can always switch to a better scheme. Things like Go seem to strain our naming conventions, not sure if Rust has similar issues.
<Sisyphe[m]>could we define rust libraries as functions taking a feature list as argument ?
<nckx>We could.
*nckx doesn't know enough about rust to know if that's sane.
<vup>Yeah rust also has features, but as currentl
<nckx>Another use case for package parametrization, then 🙂
<vup>currently all the actual building is done by cargo and it doesn't use any precompiled crates, thats not a problem
<nckx>Do Rust features often conflict in practice? I mean, almost all C libraries support ‘features’ (--with-fizz, -DENABLE_BUZZ), in practice we just enable everything needed/considered sane.
<vup>(as in a rust dependency is not a normal input, but a special `cargo-input`, and then basically included by source into the "toplevel" package that is being built)
<vup>i am actually not sure, if rust features can actually conflict
<PotentialUser-60>Is there a (recommended) way to globally install packages? /etc/config.scm?
<Sisyphe[m]>I got dependency cycle with all default features enabled for all dependencies of a package
*nckx is confused how/why the guix MLs still break DKIM signatures.
<vup>atleast cargo doesn't support conflicting features yet, so conflicts should be rather rare
<Sisyphe[m]>vup: how did you handle "native" dependencies when packaging alacritty ? did you add it as inputs of the top-level package ?
<vup>i think the problem with how version selection is done by cargo is bigger, as for binary applications rust as lock files, which specify the version of every (recursive) dependency. To build these lock files, cargo tries to minimize the number of different versions for each (recursive) dependency, which is great on a individual application level, but leads to the problem, that even if two binary applications depend on the same version of a library, the versions of
<vup>the dependencies of this library could differ between the two binary packages
<vup>Sisyphe[m]: yeah, i just added them as top-level
<vup>anyways, heading off for today,
<vup>anybody with ideas for rust crate packaging, share them in the logs;)
<Sisyphe[m]>I think I worked around this problem
<Sisyphe[m]>by providing as much version of a library as needed to satisfy each dependency, and since Guix rewrites the Cargo.lock to work with was is available, it compiles
<xavierm02[m]>quiliro: texlive-texmf is defined in the same file as texlive but with define instead of define-public so it's not visible from outside
<xavierm02[m]>I just checked
<xavierm02[m]>Trying to build thunderbird, I get ERROR: Only GCC 6.1 or newer is supported (found version 5.5.0).
<nckx>xavierm02[m]: First step would be to try adding (native-inputs `(("gcc" ,gcc-6))) ; 6.1 or newer required
<xavierm02[m]>so it is packaged
<xavierm02[m]>why isn't the newest vestion the one that's installed in my profile?
<nckx>xavierm02[m]: I don't understand the question.
<xavierm02[m]>When I run gcc --version, it tells me 5.5.0, so I have an old gcc in my profile for some reason
<nckx>The default GCC for building packages is still gcc-5 (this will be bumped with the next core-updates merge). I don't know what your profile contains (this won't be used when building Guix packages anyway), but ‘guix install gcc-toolchain’ installs 9.1 for me…
<nckx>We package every single major version from 4 to 9.
<raingloom>dumb noob question: how do I get the path of an input during building?
<raingloom>oh... wait... nevermind
<raingloom>i think i know