IRC channel logs


back to list of logs

<mark_weaver>suitsmeveryfine: that indicates that a problem happened with the network transfer. restart the command.
<suitsmeveryfine>I just run the command again without fallback?
<mark_weaver>obviously there is room for improvement here. so much to do :)
<mark_weaver>suitsmeveryfine: yeah
<suitsmeveryfine>ok, i'm downloading again
<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 which can then be send by someone who has an github account to the project upstream? not that I have ever written a, but documentation looks okay
<NiAsterisk>*patch be used in guix before it gets merged
<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>PRs open from 2014
<petter>ACTION goes to sleep
<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?
<suitsmeveryfine>btw, I forgot to change the cryptsetup -> cryptomount thing
<petter>suitsmeveryfine: yes. God natt! :)
<NiAsterisk>hm. I'll take a look how works, currently I'm comparing and looking over NixOS packages, freebsd ports etc for comparison of how things were solved at their ends.
<suitsmeveryfine>petter: sov gott!
<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 is a reputable source for Latex related packages? I can't find any in our tree, but latex2html only seems to exist on 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?
<suitsmeveryfine>no, should I have?
<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>7.1.4 Proceeding with the Installation
<suitsmeveryfine>petter told me to jump straight there after saving the configuration file
<NiAsterisk>did you run guix pull to get the latest master?
<lfam>suitsmeveryfine: How did you install the Guix package manager on your system? Using the binary method described here?
<lfam>If so, did you do step 7, which authorizes to serve you binary substitutes?
<lfam>And if so, what is being built?
<suitsmeveryfine>I didn't do any of that
<lfam>Ah, did you build Guix from source, then?
<suitsmeveryfine>I have simply followed petter's guide
<suitsmeveryfine>I believe that is what is happening now
<lfam>Can you link to that guide?
<suitsmeveryfine>This is his guide with some of my additions:
<suitsmeveryfine>I just took his first rough draft and tried to use it as is
<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>no I did this on a clean system
<suitsmeveryfine>I have never used guixsd before. I only test this for the libreboot documentation
<lfam>This is new territory for me ;)
<NiAsterisk>this is GuixSD, not Guix, suitsmeveryfine ?
<lfam>So, you are running from the Guix live USB installer?
<NiAsterisk>the guide does not mention "guix pull" before "guix init system.....
<NiAsterisk>(....= etc
<lfam>I don't know exactly the best course of action here.
<suitsmeveryfine>What do you think is going to happen?
<suitsmeveryfine>petter conveniently went to bed :)
<lfam>The live USB should have substitutes from authorized. Is the file /etc/guix/acl non-empty?
<lfam>That file is where the keys of substitute servers are stored.
<suitsmeveryfine>I can't type in any commands right now
<suitsmeveryfine>it's compiling
<suitsmeveryfine>the installer downloaded lots of compressed files form hydra
<lfam>What is it building?
<suitsmeveryfine>GuixSD with desktop configuration
<suitsmeveryfine>i.e. including XFCE
<lfam>Yes, but what exactly
<suitsmeveryfine>ncurses and stuff
<lfam>You should not have to build anything from source except perhaps linux and bind, because those were updated today and 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.
<mark_weaver>suitsmeveryfine: did you run "guix pull" ?
<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
<suitsmeveryfine>mark_weaver: no I didn't run 'guix pull'
<lfam>Please cancel the compilation and do it
<mark_weaver>we should probably put that in the manual, if it's not already there.
<mark_weaver>lfam +1
<lfam>mark_weaver: they are not following the manual.
<mood>That is not in the manual
<NiAsterisk>it's not in the manual and the guide
<lfam>Okay, good to know. It should go in there.
<suitsmeveryfine>I had hoped petter would tell me all that I needed
<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?
<lfam>`guix pull`
<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
<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 :)
<suitsmeveryfine>I like the guix pull command!
<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>fundraiser note:
<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>lfam: I'll try my best
<suitsmeveryfine>anyway, is it fine to run guix system init now after having pulled everything down?
<lfam>Try it!
<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
<suitsmeveryfine>most people have thinkpads
<suitsmeveryfine>so there might be device-specific issues with this one
<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
<suitsmeveryfine>I agree with mood: maybe also some considerations regarding swap
<suitsmeveryfine>dedicated partition vs swapfile
<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>mood: what section?
<mood>Just linking to would be a lot better
<suitsmeveryfine>+1 to wiki
<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
<mood>lfam: The link is at 7.1.3, step 2, and currently points to
<NiAsterisk>ah, okay
<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 ;)
<suitsmeveryfine>yes it is
<suitsmeveryfine>there are many macbook-specific issues all over the place
<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>Like what?
<suitsmeveryfine>in libreboot or in gnu/linux distros?
<lfam>For GuixSD?
<suitsmeveryfine>ah, well I haven't installed yet so I don't know yet
<suitsmeveryfine>but for every other issue I've tried there have been
<lfam>Let's wait until we have a problem before solving it ;)
<suitsmeveryfine>You have a point!
<lfam>We already have a lot of work to do :)
<lfam>For example, here we are trying to fix a hardware specific issue with a recent macbook:
<suitsmeveryfine>I actually looked at that yesterday
<suitsmeveryfine>because I had problems booting Parabola with full disk encryption
<suitsmeveryfine>the keyboard wasn't recognized
<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>Well, some slackers had the same issue and solved it apparently.
<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.
<NiAsterisk> I found that relatively safe and well thought. not system specific.
<mark_weaver>okay, so it looks like additional kernel modules needed to be added to the initrd
<NiAsterisk>regarding parted etc
<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
<suitsmeveryfine>ok, I'll make a note of that if I run into the same issue again
<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?
<suitsmeveryfine>now I got a build failure again
<lfam>What happened?
<suitsmeveryfine>tar: bind-9.xxxxxx: file changed as we read ut
<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
<suitsmeveryfine>and then
<lfam>The wikis are only necessary because the upstream docs suck
<suitsmeveryfine>cannot build derivation...
<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?
<mark_weaver>lfam: yes
<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
<mark_weaver>fixes for CVE-2015-8704
<mark_weaver>suitsmeveryfine: can you try again?
<suitsmeveryfine>it was one of the "patch-shebang: bind..."
<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..."' ?
<suitsmeveryfine>have a crying baby over here now :)
<mark_weaver>ah, okay :)
***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>well, agreed.
<mark_weaver>I wonder if suitsmeveryfine's clock is set correctly. maybe if it was set to 1970 there might be issues.
<lfam>Oh no ;)
<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
<suitsmeveryfine>no current time is correct
<mark_weaver>hmm, okay
<suitsmeveryfine>jan 21, 2016
<suitsmeveryfine>regarding "patch-shebang: bind"
<mark_weaver>suitsmeveryfine: does this relate somehow to the "tar: bind-9.xxxxxx: file changed as we read it" problem ?
<suitsmeveryfine>the installer ran a long list of
<suitsmeveryfine>pattch-shebang: bind-9.9.8-P3/........... changeing '/bin/sh' to '/gnu/store/aegoaj9ohao-bash-4.3..../bin/sha
<suitsmeveryfine>Shall I upload a picture?
<lfam>Yes, please
<suitsmeveryfine>no /bin/sh'
<suitsmeveryfine>just a minute, also I'm intermittently AFK also
<suitsmeveryfine>(baby issue)
<lfam>I would be crying too if I was having these issues ;)
<mark_weaver>suitsmeveryfine: those messages are expected
<mark_weaver>they happen while building isc-dhcp
<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>the OS configuration file is the desktop file
<suitsmeveryfine>with a few things added, namely: time zone Stockholm, keymap sv_SEutf8
<mark_weaver>suitsmeveryfine: thanks. hmm
<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?
<suitsmeveryfine>on a 256 GB SSD
<mark_weaver>the relevant code is here:
<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>but I don't see how that could possibly me.
<suitsmeveryfine>shall I retry system init?
<mark_weaver>yes please
<suitsmeveryfine>I hope that you don't find this too boring
<mark_weaver>suitsmeveryfine: no worries, I'd very much like to help you get GuixSD installed.
<suitsmeveryfine>I'm glad to hear it
<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
<suitsmeveryfine>Now the installer wants to build everything in bind it seems
<lfam>'tar-1.28/src/create.c' line 1821
<lfam>I believe it is comparing ctimes
<suitsmeveryfine>Is that a command that you want me to run?
<lfam>No, that is the relevant part of tar
<mark_weaver>it's comparing ctime and size of the directory before and after
<suitsmeveryfine>hmm, shall I let it build "bind" or abort?
<mark_weaver>no reason to abort
<suitsmeveryfine>no it seems to be going further
<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
<suitsmeveryfine>header and c files
<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.
<suitsmeveryfine>I understand
<suitsmeveryfine>I read about the security issue
<suitsmeveryfine>I hope the installer will be satisfied with building for x86_64
<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
<suitsmeveryfine>I have 3 GB RAM and no swap. Will I be alright?
<NiAsterisk>from my experience, yes
<NiAsterisk>you would not be able to compile libreoffice from source with this
<lfam>Ha, indeed.
<NiAsterisk>but linux will be okay
<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>maybe it's that. It doesn't matter really
<suitsmeveryfine>I guess that building linux will take several hours...
<suitsmeveryfine>I'm on a core 2 duo 2.2 Ghz
<mark_weaver>yeah, probably two or three hours, I guess.
<suitsmeveryfine>So I might need to leave this over the night. After init is complete, can I then safely halt the system?
<suitsmeveryfine>nevermine. I just read in the manual that i can do so
<Guest86323>mark_weaver: Does TMPDIR affect the derivation?
<mark_weaver>Guest86323: no
<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?
<lfam>sneek: sneek
<sneek>Last time I checked sneek is a good boy
<lfam>sneek: help
<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?
<sneek>lfam, you have 1 message.
<sneek>lfam, lfam says: hey
<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>Got it.
<mark_weaver>sneek: botsnack
<Emas>holy shit
<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>Why is Chromium not included?
<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
<lfam>Emas: You should make a Guix package for 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>(and by the generic building code in Guix)
<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?
<lfam>Yes, the part about making packages:
<Emas>ya i'll work on it...
<Emas>but have any one actually managed to get nginx to work on guixsd?
<lfam>mark_weaver: Trying to build latex2html, the configure phase fails with a complaint about too many hosts and targets:
<lfam>Emas: Check this out:
<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>mark_weaver: I will very soon go to bed but I have one question
<mark_weaver>suitsmeveryfine: okay
<suitsmeveryfine>the installer completed and I have restarted the system
<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
<suitsmeveryfine>but the file /etc/config.scm exists
<suitsmeveryfine>this can't be right, can it?
<mark_weaver>suitsmeveryfine: the boot directory should have been created by "guix system init". you didn't pass --no-grub, did you?
<suitsmeveryfine>well, one thing happned
<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
<mark_weaver>suitsmeveryfine: hmm, I don't know.
<suitsmeveryfine>ok, thanks anyway
<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.
<mark_weaver>ah, okay.
<lfam>I had the same thought
<mark_weaver>well, I dunno.
<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.
<mark_weaver>(involving latex2html)
<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
<suitsmeveryfine>I can see all the files from inside the installer
<suitsmeveryfine>anyway, thanks for today
<suitsmeveryfine>good night
<mark_weaver>suitsmeveryfine: okay, sleep well!
<mark_weaver>lfam: no, we use makeinfo --html to do that.
<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>but I'm not sure that's the problem. look at the build log from 'master':
<mark_weaver>it still contains lines starting with "S: (no latex2html)"
<mark_weaver>but it's lacking all of the D lines
<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.
<mark_weaver>ah, indeed.
<mark_weaver>sure, that would be one option
<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.
<mark_weaver>I don't know.
<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
<mark_weaver>lfam: okay, thanks for investigating!
<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.
<mark_weaver>thanks for paying attention, though.
<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>oh, sorry, I failed to read your first message.
<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>mark_weaver: no
<Emas>there is no grub.cfg there
<mark_weaver>did "guix system init" print an error and exit prematurely?
<mark_weaver>did you pass --no-grub?
<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
<civodul>Hello Guix!
<wingo>ahoy civodul :)
<rekado>hi civodul, hi Guix!
<sneek>rekado, you have 1 message.
<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 :(
<Guest86323>It's even harder without symbols
<rekado>but the symbols I have don't really help
<rekado>there's so much noise
<Guest86323>Write once, read never
<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>it's just really confusing.
<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...
<davexunit>good morning #guix!
<mark_weaver>davexunit: good morning! How did your presentation go?
<mark_weaver>current status of core-updates:
<mark_weaver>I had to set it back a few hundred builds for a libtiff security fix
<davexunit>mark_weaver: it went well!
<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.
<mark_weaver>ah, that's good
<civodul>moin davexunit!
<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.
<sneek>I'll keep that in mind.
<mark_weaver>bah, silly bot
<mark_weaver>sneek: civodul: yes we?
<mark_weaver>hmm, I don't know what just got added to his database or how to remove it.
<mark_weaver>sneek: we?
<davexunit>new nix release:
<davexunit>sha512 support
<civodul>mark_weaver: ok
<civodul>davexunit: we have it too :-P
<civodul>just not yet on the Scheme side, heheh
<davexunit>oh cool :)
<civodul>i was reading this article on Apt-over-Tor:
<civodul>i really want to be able to do that
<davexunit>ooh that's a nice feature
<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
<piyo>good article
<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>(and is non-functional now anyway)
<mark_weaver>see and
<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.
<mark_weaver>but I don't clearly recall the details.
<mark_weaver>okay, I have to go afk for a while.
<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
<davexunit>mog: now I know!
<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.
<davexunit>mog: my config is a bit messy, but here it is:
<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>cool thanks
<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.
<davexunit>and have it "do the right thing"
<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
<taylan>I make use of this to manage my services that don't need root, and wrote a short summary of what I had to do to get it working with my setup:
<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>mog: I could do that. might be better.
<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
<davexunit>sure is.
<davexunit>glad I'm past that particular problem.
<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.
<davexunit>this is where I think Hurd would be an improvement, despite conforming to various POSIXy things.
<davexunit>less emphasis on root.
<calher>Why is Chromium not accepted as free?
<calher>The FS dir doesn't say.
<mark_weaver>calher: Guix conforms to the GNU FSDG, outlined here:
<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>there's an entry for chromium here:
<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>mark_weaver: that is a useful page, thanks!
<davexunit>learned a few things about other software, too.
<davexunit>like VisualBoy Advance.
<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
<davexunit>roughly speaking, yeah.
<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>with various domains to choose from
<erased>what a lovely url..
<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 like riseup, collective run
<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
<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
<mark_weaver>who would anyone yell at you for that? *confused*
<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.
<mark_weaver>I've been running my own email for over 20 years
<mark_weaver>ACTION goes afk
<erased>NiAsterisk: it seems that the service does require an email address, for confirmation purposes
<erased>Sadly, I don't want that.
<erased>guess ill try riseup
<NiAsterisk>yes right. you get an confirmation link in that email, but iirc it would be possible without or just a temporary address
<NiAsterisk>sorry. I forgot about hat
<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
<CompanionCube>so, what's the best way to get started with GNU Guix?
<bavier>CompanionCube: have you read the manual?
<CompanionCube>ACTION goes off to read it now
<bavier>CompanionCube: :)
<CompanionCube>any particular sections?
<bavier>watching some of the videos on might also be nice, if you have time
<CompanionCube>also, for using guix is it recommended to know guile?
<bavier>no, not necessary to use it
<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>you mean modify perl itself?
<bavier>I mean the script
<mark_weaver>ah, okay
<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.
<mark_weaver>well, nevermind my idea :-/
<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>Hi! I got this error at the end of my guixsd installation:
<suitsmeveryfine>populating '/mnt'...
<suitsmeveryfine>Path '/mnt/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting
<mark_weaver>civodul +1
<civodul>i think texi2html is basically dead
<suitsmeveryfine>guix system error: failed to install GRUB on device '/dev/sda'
<civodul>actually, i think texi2html became makeinfo in Texinfo 5
<mark_weaver>suitsmeveryfine: /mnt/boot is on an encrypted partition, right?
<mark_weaver>and this is on a Libreboot machine?
<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.
<bavier>well, notably lilypond
<suitsmeveryfine>mark_weaver: ok, but has the installation failed now?
<mark_weaver>suitsmeveryfine: please give me a couple of minutes to investigate whether your system will be bootable now anyway.
<suitsmeveryfine>sure thing
<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.
<suitsmeveryfine>ok, cool. So I should halt and try to boot into GNU?
<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 ?
<mark_weaver>suitsmeveryfine: sure! make sure to "sync" first.
<suitsmeveryfine>to just run the command 'sync'?
<mark_weaver>suitsmeveryfine: right
<civodul>mark_weaver: 'guix system build -d foo'?
<suitsmeveryfine>mark_weaver: I can't unmount /mnt. Target is busy
<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?
<mark_weaver>anyway, I have to go afk for a while. good luck!
<mark_weaver>civodul: s/is part/is not/
<civodul>mark_weaver: "reboot" should unmount things cleanly
<suitsmeveryfine>ok, thanks civodul
<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>no I don't think so
<suitsmeveryfine>by the way, I've now rebooted and I'm stuck at the early phase of linux
<suitsmeveryfine>maybe initramfs
<petter>guile prompt?
<NiAsterisk>hm, is uuencode provided by sharutils?
<suitsmeveryfine>no, after hardware has been listed
<suitsmeveryfine>I'm supposed to enter a password
<petter>aha, your LUKS password?
<suitsmeveryfine>but the keyboard isn't recognized
<suitsmeveryfine>yep, so I get the same issue as with parabola
<petter>try hitting enter, anything happen?
<suitsmeveryfine>the macbook keyboard issue
<suitsmeveryfine>we talked about this after you went to bed yesterday
<petter>ok, because it doesn't print anything when you type in the password
<suitsmeveryfine>yes, no reaction at all
<suitsmeveryfine>I think I have the same issue as these slackware users:
<suitsmeveryfine>the solution is apparently to add a number of modules to initramfs
<NiAsterisk>yes it is (re: uuencode)
<suitsmeveryfine>This is what the slackware user did to make the keyboard work:
<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>Do you know how I can translate this into guixism?
<petter>i have no idea
<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.
<suitsmeveryfine>petter: yes I know; it's explained in the libreboot docs
<suitsmeveryfine>I need to add modules to initramfs first so that I can log in
<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>yes, maybe two boot entires would be nice
<suitsmeveryfine>also, to decrypt i had to use the command `crypomount -a` instead of `crypomount ahci0,gpt1`
<petter>we should use that in the guide
<suitsmeveryfine>Yes, so what do you wish to do with the guide, integrate it into the guix docs?
<suitsmeveryfine>manual I mean
<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
<suitsmeveryfine>I'm back in the USB installer again
<mark_weaver>if it's possible to boot the installed system, that would be preferable.
<suitsmeveryfine>ok, I exit the installer then and try this
<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
<mark_weaver>petter: agreed
<petter>and even encrypted/unencrypted /boot as well
<suitsmeveryfine>mark_weaver: yes
<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.
<mark_weaver>the most recent (bottom) comment here suggests that the problem might be solved by removing a particular module:
<suitsmeveryfine>mark_weaver: I see, so what the slackware user did (see above) isn't obvious to you?
<suitsmeveryfine>by the way, external USB keyboard didn't work
<mark_weaver>suitsmeveryfine: oh well :-(
<suitsmeveryfine>although the keyboard is listed as found hardware
<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
<suitsmeveryfine>So I guess that I should try both solutions then
<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
<mark_weaver>it's included within the 'base-initrd' procedure
<civodul>mark_weaver: we do now! :-)
<mark_weaver>civodul: oh?
<civodul>mark_weaver: with 'modules.blacklist' on the kernel's command line
<mark_weaver>ah, good!
<civodul>not idea, because the .ko file is still embedded in the initrd
<civodul>but an improvement
<mark_weaver>that's fine
<mark_weaver>and that command line argument can be added interactively from within grub!
<suitsmeveryfine>ah, that's cool!
<mark_weaver>civodul: so, would it be "modules.blacklist=usbhid" ?
<mark_weaver>do you happen to know the syntax off hand?
<mark_weaver>I have to go afk, sorry.
<mark_weaver>good luck!
<suitsmeveryfine>ok, maybe some others can help
<suitsmeveryfine>thanks again
<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
<suitsmeveryfine>civodul: I'm editing the GRUB entry right now
<civodul>suitsmeveryfine: beware, this is a very new thing
<suitsmeveryfine>where should it be added?
<civodul>in 'kernel-arguments'
<suitsmeveryfine>civodul: it's fine; this machine is for testing purposes
<civodul>i'm not saying "new" as in "broken", but rather as in "make sure you're using the latest master"
<civodul>obviously, it's not broken ;-)
<suitsmeveryfine>I see, well yes I'm using the latest master
<suitsmeveryfine>there are no 'kernel arguments'
<suitsmeveryfine>civodul: but I'm in GRUB
<lfam>You can put it in your OS declaration
<civodul>suitsmeveryfine: in GRUB you need to type 'e' to edit the entry
<suitsmeveryfine>that's what I've done
<civodul>and then, on the line that starts with 'linux', you must append "modprobe.blacklist=usbhid"
<suitsmeveryfine>thanks. trying it now
<civodul>that's on an Mac thing?
<suitsmeveryfine>running libreboot
<civodul>oh nice
<civodul>didn't know they could run libreboot
<suitsmeveryfine>they can :)
<civodul>ironic, in a way ;-)
<suitsmeveryfine>there are some issues though
<suitsmeveryfine>like no sleep state
<civodul>oh, ok
<suitsmeveryfine>so it gets hotter than normally
<suitsmeveryfine>it has C state 2 though so it's not a disaster
<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 ?
<suitsmeveryfine>so it didn't work
<suitsmeveryfine>blacklisting the module
<mark_weaver>hmm, maybe you need to blacklist usbkbd also
<suitsmeveryfine>ok, I can try that too
<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.
<civodul>suitsmeveryfine: from i would think that you need to blacklist only usbkbd
<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.
<suitsmeveryfine>I just tried the latter and it didn't work
<mark_weaver>(linux will silently ignore arguments that it doesn't understand, iiuc)
<mark_weaver>civodul: the final comment in the following page suggests that a "hid_apple" might be needed.
<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.
<suitsmeveryfine>no success with "module.blacklist=usbkbd" either
<mark_weaver>and perhaps the initramfs lacks some needed modules which are available after the system is fully booted.
<mark_weaver>suitsmeveryfine: I'm sorry to hear that :-(
<suitsmeveryfine>since blacklisting modues isn't working the next step is to add modules, isn't it?
<suitsmeveryfine>or rearrange the order of some modules
<mark_weaver>suitsmeveryfine: yes
<suitsmeveryfine>I'd like to try what the slacker user did
<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.
<suitsmeveryfine>what's that module doing?
<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
<mark_weaver>I wonder what could be done to improve this.
<civodul>mark_weaver: yeah, we need to improve this
<mark_weaver>ACTION goes afk again
<suitsmeveryfine>Would it be possible if I mount the file system and then run `deco start cow-store /mnt`?
<suitsmeveryfine>after which I run reconfigure?
<mark_weaver>suitsmeveryfine: I don't think so
<mark_weaver>maybe civodul would know better
<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 /
<suitsmeveryfine>I see
<suitsmeveryfine>so how do i chroot then?
<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.
<Jookia>'guix chroot' would be neat
<suitsmeveryfine>parabola has `arch-chroot /mnt /bin/bash`
<Jookia>NixOS has a kinda broken chroot
<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?
<suitsmeveryfine>it was the same thing when I did this with parabola
<suitsmeveryfine>I think because the whole kernel is loaded
<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>i see
<civodul>so, chroot, and then yes, as mark_weaver says, guix-daemon must be started in the chroot
<civodul>the outer daemon won't be used
<suitsmeveryfine>when I tried your command it cannot find bash
<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
<civodul>hoping there's only one match
<suitsmeveryfine>no such file or dir
<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/
<mark_weaver>ah, good
<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
<suitsmeveryfine>no such dir
<civodul>unless the installed system was booted before
<civodul>suitsmeveryfine: ls -l /mnt/bin/sh?
<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'
<civodul>mark_weaver: within the chroot
<mark_weaver>civodul: ah, so /mnt/gnu/store doesn't exist within the chroot
<civodul>oh right, the "/mnt" needs to be stripped
<civodul>sorry about that
<suitsmeveryfine>civodul: cannot access, no such file or dir
<mark_weaver>suitsmeveryfine: how about: chroot /mnt /gnu/store/*-bash-*/bin/bash
<suitsmeveryfine>cannot execute binary file
<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
<mark_weaver>ACTION is stumped for the moment
<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
<civodul>and then strip the "/mnt" part
<civodul>and run: chroot /mnt that-thing
<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
<civodul>(he or she)
<petter>isn't everyone on IRC male until proven otherwise?? :)
<paroneayea>petter: not a good policy!
<suitsmeveryfine>better geek until proven otherwise
<paroneayea>that one's okay :)
<petter>paroneayea: have you tried getting a GuixSD machine up and running at Serveraptor?
<petter>i have tried, but unsuccessfully
<mark_weaver>paroneayea +1
<lfam>Does Bash require Bash at build-time?
<petter> they offer GuixSD machines
<suitsmeveryfine>civodul: it worked!
<suitsmeveryfine>My propt says: I have no name!@gnu
<suitsmeveryfine>fetching food
<mark_weaver>oh right, of course
<mark_weaver>the wildcard was expanded before running 'chroot'
<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)
<suitsmeveryfine>hmm, I tried to type 'ls'
<suitsmeveryfine>but I get command not found
<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
<paroneayea>and I find it sad :(
<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
<paroneayea>petter: awesome
<suitsmeveryfine>so I don't know how to find the guix-daemon inside the chroot
<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>ok, I found the guix-daemon binary
<mark_weaver>ACTION goes afk again
<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
<suitsmeveryfine>If I try to run it with & at the end I get 501
<suitsmeveryfine>and ctrl+z doesn't work after I've started
<lfam>Do you have any other TTYs?
<suitsmeveryfine>yes I can access the manual for example
<lfam>Then I would leave the daemon in the foreground on one TTY and issue commands in another
<suitsmeveryfine>ah, thanks
<suitsmeveryfine>but then I need to chroot there as well
<lfam>Oh man...
<suitsmeveryfine>I could do that of course
<suitsmeveryfine>haha, maybe these steps could be made more convenient in the future
<lfam>To be fair, none of us went through the nightmare you are currently experiencing ;)
<suitsmeveryfine>ah, it's not a nightmare because I have great company here in #guix
<suitsmeveryfine>If I had been on my own it would have been a nightmare
<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 ;)
<suitsmeveryfine>anyway, I have a second chroot prompt