<CustosL1men>how well does guix integrate with ruby and python and their packaging systems ?
<lfam>I'm trying to make a patch to update openssl to 1.0.2e. The problem is that their release tarball has a bunch of broken symlinks for tests. They claim that the symlinks should get recreated during the configure phase , but our configure phase fails on the Makefile's "links" target. It has failed since at least 1.0.2d (current Guix master).  https://mta.openssl.org/pipermail/openssl-dev/2015-December/003633.html
<lfam>I am so glad you did that. I was not having much fun!
<lfam>I was just coming to ask where the hell that /bin/sh was coming from
<lfam>mark_weaver: Did you try letting their Configure script fix the symlinks?
<mark_weaver>lfam: yeah, that update was much more work than I expected.
<mark_weaver>it's possible that the broken symlinks could have been fixed in a simpler way, but my time was limited and I just wanted to get the rebuild started.
<mark_weaver>the broken symlinks broke the 'patch-tests' phase, which happens before Configure is run.
<lfam>mark_weaver: Yeah, I thought about that. I didn't get to the point where I could test it, but if the tests aren't accessed until the 'test' phase, then 'patch-tests' could happen after Configure.
<mark_weaver>we need suitable linux-libre config(s), possibly patched kernels (depending on the target device), GRUB for ARM, etc.
<mark_weaver>Currently, afaik, I possess the only non-Intel GuixSD system, running on a Lemote YeeLoong 8101B, but a few of the needed patches are not yet pushed to the 'master' branch for various reasons.
<rekado>instead of forcing the user, a package manager could answer the question "am I running any outdated software?" --- guix does this to some degree and can be extended to answer questions like this.
<cehteh>so a expiration date (well lets say it only notifies the user instead ceases to work) has at least the advantage not to invage privacy
<mark_weaver>well, when you build or install GNU packages, it does an automatic "freshness" check to see if there's a newer upstream version than the one in Guix.
<mark_weaver>we should probably revisit that from a privacy perspective
<mark_weaver>cehteh: so, you would add an expiration date to each individual package? what policy would you suggest for how to set the expiration date?
<mark_weaver>given that the date of the next security hole found in a package could be anywhere between "now" and "never", I'm not sure how we would decide on a date.
<mark_weaver>if the user wants to be periodically reminding to think about updating their software, I would think that should be customizable by the user, rather than something that is decided by us and per-package.
<cehteh>mark_weaver: i dont know, havent tought about it, but the question is: when you every run into some software which does that, how would you handle that in guix? .. just ignore, patch it out or add some way to guix to support an expiration date?
<mark_weaver>lfam: I didn't actually add that bit of code. the commit you mentioned only changed those lines to use 'modify-phases'.
<cehteh>mark_weaver: i dont even know if anyone has implemented that idea yet
<lfam>mark_weaver: Oh, sorry. Lazy use of git-blame on my part...
<mark_weaver>cehteh: IMO, per-package expiration dates are a bad way to encourage checking for security updates. with thousands of packages, we'd spend an enormous amount of time hitting expiration dates and having to reset them.
<alezost>mark_weaver: hm, strange, what "M-x magit-version" is it?
<cehteh>i dont even proposed it, i only asked if guix supports it and/or how it would be handled eventually
<mark_weaver>alezost: ah, thanks. indeed, running 'magit-status' fixes 'magit-show-commit' for me.
<lfam>It seems like without a really good argument for expiration dates, and nobody offering patches, it won't happen. Plus some people have philosophical qualms with it, so even fewer people will be willing to implement it.
<cehteh>if there would be already some 'expire' field in the package description it could be used for something else
<mark_weaver>cehteh: well, whatever, you raised it as a topic for discussion and seemed to suggest that we should consider it.
<lfam>What's the process for setting up cross-compilation of arm on x86_64. I did `guix environment -s armhf-linux grub` followed by `42047 ./pre-inst-env guix build --target=arm-linux-gnueabihf grub`. But it fails while trying to copy the unifont archive, like this:
<lfam>Cross-compiling grub with that method fails for arm, i686, and mips. I can build it natively on x86_64. Am I doing it right?
<lfam>Well, I can cross-compile the hello world package, so I guess it is a problem with grub or one of its dependencies.
<mark_weaver>lfam: cross-compilation doesn't work for all of our packages. in many packages, the problems might be easily fixable. for others, it might be significantly more difficult.
<mark_weaver>we have generic code to handle cross-compilation, but hydra.gnu.org tests cross-compilation for only a small number of core packages and targets. my impression is that most of our packages have not been tested for cross-compilation.
<mark_weaver>bug reports, and better yet, patches, to improve the situation would be welcome :)
<mark_weaver>sneek: later tell lfam: cross-compilation doesn't work for all of our packages. in many packages, the problems might be easily fixable. for others, it might be significantly more difficult.
<mark_weaver>sneek: later tell lfam: we have generic code to handle cross-compilation, but hydra.gnu.org tests cross-compilation for only a small number of core packages and targets. my impression is that most of our packages have not been tested for cross-compilation.
<davexunit>I haven't actually gotten it to give me a cert. need to read more about how the process works.
<davexunit>for one thing I think I need to run it from my server, not my laptop.
<mark_weaver>davexunit: lets encrypt authenticates you by having you demonstrate that you control the domain/server that the certificate will be for, e.g. by having you put up a page on your server containing a cookie they sent you, or things of that sort (I forget the exact details).
<mark_weaver>so yeah, I don't see how that can work without their software being run on the server where the certificate will live.
<davexunit>I desperately need it for my self-hosted services
<mark_weaver>I've always refused, on principle, to give money to certificate authorities, so I've had to get by with self-signed certs. finally, with let's encrypt, I'll be able to have a CA-certified certificate without financially supporting that system.
<davexunit>yes, it's a good step in the right direction