<Ulrar>Isn't there a way in config.scm to tell that eth0 is dhcp ? The documentation seems to only mention a static-networking-service <Ulrar>Well it doesn't seem to like the static anyway <mark_weaver>Ulrar: surely that's the plan, but it's not done yet. <mark_weaver>you can define your own services right in config.scm, although of course services that are generally useful should find their way to guix upstream. <mark_weaver>I suppose we should think about how best to express the network configuration. <Ulrar>I would have though of something like (interface "eth0" #:static-ip "192.168.0.2" and so on <Ulrar>So you'd be able to replace static with dhcp or something <davexunit>sounds sort of like debian's networking service <Ulrar>Yeah, that might be because I'm kinda used to those <mark_weaver>civodul probably has some thoughts on this, and knowledge of what nixos does. <Ulrar>Gentoo has something similar too <mark_weaver>jxself: why did you revert linux-libre back to 3.16.1 ? <jxself>mark_weaver: I jumped the gun. I compiled 3.16.2 for my public repository using the deblob scripts and later on updated Guix, but I didn't think to check if lxo had actually pushed 3.16.2 tarballs yet. He has not. <jxself>So I reverted it to about breakage, since it'll 404 for now. :) <jxself>I was stupid. I will be more careful in the future. <mark_weaver>we might consider doing the deblobbing ourselves, using a snippet. <jxself>Maybe. Would that mean people not using substitutes would download the kernel from kernel.org though? Would mean they're downloading non-free software. <mark_weaver>true, but I thought it was decided that it was acceptable to remove non-free software in upstream code by way of snippets. <mark_weaver>so the result of "guix build -S" includes only free code <jxself>Hmm. Perhaps I didn't fully understand the nature of that solution then. But they also only fetch source and do nothing else right? <mark_weaver>the 'origin' derivation would fetch the upstream source, run the debblob script, apply any patchers, and then pack it back up. <mark_weaver>the source of the 'linux-libre' package is then the debblobbed source. <jxself>The deblob script is being run on the user's computer though when compiling from source right? That makes me uncomfortable. <jxself>If that's what was suggested when this was originally discussed, then I clearly didn't fully understand it... :( <mark_weaver>I think the idea is that we in the free world need these debblobbing mechanisms, and they are even automated on machines like gnewsense servers and lxo's machines. I think there is value in my being able to do that deblobbing on my own machine instead of relying on some other server to do it for me. <mark_weaver>there are also several other packages that include some non-free bits but for which there is no free variant available for download. <mark_weaver>so the question is, how do we handle those packages in guix? <mark_weaver>if you want to build the package from source but rely on hydra to build the deblobbed source, then you can do "guix build -S <package>; guix build <package> --no-substitutes" <mark_weaver>that's where civodul outlined the plan whereby non-free bits would be removed from source as part of the 'origin' forms, by adding the 'patches', and later 'snippet', fields <jxself>"I’ve come up with a plan that will allow Guix to behave similarly" <jxself>But if people are deblobbing the kernel on their own it wouldn't be similiar. <jxself>IMO, freedom-respecting distros don't have people download non-free software and then delete it. <jxself>Sam's message described what gNewSense did for example. <mark_weaver>people don't deblob on their own if they use substitutes, which is the default. <jxself>I thought people had to go & authorize hydra first? <mark_weaver>do you think it's bad to distribute deblobbing scripts to enable users to easily do the deblobbing themselves? if you think that's okay, why is it bad for guix to make it easy for users to do it? <mark_weaver>(btw, I'm not trying to be combative, and I respect your opinion. just trying to understand) <mark_weaver>jxself: if we were to implement what you seem to want, I guess it would involve essentially forcing substitutes to be enabled for some subset of package sources. <mark_weaver>would you also want us to remove the code that does the deblobbing from the guix repo, and instead keep that in a different repo that we'd use only for hydra? <jxself>For one there's a difference between what people do on their own and what the distro does. <jxself>And people still got the non-free stuff upfront. <mark_weaver>if hydra's key was installed by default, so that the fully free source would be downloaded from hydra by default with no special action needed by the user, would that be sufficient to address your concerns? <mark_weaver>I guess what I'd like to know is: how inconvenient do we have to make it for users to do the deblobbing themselves? is it okay to include the deblobbing recipes in the distributed guix? is it okay to publish them in another repo? should we keep those recipes private? <jxself>If enabling hyra by default meant that people get the already-deblobbed source code then I think so. <mark_weaver>jxself: well, one issue is that, like any part of the build process for our core software, deblobbing is a security-critical process. if we trust a single set of machines to do that job for everyone, and don't provide an easy way for people to independently verify them, then we are making ourselves vulnerable to hacks on those machines. <mark_weaver>guix promises to eventually make it easy for people to gain confidence in the builds by making it very easy for people to do all the build steps independently and then comparing them to the ones we distribute. <mark_weaver>I think it's important that deblobbing security critical software be included in the set of things that we encourage independent verification of <mark_weaver>I don't think that providing convenient automated recipes to deblobbing constitutes "directing" people to non-free software in any meaningful sense. <mark_weaver>I think that language is talking about things like the kernel reporting the name of a non-free firmware file, or web browsers suggesting installing some non-free software. those are things that actually encourage people to use non-free software. <jxself>Releases are cryptographically signed, just as with kernel.org. It really is just a drop-in replacement. Isn't the same issue presented by using kernel.org? People still have to trust it. <jxself>And if the tarball were downloaded from fsfla.org instead of kernel.org can't people still repeat the same process and still get that same independent verification? I don't understand why it would be necessary for someone to download the non-free software as a prerequisite in order to verify that they and hydra both have the same thing. <mark_weaver>regarding your first point, by that argument there is no advantage to independently verifying binary builds, because debian's binaries are cryptographically signed, and no matter what you always have to ultimately trust some source code you downloaded. <mark_weaver>there is a chain that you must trust every link of here. <mark_weaver>there is a great benefit to starting from as early on that chain as you can, and encouraging independent verification of as many of the build steps as you can. <mark_weaver>jxself: I don't understand your second message. how can someone independently verify the linux-libre deblobbing process without downloading the upstream linux? <mark_weaver>jxself: what do you suggest we do about gmsh, for example. the upstream tarball of gmsh contains non-free software. currently, we remove that in our snippet, which means that if users build gmsh without substitutes, they will download the non-free software and then immediately delete the non-free code. <jxself>No, that wasn't what I was saying about crypgraphic signatures. Rather, it's one more data point for verification because at present it's computationally infeasible for an adversary to both modify the tarball and still have the signature match. If a project provides GPG signatures, are these checked? Seems like it's a good policy to do so if it's not done currently. <jxself>The idea was that if 600 people are downloading linux-libre-3.16.2-gnu.tar.xz and all going through the same build recipe and all end up with the same results, isn't it likely that they're all in possession of the same stuff? <jxself>Or change 600 to whatever other number you want. :) <jxself>And moreover they also see they're getting the same results as the distro. <mark_weaver>if all of those people who independently check start with the output of lxo's deblobbing process, then there is no independent verification of that deblobbing process. his cryptographic signature does only so much. if someone else manages to steal his private key (reasonably likely), or compromises the machine that runs the deblob script, then we are vulnerable to that. <jxself>We're vulerable to kernel.org being compromised, which has happened before. <mark_weaver>that's true, independently verifying build steps does not solve all security problems, only some of them. <jxself>And it's not as if his deblobbing process is a secret black box. The scripts are available to the public. My only objection is that distros shouldn't be having people download non-free software. It just seems wrong. :) <jxself>And I apply the same standard to gmsh. It seems that I didn't fully understand what civodul was proposing when he proposed it. <jxself>I think most if not all of the FSF-endorsed distros have hosted their own source code, which means they're in a position to be able to modify it and then host their own modified versions. <jxself>Trisquel uses helpers for example so that the source taken from Ubuntu is modified in an automated way. Then their tarball is hosted on their machine, and no one downloads non-free stuff. <jxself>And people using the distro don't need to use the helpers. They do the usual apt-get source foo and it grabs Trisquel's modified version. <mark_weaver>and "guix build -S", like "apt-get source", also results in our modified version, and the intended default behavior is to download that from hydra. but it seems that we are going around in circles, so maybe I should let you talk to civodul about your concerns and see what comes of it. <jxself>Yeah, we do and I'm not the one to make the decision anyway. Whatever method gets used is ultimately decided by the FSF as to its appropriateness for endorsement. <jxself>Oh, a thought of one difference I had during dinner: In the case of Trisquel I can manually go to the place they told me of (their repository) and the tarball I get is still free software. In this other case with Guix if I go there manually and grab that same tarball I end up with non-free software. <mark_weaver>suppose we do as you suggest. suppose we arrange to have our own server provide 100% free source tarballs of all packages whose upstream source contains non-free software. <mark_weaver>the natural way for us to implement this would be to make package recipes that automatically create our freed versions based on the upstream ones. <jxself>I imagine ftp.gnu.org or some such place would be a natural place for the modified sources to live, but I don't suppose it has to be. <mark_weaver>i.e. to use precisely the derivations created from an 'origin' declaration that includes a deblobbing snippet. <mark_weaver>so essentially, the proposal would be to blacklist those deblobbing recipes, to make sure that users won't run them inadvertently. <mark_weaver>perhaps move them to a separate repo, or keep them private. but wherever they end up, they'd be what we'd naturally end up running on our servers to keep our freed tarballs up-to-date. <jxself>Oh, and the hash would probably need updating too. <jxself>I'm not saying that the methods use to make those modifications need to be secret, like just I've not said that lxo should go hide his deblobbing scripts. <mark_weaver>well, think about how packages would be updated in such a regime. consider gmsh. when a new version comes out, how would a volunteer contributor to guix handle its update. <mark_weaver>if he's going to put in a URL to a tarball on ftp.gnu.org, then someone with privileges is going to have to arrange to produce an updated deblobbed tarball and upload it there, before an updated recipe can even be tested. <mark_weaver>but we don't need to handle it that way, because we already have all the needed infrastructure to handle this automatically. <mark_weaver>we have an 'origin' declaration for gmsh that handles creating a 100% free tarball of upstream gmsh. that exactly what we need. <mark_weaver>so the core of what you want seems to be this: that certain recipes should only be run on our servers, and not on user machines. <mark_weaver>e.g. the deblobbing derivation for gmsh's source tarball is something that should not be done on an end user's machine, it should only be done on our servers. <jxself>In Trisquel the process is mostly automated: The helper pulls in the version from upstream (Ubuntu in this case but it can be set it grab something from anywhere), proceed to bash it into shape, and then store the updated source code on the Trisquel servers. That source code is later grabbed by a different process and compiled. The Helper only needs modification or intervention if something goes wrong. People using the distro and not actively invol <jxself>So I could imagine a similiar process for Guix where an automated process is involved (including checking for new versions) and making the appropriate modifications. <jxself>But ultimately I suppose you're right that the freeing needs to be done before being delivered to people. Saying you must download this non-free software plus user-executed freedom patch seems wrong headed to me. <jxself>For something that couldn't care less about software freedom, maybe something such as that should be expected. <jxself>But I suppose that, to see it as a problem a necessary prerequisite is to first see the distribution of proprietary software as something wrong in the first place. <mark_weaver>when did I suggest distributing proprietary software? <mark_weaver>and who said anything about "you must"? [download this non-free software]. again, the intended default is to use substitutes, including for the freed source tarballs. <jxself>And the substitutes mean the binary is freed (to whatever extent that makes sense.) But the distribution of proprietary software is what this whole conversation has been about right? The distro getting people to download proprietary software. The argument in favor of it seems to be that it's okay because there is also a user-executed freedom patch to fix it. <jxself>I'd rather go further and not have that be necessary in the first place. <mark_weaver>jason, please remember that you're talking to someone who used the XO-1 as his primary development machine, followed by the YeeLoong, so that I could avoid running a non-free BIOS. <jxself>Yes, and so I don't understand why you're okay with having people download proprietary software if that can be avoided in the first place. <jxself>But maybe I should just let this go. I don't want to upset anyone and I'm a little frustrated over the whole topic. ***protein-prophet is now known as Sleep_Walker
<philed>Guile/guix complete beginner here (former common lisper): Can I mess around with the guix api from the REPL? (use-modules (gnu)) comes back with "no code for module..." Do I need to change my %load-path? <Ulrar>Well apparently providing networking is impossible, for some reason <DusXMT>Ulrar: If you scroll up in the boot log, does ifconfig complain "No such file or device" or something like that? <Ulrar>Is that supposed to stop the boot ? <Ulrar>Boots fine on the configuration without the static-networking bloc <DusXMT>Weird. I have the same bug with the network unable to init (it does it too early), but it continues on... <Ulrar>I have ssh depending on networking. Without the static-networking service it just doesn't start, but with it may be it hangs ? <DusXMT>again, same story here, but it somehow boots... <Ulrar>Ho wait, that might be my fault <Ulrar>I commented the %base-services <Ulrar>When I uncomment it, if there is 3 elements in the list I have weird errors with guix system reconfigure, so I tried without <DusXMT>Could you send a paste of the errors? <DusXMT>Ulrar: hmm. Could you also paste your config.scm? forgot to mention it as well <DusXMT>Ulrar: Yup, just as I thought. The %base-services is already a list, so you're supposed to either append or prepend to it instead of just putting it into another list <DusXMT>(append ...) merges it's argument lists together, there's probably some other procedures that do something similar <Ulrar>works fine with append, thanks :) <Ulrar>Okay, so now it boots but no network <DusXMT>Ulrar: yeah, I have the same exact problem. Ludo already knows about it <DusXMT>You can get it working with # dmd start networking <DusXMT>since the module should now be loaded <Ulrar>And what is the name of ssh ? <DusXMT>Ulrar: it's ssh-daemon. You can get a list of all running and stopped daemons with # deco status dmd <Ulrar>I installed lsh on my user to run ssh-conv, but it can't find awk <Ulrar>Shouldn't that be a dependency ? Or is it because I'm missing some things in my PATH maybe ? <DusXMT>perhaps they forgot to add it in? <Ulrar>They forgot to list gawk as a dependency you mean ? <DusXMT>I'm not sure, I'm not exactly sure how the inputs work in guix <Ulrar>Just installed gawk, now it works <Ulrar>So yeah I guess it's missing a dependency <DusXMT>try GIT_SSL_NO_VERIFY=1 ./bootstrap <Ulrar>That works, thanks. Why is the ssl certificate invalid ? Is it because /etc/ssl doesn't exist ? <DusXMT>yup, no one packaged ca-certs yet <Ulrar>It's not on the wishlist though, is there already some plan for that ? <davexunit>found out that my minetest patch has a silly mistake in it when I sent it upstream. :( <DusXMT>I'm still working on darn abiword... I know I keep saying that `I'm getting close' all the time, but this time I really am, the program compiles and runs file, but the plugins don't yet, so after I fix most of them, it'll go up <philed>My favourite thing about programming in general is the never-ending feeling that you are getting close. <Ulrar>Mh, about the license. zsh uses apparently their own license, and wikipedia refer to it as a "mit-like" license. <Ulrar>How should I put that in the recipe ? <DusXMT>define it in guix/licences.scm ? <Ulrar>So I add a license named zsh <jxself>Did anyone download it and look? :) <jxself>Or just going off what Wikipedia said it was? :) <davexunit>Ulrar: I guess you'd want to use (license (x11-style "file://LICENCE")) <davexunit>when you submit the patch you can ask about it and ludo will confirm. <jxself>Seems the effective license would be whatever GPL version, assuming that those things are being included. <DusXMT>I wonder, is it okay to pronounce Guix as Goo-ee-chs? <Ulrar>A grep GPL returns two files for autocompletion on OpenSUSE <DusXMT>will take a while to get used to <Ulrar>Ha, 3 even, there is autocompletion for systemd too <Ulrar>Seems like those files would be useless on guix <jxself>Might wanna try variations, like General Public License is case they didn't use the letters GPL <jxself>I've seen some refer to the GPL as "the GNU license" <jxself>Which is ambiguous since there are several from the GNU Project. <DusXMT>The GPL almost seems like a plague when you look at it from a non-gpl-using programmer <Ulrar>General Public License returns an autocomplete script for darcs, and configure.guess <Ulrar>DusXMT: It's been said by a few people, yeah <mark_weaver>DusXMT: for those who want to make proprietary software and deny others freedom for their own benefit, yes, it must look like a plague. <Ulrar>mark_weaver: That's also true for people who just want to use the BSD license for example <DusXMT>mark_weaver: not just to makers of propriotary software, but to makers of permissively-licensed projects too. But I guess there are consequences to strongly protecting freedoms <mark_weaver>well, the "benefit" to permissive licensing is that it can be incorporated into proprietary software. <DusXMT>Can I ask a packaging question? Abiword comes with a lot of plugins, many of which impose additional dependencies. Would it be okay to also include another package, based on abiword, (eg. abiword-light) with the plugins disabled? <DusXMT>I think I'll ask on the ML later, I still have some fixing to do before the entire thing builds... and the worst part, this computer being a pentium 3 based one, it takes over 2 hours... <mark_weaver>we already have emacs-no-x-toolkit, although that package has another rationale besides being lighter: the gtk version of emacs cannot survive after an X server it ever connected to is shut down, whereas the non-gtk version can. <tadni_>Not great news, for GNOME on non-systemd it appears. <DusXMT>I don't think it's that tragic, we still have the potential of using Mate, XFCE, KDE, LXDE; <DusXMT>After all, there's more to an operating system than just the GUI <Ulrar>Still sad that so many things starts to depend on that <DusXMT>I'm very close to actually switching to GNU as my main desktop OS, with WindowMaker as the WM, there being one last missing piece that I'm working on right now <DusXMT>Ulrar: What kind of `things' depend on it, care to enlighten me/ <Ulrar>Well udev and gdm for example <Ulrar>and with that many distro switching to udev it's not going to get better I fear