<lfam>I haven't studied the gnutls test suite, but it's weird that only one test failed due to missing datefudge. There are ~100 uses of datefudge
<MaliRemorker>Can anyone tell me how to get fluxbox up and running on GuixSD? I've seen the instructions how to add ratpoison and friends to your system config file, but the exact analogue doesn't work for fluxbox. That is, slim doesn't seem to pick it up, after installing.
<MaliRemorker>right, so i'm doing `guix system reconfigure /etc/config.scm' after adding (use-package-modules wm ...) and the first thing it does is to pull down all the substitutes from hydra. this takes aaaages
<rekado>does git fetch work for you? I cannot seem to fetch the latest commits from savannah.
<pmikkelsen>hello, are there someone who usually takes care of updating haskell packages? if not, can you give me som advice for how I would do it :) i am trying to package stack, but there are a lot of packages thats too old..
<sneek>Welcome back pmikkelsen, you have 1 message.
<efraim>sneek later tell pmikkelsen `guix refresh -t hackage' will show which haskell packages from hackage can be updated, I normally copy the information over by hand rather than anything automated. `guix import hackage foo' will download the source of foo and create a template of that version, which you can mesh with the version already in guix..
<pmikkelsen>rekado: thanks :), but what do you mean by importers? sorry if i sound stupid :)
<sneek>Welcome back pmikkelsen, you have 2 messages.
<sneek>pmikkelsen, rekado says: we have updaters for all packages that also have importers. See “guix refresh -h” on how to use the updaters.
<sneek>pmikkelsen, efraim says: `guix refresh -t hackage' will show which haskell packages from hackage can be updated, I normally copy the information over by hand rather than anything automated. `guix import hackage foo' will download the source of foo and create a template of that version, which you can mesh with the version already in guix..
<rekado>pmikkelsen: Guix has tools to create package expressions from upstream package meta data.
<lfam>ng0: It usually means that our package definition tries to fetch the source code over HTTP, but is then redirected to HTTPS. Since the package definition refers to HTTP, GnuTLS is not available in the build environment. The package definition should be updated to use HTTPS.
<lfam>It fails to download the source of lxterminal?
<lfam>Indeed, our sourceforge mirrors (in guix/download.scm) use HTTP instead of HTTPS
<ng0>i think i noticed this bwefore and wanted to patch it
<ng0>I can not patch this right now, I'm still doing the checks part of gnupg-2.1.14 .. the readme for the gpgscm tests are clear, but what I'll end up with might hopefully get fixed once upstream replies
<lfam>The annoying thing is that I ask SourceForge about all the changes, and the reply was "We haven't changed anything". So, I replied with more detail. Hopefully they write back on Monday
<ng0>gnupg test phase is really holding me back from learning more about services.. idk.. not that the roadmap i work on has a fixed fast-forward goal and needs to be finished, but maybe someone else wants to do gnupg check phase? the other 3 applications are updated and tested against each other, I only lack a building gnupg-2.1.14 to sent them in.
<ng0>gpgscm lives in the source of gnupg, specifically tests/gpgscm/ and i think either in that dir or in tests/opengpg/ the README covers what has to be done. I asked upstream to move it (only gpgscm) outside of gnupg so that it can be installed as an altered tinyscheme, which it is based on
<lfam>I've sent a patch to address the gnutls problem
<ng0>I would like to have an mailinglist which collects all the relevant announce* mailinglists.. Can you subscribe mailmans to lists?
<catonano>rekado: I'd love an introduction to the couple Geiser/Guix too
<ng0>When I build a GnuPG minus everything except gpgscm, I would have to alter the includes in the c files to include system libraries which previously were in place or in source directory. As this package is not intended to be installed into user profiles, would this change in setup behavior cause problems theoretically? Is my approach to do this to complicated? I already have an almost working gpgscm package now
<efraim>it would be a native-input so it shouldn't interfere with any packages
<efraim>plus you could alter the install phase if you wanted to only install the bits you wanted
<lfam>alcasa: Not as far as I know. The system is designed to transparently substitute binaries when they are available, but at its core it's about building from source. However, our goal is to provide substitutes for the current package tree, and at least as far back as the latest Guix release.
<lfam>It's possible that you are building so much because your version of the package tree is too old. You can update it with `guix pull`. The other possibility is that you tried to build something we recently updated, and we don't have substitutes for it yet. Or, there could be some networking problem or a problem with our servers.
<lfam>And, the central point of our build farm died a few days ago. It is coming back online but for the last few days, there have been fewer substitutes available than normal
<alcasa>lfam: thanks for the answer. when i call guix pull initially it tries to manually build gcc toolkits (which take a lot of time on smaller machines). i made sure that substitutions were available. is it expected behavior, that guix pull with install build tools?
<lfam>alcasa: It's possible but infrequent. I think it means that the newer version of Guix also requires newer versions of those build tools. I run `guix pull` several times per week and it only involves building the Guix dependencies every couple months
<alcasa>just switch to chrome numbering system to make development seem faster :p
<lfam>You will have to build sometimes. It's not like Debian or Arch where it never happens. Maybe with time we will have the resources to make it very rare
<lfam>But, we do updates of leaf packages on the master branch, which is where `guix pull` comes from. You might try to install the updated package before our build farm gets to it
<lfam>Core package updates, which would require building a significant portion of the package tree, are pushed to a staging branch which gets built before it is merged into master. So, we try to not leave ourselves building the entire world on our personal machines.
<lfam>It gave me another perspective on the concepts of positive and negative liberty. I think that very underpowered computers do not, on their own, actually give much freedom to the user, since they can't build the base of the system. Mine was unstable when loaded for long periods of time. A slow and stable machine might be fine
<pacujo>I'm new to guix and trying to map it to our existing build processes.
<pacujo>The source code is under version control, and anybody can build it (say, with build.sh).
<pacujo>Also, "official" build servers produce a new build whenever a new commit is pushed to the repository.
<pacujo>Occasionally, we want to release/publish a build officially. We have a command to do that.
<pacujo>Now the question is, how would we have to adapt our process to guix?
<lfam>pacujo: I'd start by creating a new package definition that uses the gnu-build-system. Presumably, you'd replace the default build step with something that runs `build.sh`
<pacujo>Where would the package definition go? Among the sources like build.sh?
<lfam>I've never created a Guix package definition that is not meant to be added to the official Guix repo. But, I recently downloaded and built this fun game using the Guix package definition it provides: https://davexunit.itch.io/lisparuga