<OriansJ>and the Hardware people are just as bad; Seriously you spend Billions on verification Intel and somehow you allow 17bytes of standard byte opcodes result in a hardware privildge escalation attack that you can't figure out how to fix in less than 22 months
<rekado>civodul: …with your commit I suppose staging is ready to be merged?
<OriansJ>I am embargoed from listing the number of escalation attacks that are still open with Intel but lets just say there is good reason not to put anything you depend upon in any Virtualized cloud offering
<dongcarl>Thing I've been wondering for a while: Is it possible to do `guix environment` for a package but be placed in a folder containing the (native)inputs for a package. Much like the environment would be if I did `build --keep-failed` and `guix container`d into that
<dongcarl>pkill9: What I mean is that when I write a package declaration, and `guix build`, `/bin/sh` isn't there... But when I do `guix environment`, it is there. Now assuming that `guix environment` adds the symlink like you say it does, why not do it for `guix build` as well?
<efraim>We thought about also adding /usr/bin/env but decided not to
<pkill9>so basically the symlink exists because it's put in your system configuration, and the build environment for packages isn't dependent on anyone's system configuration
<dongcarl>but isn't having `/bin/sh` standard? What kind of system configuration wouldn't have `/bin/sh`?
<pkill9>well, technically bash itself is an input, so changing the shebang makes sense as it means the package will always point to that particular version of bash
<pkill9>if it just pointed to /bin/sh, the same package could be running different versions of bash
<pkill9>or differently-compiled kind of bash, or another shell altogether
<pkill9>with regards to the container still containing /bin/sh, that's either there for some kinda convenience, or it's a bug, but i dunno
<cbaines>dongcarl, systems not having /bin/sh isn't much of a concern. Systems not having exactly the same /bin/sh is the problem.
<cbaines>It should be possible to build Guix packages that don't change in behaviour when used on different systems, even if /bin/sh is different on these systems. Not having /bin/sh in the build environnment is helpful with this.
<dongcarl>Thanks for being patient with me. I’m still not sure what this has to do with the “system”. Because build and environment are run in containers, the “system” shouldn’t matter right? Or am I understanding the definition of “system” wrong?
<pkill9>i think you're understanding 'system' right, and yeah the 'system' shouldn't matter in the container (definitely in the build container, the one created in `guix environment --container` i would also assume should match the build container), but i dunno why the symlink is left in the container created in `guix environment --container`
<pkill9>civodul or rekado might know if there's a reason behind it
<dongcarl>What I’m advocating for is to have the symlink in both, and I think I’m failing to understand how there would be “different versions of sh”
<pkill9>what would be the benefit of having the symlink in both?
<cbaines>dongcarl, so I'm using system in terms of things like a computer running Ubuntu, or a LXC container build with Fedora, just what software is present.
<cbaines>Say /bin/sh was in the build environment, parts of packages could use it, depend on it being there. You might then go run some Guix packages on Ubuntu, and they work differently or break! This could be because Guix sets /bin/sh to bash, but on Ubuntu, I believe it's dash.
<cbaines>Now you could say that depending on bash like features from /bin/sh is asking for trouble, but I think it's better to avoid the problem by trying to make the dependency more explicit, and referencing something directly in the store instead.
<dongcarl>Does anyone know if `guix environment` can be used as a shebang for executing commands inside the container?
***daviid is now known as Guest52395
***Guest52395 is now known as daviid
<OriansJ>dongcarl: not entirely required as the build on guixsd is the same as the chrooted builds with guix
<terpri>in guix, #!/bin/sh is basically the only shebang line that is guaranteed to work in all contexts
<OriansJ>terpri: or if you add (service special-files-service-type `(("/usr/bin/env" ,(file-append (canonical-package coreutils) "/bin/env")))) to your list of services, it will work with the #!/usr/bin/env ...
<OriansJ>ArneBab: honestly I don't know but if you look at my example config above you'll see it is trivial to add but only civodul knows why it isn't standard
<ArneBab>OriansJ: I had tried to add it but failed — thank you for your config!
<OriansJ>no problem; I probably have the most exotic config here (I strip out everything not required)
<OriansJ>although I have to update it nearly every release because something always breaks but I perfer having as small and clean as possible. Once curl and wget get into the guix install image, I'll be pruning the setup again.
<ArneBab>I currently most of all need a working home office and freenet development setup, and I deeply miss my KDE …
<OriansJ>dongcarl: just a minor fyi you probably want to lower the rounds for the luks container unless you really like waiting
<ArneBab>besides: what do I do about this? /etc/config.scm:83:18: warning: 'mcron-service' is deprecated, use 'mcron-service-type' instead
<ArneBab>it is clear what it wants me to do, but I don’t see how I can realize it
<ArneBab>I have the service: (mcron-service (list cpupower-powersave-job))
<g_bor>there was also a discussion on the ml regarding channel name conflict resolution, and the current recommendation seem to be to namespace the packages in the channel, so there is no naming conflict.
<kmicu>pkill9: no idea, I subed via Newsgroups: gmane.comp.gnu.guix.user