IRC channel logs


back to list of logs

<bavier>a few issues in guix wrt the configure options --program-suffix et al.
<civodul>Hello Guix!
<kraji>hello :) I'm trying to configure my synaptics touchpad in guixsd. usually i should add a configuration file to the directory /etc/X11/Xorg.conf.d/ . How is this done in guixsd?
<iyzsong>kraji: by default it's using 'libinput', which two-fingers scroll works but edge-scroll doesn't. to switch to the more configurable 'synaptics' driver, I think you have to custom the 'startx' command of 'slim-service'.
<civodul>iyzsong: should we add the synaptics driver by default?
<civodul>better yet, we should make the driver list more easily configurable
<iyzsong>its there, but a device can only use a drive at a time. and i think libinput is enough in most cases :)
<civodul>oh, ok
<civodul>wasn't libinput supposed to supersede everything else?
<iyzsong>I think so, with libinput, touchpad can be configured by GNOME Settings, but it has fewer options.
<efraim>sometimes I'm years behind in news
<efraim>I just found out the author(?) of sed died
<efraim>... in 1989
<efraim>comment in tar's code: # Blame Lee E. McMahon (1931-1989) for sed's syntax. :-)
<civodul>heh :-)
<civodul>efraim: i'm trying to build tar 1.29 on core-updates, BTW
<civodul>are you looking into it too?
<civodul>i don't want to step on your toes :-)
<LnL>what does the "substitute: updating list of substitutes ..." do exactly, seems to happen before every build
<Remjey>Hello, I’m installing GuixSD right now and was surprised to not find any vi-like editor on the installation disk. I can accomodate nano for the few files that must be edited for install, but if the installation disk was to be used as a rescue system, it would be nice to have at least a minimalist vi for people like me who heavily use vim and will insert vi commands everywhere in text files while using other editors
<civodul>LnL: it checks which pre-built binaries are available, see
<civodul>Remjey: you can run "guix package -i nvi" in the image
<civodul>but i agree we should add it by default
<LnL>civodul: isn't that supposed to be deterministic?
<civodul>the local Guix doesn't know in advance whether pre-built binaries are available
<civodul>so it checks and caches the info for some time
<LnL>but it does know what the output path should be, or is that not the case because of grafts?
<Remjey>civodul: ty !
<LnL>I'm just messing around with guix, I've been using nix for quite a while now and I notice a significant difference when installing packages
<LnL>just wondering why that is
<civodul>LnL: yes, it knows what the output path is, and it checks whether it's available on the substitute server
<civodul>currently you probably these messages repeat several times, and that's because of grafts
<LnL>civodul: alright I thought so, but it could have been some configuration issue on my part
<civodul>no, that's a limitation/annoyance of the current implementation of grafts
<efraim>civodul: was away doing dishes, I gave tar a quick shot but decided to come back to it later.
<efraim>got gdbm upgraded and was about to start checking out sqlite-3.12.2
<civodul>efraim: ah ok, i have gdbm and tar now :-)
<civodul>i'll let you do the rest ;-)
<efraim>gdbm was an easy in-place update
<Remjey>Mh, I just ran out of free space while installing, what is the recommended minimum disk size for installing GuixSD ?
<catonano>I'm trying to send a patch to the dev list with git-send-email but I get an error message
<catonano>STARTTLS failed! SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed at /gnu/store/z517ik0y7462x72c789na6bhhr823qlg-git-2.7.4-send-email/libexec/git-core/.git-send-email-real line 1369.
***kelsoo1 is now known as kelsoo
<wingo>catonano: do you self-host your mail?
<wingo>that error indicates that your connection to your smtp server isn't working
<wingo>also, ssl3?
<wingo>that sounds bogus, sounds like you should set smtpEncryption to tls
<wingo>the "sending" part.
<iyzsong>I sent some emails to guix-devel, which take 2 day to arrive.
<civodul>iyzsong: is under maintenance today apparently
<civodul>and it seems there were problems earlier
<catonano>wingo: thanks. smtpEncryption IS set to tls in my .gitconfig
<iyzsong>civodul: ok, and good to know it's back again. (thanks its maintainers)
<civodul>iyzsong: i think it *will* be off-line a bit later today
<iyzsong>ok :-
<efraim>apparently there's also a gnutls update to 3.4.11, which is good because I was getting a test failure with 3.4.9
<civodul>efraim: to 3.5, even, which includes support for Guile 2.2
<civodul>we should do that update
<civodul>in core-updates
<efraim>I wasn't sure about 3.5, they list it as stable-next
<efraim>still, guile 2.2 is good
<efraim>and it does say it's backwards compatable
<civodul>well, not sure, maybe we should wait until 3.5 is the new stable?
<efraim>backwards compatable means it should be fine, and if there's a problem it should just fail during building or testing
<civodul>optimistic approach
<civodul>i'm fine either way
<efraim>3.4.11 built without problems, testing out 3.5.0 now
<efraim>ooh I got the backtrace again on key download!
<Kooda>Hi :) Just installed GuixSD in a VM. I still have to get the hang of guix but it’s really nice so far.
<Kooda>Just a tiny problem, there was no information about how to configure the keyboard map for the installed system though there is an instruction to change the keymap of the installer.
<Kooda>(speaking of this, I was really happy to see I could select the bépo keymap (french dvoark-like mapping) in the installer :D)
<civodul>Kooda: thanks for your feedback!
<civodul>Kooda: console-keymap-service is the thing, though it's probably hard to find
<civodul>and it doesn't address Xorg
<civodul>efraim: signature-verification failure is not handled gracefully, i guess
<civodul>and it seems it failed to download the key
<civodul>BTW, i'm interested in your gnupg config, the thing that makes it use the onion service
<civodul>i always use torify but in some contexts it's not convenient
<ng0>there's one hkp onion, and gnupg-2.1 has for dirmngr the use-tor option, but the hkp onion fails for me so far
<ng0>system indepent
<ng0>I'd be interest too because of that
<efraim>civodul: re signature-verification, I didn't answer the question, I just hit enter
<efraim>I declare my keyserver several times in gpg.conf, but the last one is: keyserver hkp://jirk5u4osbsr34t5.onion
<efraim> is my gpg.conf
<efraim>i have guix's gnupg installed, so I call gpg2 normally, pretty sure debian's gpg is symlinked to the gpg v1 binary
<lfam>I sent an email about including the tar update in core-updates, but I read the logs and saw others are working on it :)
<lfam>I wasn't able to build it when I tried yesterday, but I guess you figured it out :)
<lfam>There is a security patch for gd, but one of the hunks in the git diff is a new binary file (input for the test added to guard against regressions). `patch` can't apply binary diffs from git. How should I handle this? Should I disable the test and push the rest of the update?
<civodul>efraim: just pushed a fix for 'guix import gnu which'
<civodul>lfam: ooh, sorry
<civodul>for tar
<civodul>lfam: re gd, we should probably disable the test that requires the binary file, and leave a note in the patch
<civodul>efraim: and you use an HTTP proxy that direct traffic through Tor?
<efraim>oh yeah, i have privoxy set up
<civodul>and you have $http_proxy set globally, right?
<efraim>I actually dont have that set
<efraim>it gives me better perfomance with links that way :)
<jlicht>Good afternoon #guix
<lfam>civodul: No problem re: tar. I'm always happy for somebody to finish a task before me ;)
<lfam>civodul: Okay, I'll do as you said for gd
<efraim>I applied the tar patch locally and i'm still rebuilding to gnutls-3.5.0 and sqlite-3.12.2
<jlicht>is it possible to have a i686 vm image, created on a 64 bit system with guix?
<efraim>you can append --target=i686-linux to the end and that should do it
<civodul>not --target=i686-linux, but --system=i686-linux
<civodul>not to be confused! :-)
<civodul>--target is for cross-compilation and it takes a triplet
<civodul>--system is for native compilation, and it takes a "system string"
<efraim>ah, i've been trying a bit to generate aarch64 bootstrap-tarballs
<efraim>so i've been using --target a bunch
<jlicht>`guix system --system=i686-linux vm myconfig.scm` seems to do the trick
<jlicht>thanks civodul, efraim! Having guix system --system seems a bit silly though
<jlicht>btw, will the next version of guix be 0.11?
<civodul>probably 0.10.1
<civodul>hopefully once core-updates is merge, a few weeks from no
<civodul>davexunit: how much is missing for a typical RoR environment?
<davexunit>many rails dependencies. rails has a pretty massive dependency graph.
<davexunit>and if we want to support all the major versions of rails in common usage (3, 4, and 5), there's a lot more stuff.
<davexunit>civodul: ^ the above was for you, but I forgot to highlight you. :)
<davexunit>I think we could use something like bundnix or whatever it's called that can convert a project's Bundler (the terrible dependency manager all Ruby people use) configuration into the relevant Guix package expressions
<civodul>davexunit: bah, ok!
<civodul>plus Rake, right?
<civodul>i was looking at a RoR thingie at work
<davexunit>civodul: that comes with ruby. we wouldn't be able to build anything without it.
<davexunit>so we're good there.
<davexunit>the gem importer is pretty straightforward, so it is possible.
<civodul>it's possible to fill in the holes?
<davexunit>I've gotten small ruby web applications to boot with nothing but guix provided gems
<davexunit>civodul: yeah, just depends on how big the dependency graph is.
<efraim>gnutls-3.5.0 built successfully
<davexunit>civodul: every now and again I package a handful of gems, but haven't done so in awhile.
<civodul>davexunit: the thing i was looking at has RoR and a dozen things in its Gemfile
<davexunit>civodul: there's a way for bundler to print out the full list of dependencies
<jlicht>it would actually be cool to have a generated list of "important" packages that are as of yet unpackaged in guix
<davexunit>it's hard to say what those packages are
<davexunit>civodul: bundle list | wc -l
<davexunit>subtract 1 from that result
<davexunit>(the first line is just a header)
<davexunit>the main application at work has 197 total Ruby gem dependencies
<jlicht>it probably does not work in guix yet, right?
<davexunit>absolutely not
<davexunit>but I use a hybrid environment currently
<davexunit>where I make a container with guix that has all the native libraries and ruby itself
<davexunit>and then install all the Ruby gems with Bundler
<jlicht>you actually use guix for work-related stuff?
<davexunit>jlicht: for some stuff, yes.
<davexunit>only on my workstation. production systems have no guix at all.
<davexunit>which turns out to be a pain because I write terrible Chef scripts that Guix could do better if it were just given a chance.
<davexunit>I literally spent all of yesterday writing Chef scripts to compile special versions of boost, jsoncpp, kaldi, openfst, and more for the speech recognition component of my company's software.
<jlicht>davexunit: ouch. AFAIK, the Powers That Be at my day-job would not be comfortable using any <1.0 software, so I will be stuck in a similar position for the forseeable future
<davexunit>and in doing so all sorts of questions come up: how can I figure out if this software needs to be (re)compiled and skip it when nothing has changed?
<davexunit>how do I isolate build environments? (you don't)
<davexunit>what installation prefix should I use for this custom stuff?
<civodul>davexunit: which package provides 'bundle'?
<civodul>do we have it?
<davexunit>civodul: bundler
<davexunit>yes, we have it.
<civodul>ah yes
<civodul>"Your Ruby version is 2.3.1, but your Gemfile specified 2.3.0" wtf?
<civodul>"Could not find rake-11.1.2 in any of the sources" ?!
<jlicht>davexunit: well, if it's any consolation: it seems things are as bad as they will get for you now. Just imagine, {0.5,1,2.5} years from now, when guix will be ubiquitous ;-)
<davexunit>civodul: I guess your gemfile is forcing a particular version of ruby to be used.
<civodul>yes i've changed that, but then there's this rake error
<davexunit>jlicht: heh, I'm not so sure about that, but I hope to eventually work somewhere that thinks Guix is the thing to use.
<davexunit>civodul: you ran 'bundle' ?
<civodul>yes, the errors come from 'bundle'
<davexunit>is 'rake' in the Gemfile?
<davexunit>some applications explicitly depend on some version of rake
<civodul>it's not the case here, AFAICS
<civodul>at least not in this Gemfile, maybe it could happen indirectly
<davexunit>civodul: one issue may be that you need to set GEM_HOME to a place that bundler can actually install to
<efraim>gnutls and sqlite pushed to core-updates
<davexunit>civodul: I often just use $PWD/.gems for this purpose
<civodul>efraim: thanks!
<davexunit>here's some of the things I do for ruby with guix
<davexunit>many things are probably irrelevant for you here, but just in case
<civodul>oh running "bundle" with no arguments makes it fetch stuff
<davexunit>it's equivalent to "bundle install"
<civodul>"Failed to build gem native extension." heheh
<davexunit>civodul: now the fun begins!
<davexunit>which gem?
<davexunit>(look, guix is validating its extistence!)
<davexunit>yup, that's one of the common ones
<davexunit>needs the mysql client libs
<davexunit>our mysql is now 5.7, which is too new for some rails codebases (ran into that myself)
<jlicht>Can gems have cyclical dependencies? And if so, how do we deal with that?
<davexunit>jlicht: this is indeed a problem that we've run into on many occasions
<davexunit>typically, the cycle happens in the test suite
<jlicht>because I am finding that npm-land seems to be built on circular dependencies. Circular dependencies all the way down xD
<davexunit>the test suite requires a gem that depends on the gem you are trying to build :(
<davexunit>or, the test software itself depends on another gem that uses that software to run its own test
<davexunit>jlicht: the only way to break it is to build intermediate versions of packages that are tweaked to break the cycle
<davexunit>for instance, our rspec gem doesn't run tests because to do so would mean a cycle
<civodul>jlicht: sounds like you'll have a lot of fun with npm import :-)
<bavier>the same happens with many perl packages
<jlicht>civodul: yeah, already have some fun with that :#
<civodul>to be fair that also happens in traditional C/GNU/Linux land
<jlicht>what is the current approach to making sure that the correct version of packages get loaded?
<jlicht>do we set the "load path" for each e.g. guix gem package via a wrapper so that it will only load those gems?
<civodul>jlicht: yes that or we build a "profile" that contains exactly those packages you asked for
<jlicht>civodul: not quite sure what you mean regarding profiles. I know of guix profiles, but how do these relate to package installs and their load paths?
<civodul>"installing a package" in Guix means creating a profile that contains it
<civodul>so all you need is to set your load path to point to that profile
<civodul>or did i misunderstand your question?
<jlicht>civodul: I think I need to put my thoughts on paper to clearly articulate them. Maybe I am seeing problems where there might be none though.
<jlicht>but basically, lets say I want to `guix package -i foo`. Foo depends on bar@1.2, and also on baz@1.0, which depends on bar@2.0.
<jlicht>in a system that ignores versioning at runtime, how do we make sure these versions of bar do not clash
<bavier>jlicht: bar would only be installed into a profile if it is a propagated input
<bavier>otherwise the packages depending on it refer directly to the store
<bavier>so there is no clash
<jlicht>bavier: yes, but if they still need to be loaded at run time by a version-agnostic (or rather, ignorant..) system, this implies we need to have different run-time "load paths"
<jlicht>tl;dr: are wrappers a good way of setting specific environment variables for packages?
<civodul>jlicht: it depends on the language's run-time environment
<civodul>few languages allow different versions of a dependency to be loaded at run time in the same program
<civodul>i think Node is a notable exception
<jlicht>hurray for Node then :/. But wrappers for setting this run-time load path, referring to store items, would not necessarily be a problem, as they do not ever change. You know, because of the whole guix thing ;-). Am I understanding this correctly?
<civodul>to answer that, i would first need to be sure i understand correctly ;-)
<civodul>Guix sortof assumes that there can be only one package of a given name in a profile
<jlicht>_that_ is a good thing to know. If I really need different configurations/versions of the same package available in the same profile, I need to package them multiple times?
<civodul>it's not really supported
<civodul>i don't know what it would mean
<civodul>well, except for Node...
<jlicht>I am talking more about the python2/python3 situation
<civodul>packages are called "python-foo" and "python2-foo", so no problem here
<bavier>so, lsh hasn't been released yet
<civodul>bavier: you mean a new release?
<bavier>civodul: yes. from the list archive, it looks like it got lost.
<bavier>I was trying to build lsh through GSRC, but the nettle 3 incompatibility hit
<civodul>bavier: yeah a couple of us have been lobbying for a new release, but that hasn't happened yet
<civodul>so you use GSRC too?
<bavier>I do, at $dayjob workstation
<bavier>makes building in unprivileged env easier
<bavier>but I think I can generate an lsh key on a different machine
<bavier>I'm trying to setup guix offloading to a custom guix-daemon
<efraim>so its not just me having a hard time generating an lsh key?
<civodul>it should be quite easy
<civodul>ACTION stumbles upon
<davexunit>civodul: yeah, we were on the front page for awhile, but didn't generate much discussion.
<davexunit>not compared to other similar software that shows up there, like Docker or NixOS.
<civodul>yeah well
<davexunit>some decent comments here, though, along with the usual anti-GNU bashing.
<davexunit>comment I liked: "Although Guix have arguably passed Nix in terms of features already, with a much better command-line tool, a linter, importers for several external package registries and grafting[0] which is a real pain point in Nix."
<civodul>yeah, it's encouraging ;-)
<civodul>i'd like to have more feedback, good and bad, from people who've used both Nix and Guix
<davexunit>a good number of Nix users seem to not be swayed by the unity of Guix's implementation language
<davexunit>totally anecdotal evidence
<bavier>oh, I need lsh to process offloads on the client end too, so I will need to figure this lsh build out.
<bavier>maybe offload needs to warn of missing "lsh" command, rather then report an exit value of 1
<civodul>above all, offload needs to switch to guile-ssh...
<civodul>ACTION has to go
<bavier>can a patch fail apply if the file encodings are different?
<kyamashita>So has anyone contacted the Tor Project yet about the bundle problem?
<GNUtoo-irssi>hi, I did: guix gc, and then guix pull
<GNUtoo-irssi>"guix pull: error: build failed: some substitutes for the outputs of derivation"
<kyamashita>GNUtoo-irssi: Is some of that error message missing?
<GNUtoo-irssi>maybe guix itself is not up to date...
<GNUtoo-irssi>failed: 410, "Gone"
<GNUtoo-irssi>le tme find what failed
<GNUtoo-irssi>*let me
<GNUtoo-irssi>though, now it's downloading linux
<efraim>bavier: it needs lsh on the other end too? lsh on "local" and ssh on "remote" doesn't work?
<GNUtoo-irssi>I'll pastebin
<bavier>efraim: with "client" I meant "local", i.e. the machine that's requesting the build
<bavier>I think ssh on remote would work, but I haven't gotten that far yet
<kyamashita>What is lsh?
<efraim>i'm still stuck at lsh-make-seed -o "/home/efraim/.lsh/yarrow-seed-file"
<efraim>ooh it worked on my machine finally
<efraim>I guess it can be described as an alternate ssh implementation
<lfam>Should I apply the gd patch with a graft, or the "regular" way?
<lfam>"Building the following 54 packages would ensure 97 dependent packages are rebuilt"
<bavier>lfam: 97 seems fine.
<bavier>hydra doesn't seem too loaded at the moment
<lfam>Okay. It will be up there soon
<lfam>libreoffice is affected, but that seems to *always* be the case
<lfam>I know decided whether or not to graft depends (to some degree) on which packages are affected. but ignoring that factor, what do you think is the number that requires a graft versus a normal rebuild?
<kyamashita>What does grafting do? Is it just an update of one package and reassigning symlinks?
<bavier>kyamashita: grafting does rewrites of package dependencies starting from an existing package
<efraim>python programs normally "count less"
<lfam>It also rewrites internal runpaths in the binaries, right?
<bavier>which is perhaps poorly-worded; the manual is better:
<davexunit>it rewrites all references to the grafted store item
<bavier>lfam: yes, every reference
<lfam>Right, that's what I thought
<efraim>I try not to hit gtk-3 dependencies, qt is fair game since it only has ~50 rebuilds
<lfam>Almost everything seems to affect libreoffice and a set of python-based scientific / math software
<efraim>and I try not to break bio packages :)
<lfam>Yes, that's rekado's job ;)
<lfam>I'm interested in a pre-push Git hook that will prompt me to sign what I am about to commit. I think I'd prefer that over forcing myself to sign everything I do locally.
<lfam>what I am about to commit to Savannah, that is
<bavier>we've not implemented a server-side hook to force signing yet
<bavier>but there are probably some useful local hooks that we could collect somewhere
<lfam>No, but that would serve a similar purpose.
<lfam>I have searched all over the net and found no examples of this. Pre-push hooks are relatively new
<lfam>I haven't sat down and tried to write the hook, yet. It's probably not that hard
<bavier>I've seen one project that keeps a "hooks" directory in its repository
<bavier>I think it's up to the developers to enable them
<bavier>I'm not too familiar with git hooks
<kyamashita>If I wanted to correct my name in the Guix tree (shedding a psuedonym), would I just submit a patch with those changes?
<bavier>kyamashita: yes, that's how we've done that in the past
<efraim>is the tcsh test suite supposed to take forever?
<GNUtoo-irssi>sorry, sidetracked
<kyamashita>bavier: Do you have an example commit for the correct format?
<lfam>efraim: You should solve the halting problem and find out ;)
<bavier>kyamashita: commit 822efdff8a52 e.g.
<lfam>efraim: The info on hydra suggests that it should not take more than 10 minutes
<lfam>GNUtoo-irssi: Are you upgrading from a very old version of Guix?
<lfam>It looks like you are so far back that you don't current versions of what is required to build Guix itself
<GNUtoo-irssi>pcr/guix 0.10.0-1 [installed]
<GNUtoo-irssi>should I guix pull --bootstrap?
<efraim>ERROR: no code for module (guix config)
<datagrok>I recently encountered my first "warning: collision encountered:" message. should I file a bug? seems like guix might need to grow a feature like debian's "alternatives"?
<davexunit>datagrok: they're harmless.
<davexunit>not a bug.
<bavier>datagrok: it's a known issue
<davexunit>annoying, but harmless.
<kyamashita>davexunit: When would they be a problem, if ever?
<lfam>They are often harmless. Most of them are, but you have to evaluate them to make sure some important file isn't being excluded from your profile
<davexunit>well, it's a good warning to see in the cases that there really is an important collision. but currently, they are too noisy.
<lfam>Imagine two packages that both provide a same-named binary. Only one binary will be linked from your profile
<davexunit>there's a lot of collisions in most people's profiles due to desktop stuff
<lfam>Right, it seems to be mostly icon caches and stuff like that
<kyamashita>lfam: I agree.
<lfam>Working on the libndp update; rebuilding gnome
<datagrok>in my case it was ...ld-wrapper-0/bin/ld vs ...binutils-2.25.1/bin/ld
<davexunit>that's one of the harmless ones
<lfam>I think should upgrade shotwell or remove it:
<lfam>"There was an issue with verifying TLS certificates in previous versions of Shotwell so it might be possible that publishing sessions were intercepted. "
<bavier>we should upgrade it
<lfam>Does anyone use it and want to try the upgrade?
<lfam>Or at least applying the patch mentioned in that message?
<datagrok>once i have run "guix environment ...", can I add more packages to that environment without polluting my user profile?
<davexunit>exit and make a new one
<davexunit>or make yet another subshell if that works
***frafra_ is now known as frafra
<datagrok>ty davexunit
<bavier>lfam: I use it occasionally, I can attempt the upgrade
<lfam>bavier: Okay, good :)
<kraji>ok. so I modified a package with guix build --with-source. How do I install it?
<bavier>kraji: guix package --with-source=... -i foo