<Krafter_>I notice that the samples have a top level use-package-modules function unlike the generated one.
<nckx>Krafter_: The use-foo-modules forms are just more compact ways of saying the same thing, but it would be user-friendlier to use them in the generated files for familiarity. Good catch. I look forward to reading your notes.
<reepca>boogerlad: often it's necessary for the builder to be able to look up where a certain input is in the store. It can't do that using the package name, because it's possible to have multiple input packages with the same name (for example, suppose you had a gcc toolchain for x86-64 and a cross-compiler toolchain for aarch64 both used in the same package). So some sort of identifier is necessary.
<boogerlad>reepca: the documentation says "a package, origin, or derivation as its second element". since I'm not familiar with the terminology, a package refers to a scheme variable, origin is some url, and derivation is something in /gnu/store?
<reepca>boogerlad: a package is a structure usually referred to via a scheme variable. An origin is another structure that generally describes a way of fetching something from some other place into the store (url-fetch for ftp, http, https, git-fetch for git repositories, etc). The value of the "source" field of a package is an origin, for example. A derivation is another structure that describes how to construct an output from certain
<reepca>inputs. It's serialized as a file in the store with a .drv suffix.
<reepca>The common idea is that they are objects that end up representing stuff in the store - in the case of a package, it represents the outputs from building that package. In the case of an origin, it ends up representing some file fetched into the store. In the case of a derivation, it represents the serialized file version of the derivation (I think, I could be wrong and it represents the outputs of the derivation in a similar manner to
<emacsite>Installing with GNOME and full disk enc.
<emacsite>Wow, lots of packages to download! Hope it dings on me when it's done; I can't see what's happening in the other console.
<Guest85934>thanks rekado and reepca: only issue with `guix environment some-package` is that I'm needing the build tools in an environment that's for a non-packaged Python web app that needs to build a bunch of stuff from PyPi
<reepca>Guest85934: well, I guess you could get all the implicit inputs for the python build system by just running "guix environment some-python-package". Everything else would have to be specified manually anyway.
<g_bor[m]>do you think that moving the deps to the verison that was used might help?
<roptat>like EXCEPTION: /tmp/guix-build-kotlin-0.drv-0/kotlin-0-checkout/libraries/stdlib/src/kotlin/Integers.kt: (3, 1) org.jetbrains.jet.codegen.CompilationException: Back-end (JVM) Internal error: Failed to generate function times
<g_bor[m]>It would be nice to do something like have a test, so that the latest 'target version' can always build the latest 'dev version'. This could avoid a lot of mistakes. Moreover, the 'target versions' become apparent. But that might sound like an utopia :)
<g_bor[m]>ok, maybe I did not express myself clearly. What I believe would be good development practice for projects is something like: pin a release, that is clamined to be able to build the latest dev version, and then have a ci job to test that assumption, and do not allow a commit to be integrated to master if that ci job fails. Wdyt?
<g_bor[m]>or substitute whatever branch naming scheme fits you :)
<g_bor[m]>When it becomes inconvinient , then create a new release, based on one of the dev versions...
<Jackneill>i have an existing ubuntu boot usb. can i just dd into it?
<Jackneill>and be bootable? the iso contains the fat32 table etc?
<g_bor[m]>I have some problems with one of my vm-s. It becomes unresponsive, and the last lines of log I see before restarting it through the hypervisor tells me that elogind-daemon suspended the system. Any idea?
<roptat>nothing prevents you from downloading a more recent version of the plugin though
<g_bor[m]>It seems that currently no os config can be specified without a bootloader-configuration. I believe that we could relax that requirement in the view of system containers. I guess that currently it needs to be specified even then.
<rekado_>g_bor[m]: I thought so too. It would be good for VMs.
<str1ngs>nice, I've been thinking of getting one myself
*vagrantc has a package for guile-gcrypt and guile-sqlite3 for Debian and working through the guix build-dependencies...
<yurb>Hi everyone. I'm currently using nix on fedora to install audio software, but I'm also curious about guix. I have question - currently in nix OpenGL on non-nixos seems quite tricky. How does guix handle OpenGL on non-guix distributions?
<yurb>str1ngs: well, in case of supercollider it only uses it to render its help pages which are html and some trivial JS, certainly no WebGL or things like that
<brendyyn>ArneBab: because it is a monster 3-4GiB source code repository with code that was copy-pasted from all over the place apparently, so its dubious whether to call it libre or not. some of us feel that sufficient effort has already been put into librefying it, so it can be included, but others disagree.
<yurb>well, with the insane complexity of web today, I couldn't imagine how one could write another web browser (not using chroimum or firefox's codebase)
<str1ngs>there is gtk webkit and qtwebengine. that's about it
<yurb>browsers now are more like operating systems
<ArneBab>brendyyn: :-/ — real unity (not forced) needs a consensus, which needs good reasoning. If that’s not there, there can’t be real unity.
<devilishtype>and I don't think Mozilla has done anything yet, or what degree they'd take steps, but .. uh.. I'll have to look for the press conference. They were talking about making it harder to remove tracking, and adding an ad system.
<ArneBab>I for one am glad that there’s the ungoogled chromium, because some things don’t work with either my local firefox-workaround or icecat.
<brendyyn>id like to package electron programs eventually
<str1ngs>until someone writes a freedom html engine , nothing will be free
<devilishtype>I can't remember if it was Beard or someone else, but it was someone high up at Mozilla talking about their "monetization" strategy.
<str1ngs>so all the bitching in the world won't make a difference
<ArneBab>str1ngs: Both Gecko and Chromium are free — Chromium is what became of KHTML, Gecko is just free
<brendyyn>can't really blame them for talking about money wheen they are being drip-fed by google to survive
<arshin>str1ngs: webkit is free (LGPL + BSD licenses)
<rekado_>mouldysammich: this is from within the environment of the guix-daemon.
<rekado_>mouldysammich: there are three possibilities: 1) you don’t have GUIX_LOCPATH set to a valid location (e.g. in the systemd unit file), or 2) you don’t have glibc-locales installed where GUIX_LOCPATH points to, or 3) the version of glibc-locales is for a different glibc version than the one used by the guix-daemon.
<mouldysammich>ok, its installed on top of another distro, shoudld a sysctl restart guixdaemon do the trick? or should i set the variable in the .service file?
<mouldysammich>ok, thanks ill set it in the unit file and report back, thanks
<vagrantc>i skipped sleeping and packaged guile-gcrypt, guile-ssh, updated guile-json (twice), and re-added the guile-gnutls bindings to a local build of the debian package ... i've finally reached the "i can try to build guix" part of this
<jonsger>I wonder if there is a way to run "make check" to install the packaged guix version? I would be really interessted in this
<vagrantc>the other thing i started on was just packaging guix-install.sh ... but that seemed kind of silly.
<vagrantc>so, i guess i should just make a tarball from git and ignore the released tarball ... it mostly just contains changes to po/* and autogenerated build files ... and the packaging with run autoreconf anyways, so those are silly.
<maav>Smalltalk seems to be unavailable for substitutions. I'm getting errors during tests when I guix build it, but when I do the make check manually it works... where should I look to get the error from Hydra?
<pkill9>i dunno about compiling the kernel let alone compiling custom one on guix
<maav>civodul: the Smalltalk problems seem to be unrelated with /bin/sh, even though I'm not sure if we should patch scripts/Package.st... I'm getting different errors with guix environment --container smalltalk, all related with networking, but I have to look at the code
<roptat>and it creates a generation of the system everytime, so you can always roll-back a generation if you make a mistake
<maav>civodul: but I cannot reproduce the guix build failures (ANSI compliancy tests)
<civodul>maav: these tests are network-related, given their name, so there's probably something that has to do with host name lookups or connecting to remote machines
<civodul>perhaps you could strace the failing tests to see what's going on
<vagrantc>hrm. so i've got all the dependency packages built, but guix doesn't seem to find guile-git
<maav>civodul: it seems something weirder. abort is called 366 times through the code, some of them must reveal the problem (as the tests inside the daemon exit with 134, sigabrt), but my machine's memory is almost full...
<vagrantc>looks to have the same files as guile-git in guix has...
<rekado_>vagrantc: are the files on GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH?
<maav>I'm building gettext-0.20.1 from gettext-boot0 to gettext-runtime and gettext-tools (with java and mono) from core-updates + master, so my machine has already died twice
<samplet>Luke|Skywalker: No. I more-or-less copied our “bare bones” configuration file and added the mail services. I just wanted you to know that it is possible and you are probably even close! :) Pasting your config might be the easiest way for us to help you: <https://paste.debian.net/>.
<nckx>By the way, just tested: (service exim-service-type (exim-configuration)) works fine, no need for a configuration file. The fact that exim-configuration is needed at all is a cosmetic bug, though, IMO.
<nckx>You will need a non-empty mail-aliases-service-type.
<_rad>nckx: well whats more strange is the the install USB gets past grub just fine
<kmicu>(Some folks prefer ‘Configure-By-Example’ style and Guix is currently better for folks prefering ‘Configure-By-Reading-Manual-Top-2-Bottom’ style. Today there are not many real world examples on GitHub/GitLab/etc to make first style not frustrating or futile.)
<_rad>and I think they use the same grub version... will compare the cfg files to see if theres something that catches my eye
<_rad>now getting kms working is still in progress :)
<nckx>bundle latest supported msgpack-python release (0.5.6), remove msgpack-python from setup.py install_requires - by default we use the bundled code now. optionally, we still support using an external msgpack (see hints in setup.py), but this requires solid requirements management within distributions and is not recommended.
*rekado_ wrote an HTML syntax highlighting post-processor
<str1ngs>hello, I have a foreign distro hosted publish server. but --cache does not work. on the client end I get 404 error on first hit. which is normal. but then the guix-publish server does not baked the nar.
<nckx>Luke|Skywalker: I'm not familiar with exim, but I think ~/Maildir is the default.
<jdormit[m]>Anyone here using guix as a package manager on arch and running X installed with guix? I'm having trouble running startx, since the X server is meant to be installed globally but guix only installs packages per-user
<vagrantc>oh dear. now i remember why i didn't put much effort into packaging guix ... the guile-gnutls bindings are not built in debian due to a history of intermittant test suite failures ... and is likely reluctant to support it again