IRC channel logs
2019-09-07.log
back to list of logs
<Minall>Is possible that the filesystem type has something propietary? then guix doesn't mount it? <vagrantc>and when i try to add zip ... ("zip" ,zip) to native inputs ... i get: guix build: error: /home/vagrant/src/guix-workspace/gnu/packages/package-management.scm:560:4: package `diffosco <vagrantc>pe@122' has an invalid input: ("zip" #<procedure zip (clist1 . rest)>) <rekado_>you would need to disambiguate between “zip” (the package), “zip” (the procedure from srfi-1), and “zip” (the license from (guix licenses)) <vagrantc>rekado_: i figured something along those lines ... <Minall>rekado_: Then, how should I see if there's a problem with the device? <enderby>hi, i'm trying to use next (browser), and I keep getting "No server addresses left to try to open." Anyone else experiencing the same? <rekado_>I can’t reproduce this with an up-to-date Guix <civodul>now we need paren matching but i don't know how to do that <Ronie>o/ hi! I just installed the Guix System on my laptop, but the wifi is not working. The crazy thing is that, during the installation it worked perfectly, but once I booted it, puff... no internet. Anyone could help me, please? <Ronie>Also, "rfkill list all" shows Hard and Soft on <quiliro>Ronie: how are you trying to connect? <Ronie>I'm just trying to ping gnu.org. No luck. Also, I got no IP <Ronie>It's a Qualcohh Atheros 9k. It seems to have no problems with free software (I assumed that because I was able to install Guix using it, too) <Ronie>I have this line in the logs that is puzzling me (maybe it's related to the problem): ': NetworkManager: <info> device (wlp2s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') <Ronie>And later: NeworkManager: <info> device (wlp2s0): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed') <quiliro>Ronie: is it an external usb device? <Ronie>Sorry, quiliro! Thx for the help, but I need to go :) <quiliro>Ronie: did you search the web for errors? <zacts>ok, I'm going to try installing guix system *apteryx tihs reminds me of someone... <apteryx>efraim: Do you think the NTP patches are good for master? <rekado>FWIW I think it’s fine to have /usr/bin/env by default. <rekado>it’s not like it can’t be easily removed, and it doesn’t have an effect on the build environment anyway. <janneke>yeah, if only we had someone great at de-escalating <rekado>and it has the great advantage of making scripts less awkward to run. <rekado>the escalation has been rather unnecessary. <rekado>we reserve reverts for serious breakage and honest mistakes <rekado>they are not the right tool for disagreements. <rekado>I have to leave now, but I’ll write to the list about this later today. *nckx sucks at de-escalating. *janneke often admires civudul there <janneke>fwiw, i have feelings for both sides of the /usr/bin/env choice <nckx>Agreed. Quite a few others here too (rekado, lfam, … not to turn this into a love-fest but I could sure use one after this morning). We're lucky that way. <nckx>janneke: Oh, so do I, it's the inconsistency (keeping /bin/sh) that gets me 😛 <janneke>nckx: i have thought of arguing /bin/sh -> /bin/guile <nckx>I unironically support that if we have */bin/anything. <janneke>i'm using /usr/bin/env on my machines *but* i'm pretty worried about bootstrappability/reproducibility and i'm happy that mark_weaver is taking that very seriously too <nckx>janneke: Could you explain how one affects the other? This is not at all clear to me, and I'm disappointed that the amount of mail that has been produced today hasn't changed that. <janneke>nckx: no i cannot and i suspect therein lies the problem <janneke>i think i'm afraid of a slippery slope <nckx>I know you're not implying otherwise, but I'm just as concerned about both. <janneke>/bin/sh is OK for throwaway scripts, is OK for all my scripts, /usr/bin/env xx, yy, zz <nckx>I can understand that. I have the similar gut feelings about things like flat paks and app images. <janneke>the end of the slope goes like this: if we "don't care" what intepreter we run, why do we have the store at all, just use /usr/bin/* because bash == bash <nckx>Next to those, scripts sound positively innocent. <nckx>janneke: Well, that brings us to ‘why have $PATH’ at all, no? <janneke>so in this light i would welcome a thoughtfull discussiong, maybe i am just seeing ghosts? <janneke>...and i would very much like a good/friendly solution for what /usr/bin/env tries to solve <nckx>I'd honestly rather remove /bin/sh by default, I thought that would be too controversial. If I'd know what would happen I would have submitted *that*; at least the drama would have been more worth it :o) <janneke>yeah, well i hope that the drama is somehow a reflection of how much we care about doing the right thing <nckx>As it is, I'm constantly (yes, frequently) advising people to ‘use /bin/sh, not /usr/bin/env sh, on Guix System’ and that does not leave me feeling clean & happy. <nckx>janneke: Of course. And that's exactly the reason most of us are here. <rekahsoft>Hi all, I have a series of patches that I have been preparing for guix (all package additions) while I work from switching over from Archlinux to GuixSD. In my travels I have packaged podman, buildah, and their required dependencies. I am now down to an issue with rootless podman where OCI containers can be run in usernamespaces (without root privs). Currently, assuming the image was pulled by root, this works. Howe <rekahsoft>ver when pulling as a user I receive an error http://ix.io/1Uvl. I thought maybe it was because kernel.unprivileged_userns_clone was disabled, however when I went to inspect its value with sysctl, to my surprise the unprivileged_userns_clone file dne in /proc/sys/kernel/. Any ideas here? <rekahsoft>Also I was wondering how best to deal with package configuration. What is the best way to provide some default configuration for a package (say a few files in /etc/), but also allow users to override this configuration? <apteryx>nckx:If think the argument to not have /usr/bin/env is that it breaks software that might depend on it, which is good for Guix in supporting the "everything should be explicitely defined" philosophy. <rekado>the reason why /bin/sh exists is because POSIX specifies it. <rekado>apteryx: I’m not convinced that this reason is good enough to ban it. We don’t have /bin/sh or /usr/bin/env in the build environment. <rekado>Software behaviour is also affected by the presence of /usr, /lib, /bin, etc, and these can all exist at runtime. <rekado>(as is the case when Guix is used on a foreign distro) <rekado>we don’t quarantine contributions from people who use Guix on a foreign distro <rekado>instead we assume that building in an isolated environment is usually sufficient <rekado>and yet we sometimes find that applications behave differently when run inside of containers <rekado>(e.g. applications that call out to coreutils that are usually available in a normal system) <rekado>with the same justification we could campaign against having coreutils on PATH, so I think this reason on its own isn’t sufficient. <rekado>(this isn’t a far fetched example, by the way. R does this and we found out only when we ran it in a container without coreutils.) <rekado>mbakke: would it be fine if I pushed an upgrade of openblas to core-updates? <olivuser>Hej. Which packages do i need to install for audio/video playback on popular platforms like yt/soundcloud/vimeo to be possible? <rekado>olivuser: if you’re using epiphany you’ll probably need gstreamer plugins, such as gst-plugins-good. <janneke>uh, we have no guile substitute for armhf-linux? <rekado>what does ci.guix.gnu.org say about this? <janneke>core-updates says failed dependencies <rekado>fixing the failed dependency info is on my list <rekado>this broke after changes to how derivation inputs are handled <janneke>i wonder on what commit the arm people live, atm :) <mbakke>rekado: core-updates is really frozen right now, perhaps it could go through 'staging' if it's urgent <rekado>is core-updates-next free for commits, though? <mbakke>rekado: I'll include it in the next staging round anyway, but waiting for core-updates first. <nckx>rekado: Interesting point about POSIX. I guess that's the first sane (well… if you consider POSIX either relevant or sane) /bin/sh-over-/usr/bin/env argument I've heard, thanks. <nckx>If c-u-*next* can be frozen too, something is probably very wrong. <bandali>hi people, can anyone help me fix my emacs master package definition? <nckx>bandali: What's the error? <bandali>nckx, i don’t have it handy this second, sorry. would you be able to try adding it as a channel yourself? i think you should get the error when you do guix pull afterwards <nckx>Seems like you need an explicit (name "...") field. <bandali>let me go try. i *think* i’d tried that and it wasn’t it <nckx>It might not be ‘it’, but I have it internalised as a rule (which I never checked), so it might be ‘a’ problem. <bandali>i see :) i’m doing a guix pull to get the error <nckx>Hm. Considering you explicitly use ‘name’ later I think it will cause problems. <nckx>bandali: Yeah, it needs a name. <nckx>Now it's fetching (slowly)… <nckx>‘Failed to do a shallow fetch; retrying a full fetch..’ — proceeds to do nothing, silently… <bandali>what name should i give? can it be emacs again? <bandali>(i’m trying to override guix’s emacs and consequently emacs-minimal to use emacs master) <nckx>bandali: It can certainly be emacs, Guix doesn't care. ‘guix install’ and friends will auto-choose the latest version (so, yours). You might prefer ‘emacs-git’ for clarity but neither is better. <bandali>nckx, aha. will my package still override guix’s “emacs” if i choose (name “emacs-git”) ? <nckx>bandali: Depends on what you mean by override, but ’less so’. If you want ‘guix install emacs’ to install your version, use ‘emacs’, if you don't want that (maybe because it's too experimental), don't. It's your choice. Remember that there's also a difference between variable name and package name… <nckx>…git is using 397% CPU now OK bud… <bandali>yeah the emacs repo is pretty brutal to clone <nckx>bandali: Was the above even a bit clear? I'm sneaking in IRC when I should be social IRL… <rekado>bandali: to override a package you can’t just write a new one and give it the same name. <rekado>bandali: package dependencies are established through identifiers <bandali>nckx, re package name: right; yeah i guess i’m having a bit of a hard time deciding what would be best: do i want people to automatically get emacs 27 when they use my channel and ‘guix install emacs’, or can i give them a choice? <rekado>so we have the “emacs” variable, which is bound to a variant of an Emacs package object. <nckx>Thankly rekado explains the good. (y) <rekado>when the package name is “emacs” and someone runs “guix install emacs” they’ll get the latest version <rekado>whichever enabled channel provides it. <nckx>bandali: r:sha256 hash mismatch for /gnu/store/dsr7l0rsn9a54g0x7prkz4b3b1z69mbx-emacsx-27-0.7803e65-checkout: expected hash: 0xswsikl8ks757p4jps16ns28ygicn7pbwqn94papyv5fp0ibc2j, actual hash: 19l0ydx7y0x38vf0pn34rhl9himn71irl39nxqd2zk6fhwpbqx0h <bandali>rekado, i’m striving for a clean way to enable a user of my guix-bandali channel to use emacs 27, including for emacs-minimal which is in charge of building emac spackages <rekado>if they want an older emacs they can do “guix install emacs@26” <rekado>that’s just the user interface, though <rekado>if you want to change the emacs package that’s used for building emacs packages that’s a whole different thing <nckx>bandali: Grepping the manual for ‘input rewriting’ (I think) should interest you. <rekado>the machanism we offer for that is less obvious – it’s input rewriting <bandali>yeah, i mean i wouldn’t want someone using emacs 27 through my channel to use packages built by emacs-minimal 26 <rekado>and it cannot be forced by installing a channel. <rekado>you can, however, offer variants of all emacs packages in your channel <rekado>automatically generated via input rewriting. <bandali>i wish there were an example of this :( i’m still a guix noob <nckx>bandali: This isn't considered nooby stuff, so don't feel bad about that. <rekado>the manual has a simple example under the definition of package-input-rewriting <rekado>(section 6.2, defining packages) <rekado>I don’t know if input rewriting actually works for build system packages <rekado>I vaguely remember that this wasn’t all that easy. <bandali>am i trying to push guix to its limit here? :p <rekado>you may be able to do without input rewriting and instead write a procedure that takes an Emacs package and modifies the #:emacs build system argument <rekado>(define (package-with-my-emacs pkg my-emacs) (package (inherit pkg) (arguments (substitute-keyword-arguments (package-arguments pkg) ((#:emacs _ #f) my-emacs))))) <rekado>then you can do (define emacs-magit-with-emacs-27 (package-with-my-emacs emacs-magit my/emacs-27)) <bandali>aha i see! that sounds like a more reasonable approach, perhaps <rekado>input rewriting is similar: (package-input-rewriting `((,emacs-minimal . ,my-emacs-minimal))) <bandali>i wonder if there’s an automatic way of doing this for all emacs-xyz packages <rekado>that’s a procedure that would replace “emacs-minimal” with “my-emacs-minimal” recursively throughout the dependency graph. <nckx>Some build systems take relevant optional arguments (linux-module-build-system takes a #:linux keyword, for example), but it needs to be explicitly supported and I don't know if the emacs one does so. <nckx>*If* so, you can ‘rewrite’ that too, even automatically, but it does start to get complicated. <rekado>also note that the “package-with-my-emacs” above doesn’t change packages recursively. It only changes the given package. <rekado>IIRC it’s a missing feature in input rewriting to work on build system inputs. <rekado>we do have a similar case with python->python2 <bandali>yeah this sounds like it would be very useful to have <rekado>more generally we have “package-mapping”, which takes a procedure and a cut predicate. <rekado>you could use that to make arbitrary changes in the depended packages and stop whenever you hit something that’s not an emacs package. <rekado>there’s no example for that in the manual, unfortunately. <rekado>the implementation would be a little verbose, I’m afraid. Not a one-liner. <nckx>This was something that Nix made very easy (it was expensive to evaluate, and I'm sure the implementation wasn't pretty, but it *worked*): there was a function you could call that was as simple as ‘with pkgs = f(pkgs, mypkgs)’ and boom, every package on your system is rewired to point to your custom packages. I've long since forgotten the name, but used its awesome powers often. <nckx>I'm sure Guix can do this, and probably ‘better’, but it's not a handly library function. <reepca>I'd like to note that there are edge cases where the existence of /bin/sh does affect the result of builds - for example, if you're trying to test building packages in test-env (where --disable-chroot is the default), building the bootstrap gcc produces different results depending on whether /bin/sh exists or not. <rekado>yes, “--disable-chroot” is the worst case. <rekado> /bin/sh exists on POSIX systems; it just doesn’t exist in our build container. <rekado>nckx: I think package-mapping comes close. <rekado>it’s unfortunate that we have this distinction between build system arguments and inputs. <rekado>this makes the whole undertaking a bit more awkward <nckx>bandali: After replacing the hash with the one above, I get: http://paste.debian.net/1099425/. Without reading it in detail, it looks more like your simple inherited package is missing the extra inputs needed to bootstrap from git, than any error in your expression. *nckx will reiterate one more time that they're not ‘pro-/bin/sh’ at all, just to be clear 🙂 <reepca>one of gcc's build system shell scripts generates new scripts and then immediately runs them as a means of implementing recursion (yikes!). The point to take away is that there are definitely cases that no sane shebang-patching process could anticipate. <bandali>cool, thanks nckx! i guess being able to build emacs 27 using guix would already be a nice first step towards moving my emacs uses from debian to guix <nckx>So it was ‘packageOverrides = super: let self = super.pkgs; in {}’, not quite as simple as I thought and I'm sure it has plenty of warts that have faded from my memory, but it was still a very empowering thing to learn about. <nckx>reepca: I guess I just find it… extremely hard to be moved by that example? I don't doubt that /bin/sh will affect builds (build systems will sniff *anything* if you let them, like badly trained dogs), but this to me is just outside of Guix's scope. The same is true of /etc. Of *everything*, really. Crippling user systems to catch packaging bugs, as I noted on the ML, just don't sit right with me. <rekado>the only way to be really sure that a package doesn’t depend on user state at runtime is to run it in a container. <rekado>we do that at build time already <nckx>If the sandbox is so broken that all the dogs escape and start scratching up the furniture, we can't hide behind ‘well you shouldn't have dared put chairs in your house, you impure lazybum.’ <nckx>(Sorry, I couldn't resist. But it is the sentiment of my argument, I think.) <rekado>as I wrote, R suffered from that very same problem: it depended on gzip and a bunch of coreutils, and we couldn’t see this until we started building Docker images containing R but not gzip or coreutil.s <rekado>so this is not an argument for or against /bin/sh or /usr/bin/env, but it’s about whether we use containers or not. <nckx>At least we have that one sticky chair from the eighties that some standard cares about. Never mind that bash isn't really POSIX-compliant, even when it tries to be 😛 *nckx goes a-socialising; g'night o/ <vagrantc>with Guix System, is it normal to have guix-daemon called with a very long list of --chroot-directory arguments? <vagrantc>i've seen this happen on a couple of different systems <rekado>vagrantc: yes, but only if you have enabled the qemu binfmt services <leungbk>efraim: I've sent an updated version of the crate-recursive-importer to you. 