<roelj>tsyesika: Does it work in a text console? (Or is it impossible to get there..) <tsyesika>once booted it doesn't work in the installation at all <tsyesika>calher_MomsPC: neither, it's a macbook 6,2 <tsyesika>could be but there doesn't seem to be a solution posted <tsyesika>not sure what could cause a keyboard to stop working <roelj>Could it be that a wrong keyboard driver is loaded in the kernel? Grub uses different drivers, doesn't it? <roelj>Maybe you could try removing kernel modules with an external keyboard. But then the driver must be loaded as a module, and not be built-in.. <tsyesika>i'm not sure, it seemed to me the driver should be usbhid, but that's loaded when i boot into guix, i checked <tsyesika>well, i'm going to head to bed, thanks anyway <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 [1], but our configure phase fails on the Makefile's "links" target. It has failed since at least 1.0.2d (current Guix master). [1] https://mta.openssl.org/pipermail/openssl-dev/2015-December/003633.html <sneek>lfam, mark_weaver says: thanks for offering to do the openssl update, but I took care of it. the 'security-updates' branch not contains updates for openssl, libxml2, and pcre. <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. <lfam>Well, if it works, it works. Thanks for doing it! <mark_weaver>when combined with the libxml2 and pcre security updates, there's a lot to rebuild though: almost 6000 builds <mark_weaver>this reminds me that we really need to get grafting working properly. <lfam>Yes, I noticed that `guix refresh -l openssl` indicated >2000 rebuilt packages. If all of the current ~2700 packages are on each platform, we'll have to rebuild the majority of the distribution. <mark_weaver>we should probably also switch most (all?) users of openssl to libressl instead. <lfam>Yes, I was thinking that while wondering why the release tarball has broken symlinks and files named 'config' and 'Configure' but no file named 'configure'. <lfam>mark_weaver: I've been meaning to ask you, do you know if anyone is running guixsd on arm? <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. <lfam>I forgot about the dependency on grub <mark_weaver>it's important because we need a way to easily boot into arbitrary old generations of the system. <mark_weaver>upstream GRUB from git (not yet released) apparently works with U-boot on at least some ARM systems. <rekado>CustosL1men: what do you mean by "integrate"? <rekado>we usually create Guix package expressions for every ruby or python package that we're interested in. <rekado>we also have python-pip, so it should be possible to use the python way to install stuff, but packages would not be installed into the store then. <rekado>It seems that our mailing lists are slow again. ***davi_ is now known as Guest7365
<wingo>Jookia8: see logs from last night :) <wingo>there was a conversation around 3h40 UTC <Jookia8>I have NixOS running on ARM with rollbacks in u-boot menu <Jookia8>At this point it's not looking great for getting Novena support in to NixOS- so, does anyone have any notes on bootstrapping? ***zimmermann_ is now known as zimmermann
<davexunit>hmm, letsencrypt demands to write to /etc/letsencrypt :/ <apa512>anybody else having problems with corrupted packages on hydra preventing guix system reconfigure at the moment? <davexunit>apa512: not right now, but I have seen that in the past when hydra is really bogged down :/ <bavier>apa512: if you don't mind building some things, there's always --fallback <apa512>i tried --fallback but there was some error message. can't remember what exactly but something like unmatched dependencies. <cehteh>davexunit: now with the release there are a lot complaints about letsencrypt .. and already some lightweight solutions on the way <davexunit>cehteh: yeah someone showed me that yesterday <cehteh>for guix it prolly makes sense to implement something similar/tiny in guile <davexunit>it uses a lot of python standard library stuff <cehteh>can guix package have an expiration date? <cehteh>someone suggested that years ago, add expiration dates to software where it stops to work <cehteh>to force users to install updates/security patches <cehteh>ofcourse with free software this could be always circumvented, i am also not too fond of the idea <bavier>it seems orthogonal to guix really <cehteh>but having an expiration field in guix packages when it must be reinstalled can automate the key rollowver <davexunit>and also in opposition to the spirit of free software <cehteh>yeah i know that, i dont like the idea, but i wouldnt rule it completely out for some things it *may* make sense <cehteh>and for free software there is least danger, because one can patch this expiration date easily out <cehteh>so maybe, under some cictumstance, carefully .. i think one should think about it and not completely refute the idea <rekado>there's no way to enforce expiration. <rekado>not even with a kernel module (because you could unload it). <rekado>you just want it to nag the user? <rekado>it would be less patronising to show the age of the last release tarball. <cehteh>but i support the idea that "the safe way should be the easier way" ... aka its easier to make regular updates to your openssl than patching the expiration date out for example <cehteh>or when i make release tarballs from my software i sign them with gpg inline -> tar.gz.gpg .. one *has* to use gpg to check the signature and unpack it <cehteh>just make the safe option the default <rekado>what I love about Guix is that it makes patching sources so easy. I think for Guix it would be simpler to patch out an expiration date ;) <rekado>BTW: Guix also supports users running ancient profiles for reproducibility reasons. <rekado>it is not necessary a bad idea to use old software. <cehteh>having some .sign file along on the webserver isnt much use imo <cehteh>thats ok, i clearly saied that i dont like the idea, only that its worth some consideration, and absolutely not for *every* software <cehteh>cat foo.txt ... > "your 'cat' is expired, please install a newer one" :D <mark_weaver>cehteh: can you give a specific example of when an expiration date would be used, and why? <mark_weaver>security updates don't qualify, because we don't know in advance when the next security hole will be found in any given package <cehteh>mark_weaver: its still forces the user to do regular updates (which may be just reset the expiration timer) and it forces the vendor to care for regular releases <mark_weaver>"forcing" the user to do anything, including updating, is something that we consider an anti-feature. <cehteh>but i cant stress that i only mentioned that idea but i am not convinved by it <mark_weaver>and what is a "vendor" in this context of free software? <cehteh>i will prolly never ever use it in my software <cehteh>vendor can be distributor or upstream <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>i am just playin devils advocate here <cehteh>some ideas from that are not wrong (aka make the safe and secure way the default) <cehteh>but i strongly oppose nannying users <mark_weaver>I think that forcing the user to update would be wrong. providing good tools to notify them about things like upstream updates and unpatched security flaws are good things. <mark_weaver>"guix lint" recently gained a basic CVE checker, so that's a step in the right direction <cehteh>as long the software doesnt constantly phone home at least that should be optional too <cehteh>just a check at startup if there are updates can invade privacy <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. <lfam>davexunit: Regarding lets-encrypt wanting to write to /etc/letsencrypt, is that a problem? I figured it would be okay since parts of guix itself write to /etc <mark_weaver>it's not ideal, but nor is it an immediate technical blocker <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? <lfam>It was working already ;) <lfam>Although not tested on GuixSD <davexunit>lfam: it took a bunch of tweaks to make it work for me <lfam>Oh yeah? It will be interesting to see what you had to do <cehteh>btw .. thinking about things like 'conference schedule apps' .. i'd call it a service when they desinstall themself a quarter after the conference :D <davexunit>lfam: I also took care of the weirdness with 'dialog' <mark_weaver>cehteh: I don't understand the question "when you every run into some software which does that, how would you handle that in guix?" <mark_weaver>can you give a concrete example of "software which does that"? and tell me what "that" is? <lfam>mark_weaver: in 04e0eac1 you disabled a test in grub, to be re-enabled "when we have Parted". Is that safe to re-enable? <davexunit>lfam: what I have left to do is the boring stuff: clean up synopses and descriptions and run the linter one last time <lfam>davexunit: Do you want me to do that? <mark_weaver>lfam: if you can get it to pass its test suite without disabling that test, that would be great <lfam>It passed on x86_64. I'll check the others. <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>mark_weaver: i saied that should be *never ever* used for all packages <cehteh>there may be very few which (arguably) benefit from it <mark_weaver>cehteh: okay, it sounds like this idea is not fully baked. maybe we should table this discussion until you have a proposal that is more concrete <alezost>mark_weaver: oh, right, I confirm: for me it happens when you run `magit-show-commit' before loading "M-x magit-status". <lfam>Is there any advantage to just running `guix package -u` periodically? <lfam>Versus the expiration date thing? <mark_weaver>cehteh: well, I don't care who originally came up with the idea; you're the one who proposed it to us. <cehteh>i am playing only devils advokate, that wasnt my idea, i only read about it some years ago <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>Any workaround for guix build: error: build failed: EOF expected (protocol error?) while using guix from a source checkout? <lfam>Err, sorry that line is a mess <bavier>lfam: `make clean && make` might help <lfam>Right now they are discussing reproducible grub builds on #libreboot <mark_weaver>lfam: it's a non-deterministic error. retrying usually works. <lfam>Ah, I didn't see it had been fixed. Thanks! <davexunit>that protocol error got me too, then I read my guix-devel backlog :) <lfam>It's non-deterministic but very likely! <lfam>What is the difference between the build options "--system" and "--target"? <mark_weaver>lfam: --system performs native builds, --target does cross-compilation <mark_weaver>so, if you pass --system=i686-linux on a x86_64 system, then it will actually download native i686 binaries for the toolchain and all other inputs, and do the build in 32-bit mode. <lfam>mark_weaver: So is system only used to build between x86 and x86_64? <mark_weaver>if you have offloading set up, with build slaves running on other architectures, then you can use --system even with non-Intel platforms. <mark_weaver>e.g. if you have an armhf-linux build slave set up, then if you pass --system=armhf-linux on an x86_64 system, then the build can be automatically offloaded to the armhf system. <lfam>Ah, offloading. That makes sense. <mark_weaver>in theory, we could support --system without offloading using qemu <alezost>mark_weaver: sure, thanks for raising it up! <lfam>Anyone seen this before: "guix build: error: fport_fill_input: Connection reset by peer" <bavier>lfam: I've seen that error before <lfam>bavier: Using the "system" guix or the guix in a git checkout? <lfam>What's the easiest way to get the path to the downloaded source of a package? <mark_weaver>lfam: note that "guix build -S <package>" will not always be the same as the downloaded source; it includes patches and snippets <lfam>Right, so it matches what is used to build, but not the upstream source. <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>Oh, it happens for i686, too. <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. <mark_weaver>sneek: later tell lfam: bug reports, or better yet, patches, to improve the situation would be welcome :) <davexunit>sneek: later tell lfam: I updated wip-lets-encrypt in the official guix repo. could you test it out and make sure it still works for you and then I will merge it? <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>so hopefully lfam can validate that my tweaked package actually still works for the whole transaction :) <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 <kristianpaul>but Guix looks like something we ever wanted but wasnt there untill now :) <davexunit>ACTION looks at open-connection in (guix store) <davexunit>I'd like to make it possible to initiate a connection to the daemon with any port object <davexunit>that will make it possible to do things like talk to a remote guix daemon over an ssh tunnel <kristianpaul>I wonder if the mipsel is intentional for the lemote laptops? <davexunit>yeah, that's the hardware people are using with the MIPS port. <mark_weaver>kristianpaul: I bootstrapped our MIPS port on a Lemote YeeLoong 8101B, although I've tried to ensure that it would work on any MIPS III system. <kristianpaul>mark_weaver: i havent look all the docs, but should be just a tipical boostrap operation? <mark_weaver>kristianpaul: I'm not sure I understand your question <mark_weaver>the process of bootstrapping Guix on a new architecture is outlined in the "Porting" section of our manually. <mark_weaver>I also bootstrapped our armhf-linux port, using a Novena board. <mark_weaver>We use Lemote 8133 laptops (Loongson 3A based) to build binary substitutes for MIPS, so we know that Guix works there as well. <mark_weaver>to my knowledge, our MIPS packages haven't actually been tested on any other processors besides Loongson 2F and Loongson 3A. <mark_weaver>kristianpaul: do you have a MIPS machine that you'd like to run Guix on? <kristianpaul>with typical i mean the mipsel tarballs here ftp://alpha.gnu.org/gnu/guix/ goes to the same ext2 partition where i put the debian for the yeeloong ? <mark_weaver>kristianpaul: to install from binary tarball, follow the instructions in section 2.1 (Binary Installation) of the Guix manual. <mark_weaver>that process is the same on all supported architectures <mark_weaver>however, your kernel needs support for running 64-bit MIPS executables using the N32 ABI, and also some other features to use guix-daemon. <mark_weaver>I'm not sure off hand whether the stock MIPS debian kernel has the needed features. <fps>hmm, for some reason neither ctrl-left/ctrl-right seem to work in any terminal with bash <fps>nor does command editing <fps>for some reason the command is always garbled if it's longer than a line <fps>maybe something with the terminal database - a part of unix/linux systems i've always been happy to never look at ;) <fps>pressing ctrl-left gives me an uninterpreted control code of ;51 <fps>and sadly xfce4-terminal doesn't see all installed fonts in the system :( <fps>ah, the ctrl-left/right thing is solved by a .inputrc <fps>hmm, should i make a package for that? or a service that populates /etc/inputrc? <kristianpaul>mark_weaver: so what OS you installed guix on in your YeeLoong <fps>ok, i found the place in the guix build daemon that ignores timeout errors when caching failures <fps>it's hardcoded in build.cc ll1476-1510 <fps>i guess to fix the problem i saw i could add options to the daemon to switch failure caching for the different cases individually <fps>but i have a gut feeling that representing failures more explicitly in the store could have other benefits, too <fps>also it just feels more explicit and cleaner. would need an overhaul of the store path format though.. <fps>and of course emacs is garbling the formatting ;) <fps>ok, i'll fight it for now.. ***calher_ is now known as calhim
<fps>sent a patch to the ML. review if you so please.. <fps>can someone here maybe give me two quick tips to test it: <fps>1] how to deploy the build of guix-daemon in my laptop's system? <fps>2] how two write a quick package that does nothing but timeout the build [e.g. sleep for 10 seconds so i can set --max-silent-time to 5 and see if it caches the failure faithfully]? <fps>ACTION runs guixsd on this laptop