<mark_weaver>suitsmeveryfine: that indicates that a problem happened with the network transfer. restart the command. <mark_weaver>obviously there is room for improvement here. so much to do :) <lfam>suitsmeveryfine: I was able to download that file using curl and decompress it just fine. <NiAsterisk>even if I think it shouldn't be my task to fix obvious issues which are ignored or put way down the roadmap, wouldn't it be easier for python setup in guix if I provided a patch for a working setup.py which can then be send by someone who has an github account to the project upstream? not that I have ever written a setup.py, but documentation looks okay <lfam>NiAsterisk: I have contributed a few changes upstream as a result of packaging headaches. It's worth the effort if the upstream seems open to new contributors <NiAsterisk>bitmessage seems a tiny tiny little bit slow in merging. <NiAsterisk>Peter Surda stepped in to fix this, but i don't get how they work now.. there's mailchuck/PyBitemssage as the dev thing, and then there's upstream which is still waiting, and peter surda has access i think <lfam>I'm not sure that a complete revamp of a package's build system is an appropriate patch to apply in Guix. But if you make the patch I could try to upstream it. Although it would be much better if the patch author submitted it themselves. I won't have anything intelligent to say if they ask me questions about the patch. <suitsmeveryfine>petter: ok, let's continue the discussion about the guide tomorrow or so <lfam>Does bitmessage require a new build system to get into Guix? Can't we just do whatever nix did? <petter>suitsmeveryfine: yes. God natt! :) <NiAsterisk>hm. I'll take a look how setup.py works, currently I'm comparing and looking over NixOS packages, freebsd ports etc for comparison of how things were solved at their ends. <lfam>Although I have to say I'm wary of all these unaudited crypto-messagers. I've been maintaining some private packages of similar projects because I'm not comfortable submitting untested crypto stuff to the "official" GNU Guix package repository. <lfam>It would be good if one of those projects raised the funds for a proper audit <lfam>Or at least had some recognized crypto expert on the team to give a thumbs up. <lfam>I'm completely unqualified to make the judgement <NiAsterisk>i have the opinion that they serve as good libraries for other projects which could merge functionalities in the near future. I really have like .2% clue about crypto if at all, I rely on what other people tell me they analyzed on an private audit level of security.. that's the middlepath for me <NiAsterisk>there'S too much people working on reinventing the wheel. merging efforts will be better for all. <lfam>I mean, if somebody eles submitted my private packages to Guix, I wouldn't object. But I don't want to be the one that vouches for the upstream code quality in those cases <lfam>Does anyone know if ctan.org is a reputable source for Latex related packages? I can't find any in our tree, but latex2html only seems to exist on ctan.org now. And they are actually active, having recently merged all the Debian patches <NiAsterisk>I see it like this, people already use bitmessage if it's not for the code security it's for things it provides which is distributed messaging. it's not audited, and if it would be mentioned in the package description that would be okay for me personally. people consent to use an unaudited software in this case <lfam>That makes sense. There is tons of crappy / unaudited code distributed through the various gnu/linux distros. <lfam>Although, since GuixSD has a postfix service, it could be very easy to have distributed messaging through email ;) I haven't tried the postfix service yet <lfam>Declarative OS configuration could rescue decentralized email ) <NiAsterisk>if it's a bigger issue, we might need to write down what would be not very ideal to contribute, exceptions to make or how to handle them. (case: supernewencryption-stuff: code not audited, please mention in description that it is not audited (in words accessible to everybody)) <lfam>It's not a big issue, it's just my personal desire to not be like that poor person that broke openssl in Debian for several years. <lfam>If there is an issue it can be raised on the mailing list in response to specific patches, in my opinion. <lfam>So, I'd say, please package bitmessage, and perhaps it can be described as "experimental" in the package's description. <suitsmeveryfine>why is the installer building so many packages? I thought building from source was just an option <NiAsterisk>it's difficult for me personally. on the one hand, there's quality and security you normally don't think about. then projects like gentoo maintain a large set of patches which is not merged to upstream.. this is not ideal. otoh, the current scenario of applications out there is not ideal, and people should be free to choose what they think they might want to test in free software. <lfam>suitsmeveryfine: Did you do the `guix authorize` step to allow substitutes? <NiAsterisk>okay. i'll try and do my best to give a hint about the bitmessage status in descirption <lfam>suitsmeveryfine: What step of the manual are you on? I'd like to know so that we can improve the manual <suitsmeveryfine>petter told me to jump straight there after saving the configuration file <lfam>If so, did you do step 7, which authorizes hydra.gnu.org to serve you binary substitutes? <lfam>And if so, what is being built? <lfam>Ah, did you build Guix from source, then? <lfam>Can you link to that guide? <lfam>That guides appears to assume that you have the Guix package manager installed on another distro. Is that correct? If so, how did you install it? <suitsmeveryfine>I have never used guixsd before. I only test this for the libreboot documentation <lfam>This is new territory for me ;) <lfam>So, you are running from the Guix live USB installer? <NiAsterisk>the guide does not mention "guix pull" before "guix init system..... <lfam>I don't know exactly the best course of action here. <lfam>The live USB should have substitutes from hydra.gnu.org authorized. Is the file /etc/guix/acl non-empty? <lfam>That file is where the keys of substitute servers are stored. <lfam>You should not have to build anything from source except perhaps linux and bind, because those were updated today and hydra.gnu.org may not have substitutes available yet. If it is building ncurses then something is wrong <mark_weaver>a few things have been pushed to the repo recently that aren't yet built, e.g. linux-libre-4.4 with a fix for CVE-2016-0728. <mark_weaver>suitsmeveryfine: oh, if it's building ncurses, that's bad. <lfam>If you didn't do `guix pull` before `guix system init`, you should. That is like `apt-get update`. Otherwise, you are building package recipes that are out of date and no longer covered by the hydra binary substitute server <lfam>Please cancel the compilation and do it <mark_weaver>we should probably put that in the manual, if it's not already there. <lfam>mark_weaver: they are not following the manual. <mood>That is not in the manual <lfam>Okay, good to know. It should go in there. <mood>I was following the manual, and it was merrily downloading stuff for several hours already <lfam>mood: Downloading upstream source tarballs or downloading substitutes? The latter is desirable, the former is not <NiAsterisk>is the manual in version control, so one can create patches for additions? <suitsmeveryfine>lfam and mark_weaver: I have interrupted and have access to prompt. what now? <mood>lfam: I believe substitutes <lfam>NiAsterisk: Yes, it is in 'doc/guix.texi'. <lfam>mood: Okay, that is good. Not good that is taking hours but then again, we are having a fundraiser to get faster hardware and hosting for hydra.gnu.org <mood>lfam: The download speeds were abysmal, so yeah. I cancelled it now though, hadn't run guix pull beforehand <lfam>Oh, then you may have been downloading a mix of upstream sources and substitutes that were still valid because their package definition had not been changed <lfam>Indeed, abysmal download speeds are a big motivation for my donation to the fundraiser :) <lfam>We like it too, it's essential and just got a lot faster. The version in your live usb will be the old slow version. <lfam>suitsmeveryfine, mood: I recommend you spend the time to read the manual. We would like it to be completely sufficient. I am making notes of your issues so I can patch it. So, please be vocal when the manual it not sufficient so it can be improved. And feel free to improve it too! We are very open to new contributors :) <suitsmeveryfine>anyway, is it fine to run guix system init now after having pulled everything down? <lfam>By the way, I am excited to get a libreboot package into Guix. That will be just awesome! <suitsmeveryfine>Yep! I am installing it on a somewhat awkward machine though: the macbook2,1 <lfam>That's okay. We have to start somewhere. <mood>lfam: It would be nice if the manual gave some hints regarding the actual partitioning of the drives in the manual, even just an example invocation of parted, or a link to a more helpful page in the Parted manual <lfam>mood: Yes, there is a balance to be struck when trying to explain how to use 3rd party tools in our manual. I have a related patch re:QEMU in the queue right now. I'm not sure what's best. <lfam>Since GuixSD is so young, users are expected to do a lot of things (like partitioning) that older distros abstract away <NiAsterisk>maybe the manual should be short, and detailed info could fit into a wiki/wiki-like documentation system with place for more examples and writings? <mood>Well, I'm used to doing partitioning manually (currently using Arch), but the one link into the Parted manual goes to a page that is several clicks away from actual usage information <lfam>We discussed manual vs wiki a few months ago and I think the consensus was that we didn't want to do a wiki <bavier>I'd much rather accept patches to the manual; wikis are difficult to keep in sync <lfam>I see the value of wikis (I sometimes find useful stuff in the arch wiki) but IIRC the objection was that it's impossible to keep wikis in sync <suitsmeveryfine>so where is the place to contribute thinks like: potential issues when installing guixsd on a macbook <lfam>suitsmeveryfine: Upstream ;) <lfam>Is there a macbook specific issue with GuixSD? <lfam>I mean to libreboot but I misread your message ;) <lfam>If there is system-dependent issues with GuixSD then ideally that issue should be fixed rather than mentioned as a workaround in the manual <lfam>Let's wait until we have a problem before solving it ;) <lfam>We already have a lot of work to do :) <suitsmeveryfine>so I got stuck at the password prompt. Connecting a USB keyboard didn't help <lfam>Ah, that seems like a hard nut to crack ;) <suitsmeveryfine>Unfortunately I couldn't translate their slackware solution into the one I needed <lfam>mood: Thanks for putting all the links together for me :) I wonder, should a user that does not know how to use parted jump right in to "Using GNU Parted"? I think that might be dangerous <lfam>suitsmeveryfine: So the solution was to create a new initrd? That can be done in GuixSD in the system configuration. Unfortunately I can't give you specific advice on HOW to do it. <mark_weaver>okay, so it looks like additional kernel modules needed to be added to the initrd <suitsmeveryfine>mark_weaver: yes, but the first person who posted said he had already done that, didn't he? <mark_weaver>section 7.2.11 (Initial RAM Disk) of the Guix manual explains how to specify additional kernel modules for the initrd <lfam>NiAsterisk: That looks like a really comprehensive guide to how to manage block devices. I don't know whether or not its appropriate for a specific distro manual. Perhaps you should raise the question on guix-devel? <NiAsterisk>lfam: yes. I have some thoughts behind "there could be a wiki", i'll take notes and send to the devel lists soon <mark_weaver>suitsmeveryfine: he already built a ramdisk, but it was missing most of the modules that the latter commenter added. <suitsmeveryfine>builder for '/gnu/store/blablabla-dhcpblabla.drv' failed with exit code 1 <lfam>NiAsterisk: Not saying I haven't found these total-comprehensive-how-to-unix Gentoo and Arch wikis useful. But I think that in the long run the best approach is to upstream the documentation to parted, etc <lfam>The wikis are only necessary because the upstream docs suck <mark_weaver>wow, tar said that the file changed while it was being read. that's strange. <lfam>The file changed as it was reading? That seems wrong... <lfam>suitsmeveryfine: Can you share your OS configuration? <lfam>And the specific command-line invocation you started the build with? Also, are you out of disk space? <lfam>Seems like the error could be wrong in this case <NiAsterisk>possibly, and because people have to start somewhere + get into using the distro somehow, having entry docs at a centralized place. there are pros and cons for wikis. one con would be, if there will be a smart GUI for setup, wiki is not really needed when dcumentation is fool-proof. <lfam>Also interesting that bind was updated today, correct mark_weaver? <NiAsterisk>but i guess i'll read through your discussion on the list some months ago <lfam>NiAsterisk: Feel free to raise the question again, also <lfam>The file changed as it was reading... how could tar know? I don't know tar internals. Does it checksum as it goes? Or is it a general corruption error? Parallel build issues? <mark_weaver>suitsmeveryfine: what do you mean by 'it was one of the "patch-shebang: bind..."' ? ***Jookia is now known as Guest86323
<mark_weaver>lfam: there are many ways that it could know. I don't know off-hand what it does. <lfam>Nothing should be writing to the file <mark_weaver>I wonder if suitsmeveryfine's clock is set correctly. maybe if it was set to 1970 there might be issues. <lfam>Well, suitsmeveryfine is at least familiar with that issue because they are from libreboot <mark_weaver>and actually, that has been an issue with recently coreboot/libreboot on X200 <mark_weaver>suitsmeveryfine: does this relate somehow to the "tar: bind-9.xxxxxx: file changed as we read it" problem ? <suitsmeveryfine>pattch-shebang: bind-9.9.8-P3/........... changeing '/bin/sh' to '/gnu/store/aegoaj9ohao-bash-4.3..../bin/sha <lfam>I would be crying too if I was having these issues ;) <mark_weaver>and similar messages are common when building software in guix <lfam>The shebang patching is normal but it would be good to see some of the output around the error <lfam>And also to see the OS configuration file <suitsmeveryfine>with a few things added, namely: time zone Stockholm, keymap sv_SEutf8 <lfam>So, tar is reading the file as patch-shebang is doing its thing? <mark_weaver>suitsmeveryfine: what kind of filesystem is this running on? <mark_weaver>it unpacks bind.tar.gz (included in the dhcp tarball), runs patch-shebang on all the files within, and then repacks it. <mark_weaver>it's clearly sequential, but it's almost as if the patch-shebangs are still running after the repack 'tar' command is begun. <mark_weaver>suitsmeveryfine: no worries, I'd very much like to help you get GuixSD installed. <mark_weaver>now it becomes relevant to investigate how 'tar' decides that a file changed as we read it. <lfam>And how patch-shebang terminates? Could it be signalling that it's done when really some forked child is still working? <lfam>It seems like we would have tons of issues if that was the case <lfam>'tar-1.28/src/create.c' line 1821 <lfam>I believe it is comparing ctimes <lfam>No, that is the relevant part of tar <mark_weaver>it's comparing ctime and size of the directory before and after <mark_weaver>I wonder if the directory is somehow getting optimized lazily after we finish modifying files in it, or something. <suitsmeveryfine>hmm, but it's listing the sources for all the architectures in linux-4.4 <mark_weaver>suitsmeveryfine: ah, good. maybe it's just a transient failure. there are many of those. <mark_weaver>suitsmeveryfine: that's expected. I pushed a security update for linux-libre-4.4, but hydra hasn't yet build the new one. <mark_weaver>if you used the x86_64 installer, then it should be fine. if you used the i686 installer, it would be building i686 binaries anyway. <mark_weaver>ACTION goes afk for a couple of minutes to reboot into the patched kernel (which I recently finished building on my X60 :) <NiAsterisk>tar just failed here with linux 4.4 with no more space on disk <lfam>Sounds straightforward ;) <NiAsterisk>forgot to mount the swap. ram is like 200mb on what I am building on right now, so i did expect that <NiAsterisk>you would not be able to compile libreoffice from source with this <suitsmeveryfine>I find it strange that the installer goes through all the architectures <mark_weaver>NiAsterisk: local builds are done in /tmp by default. if your /tmp is not large enough (e.g. if it's a ramdisk) that can be problematic. <mark_weaver>NiAsterisk: you can choose a different directory (e.g. /var/tmp) to perform builds in by setting the TMPDIR environment variable in the environment that guix-daemon is run in. <mark_weaver>suitsmeveryfine: I'm not sure what you mean. the only analogue I can think of is that when building 'guix', the bootstrap binaries of all architectures are downloaded. <NiAsterisk>I could do that... thanks. I'll see if it fails again now, if it doesn't i'll see what happens tomorrow, i'll be off to bed now <suitsmeveryfine>So I might need to leave this over the night. After init is complete, can I then safely halt the system? <Emas>is there a way to fix this "id-wrapper error attempt to use impure library" when doing a make install? <mark_weaver>Emas: it sounds like you are building software with a mixture of libraries+toolchain from Guix and from your host distro. <mark_weaver>if so, that won't work. when building software manually, you need to ensure that either everything is from Guix, or everything is from the host distro. no mixing. <mark_weaver>because Guix and your host distro most likely use different C libraries. <mark_weaver>Emas: there is a GUIX_LD_WRAPPER_ALLOW_IMPURITIES environment variable that you can set to override the warning, but there's a good chance you'll have problems down the line anyway. <Emas>i actually get this error when trying to build so far three programs ifstat, nginx, and apache httpd on a guixsd <lfam>sneek later tell Emas: I don't think it's necessary to use `make install` on GuixSD. What are you trying to do? <sneek>Last time I checked sneek is a good boy <lfam>sneek: later tell Emas I don't think it's necessary to use `make install` on GuixSD. What are you trying to do? <lfam>sneek: later tell Emas: I don't think it's necessary to use `make install` on GuixSD. What are you trying to do? <mark_weaver>sneek: later tell Emas: all of those programs are available in Guix packages. ifstat is part of the 'iproute2' package. apache httpd is in the 'httpd' package, and nginx is in the 'nginx' package. <sneek>Welcome back Emas, you have 1 message. <sneek>Emas, mark_weaver says: all of those programs are available in Guix packages. ifstat is part of the 'iproute2' package. apache httpd is in the 'httpd' package, and nginx is in the 'nginx' package. <Emas>I just found out about this sneek bot, that's so cool <calher>BTW, I successfully acquired WiFi on the GuixSD live system. <Emas>mark_weaver: i did not know that apache httpd is available in guixsd, i thought it name is apache2 like in debian, but i'm trying to compile because i'm unable to get them to work <Emas>and i meant another ifstat <mark_weaver>Emas: if you build and install software the old way, you'll defeat the advantages of Guix, and also will run into various problems that are dealt with by the package recipes. <mark_weaver>I think you will find that it will take less time, and have better results, to figure out how to get the software in Guix's packages working than to build and install those packages from source code yourself. <Emas>mark_weaver and lfam: will i'm learning how to do that, i wanted ifstat to be my first package in guix but i ran into problems like this ld one <lfam>Did you try making a package definition as shown in that link I gave earlier? <Emas>but that's fine, i'll just learn how to build the package in guix <Emas>lfam: i didn't receive the link, but was it to the gnu guix manuale? <Emas>but have any one actually managed to get nginx to work on guixsd? <lfam>You'll want to adapt that example and put it in your system configuration <mark_weaver>lfam: it looks like the ./configure script doesn't follow the GNU build system conventions. It doesn't understand the variable setting arguments like CONFIG_SHELL=... <lfam>Alright, I'll remove those and keep trying <mark_weaver>lfam: I guess it will need a custom configure phase that passes a simpler set of arguments, and probably various other problems will have to be worked around, since custom configure scripts are usually far less robust than the ones generated by autoconf. <suitsmeveryfine>when I try to boot from GRUB I can decrypt luks but apparently there is no /boot directory <Emas>lfam: thanks!! i'll do that <mark_weaver>suitsmeveryfine: the boot directory should have been created by "guix system init". you didn't pass --no-grub, did you? <suitsmeveryfine>the machine ran out of power and shut down while compiling the kernel so I had to redo init <lfam>mark_weaver: Unfortunately, I don't think I have the knowledge to write a custom configure script for latex2html. <suitsmeveryfine>is it likely that this suddent shutdown corrupted the whole installation? <mark_weaver>lfam: it's probably better to just disable the tests that depend on latex2html <lfam>I'll dig a little to see what Debian does but I think you are right <mark_weaver>lfam: sorry, you don't need to create a custom configure script. I was saying that you need to create a custom configure *phase* in guix. <lfam>Ah, that I can probably do <lfam>I like this line in the nixpkg for latex2html: broken = true; <mark_weaver>after you already have a working system, the commands that add a new system are safe, because they just add more stuff and then switch a symlink. but the initial installation with 'guix system init' is another matter. <mark_weaver>lfam: actually, I would have expected latex2html to be part of the tex2html package, somehow. <mark_weaver>it seems rather strange for tex2html to depend on an external latex2html package. <lfam>I mean... is it uesful? Should I bother? <lfam>Is it a new test for texi2html that we don't need? <mark_weaver>it would be interesting to see if the older version of texi2html performs the same tests. <lfam>Is texi2html what builds the html version of guix.texi? <mark_weaver>well, rather, whether texi2html on the master branch does those tests. <suitsmeveryfine>mark_weaver: it appeares that /boot doeas actually exist but libreboot's grub refused to show it in the tree <mark_weaver>note the description of our texi2html package. it appears to be orphaned upstream. <lfam>Oh, just like latex2html, until a couple months ago when someone merged 7 years of patches from Debian <mark_weaver>lfam: for now, I think we should just disable the tests that depend on latex2html (assuming that this is the problem). <lfam>Yes, I don't think this is worth fixing properly <mark_weaver>it still contains lines starting with "S: (no latex2html)" <mark_weaver>so I guess the problem is different than we guessed. <lfam>Yes, and the test README for texi2html says that the relevant tests are skipped if latex2html is not found <mark_weaver>texi2html is a perl program. I guess that the perl upgrade somehow broke it. <lfam>Did we keep the old Perl in the tree? <mark_weaver>no, and it may have a security flaw that's not trivial to backport. <lfam>Maybe we can make lilypond not depend on texi2html. That is the only user <mark_weaver>it looks like only a few packages depend on texi2html. so it's probably not a high priority. <lfam>Although `guix refresh -l` reported the lilypond user frescobaldi instead of lilypond. That's not what I expected it to do. <mark_weaver>yeah, for some reason which I've never understood, it doesn't print the full list of dependent packages, but only a set of packages that, if rebuilt, would force rebuilds of all the dependent packages. <lfam>It re-uses the code from `guix graph` now, right? <mark_weaver>although it also sometimes drastically underestimates the number of dependent packages, because there are certain kinds of dependencies that it cannot see. <lfam>sneek: later tell rekado: We'd better ask rekado what to do about lilypond and the failure of its dependency texi2html, which seems to be related to the perl update <lfam>I'm deleting my latex2html branch <lfam>Talk about a wild goose chase :p <lfam>mark_weaver: Are we affected by CVE-2016-1572 (ecryptfs-utils)? We don't have a package of that name but I'm not sure if it's under some other name <mark_weaver>lfam: I don't think we have any such package. searching for "ecrypt" in gnu/packages.scm doesn't turn up anything. <lfam>I subscribed to DSA. I'll help where I can <Emas>guix gc --list-dead shows the directory /gnu/store/p8hp..-grub-2.00 which is used in /boot/grub/grub.cfg , is this a bug or did i do something wrong while installing GuixSD <Emas>is there a way to stop guix gc from deleting it? <mark_weaver>Emas: you can add gcroots by adding symlinks to /var/guix/gcroots/ <mark_weaver>anything it points to will be scanned for references to /gnu/store/... and protect those from garbage collection. <mark_weaver>Emas: /var/guix/gcroots/grub.cfg should be a symlink pointing to a file in /gnu/store with the same contents as /boot/grub/grub.cfg. is that the case? <Emas>i'v installed guixsd before and it did remove the directory, so i had to reinstall it cuz' i don't know what else it got rid of, after the second installation it shows in the gc list <Emas>there is no grub.cfg there <mark_weaver>did "guix system init" print an error and exit prematurely? <Emas>but i didn't use guix pull before guix system init <mark_weaver>well, that's okay, it shouldn't have caused a problem. <mark_weaver>(except that if you haven't since updated you will be missing some important updates such a security fixes) <mark_weaver>did you use the USB installer, or the binary installer, or build from source? <mark_weaver>that symlink should have been created as part of 'guix system init'. <Emas>ya will it's not there, i'll create one as you said in /var/guix/gcroot/ <mark_weaver>better to run, as root, "guix pull" and then "guix system reconfigure <CONFIG-FILE>" <mark_weaver>that should create the symlink. if it doesn't, we can investigate. <mark_weaver>that will also apply security updates to your system <Emas>okay will do that and report back. <mark_weaver>well, it will update to the latest packages, more generally. <Emas>mark_weaver: ya that did it, thanks ***nckx is now known as nckx|offline
<sneek>rekado, lfam says: We'd better ask rekado what to do about lilypond and the failure of its dependency texi2html, which seems to be related to the perl update <rekado>lfam: I didn't quite understand what's wrong with texi2html. Can't we just try to fix it? <rekado>I wouldn't want to patch lilypond's convoluted build system to do without texi2html. <lfam>rekado: We couldn't figure out why texi2html wouldn't build. mark_weaver suggested there could be some incompatibility with the version of perl in core-updates. <rekado>I'd like to have a build-system argument #:debug? to easily enable building of debug symbols. <Guest86323>rekado: I'd *love* that. I'd love to keep debug symbols everywhere <rekado>maybe is it enough to delete the "strip" phase. <rekado>debugging C++ with GDB is hard :( <rekado>but the symbols I have don't really help <rekado>the code is fairly clean (as far as that's possible with C++), but the symbols are a mess. <rekado>I blame templates for now until I have a better scapegoat. <civodul>rekado: GCC installs libstdc++ pretty-printers for GDB <civodul>if you allow GDB to load them, it's OK <rekado>civodul: this doesn't seem to help in my case. <rekado>I allowed loading of libstdc++ stuff, but I don't recognise any change. <rekado>I'd like to see the value of one variable defined and assigned in the current function but there's just too much stuff. <civodul>what do you mean? is it optimized out or something? <civodul>ACTION just read the nice interview of joeyh in LWN <rekado>"info scope" shows me pages of symbols, none of which seem to matter. <rekado>"bt full" doesn't contain the value I'm looking for. <rekado>never had problems using gdb with programmes written in plain C <rekado>I'm probably doing something wrong and should be reading the gdb manual... <mark_weaver>davexunit: good morning! How did your presentation go? <mark_weaver>I had to set it back a few hundred builds for a libtiff security fix <davexunit>unfortunately, my recording attempt failed miserably and froze my computer about 10 minutes into the talk. <davexunit>luckily, they had a camera of their own that recorded the whole thing. <davexunit>so when that's available I'll let people know. <davexunit>just know that I'm not as good or experienced as civodul, so things aren't as smooth! <civodul>you already brought one person on help-guix, which is a good sign! :-) <davexunit>but people seemed into it. got asked a lot of good questions. talked with people for nearly an hour afterwards, too. <davexunit>civodul: yes, he was really grilling me on that subject! <civodul>mark_weaver: it seems not-so-bad; only 40 failures compared to master? <mark_weaver>civodul: yes, we are making progress, although with 5000+ queued builds there may be more failures yet to be seen. <mark_weaver>hmm, I don't know what just got added to his database or how to remove it. <civodul>just not yet on the Scheme side, heheh <civodul>we can partly do that using http_proxy + Privoxy, but it's not very convenient <civodul>also i wonder how hard it would be to put a Let's Encrypt certificate on hydra.gnu.org <civodul>and have nginx serve things over HTTPS <davexunit>civodul: it's not too hard. guix has letsencrypt that so that's one thing down. <davexunit>for maintenance, you would set up a cron job that regenerated the cert every so often (90 days max) and run 'nginx -s reload' <mark_weaver>civodul: our qemu package probably has security flaws, but I'm not in a good position to update that package for various reasons, e.g. my x86_64 machine doesn't support KVM. <mark_weaver>I guess that updating to the latest qemu release isn't good enough. more patches will be needed I think. <civodul>i can't look into it right now, but i can try later if nobody beats me at it <civodul>'guix lint -c cve qemu' reports nothing, it doesn't seem to be very good, not sure why <mark_weaver>civodul: yeah, I'm not sure where the fault is there. I suppose it's possible that somehow our qemu doesn't need updates, but I'd be surprised. <mark_weaver>btw, I've found that xen security updates are sometimes (usually?) applicable to qemu. <mog>davexunit, didn't get a chance to tell you last night. good talk. <davexunit>mog: thanks! now I don't know which face belongs to this nick! <mog>really? i was one bugging you with all the nix stuff <mog>i do want to try shepard on my box now though <davexunit>I like it. I think it needs tweaks to become more easily hackable, but I really enjoy using it to manage my user services. <mog>has name change not propagated btw ? i can only seem to find dmd <davexunit>things have been in the process of migration for the past week or so <davexunit>so if you spot an inconsistency somewhere, that's why. <mog>ya i had heard about dmd before when i was looking at guixsd in past <davexunit>the big feature that Shepherd needs is "live hackability" <davexunit>we need to be able to give it a whole new set of services on the fly. <mog>i just have been very big into not doing anything as root since getting into nixos, and i dont like dealing with systemd as a user so this seems like good option <davexunit>is systemd difficult to deal with as an unprivileged user? I've never tried. <mog>it isnt really, its just not documented much as most everyone else just deals with everything at root level <taylan>on Debian 8 one gets a user instance that one can control via systemctl --user <mog>right thats the way it is on every os ive found <mog>ill get systemd to start shepard for me <mog>i meant to ask you that at talk davexunit why dont you use shepard to start your shepard? <mog>taylan, thanks for link <davexunit>but I haven't had any real issues with having XFCE start it. <mog>right but i meant as a guixsd default <mog>have shepard look for user shepards and start them <mog>ACTION is very anti root <davexunit>mog: that's probably a good idea. we could easily write a 'user-shepherd-service' constructor that did this. <mog>being able to start and manage services is an annoying part of doing things as a user <taylan>to be honest, the traditional user management of Unix seems like an odd fit for *personal* computers. one could say it merely serves as a half-baked "sandboxing" mechanism for programs. https://xkcd.com/1200/ <davexunit>this is where I think Hurd would be an improvement, despite conforming to various POSIXy things. <calher>Why is Chromium not accepted as free? <davexunit>I'm actually not sure what the problem with Chromium is <davexunit>it's definitely a technical challenge to package. <davexunit>but from a licensing standpoint... I don't know. <mark_weaver>I haven't investigated Chromium, but the most likely issues to come up in a browser are: (1) steering the user to installing non-free software, e.g. plugins, and (2) no spyware. I vaguely recall that every key that you type into the location bar might be sent to Google immediately, which might be considered a spyware issue. <mark_weaver>recently, there was an issue with Chromium where it would silently download non-free software the first time it was run. I don't know what the status of that is. <davexunit>I would have expected to see an icecat/iceweasel like fork of chromium by now. <mark_weaver>they list these issues: Problem: (1) Copyright or license of some code is unclear. (2) Links to proprietary plugins. <mark_weaver>so we'd need to investigate and address those issues <davexunit>learned a few things about other software, too. <NiAsterisk>rather offtopic, but what am I looking for in notes how to do it, when I want: clone guix from savannah, push local changes to notabug and keep it up to date? I want to do this for when I don't want to take my harddrive with me... do I git clone guix from savannah, then add my remote at notabug and then? <davexunit>NiAsterisk: just add multiple remotes, yeah. <NiAsterisk>checkout the savannah part, then push to notabug? that easy? oh :D <erased>non-guix related question but you guys seem to talk about a variety of stuff. What are some email services that don't require thing such as phone verification or already having an email account? <NiAsterisk>the only policy is that you have to agree to their manifesto or share it <erased>oh, i was expecting something *chan related because of the url ('autistic') <NiAsterisk>it's 15 years now in service, one breach in the very beginning. I'm using their services for 6 years now iirc and they are okay. <NiAsterisk>tor friendly etc, run their own CA, but i don't want to advertise :) that's just my experience <erased>Yeah, seems like an awesome service <erased>And tor-friendly is a very nice thing to have since I use tor heavily <erased>Their manifesto is nice as well, I agree with their views. <erased>Though guaranteeing a logless service presents a false sense of security, so I don't see the point in making such a statement <NiAsterisk>i used to hang out on their irc.. there was an bigger outage just before the opening of this new big bank in frankfurt, several activsts networks got ddos'ed some for 30 dayss and more, but A/I handled it very well, one server replaced, 4 days later it was okay <NiAsterisk>yeah, I don't agree with many of their technological claims these days <NiAsterisk>my intention years ago was to start a similar collective with people I know, but my view on security etc changed. <mark_weaver>erased: I've heard many good things about riseup.net <mark_weaver>(I haven't tried them myself because I run my own email server) <NiAsterisk>i heard they timeout very often, people often ask me about alternatives to riseup <erased>people always yell at me when i start thinking about running an email server <erased>because they say securing your own email server is incredibly difficult and that I won't be able to combat spam <erased>I'll set one up eventually, just don't have the internet connection to do so right now <efraim>mine's been working out alright so far <NiAsterisk>it would be too much work i don't want.. when I have my domains back I outsource it to friends who can then care about blacklists etc. <erased>NiAsterisk: it seems that the service does require an email address, for confirmation purposes <NiAsterisk>yes right. you get an confirmation link in that email, but iirc it would be possible without or just a temporary address <erased>no need to apologize over a small thing <erased>seems like it could take weeks to get a riseup email address. <erased>anyone here by chance have an invite code for riseup? <NiAsterisk>i don't know about the signup process at protonmail anymore, but i would avoid them. I gave them two last feedbacks before destroying my last address, it's horrible that they push such bad things to a public beta <lfam>The Zsh test suite runs a Zsh script. How can I provide a Zsh interpreter for the build environment which is building Zsh? Should I use the interpreter built in the build phase? <bavier>the texi2html tests are failing because of diagnostic output from perl <bavier>the tests diff against expected output <bavier>CompanionCube: have you read the manual? <bavier>watching some of the videos on www.gnu.org/s/guix might also be nice, if you have time <mark_weaver>lfam: for Zsh, using the interpreter built in the build phase sounds like the right approach <mark_weaver>bavier: thanks for looking into texi2html. would it be feasible to run 'substitute*' over the files containing expected output, to make them conform to the new perl? <bavier>mark_weaver: possible, but might not be easy <bavier>the text contains the name of the tool used to process the input <bavier>that is, texi2html, texi2any, or makeinfo <bavier>it might be easier to fix the warnings, but my perl-foo is not great <mark_weaver>maybe the substitute* could work on the parts before and after the tool name, independently? <mark_weaver>or, if the number of tools is small, there could perhaps be a loop running substitute* for each tool name. <mark_weaver>ah, so there's additional output, not just changed lines. <bavier>we could possibly patch the test runner to filter such lines from stderr <civodul>bavier: i think it would be OK to turn off tests for texi2html, if fixing them is too much work <suitsmeveryfine>Path '/mnt/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting <civodul>actually, i think texi2html became makeinfo in Texinfo 5 <mark_weaver>suitsmeveryfine: /mnt/boot is on an encrypted partition, right? <bavier>civodul: it did, but some packages still use the old texi2html <mark_weaver>suitsmeveryfine: okay, so GRUB is actually being smart about this. It realizes that it will not be able to load its modules. but we realize that we won't be using that grub anyway. <mark_weaver>suitsmeveryfine: please give me a couple of minutes to investigate whether your system will be bootable now anyway. <lfam>lilypond is the only user of texi2html <mark_weaver>suitsmeveryfine: it looks to me like the only thing that didn't get done was to create a symlink in /mnt/var/guix/gcroots/ pointing to the grub.cfg file, which will protect some things from garbage collection. <mark_weaver>suitsmeveryfine: so, here's my suggestion: for now, don't run "guix gc", and we'll get the symlink fixed up. <mark_weaver>civodul: how can we find the name of grub.cfg in /gnu/store that would have been symlinked at /mnt/var/guix/gcroots/grub.cfg ? <civodul>mark_weaver: 'guix system build -d foo'? <mark_weaver>civodul: is there a way to properly unmount the target after USB installation? I'm not sure with the cow-store thing. <mark_weaver>civodul: grub.cfg is part reachable from the system, is it? <civodul>mark_weaver: "reboot" should unmount things cleanly <civodul>so to get the grub file name is a bit trickier <civodul>guix gc --references $(guix system reconfigure configuration.scm -d )|grep grub <petter>suitsmeveryfine: where you cd'ed into /mnt when you tried umount? <suitsmeveryfine>by the way, I've now rebooted and I'm stuck at the early phase of linux <petter>try hitting enter, anything happen? <petter>ok, because it doesn't print anything when you type in the password <suitsmeveryfine>mkinitrd -c -k 4.2.5 -f ext4 -r /dev/cryptvg/root -m usb-storage:xhci-hcd:usbhid:hid_generic:mbcache:hid:jbd2:ext4:i915:hid_apple:ohci-hcd:evdev:uas:xhci_pci:xhci_hcd -C /dev/sda5 -L -u -o /boot/initrd-4.2.5.gz <suitsmeveryfine>ok. But besides this hardware-specific issue, installation seems to have worked <suitsmeveryfine>I could find 'configfile (crypto0)/boot/grub/grub.cfg' which gave me a new GRUB menu <calher>I'm trying to make a Chromium recipe. <petter>right. I actually haven't "flashed" it into Libreboot yet, because i like typing the commands. But you can create a menu entry in Libreboot Grub that does this. <petter>It should be possible to skip the GuixSD grub.cfg as well, with some symlinks to boot the current setup. And have a another menu entry that goes to GuixSD grub.cfg <petter>suitsmeveryfine: right. Didn't know if you had read this <suitsmeveryfine>also, to decrypt i had to use the command `crypomount -a` instead of `crypomount ahci0,gpt1` <suitsmeveryfine>Yes, so what do you wish to do with the guide, integrate it into the guix docs? <petter>or mention both i guess. Someone may have a disk with encrypted partition they don't want to decrypt at this stage. <mark_weaver>suitsmeveryfine: might an external keyboard work for now? <mark_weaver>if that doesn't work, it might help to try plugging the USB keyboard in before booting. <suitsmeveryfine>it didn't when I tried this on parabola but unfortunately I didn't try it now <mark_weaver>if it's possible to boot the installed system, that would be preferable. <mark_weaver>suitsmeveryfine: is this one of the MacBooks that's supported by Libreboot? <petter>i think this part with encrypted root belongs in the GuixSD manual <petter>and even encrypted/unencrypted /boot as well <suitsmeveryfine>francis doesn't have a macbook though so I'm doing the testing on this particular device <suitsmeveryfine>I'd like to document and have the hardware-specific issues fixed. Others are working on it too <mark_weaver>suitsmeveryfine: section 7.2.11 (Initial RAM Disk) of the Guix manual explains how to add extra modules to the initramfs. <mark_weaver>but it's not clear whether we need more modules or fewer. <suitsmeveryfine>mark_weaver: I see, so what the slackware user did (see above) isn't obvious to you? <mark_weaver>suitsmeveryfine: well, the slackware user seems to have added additional modules to the initramfs. <mark_weaver>and the user at the end of that bug report I just cited, who is using GuixSD, seemed rather to remove some modules. <suitsmeveryfine>but the GuixSD user didn't have a problem when using an external keyboard <mark_weaver>I guess that works after the system has booted, but maybe not early enough to type in your luks password. <suitsmeveryfine>yes, I guess so too since I can use the keyboard in the guixsd USB installer <mark_weaver>unfortunately, although we provide an easy way to add more modules to the initrd, we don't provide an easy way to exclude 'usbhid'. <lfam>Gah so annoying all the module and input lists out of order <civodul>mark_weaver: with 'modules.blacklist' on the kernel's command line <civodul>not idea, because the .ko file is still embedded in the initrd <mark_weaver>and that command line argument can be added interactively from within grub! <mark_weaver>civodul: so, would it be "modules.blacklist=usbhid" ? <civodul>mark_weaver: the syntax you give is correct; it can even be a comma-separate list, like modprobe.blacklist=usbhid,usbkbd <civodul>yeah, it's actually modprobe.blacklist <civodul>suitsmeveryfine: beware, this is a very new thing <civodul>i'm not saying "new" as in "broken", but rather as in "make sure you're using the latest master" <lfam>You can put it in your OS declaration <civodul>suitsmeveryfine: in GRUB you need to type 'e' to edit the entry <civodul>and then, on the line that starts with 'linux', you must append "modprobe.blacklist=usbhid" <civodul>didn't know they could run libreboot <civodul>could be problematic if it gets too hot <mark_weaver>civodul: yeah, I'm trying to avoid asking suitsmeveryfine to run "guix system init" again, if possible. <NiAsterisk>slightly offtopic.. dd if=/dev/urandom count=1 2 > /dev/null | uuencode -m - | sed -ne 2p | cut -c -8v1/oVN+S i have discovered this snippet while cleaning out my room, but the cut part seems wrong.. any idea what could be wrong with cut after -c ? <mark_weaver>it's not explicitly listed in the set of modules included in the initramfs, but it might be pulled in as a dependency. <mark_weaver>suitsmeveryfine: please try both "module.blacklist=usbkbd" and "module.blacklist=usbhid,usbkbd" <mark_weaver>the quotes should not be included in the linux command line, to be clear. <mark_weaver>(linux will silently ignore arguments that it doesn't understand, iiuc) <jin>hi suitsmeveryfine, i test on macbook10 removing module with an external keyboard , with 'rmmod usbkbd usbkbd' and later push some key of the macbook <mark_weaver>jin: thanks! suitsmeveryfine has the additional complication that he needs to use the keyboard during early boot, to mount an encrypted root filesystem. <mark_weaver>and perhaps the initramfs lacks some needed modules which are available after the system is fully booted. <suitsmeveryfine>since blacklisting modues isn't working the next step is to add modules, isn't it? <mark_weaver>there is a "hid-apple" module that you might need, but that doesn't explain why an external USB keyboard doesn't work. <rekado>blacklisting usbkbd should still be done, though. <rekado>you don't want the keyboard to be served by usbkbd <calher>I can't get the source code to Iridium. I wanted to make my first Guix recipe. <lfam>calher: What's the issue? <mark_weaver>suitsmeveryfine: okay, so you'll need to reinstall from scratch, but with a modified OS config, with additional modules added to the initrd. see section 7.2.11 (Initial RAM Disk) of the Guix manual <rekado>usbkbd is used for USB HIDBP (boot protocol), that's not the right module for generic USB HID hardware <mark_weaver>suitsmeveryfine: I would recommend omitting the module.blacklist from the OS config for now. <suitsmeveryfine>mark_weaver: is it not possible to just update the system from inside the live installer? <mark_weaver>civodul: can you answer suitsmeveryfine's question above? ^^ <rekado>HIDBP and HID are mutually exclusive; you can only use one or the other. <mark_weaver>once you have at least one working system generation, it's trivial to play around with new systems with safe rollback. <civodul>suitsmeveryfine: hmm i don't think it's possible <mark_weaver>but if you have problems with the initial install, it's a major pain. <civodul>suitsmeveryfine: or maybe it is: chroot into the root file system and run 'guix system reconfigure' from there <civodul>mark_weaver: yeah, we need to improve this <suitsmeveryfine>Would it be possible if I mount the file system and then run `deco start cow-store /mnt`? <mark_weaver>well, for one thing, guix system reconfigure doesn't even have an argument for the target filesystem. it assumes that it will modify / <mark_weaver>and I've heard many reports of "guix system init" failing if the target filesystem is already populated, although maybe that's been fixed, dunno. <mark_weaver>I don't know how the chroot is going to interact with whatever magic is done by grub-install <mark_weaver>although maybe it doesn't matter, since you're not using our grub anyway. <civodul>suitsmeveryfine: presumably, from the installation media, you can run: chroot /mnt $(type -P bash) <suitsmeveryfine>It would be very time consuming for me having to reinstall for every module I try to add <mark_weaver>civodul: but wait, what will happen when "guix system" tries to talk to guix-daemon, which is still running in the outer root? <civodul>i don't understand though: there's no keyboard issue when running the installation image? <Jookia>mark_weaver: Maybe guix-daemon should be spawned within the chroot? <mark_weaver>civodul: presumably it works because all the daemons are started, e.g. udev, etc. <mark_weaver>whereas here we need the keyboard to work during early linux boot. <civodul>no difference compared to the installed GuixSD <suitsmeveryfine>with encrypted installation only initramfs starts and then it asks for luks password <civodul>so, chroot, and then yes, as mark_weaver says, guix-daemon must be started in the chroot <civodul>painful to have to go to great lengths like this :-/ <suitsmeveryfine>yes, but I'm doing this now for every other macbook2,1+libreboot+guixsd user <civodul>suitsmeveryfine: in that case, try: chroot /mnt /mnt/gnu/store/*-bash-*/bin/bash <mark_weaver>civodul: does guix-daemon listen on a TCP socket or Unix domain socket? <suitsmeveryfine>which is strange because it does print '/run/current-system/profile/bin/bash' in the first case <civodul>mark_weaver: unix-domain, under /var/guix/daemon-socket/ <civodul>suitsmeveryfine: can you find a 'bash' executable under /mnt/gnu/store? <mark_weaver>civodul, suitsmeveryfine: how about: chroot /mnt /mnt/bin/sh <civodul>/bin/sh may be nonexistent at this point <civodul>unless the installed system was booted before <mark_weaver>civodul: is the second argument to 'chroot' interpreted within the chroot or outside of it? <petter>maybe helpful: find /gnu/store -path '*-bash-*/bin/bash' <mark_weaver>civodul: ah, so /mnt/gnu/store doesn't exist within the chroot <civodul>oh right, the "/mnt" needs to be stripped <mark_weaver>suitsmeveryfine: how about: chroot /mnt /gnu/store/*-bash-*/bin/bash <suitsmeveryfine>Well, if you haven't figured out a way to reconfigure a system from inside the USB installer I could try a complete new installation <suitsmeveryfine>but then I'd like to know with which modules and at which order the keyboard will be recognized <civodul>suitsmeveryfine: can you try: echo /mnt/gnu/store/*-bash*/bin/bash <petter>if he'll be reinstalling a couple of times i guess he could base his config off the bare-bone example instead - less packages to install <petter>isn't everyone on IRC male until proven otherwise?? :) <petter>paroneayea: have you tried getting a GuixSD machine up and running at Serveraptor? <petter>i have tried, but unsuccessfully <lfam>Does Bash require Bash at build-time? <civodul>suitsmeveryfine: so now you need to find a guix-daemon binary in there and to start it, with --build-users-group=guixbuild <paroneayea>petter: I haven't, are they now claiming to support guix? <civodul>lfam: a Bourne shell is required to run ./configure <paroneayea>petter: if they claim to support guix I'll be interested in trying <lfam>civodul: Do we use a Bash binary to bootstrap it? <petter>(for what it's worth, this "everyone is male until proven otherwise" is a reference to something i thought would be recognized. It was meant as a joke) <petter>paroneayea: yes. GuixSD shows in their list. But i got a Server Failure earlier when i tried <paroneayea>petter: I figured it was a joke, and no worries :) <paroneayea>it's unfortunately often a policy that people *do* take <civodul>lfam: yes, see "Bootstrapping" in the manual <lfam>I wonder if the Zsh failure is related. It has many shebangs referring to /bin/zsh <suitsmeveryfine>civodul: the echo command inside the chroot only returns the argument <petter>paroneayea: i can let you know when i get a GuixSD machine up and running there <civodul>suitsmeveryfine: export PATH=/run/current-system/profile/bin <civodul>suitsmeveryfine: echo /gnu/store/*-guix*/bin/guix-daemon <mark_weaver>civodul: maybe look for the system instead, and then set PATH to point to its profile? <Jookia>Shouldn't you be able to find guix-daemon in the root profile <mark_weaver>searching for each program like this will be tedious <civodul>right, but hopefully /run/current-system/ is a valid symlink <suitsmeveryfine>I'm running the binary with --build-users-group=guixbuild but nothing seems to happen <lfam>suitsmeveryfine: The daemon blocks. You have to background it if you want to do something else <lfam>Do you have any other TTYs? <lfam>Then I would leave the daemon in the foreground on one TTY and issue commands in another <lfam>To be fair, none of us went through the nightmare you are currently experiencing ;) <Jookia>Well, I'll probably be next- I have a T400 with no screen for GRUB and I plan on having an LVM + LUKS encrypted install ;)