IRC channel logs
2016-11-24.log
back to list of logs
<lfam>I'm not sure what the best mechanism is for this <jeaye>Has GuixSD handled declarative user homes? That's something I've been missing in NixOS. <ng0>lfam: isn't that only for GUIX_PACKAGE_PATH ? <ng0>but it could be a start <jeaye>To work around it, for now, since NixOS allows the contents of /etc to be declaratively specified, I've been putting users there. For example, /etc/user/jeaye would be my home. This isn't ideal though. <ng0>Okay i think i did not understand you correctly, your sentence could mean different things and I'm not sure which interpretation is correct <lfam>jeaye: Yes, please see the manual section 7.5.2 User Accounts <lfam>ng0: I see. You're right, my idea requires users to use GUIX_PACKAGE_PATH or to work from Git. <lfam>Which I think is what such "power users" will do anyways <lfam>`guix pull` is not flexible enough if you have special requirements <lfam>But I think it's good to have a no-configuration "update my system" tool like `guix pull` <ng0>I'd like to look into replacing openssl with libressl globally, or at least leave out those applications where it's uncertain what it'll do (bitcoin was one of those at least 1.5 years ago) and replace the rest <ng0>globally, as the default for guix I meant <lfam>Personally, I'm skeptical of using it for packages whose upstream maintainers ask packagers to use OpenSSL. On the other hand, LibreSSL has a better reputation than OpenSSL. <lfam>We should discuss it on guix-devel <ng0>that's why I said we should use our flexible system and use openssl where it is not confirmed to be tested (not necessarily upstream reports, as upstream can have a tendency to not judge clearly about some problems, depending on the people and projects involved) <lfam>I guess using LibreSSL is not that different from upgrading incompatible versions of OpenSSL, which we will have to do as they drop support for old versions <lfam>In terms of breakage, that is <ng0>we have Gentoo, FreeBSD and OpenBSD to look at in case applications upstream do not support it in code yet <ng0>possibly others, but those I used in the past <lfam>OpenBSD, especially, since they are the LibreSSL experts <ng0>and whatever libressl leaves out which makes openssl non-deterministic, they leave it out and are deterministic build so far. <lfam>ng0: I notice you asked about openssl reproducibility. You should use diffoscope to find out what the problem is :) <ng0>I should learn to use that <lfam>`diffoscope --html /tmp/report.html $(guix build openssl) $(guix build openssl --check)` <ng0>I just thought asking first to see if I start to look into something really obvious <lfam>It will make an HTML report of the differences in /tmp/report.html <lfam>It's a nice little tool :) <lfam>Probably there is a timestamp somewhere <lfam>Maybe they have already catalogued the problem <ng0>i think they are aware of the problem, as past problems were addressed in openssl <ng0>.diffoscope-real: error: unrecognized arguments: /gnu/store/4fdfjp49xhm5vlgm3dqimz5pwblmxjiw-openssl-1.1.0b-static but I'll look into this tomorrow or later this week. thanks <ng0>ACTION tests new luks system <albertoefg>I am thinking of doing a few video tutorials on Spanish on how to install Guix and install and remove software :) <albertoefg>I am not expert so any suggestions on commands I should cover on the video? Besides installing guix, installing and removing a package <ng0>i tested the luks system.. but I think I used the wrong uuid, how do I find out the luks-uuid again? I was able to boot but dropped into guile repl then because guix couldn't find the partition/uuid <marusich>From the guile repl? I'm not sure... maybe there is a guile library to check filesystem details which is available in the repl. Or perhaps, if you can get to an interactive GRUB shell, you might be able to find something in the GRUB manual about how to check for device details? <marusich>should display the UUID associated with each partition <ng0>ah right, blkid not lsbblk <marusich>but when I click on the 'statistics' button (the one with the lady standing pointing at a pie chart) I see no graphs. Is that normal? <marusich>Instead, I see a totally black panel where I expected to see the graphs. <ng0>longer explanation and sentence, one moment <marusich>No problem. If it helps, I see the following message in terminal when I launch gnunet-gtk: "(gnunet-fs-gtk:13076): Gtk-WARNING **: Failed to fetch network locations: Automount failed: Message recipient disconnected from message bus without replying" <ng0>It's problematic, I would no longer recommend installing the one which comes with guix. The only thing which prevents a release so far (and I can understand that) is that cadet is broken once more again which would mean christian would have to release a gnunet with the note of "hey, we have 40+ applications but you can only use gnunet-fs". So, even if cadet is broken I'd try the git. Or read in mantis about <ng0>those problems, they were fixed in some commit in the 2.5 years since the release of 0.10.1 <ng0>though i'm working on the service for shepherd, using 0.10.1 as a base <marusich>I might try to do that sometime; I was just experimenting for now <ng0>I can tell you the svn revision where cadet was okay, but you'd have to find out the git commit yourself <ng0>if you are just experimenting you can build it directly from within the git checkout <marusich>Hope your full disk encryption works out. I'm going to try it soon, too, probably after I get back from my Thanksgiving vacation. <ng0>i'm looking at the log, can tell you soon where it was <ng0>The good thing about broken cadet is, for something which will use -fs I don't have to care about the general broken state. So working on distribution via -fs is safe <marusich>That's good to know. I heard there was some work to use GNUnet for package publication in Guix, but I don't think it's been finished yet. <ng0>people worked on it in the past, i'm reading the old discussions as I only discovered them after I mapped out my own ideas <ng0>I decided to take this as my main topic and motivation when I start university unless I get funding before I do so <ng0>if I used the wrong uuid, can I still boot into the system when I change it in the grub? I think this will work, but I'm not so sure <ng0>and will the grub shell have the ability to let me find out the uuid, or do I have to do something in the repl? <marusich>I suspect the answer to both of those question is "yes", but I'm afraid I don't know the actual way to do it off the top of my head. <marusich>If I were in your situation, I'd start by looking for the crypto-related documentation in GRUB's manual. <jmd>Has anyone ever got "make check-system" to work? <marusich>jmd, the nss tests consistently fail fo rme. <jmd>I'm not sure which test is failing. How can one tell? <marusich>jmd, a list of passing/failing tests should be output at the end. I think it's possible to have the tests fail to launch, in which case you might not get a report at all?> <ng0>marusich: i see no uuid in the grub entry to edit, so I have to do something else <marusich>ng0, I see. I'm afraid I can't think of a more detailed answer, though. Perhaps civodul can assist. <jmd>Yeah it never completes for me. <marusich>I'm not familiar with how GRUB normally handles encrypted devices. <marusich>jmd, I suggest you look up through the output to find errors/failures; there should be something if it failed. <ng0>currently it is --root=/de/mapper/rootfs , where /dev/mapper/rootfs was also used in the config. <ng0>i went by the test example <jmd>Finding failures is not the problem. Finding out to which test they belong is. <ng0>i think there was something like /disk/by-uuid/ <marusich>ng0, I wish I could help more, but at this point I'd just be speculating, which probably wouldn't be helpful. I gotta go get some sleep, also. I'd ask civodul since he just implemented this and probably has an idea. <marusich>jmd, I suspect that if you are not seeing a report of passes/failures, some of the setup failed before any tests could be run. But that's just a guess. Sorry I can't help more! <marusich>you could in theory try running each test individually with TESTS=foo-test, as described in the manual page civodul linked. However, if something is failing before the tests can even be run, that might not help. <jmd>I don't understand why when I say "make check-system TEST=run-basic-test" I still see the message "Running 9 system tests" <jmd>Oh it should be "TESTS=..." <jmd>Hey but now it runs 0 tests. <ng0>kernel /boot/kernel-3.4.0-gentoo crypt_root=UUID=<encrypted partition uuid> root=/dev/mapper/root what I don't see in the guix generated config, is crypt_root <ng0>or something like cryptdevice=UUID=<device-UUID>:cryptroot root=/dev/mapper/cryptroot archlinux wiki <civodul>jmd: grep for '(system-test' in gnu/tests to see the test names <jmd>civodul: the openssh test just kernel panics for me. <jmd>and like marusich said, the nss-mdns test fails. <civodul>jmd: can you send the details of the openssh test failures on the list? <jmd>I'll try to do that tonight. It might be difficult because after failure the terminal locks up. <jmd>Let me try it again now. <jmd>Ah no. The terminal's ok. <jmd>(except for the issues that xterm has always had in Guix) <ng0>civodul: i'm trying the system again with /dev/ instead of uuid <ng0>civodul: works for me for /home on this system <ng0>the test system has only a grub_bios partition before the root partition which also includes /boot <ng0>so I asume it'll work <htgoebel>civodul: Regarding the test-case for "guix gc --keep-going": How to correctly run "guix gc --keep-going" from within the test-suite? <htgoebel>Me fool: delete-paths accepts an additional parameter. I added it myself *gnaa* <ng0>I think you misunderstood me by the limited information I gave away, civodul. But thanks for offering the help. If I fail this time again, I'll go more into detail <htgoebel>Any hints how I can speed up running the test suite (beside "TESTS=tests/store.scm")? This simple one is running since 10 Minutes now, but the log-file is still quite empty. (If I add my test-cases, it fails quickly. Curious) <ng0>I think it should not be impossible hard to "port" guix to sailfish/jolla if the hardware platform is supported <jmd>ng0: But that might be a big "if" <htgoebel>How to I mark a store-object to be "alive"? When doing (t1 (add-text-to-store …)) (t2 (add-text-to-store … (list t1)) and then (delete-paths %store (list t1)), both are delete. I'd assume t2 being "alive" and thus "t1" not being deleted. <rekado>bah, I'm filing email bankruptcy <civodul>htgoebel: store items are live at least for the duration of the session that created them <civodul>so if you do (let ((s (open-connection))) (add-to-store s ...)) <civodul>the thing added to the store is live until you do (close-connection s) <civodul>so in your example, both t1 and t2 are live <htgoebel>civodul: Is there a test-case showing this usage? I can't find a test for the basic function of delete-paths in tests/store.scm, which I could base on. <civodul>htgoebel: the "dead path can be explicitly collected" test proves me wrong, though LocalStore::addTextToStore does add a temp root <htgoebel>civodul: Fine. Unfortunately they fail unexpected :-( <htgoebel>E.g. the second one: if enabling the (remove-permanent-root t3), (file-exists? t2) just below fails. <htgoebel>Seems as if the store gets cleaned up before I can test it. <civodul>oh i think there's a subtle thinko in readTempRoots: <civodul> /* Try to acquire a write lock without blocking. This can <civodul> only succeed if the owning process has died. In that case <civodul> we don't care about its temporary roots. */ <civodul>it can also succeed if the owning process is self <civodul>not harmful in practice because apart from tests processes don't normally build stuff *and* call the GC in the same session <htgoebel>So I'm postponing the whole gc --keep-going patch until this is fixed? Or just the test-cases? <civodul>i just reported the bug and Cc'd you and Eelco (of Nix) <civodul>somehow i must have thought back then that this was normal behavior <civodul>i think quite a few tests rely on this behavior <baconicsynergy>So, sometimes after I install or upgrade a package, guix tells me to add some environment variables. Should I just slap them on .bashrc? <civodul>baconicsynergy: you can simply source ~/.guix-profile/etc/profile from there <baconicsynergy>okay my guix system is currently ship-shape and I've got all of my standard tools and workflow <baconicsynergy>Funny how time flies. I remember two years ago when I first discovered gnu and linux, and here I am now <htgoebel>BTW: Are we using /lib64? I found that the kde-framework is installing there. <civodul>we'd rather not, but it's in GCC's search path <baconicsynergy>i deleted /var/guix/profiles/system-profile-2 and ran guix gc but I don't know if I remembered the right way <baconicsynergy>it would be nice if there was a guix system delete-generations command <ng0>this guix install feels like a gentoo stage 1 install.. everything from source. yesterday it was easier with the first run <ng0>still testing the luks <roptat>is there a package that provides javac? I can't find openjdk <ng0>guix package -s openjdk <ng0>but I have no idea about java <roptat>should have read the description <htgoebel>roptat: We are seeking a brave java-developer for bootstrapping maven :-) <civodul>BTW, happy holidays to everyone in North America! :-) <civodul>i guess none of them is at the keyboard right now ;-) <civodul>rekado: we should synchronize on FOSDEM talk proposals, there's a deadline tomorrow <ng0>network-manager services works now? <civodul>ng0: mostly, but you should try and provide feedback <ng0>if the luks test system is done, I can do it. <nckx>civodul: thanks! ('murrican in exile here.) <ng0>I should abort the luks 2nd build and re-format that.. 12 hours building is too much <ng0>this is what happens when you try to init over a failed first system attempt <ng0>first time I did set up a system through 0.11 medium and guix pull, testing luks with it, something went wrong and I wasn't able to boot into it. so I just tried to init into it again, but it builds the world since this morning <ng0>first run had some substitutes <civodul>normally it you run 'guix pull' in the image, you're at current master <ng0>oh now i have substitues again <ng0>it's nice how I can combine libressl and openssl and not crash the system <rekado>civodul: it’s the distributions track deadline tomorrow. <rekado>civodul: did you want to submit a talk there or would you like me to give it a try? <rekado>I *might* submit a proposal for the HPC track, but I’m not sure if it would be interesting for a general audience. <rekado>I could talk about the experience of using Guix in bioinfo at the MDC, but I think the HPC talks are usually less reflective <civodul>rekado: it'd be nice to have you in the distributions track :-) <civodul>for the HPC track it could be you or Pjotr or Roel, mostly <ng0>yesterday we were wondering, is fosdem plain "let's not get political" tech or is there some room/audience for such, if someone prepared a talk about the broken internet and how to tackle the broken state (summarizing ~very~ roughly what someone I know is preparing) <civodul>rekado: and then we have containers and testing/automation <civodul>i could try one of them, probably testing/automation <rekado>civodul: I haven’t looked at testing enough. I’d love to hear you explain the system tests. <rekado>civodul: I’m new to recurrent participation at conferences like FOSDEM; should I start from scratch in the distros track or should the presentations always be “fresh” and show stuff that wasn’t previously presented? <civodul>rekado: my guess is that the audience is not super aware of Guix{,SD} <civodul>so it cannot hurt if there's some overlap, IMO <civodul>now it's probably good to focus on one aspect after the general intro <rekado>re containers: I feel I know too little about them to give a talk. I could only show “you don’t need Docker for containers” <rekado>that might be enough for a presentation but I’m afraid I wouldn’t be able to answer any questions. <civodul>well, we could simply do the frozen pizza vs. declarative story <rekado>(especially since I haven’t seriously used any of the hip container-based tools) <civodul>i feel less at ease with that one, but at the same time it seems good strategically <civodul>or maybe paroneayea would know? hint, hint! :-) <rekado>I have to go now, but I’ll try to be on IRC tomorrow in the morning and after 1pm UTC+1; will try to prepare a proposal, but I’ll be stuck in meetings for the bigger part of the day :-/ <rekado>civodul: the MDC might have some no-longer-HPC nodes; trying to figure out if some of them can be either donated to the Guix project or used as build nodes in our data centre. <civodul>ok, let's try not to miss the distro track! <rekado>I have no idea if libreboot could work on them. <civodul>there was a possibility at work too, but that was with network cards requiring non-free firmware :-/ <civodul>libreboot works only one 1 or 2 different models of motherboards <rekado>I’ll try to figure out more about these nodes and let you know in case we have chance