<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 <OriansJ>eubarbosa: There are more hardware security vulnerabilities that never hit the news than you can dare imagine <eubarbosa>I guess so. We only got know about SPECTRE because RedHat took corage to say so <OriansJ>Current State of Michigan Security Vulnerability list for 2018 alone is 381 unpatched hardware vulnerabilities for Intel Processors. Of which 80+ are remotely executable <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 <OriansJ>or more precisely, in any cloud offering <OriansJ>just assume it can easily be read/altered unless you have strong crypto limiting the things you wish to prevent <civodul>there's 70% of substitutes for x86_64, which is "rather good" <serichsen>Is someone looking into btrfs subvolume support in the generation of grub configuration files? I have some ideas, but no experience with guile/scheme/guix. <civodul>rekado: looks like we lack Rust though <eubarbosa>" This report is inaccurate and unfounded." lol <OriansJ>however should one spend about $17K, they too can discover what the private key to that public key is and well; it certainly does some really interesting things on old Windows systems <eubarbosa>I think its madness spending so much money in system one does not know what its do behind curtains <OriansJ>eubarbosa: there is a reason why it is called the greatest scam of all time <dongcarl>Hey all, any way for me to drop into a shell/environment in the middle of a build step in guix? <dongcarl>I want to check out the situation _in_ a build step <dongcarl>Just found `-K`, you guys really have thought of everything... <OriansJ>dongcarl: no but we do actively try to make our own lives easier and make our work enjoyable <tavoris>is there a way to build a profile based on the manifest in another user's profile? <dongcarl>Any way to set `$SHELL` to the proper `sh` path in a package? <dongcarl>One of the configure scripts seems to just want to read from the environment <dongcarl>actually it does this: `SHELL=${CONFIG_SHELL-/bin/sh}` <dongcarl>but I don't think the auto patch scripts picked that up <eubarbosa>OriansJ: Well, I guess it was rather amusing what shitty excuse to explain that! lol <OriansJ>eubarbosa: not as good as the ones I have seen from people denying gravity and diffusion <OriansJ>cup of salt water + cup of fresh water => boom proof and still they scream that the salt water doesn't mix with the fresh and threaten to kill you for questioning them. <eubarbosa>whoever says that is in a level beyond my humble mind logic to differ on that conclusion <dongcarl>Is the appropriate way to override which targets `make` tries to build setting `make-flags` or overriding the `build` phase? <terpri>dongcarl, yes, overriding the phase is best for changing targets <terpri>because gnu-build-system applies the make-flags option to all invocations of make ('make check', 'make install', etc.) ***daviid is now known as Guest97511
***Guest97511 is now known as daviid
<dongcarl>Any way to get the output of a shell command? <dongcarl>I know you can do invoke, but that doesn't give me the output <apteryx>dongcarl: by "getting" the output, do you mean caputer? <apteryx>capturing the output of the "diff" command <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 waits patiently <efraim>TIL python configure-flags are applied to the 'install phase only <g_bor>I've seen OriansJ talk about getting jdk11 in. <g_bor>I have a working package, all unbundled, but not reproducible. <g_bor>If you wish I can push it as is, and continue working on reprodubility on master. ***rekado_ is now known as rekado
<rekado>g_bor: sounds good. Please submit the patch to guix-patches and send a bug report with the current status description to bug-guix. <g_bor>I will need a bit of time, I have a few lint errors because of too long lines. <g_bor>I can also attach a small howto, as the differences are not so easy to analyse, diffoscope misses some filters that would be useful for java 9+ <nly>If a package requires 'gnupg at runtime then should 'gnupg be 'native-input or 'propagated-input? <cbaines>it could be either a propagated-input, or an input, depending on if it needs to be included in the environment when the package is in the environment <cbaines>if it doesn't need to be in the environment, it can just be a input <cbaines>(not a great explaination, but hopefully that makes some sense) <nly>thanks, then i think package 'shroud needs to be updated, as it basically calls 'gnupg from the (system ...) calls <nly>should i send a patch? <pkill9>nly: if it calls `gpg` then it would typically be wrapped to provide it in the path <pkill9>although gpg itself calls gpg-agent if gpg-agent isn't running, so might need that too ,but idk <pkill9>how do i remove a service from the %desktop-services list? <pkill9>I want to replace the service 'slim-service-type' with sddm <efraim>python-click@7.0 and python-flask@1.0.2 sources I had to download from swh <g_bor>how do I delete current-guix generations? <g_bor>ok, I thought we have a profile that I can use with guix package --delete-generations... <pkill9>does sddm not work for anyone else? <pkill9>the default one in %desktop-services is NetworkManager <pkill9>other than that, I odn't think it has a default network manager <pkill9>in the installation image, you have to put up the network device, run dhclient, etc from the command line <dongcarl>I was wondering what the rationale is for removing `/bin/sh` from the build containers rather than just symlinking it to (which "sh")? <pkill9>dongcarl: it's not that the /bin/sh synlink removed from the containers, rather it's added to the system <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? <dongcarl>It seems that there's a lot of shebang patching that's done for gnu-build-system packages just to get around this *dongcarl waits patiently <pkill9>well, the /bin/sh symlink is created by a service specified in your system configuration, which is added by default in %base-services <efraim>There was a time it wasn't there <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>pkill9: We would avoid a lot of the shebang patching, and even some packages manually (substitute* /bin/sh (which “sh”) files...) <dongcarl>cbaines: I see!!! That makes it very clear. <Copenhagen_Bram>efraim: how do you replace network manager with connman in the config file/ <OriansJ>Copenhagen_Bram: only if we get more people improving the documentation and translating it to more languages <Copenhagen_Bram>not to mention more packages. Is there an esperanto translation yet? i plan to learn experanto eventually <Copenhagen_Bram>why does it say I'm missing an use-module when I try to add sbcl-stumpwm-with-slynk and I put lisp in use-package-modules? <lovelyn>Copenhagen_Bram: the variable is named sbcl-stumpwm+slynk <lovelyn>looks like that's deprecated in favour of just stumpwm+slynk, though <Copenhagen_Bram>is it safe to run `guix pull` on the live Guixsd before installing GuixSD? <dongcarl>How do I get a `guix environment` with `/usr/bin/env` available? <civodul>Copenhagen_Bram: it is, but you might end up getting fewer substitutes (pre-built binaries) <Copenhagen_Bram>lmao i'm actually running with --no-substitutes so everything is compiled :) <dongcarl>Is it possible to use a manifest environment for a package? <cbaines>dongcarl, what do you mean by "use" in this context? <dongcarl>cbaines: I mean I define a manifest as a build environment, then refer to that manifest in my package declaration so that it populates my native-inputs <cbaines>dongcarl, what's your use case? Are you trying to share the description of dependencies and a development environment? <dongcarl>cbaines: Yes. What I've been doing so far is just to declare everything in a package and tell `guix environment` to build an environment for that package <dongcarl>cbaines: Just wondering if the same can be done for manifests <cbaines>dongcarl, I'm not sure actually. I haven't used manifests. If they're evaluated though, anything should be possible... <terpri>dongcarl, for /usr/bin/env, use guix environment -C --expose=`which env`=/usr/bin/env ... *dongcarl considering running guixsd in a container or sth <OriansJ>as in guixsd can be configured to run as an empty container with only guix installed <OriansJ>kinda like guix environment --container <OriansJ>toss in --pure and clear out environmental variables from contaiminating your build <dongcarl>OriansJ: Are you saying `guix environment --container --pure` is almost a GuixSD? <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 ... <g_bor>Copenhagen_Bram: its part of bootstrap binaries, a statically linked coreutils, tar, and some other tools to bootstrap the gnu-build-system <ArneBab>OriansJ: that is actually something which breaks many of my scripts, because the canonical advice for python is to use #!/usr/bin/env python <ArneBab>I wish providing /usr/bin/env were standard in Guix … <ArneBab>is there some rationale why it is not? <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)) <OriansJ>ArneBab: probably -> (mcron-service-type (list cpupower-powersave-job)) <ArneBab>OriansJ: on sudo guix system reconfigure /etc/config.scm I get "filesystem is read-only" <ArneBab>(when trying to create /usr/bin/env) <ArneBab>with mcron-service-type I get /etc/config.scm:83:18: Wrong type to apply: #<service-type mcron 2ab5c30> <OriansJ>ArneBab: it looks like efraim's example might help <efraim>I define the actual jobs near the top of my config <efraim>(sorry, i'm working on my presentation for tomorrow, so I'm mostly not here) <ArneBab>OriansJ: ah, yes, that helped. THank you! <Misha_B>is there a way to disable all display managers and just run x using startx ? <OriansJ>Misha_B: easily, don't include (service slim-service-type) or any other display managers in your config <pkill9>Misha_B: also get the startx package from xinit, but the script is broken because it hardcodes a path to X that doesn't exist (<xinit package>/bin/X instead of <xorg-server package>/bin/X) <pkill9>i been meaning to submit a fix for that <pkill9>I'm curious how others use that though, maybe I'm using it wrong <g_bor>I created a detailed list of the content, available on the bootstrappable.org site, and you can also have a look at gnu/packages/make-bootstrap.scm <dongcarl>But it seems like I can't invoke make in it? <dongcarl>That seems odd to me as I don't see a separate `make` package <pkill9>dongcarl: there is a separate 'make' package <terpri>it's called gnu-make in scheme, in (gnu packages base) <dongcarl>(want to know so I can better find packages in the future) <kmicu>pkill9: there is ‘[HOWTO] Start X server manually instead of using a login manager’ on the mailing list. <g_bor>dongcarl: you can use guix package -s to search for packages, it is a quite powerful search facility. <OriansJ>(so we either can fix the documentation to help people deal with the problem or just fix the package) <pkill9>dongcarl: also you can write a manifest in such a way that you don't need to refer to the scheme variable itself <g_bor>if you want to see the scheme name, once you have the package name, you can use for example guix edit packagename, which opens an editor right at the definition. <pkill9>and don't need to import modules <kmicu>pkill9: guix user hence the mailing list xD <pkill9>ok, i was looking in guix-devel :P <dongcarl>pkill9: you mean using `specifications->manifest`? <kmicu>pkill9: There is also a thread on xorg-devel to not use startx/xinit anymore but it’s free software so you still can ;) <pkill9>dongcarl: i think so, i think there's an example in the manual <pkill9>kmicu: do you know where the guix-user mailing list archive is? <g_bor>dongcarl: yes, you can use specifications->manifest, and then you only need the package name <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 <g_bor>OriansJ: I am currently preparing my jdk11 package for inclusion. ***renich_ is now known as renich
<g_bor>It would need some more help in reproducibility, but it's in a good shape ***samis is now known as CompanionCube
<dongcarl>does anyone know how I could find out what to include in a manifest to replicate the gnu build system in guix more or less? <dongcarl>I know that there must be a nice command to do it in guix <g_bor>dongcarl: what exactly are you trying to do? *g_bor keep forgetting exclude-directory-metadata on diffoscope command line <g_bor>I will have a quick look around, but I would look for %gnu-build-system-modules first... <dongcarl>It also seems that when I use `specifications->manifest` I can't seem to specify `gnu-make` <g_bor>yes, that's because the package name is make. <dongcarl>package name is different from scheme variable, got it! <g_bor>dongcarl: it seems to me that you are looking for the procedure standard-packages in module (guix build-system gnu) <dongcarl>g_bor: What would I do to call that procedure from the command line and get the list? <rekado>dongcarl: do you need it on the command line or just in a manifest? <dongcarl>rekado: Both haha, I'd like to know what's in it... And add it in a manifest :-) <rekado>In a manifest you can just use the variable %final-inputs from (gnu packages commencement). <dongcarl>and in the command line I could just use the repl? <rekado>on the command line you can’t really do anything with it, because it’s not a package but a list. <rekado>yes, you can use the REPL, or you can look at the file gnu/packages/commencement.scm *dongcarl promises he's learning... slowly but surely ***renich_ is now known as renich
<cbaines>rekado, thanks for your quick and thorough review of those rubygem patches! <rekado>I re-subscribed to guix-patches and guix-commits again after I had been unsubscribed a while ago, and it lowered my barriers to patch review. <tavoris>when starting tmux I get "tmux: invalid LC_ALL, LC_CTYPE or LANG" anyone know what I'm missing? <rekado>tavoris: you need to set GUIX_LOCPATH and install glibc-locales <tavoris>rekado: I'm pretty sure I have those ^^' <rekado>then maybe LC_ALL, LC_CTYPE or LANG are invalid ;) <tavoris>rekado: it's possible I've tried setting them to various things even unsetting them. can't seem to get it right. if you use tmux, could you show me what you have them set to? <rekado>you probably shouldn’t set them at all. <ngz>Hello. I installed Kodi, but it is not able to connect to add-on repository. Has anyone else noticed it? I mean: is it specific to Guix? <bavier>ngz: I haven't noticed, but I also haven't tried using add-ons with Guix's Kodi package <ngz>Well, every time I try to "Install from repository", it says it cannot connect to it. <kmicu>ngz: Does that repo url work in a browser? Did you test on a different Kodi setup besides that one from Guix? <ngz>I activated debug log, it looks like a hash mismatch. So the server responds, but something else fails. I didn't try another Kodi setup. <kmicu>Let’s wait for some Guix/Kodi then. I only have Kodi on a LibreELEC box. <civodul>progress bars for on-going builds, yay! <civodul>EternalZenith: at least it's not in Guix proper <EternalZenith>Yeah, I was just wondering if anyone had packaged it but not submitted it <tavoris>EternalZenith: looks like it just uses make to me <EternalZenith>The PKGBUILD from the AUR looks a bit intimidating considering the instructions on github are literally just "run gui.sh" <tavoris>EternalZenith: are the dependencies all satisfied, do you know? <EternalZenith>On an unrelated note: has anyone gotten flatpak working? It segfaults whenever I try to add a repository