<bavier>a few issues in guix wrt the configure options --program-suffix et al. <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>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>comment in tar's code: # Blame Lee E. McMahon (1931-1989) for sed's syntax. :-) <civodul>efraim: i'm trying to build tar 1.29 on core-updates, BTW <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>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? <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 :-) <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>that sounds bogus, sounds like you should set smtpEncryption to tls <iyzsong>I sent some emails to guix-devel, which take 2 day to arrive. <civodul>iyzsong: lists.gnu.org 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 <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 <efraim>I wasn't sure about 3.5, they list it as stable-next <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 <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: console-keymap-service is the thing, though it's probably hard to find <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>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>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: 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? <civodul>and you have $http_proxy set globally, right? <efraim>it gives me better perfomance with links that way :) <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>--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>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>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>the gem importer is pretty straightforward, so it is possible. <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. <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>the main application at work has 197 total Ruby gem dependencies <jlicht>it probably does not work in guix yet, right? <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>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>"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>some applications explicitly depend on some version of rake <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 <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 <civodul>"Failed to build gem native extension." heheh <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 <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 <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? <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 <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 <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? <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. <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>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 <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... <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>"guix pull: error: build failed: some substitutes for the outputs of derivation" <kyamashita>GNUtoo-irssi: Is some of that error message missing? <GNUtoo-irssi>/gnu/store/1ka272y86pigw4sk404xxjnc9kmhn6r3-file-5.25.tar.gz <efraim>bavier: it needs lsh on the other end too? lsh on "local" and ssh on "remote" doesn't work? <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 <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>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? <davexunit>it rewrites all references to the grafted store item <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? <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 <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"? <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 <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 <lfam>"There was an issue with verifying TLS certificates in previous versions of Shotwell so it might be possible that publishing sessions were intercepted. " <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? ***frafra_ is now known as frafra
<bavier>lfam: I use it occasionally, I can attempt the upgrade <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