<g_bor_>efraim,civodul: so for example in cases like this, we might try to add a bug with wishlist or minor, and also easy, to allow new contributors to pick this task up. We could also have these for upgrades. But this might be an overuse of the bug tracker. WDYT?
<civodul>g_bor_: the wishlist items currently in the BT are typically non-trivial things, or things for which we don't have a clear implementation plan
<civodul>now i think there are "easy" bugs in the bugs.gnu.org/guix that simply miss the tag
<civodul>we could write a section, say "Your First Contribution", in the manual
<civodul>that would tell people they can add new packages, upgrade existing packages, or look for "easy" bugs in the BT
<rekado>civodul: I always recommend adding R packages because the importer is pretty good.
<rekado>(I was under the impression that there are no easy bugs in the bug tracker)
<snape>well, fixing a Qt 5.11 build issue is typically an easy task
<rekado>“The public key for hydra.gnu.org is installed along with Guix, in prefix/share/guix/hydra.gnu.org.pub, where prefix is the installation prefix of Guix. If you installed Guix from source, make sure you checked the GPG signature of guix-0.14.0.tar.gz, which contains this public key file.”
<g_bor_>I've just read the limitations section in the manual claiming that we miss KDE. We have some KDE related stuff, what is still missing? Is this a work in progress?
<civodul>g_bor: Hartmut did a lot of work in this area, but i don't know what's missing
<civodul>i think on guix-devel they even discussed the beginning of a KDE service
<g_bor_>civodul: I just asked, because I have a feeling, that this work is somewhere near completion, and it would look really good, if we could remove that from the list of limitations. I guess I will contact Hartmut and ask around.
<g_bor_>Now I'm trying to systematically evaluate these limitations, and try to get invoved where I can... I've also seen a graphical installer in development on some wip branch.
<g_bor_>I am going through the list of limitations mentioned in the guix manual about guixsd. I have noticed earlier how lvm does not fit our current mapped device concept, but at first I thought, that this could be mitigated by settign the volume group either as source, or as target.
<g_bor_>The problem with that an lvm volume group is neither a source, nor a target in the current sense. The arity of these attributes suggest to choose a vg as a target, but this approach has its problems.
<g_bor_>And it is still a problem, that the source would be empty.
<rekado>I’m trying “guix pull --branch=core-updates” on another laptop with a somewhat recent Guix, but I get an error: no binding `invoke-error?' in module (guix build utils).
<axd>pkill9: that's perfect thank you. I'm still a guix noob, so didn't realize that packages are sometimes like categories. What's a command to be able to see the all of the possible outputs of a specific package? When I use `guix package -s `icedtea`, am I seeing just the "out" output?
<reepca-laptop>there should be an "outputs" field (it goes name, version, outputs, ...)
<pkill9>axd: there's an 'outputs' part, like reepca-laptop says
<pkill9>also `guix package --show=icedtea` for a single package
<axd>pkill9: how would I see what's the difference between the out and jdk, outputs for example. In this case I can imagine what jdk means, but what was the default "out" then?
<pkill9>i think the only way you can tell is by browsing the output really (the 'ranger' program is great for this, and it's now packaged in guix)
<reepca-laptop>also it's quite possible that whoever wrote the package definition made some notes about it. "guix edit icedtea" shows that they did indeed write a comment next to each output.
<pkill9>i think the default 'out' output is kinda decided on a case-by-case basis, so if a package is primarily used for libraries at compile time, it will by default have all the libraries in the 'out' output and have binaries provided in a 'bin' output
<pkill9>then some other packages have a 'lib' output
***dmc is now known as cmd
<pkill9>so i assume the binaries they create are primarily what that package is used for
<vagrantc>heh. forgot about a beast of a machine i *should* have been doing all this arm64 stuff on ... softiron overdrive1000 ... it's big and bulky, but has 16GB of ram, quad-core and SATA ... and now seems to run GuixSD just fine :)