<mark_weaver>if someone wants to port Guix to the XNU kernel, take a look at the "Porting" section of the manual. basically it involves using Guix on an already-supported system to cross-compile a set of bootstrap binaries, and then using those bootstrap binaries on the target system to build a natively-built set of bootstrap binaries, and then going from there and fixing problems as they arise. <mark_weaver>I don't know off hand how well XNU is supported by GNU libc and the GNU toolchain. <suitsmeveryfine>lovely, I can't boot the guixsd installer because of a bug in libreboot <_`_>the biggest problem with trying to support XNU (specifically Apple's XNU) is that whatever route you take (native compilation or cross compilation) it'll have a dependency on the xcode-sdk. That fact in of itself seems to conflict with guix's direction. <mark_weaver>suitsmeveryfine: do you know it's a bug? booting the GuixSD USB installer from Libreboot must be done differently than for most other USB installers, because GuixSD's installer is not an ISO image. <suitsmeveryfine>"Search for GRUB configuration (grub.cfg) outside of CBFS from" doesn't work <mark_weaver>_`_: are you sure? so GNU libc, GCC, and binutils aren't able to target XNU? <_`_>mark_weaver: they are but you need to build them with xcode-sdk <_`_>or someone else's prebuilt variants built with xcode-sdk <_`_>the path to bootstrap is from xcode's clang/llvm <mark_weaver>suitsmeveryfine: okay. fwiw, even on the X60, I found that GRUB would only sometimes see the USB stick. as I recall, I had to reboot multiple times, try different USB sticks, make sure they were plugged in before booted, or some combination of those things, to get it to work. <mark_weaver>so it's not possible to cross-compile the GNU C library and toolchain for XNU from GNU/Linux without using components from xcode? <_`_>even the cross compilers use xcode <_`_>os x shouldn't be a desired target because of that but just 2c. :> <suitsmeveryfine>mark_weaver: yes, it's sad that it can be so unreliable. For me, that GRUB entry always work with the latest stable libreboot version but never with the latest unstable ones, with the exact same devices connected. <mark_weaver>so if someone cares about support for XNU, I think the first step is to add support for XNU to GNU libc and the GNU toolchain. <_`_>I'd rather see guix on top of potentially nicer systems like illumos kernel. Additionally a guile interface to its resource controllers instead of the java/C silliness they currently have for it would be neat. <bavier>ugh, trying to fix the ghc package build failures, but now I'm getting an 'unpack failed' with doing 'git push' to core-updates <bavier>aha, didn't have the remote url configured correctly <calher>mark_weaver: Wait, remember that Guix has support for the Hurd now. <mark_weaver>calher: Hurd support is not in the master branch yet. <mark_weaver>there may be some bits in master, but not enough to actually use it. <NiAsterisk>ah, i see. I'm not that deep in osx, barely scratched the surface.. I was only exposed to it for some years back in school with macromedia, I might get back to it to say that I have skills with osx on my CV. <codemac>Getting a weird error running guix on nix, "guix package: error: build failed: derivation ‘/nix/store/678...-guile-bootstrap-2.0.drv’ has incorrect output ‘/gnu/store/d14...-guile-bootstrap-2.0’, should be ‘/nix/store/rzz...-guile-bootstrap-2.0’" <codemac>is there some different way of hashing I must configure? <NiAsterisk>some really nice job offers I see have "OSX administration & user experience" in their requirements. It will be another 2-3 years until I can decide on jobs again, but I can work on projects and skills in the meantime <NiAsterisk>though I wouldn't touch osx otherwise. just "for science" <codemac>If anyone has a successful "guix on nix" nix package, please let me know :) <mark_weaver>codemac: to run guix on the nix-daemon with the nix store location /nix/store, you need to build guix from source, and pass --with-store=/nix/store to guix's configure script before building it. <mark_weaver>and you won't be able to use any of our binary substitutes, so you'll need to build everything from source code. <mark_weaver>because our binary substitutes are built to use /gnu/store as the store location. <mark_weaver>alternatively, run guix-daemon side-by-side with nix-daemon, each with their own store. <mark_weaver>IMO, the latter approach will probably make you happier, because no substitutes means building a *lot* of stuff every time we have a core-updates cycle. <NiAsterisk>running source-based (like this would be/feel like) systems can be very time consuming. <davexunit>this should make it so I can record using a webcam tomorrow <davexunit>yes! I can now record audio/video from a webcam, video from my desktop, and easily combine them into a single video. <Jookia>I wonder how hard it'd be to get a Guix container on Wine using only free software <mark_weaver>Jookia: what do you mean by a "Guix container on Wine"? <Jookia>mark_weaver: Something that's bothered me for a while is that we're close to having a fully free development chain for Windows- we can cross compile and we can test executables in Wine. Unfortunately we still don't have a free way of running GNU/Linux on Windows yet, and by free I mean compilable using only free tools and running with only free software. There's some work on getting MSYS2 to play well in Wine which would kind of be w <xd1le>Jookia: but windows itsef is nonfree ¯\\_(ツ)_/¯ <Jookia>xd1le: This is true, and yet a lot of projects still support Windows. How do we support platforms we can't use? <xd1le>by hoping that cygwin/mingw/whatever works with it? <Jookia>I suppose there's two issues here- developing for Windows which can be done using free tools while ironically we can't develop on Windows using free tools <xd1le>well i suppose we could never really develop on windows with free tools <xd1le>if by develop you eventually also include "testing on that system itself" <xd1le>(because windows is nonfree) <Jookia>We can test using Wine, but there's no free development environments on Windows <mark_weaver>Jookia: why do you want to develop on Windows? isn't it enough to develop on a free system and cross-compile to windows? <xd1le>Jookia: by free development environments, do you mean something like guix containers? <xd1le>also yes mark_weaver raises my first thought in the first case <xd1le>who cares and why bother wasting time on it <Jookia>mark_weaver: I'd probably cry if I had to develop on Windows- it's other people that might want to do it, and one 'solution' is running GNU/Linux in a VM using only free tools somehow <xd1le>imho not having to support windows might be a virtue <xd1le>simply because it's different <xd1le>i've seen the nix people spend a lot of time on getting it to work on <xd1le>windows/worrying about supporting windows in the future etc. <xd1le>supporting nonfree systems is sort of a double edged sword <mark_weaver>Guix is not interested in running on nonfree systems at all. <xd1le>on one hand, you can support it, and then the people on those systems will <xd1le>and will hopefully therefore like free software, the concept <mark_weaver>Running it on Windows is a non-goal for us, and we don't want the added maintenance burden. <xd1le>maybe even be like a gateway drug (in a good way) <xd1le>otoh, supporting nonfree systems could mean less chance for world domination <mark_weaver>Jookia: why spend effort trying to create a fully-free development environment for someone who insists on running it on a nonfree OS? <xd1le>because you would allow them to stay on nonfree systems, instead of putting <xd1le>(and also ofc, you will probably need to spend time on supporting a system <Jookia>mark_weaver: Does Guix support these systems? <mark_weaver>if they want to run a fully-free system on their computer, they can run GNU/Linux on it <xd1le>(but if it's not *too* much time, it could be justified to support nonfree <xd1le>systems for the first case i mentioned above) <xd1le>Jookia: no, guix doesn't support windows if that's what you asked? <mark_weaver>at present, Guix only supports systems based on Linux (the kernel), and we intend to also support the Hurd. <Jookia>If I build a VM image will it work in nonfree VM systems? <mark_weaver>we have no plans to support other systems. Being a portable build system to run on any system is a non-goal for us. <mark_weaver>Jookia: if the VM system faithfully emulates hardware supported by Linux, then I guess the answer is yes. <xd1le>oh, by "nonfree systems" above i was referring to "non free operating <xd1le>so like windows and stuff, not nonfree VMs <Jookia>There's a lot of freedom to be made <mark_weaver>Jookia: making freedom on top of a non-free OS is not something I'm interested in working on. <xd1le>Jookia: Windows can fucking die for all I give a shit. I invite you to preach that to those "other people that might want to do it". <Jookia>xd1le: No need to get so aggressive, especially 4 hours after the discussion. :) <xd1le>sorry, no aggression intended towards you <xd1le>(no passive aggression either in case you think that) :) <Jookia>It's just an operating system- in all likelyhood Windows is dead already given how stagnanted it is <xd1le>also don't do what i just said <xd1le>because that will turn people away from free software <xd1le>if you're aggressive like that <Jookia>There's many ways to turn people away from free software projects, and most of them I've encountered weren't aggressive <xd1le>i just came back from a run, so => impulsive commenting <xd1le>but definitely tell them to reconsider their choice to use windows <xd1le>i just think it's a waste of time, esp when guix doesn't really have the manpower <Jookia>I think there's going to be a time and a place when we'll have legacy systems like ReactOS and Wine running a lot of software, and it makes me wonder where Guix will fit in. Maybe it's decades off <Jookia>But we already see this with things like DOS where we have no free replacements for it <xd1le>but imo who cares. it's not like there aren't free alternatives to windows <Jookia>Well when we want a society where all software is free it's hard not to think of these things <xd1le>also, a lot of software made for windows is nonfree too, so who cares about <Jookia>There's a lot of free applications that run on Windows that don't have ways to import data in to GNU applications or alternatives there <xd1le>well those free applications run on a nonfree system, so from a guix point <xd1le>of view, they require a nonfree dependency, meaning they are nonfree at the end <xd1le>of the day too (not their fault of course), so who cares <xd1le>a good thought experiment may be, what if windows ever does become free? <Jookia>If we start saying that nonfree dependencies make software nonfree suddenly we run in to a lot of problems with what becomes free and what isn't <xd1le>but from a user point of view <Jookia>Is free software that requires hardware-assisted virtualization free considering we don't have implementations of that? <xd1le>as in a windows program might rely on whatever nonfree windows c compiler <xd1le>i guess not, from a practical viewpoint <xd1le>it would 'suddenly' become free if we did <xd1le>and again, who cares about these applications anyway <xd1le>the other issue is technical <xd1le>in that, windows probably doesn't work similar a unix/posix way <xd1le>so if ever say reactos becomes a thing <xd1le>supporting that would probably require significant effort for a port or whatever <xd1le>and also continued maintainence <xd1le>and so there's also an issue of manpower <Jookia>I feel it's a bit weird to say there's an issue on manpower at a future date without information <xd1le>like probably no one using guix probably even cares because they don't use <xd1le>unless like you care enough? and have enough technical aptitude to do something about it? <Jookia>I imagine that'd be the case if it happened <Jookia>I think it's interesting to imagine the platforms Guix could go on, non-POSIX <xd1le>or is it just that, you care about putting guix on other platforms? <xd1le>i think though, that it would be better to promote GNU instead and trying to kill Windows instead <xd1le>because in my opinion, reactos is predominantly pointless, with regards to the free software movement <xd1le>because there's gnu programs for the gnu operating system anyway <Jookia>Ah, so it's not useful for non-GNU systems? <xd1le>imho nix wastes a lot of time supporting non gnu systems like *bsds and mac <xd1le>i'm not aware of it running on non-GNU systems, but i might be wrong. <Jookia>What about after GNU? Would we have to go back to Nix? <xd1le>because guix doesn't run on non-GNU systems to my knowledge <Jookia>It feels kinda weird to act like GNU is the end-all <xd1le>that's why in a general sense we should aggressively copyleft everything so <xd1le>so we that free software infects like a cancer <xd1le>because the free BSDs aren't copylefted <Jookia>xd1le: We can't do better in design, maybe make a GNU2? <Jookia>GNU Hurd is awesome but it's still stuck with POSIX <xd1le>definitely better than Mac or Windows <xd1le>not sure about the free BSDs <xd1le>or other alternative free systems <Jookia>Plan 9 has some really cool ideas <xd1le>i guess if computers really change in how they work in the future <xd1le>maybe personal quantum computers some day <xd1le>but i think the GNU itself is pretty good <xd1le>I also think systemd is also a really good design for an init manager <xd1le>but of course it requires Linux so no go for guix <Jookia>GNU is great and shall be around forever, and if there's going to be legacy systems out there I'd rather it be GNU than ReactOS ;) <xd1le>i think the butterfs seems like one for the future too, but that's 'just' filesystem <xd1le>i think the most improvements would be at the level of the graphical display or whatever you call it <xd1le>i.e. improving/replacing the legacy X server <xd1le>but that's probably more near future <xd1le>obviously one of the selling points of the free BSDs is their ports system <xd1le>but imo guix fully trumps that <xd1le>so i guess there can be others, but at this point, there doesn't seem to really be anything else worth supporting <xd1le>maybe in the future if GNU is dying, guix could adapt ***quigonjinn` is now known as quigonjinn
<NiAsterisk>hi! if I have (services (cons* (lsh-service) (tor-service (config-file "/etc/tor/torrc")) (console-keymap-service "de") %desktop-services)) why does the tor part fail? I also tried it with (tor-service "/path/to/torrc") <NiAsterisk>I'm just beginning with scheme, so I might misread the part in the manual <NiAsterisk>it might have to do with my config.scm in general though.. there is one section I am uncertain about. ***quigonjinn` is now known as quigonjinn
<davexunit>NiAsterisk: (use-service-modules (foo)) expands to (use-modules (gnu services foo)) <NiAsterisk>hm. it broke at some point, which is why I did not use use-service-modules over use-modules yet <NiAsterisk>ah. i guess it broke because I had it inside (use-modules) <davexunit>and the macro is only available if you import the (gnu) module <NiAsterisk>reconfigure still needs the a place, right? like guix system reconfigure /etc/config.scm / <NiAsterisk>without place: "<unknown place>: error: source expression failed to match any pattern" <mark_weaver>NiAsterisk: reconfigure does not need a place. just "guix system reconfigure /etc/config.scm" <mark_weaver>the error is probably due to a syntax error in your OS config <mark_weaver>can you show me the config file that you're trying to use now? <davexuni`>looks like some package upgrade since last night is causing a lot of stuff to be rebuilt <mark_weaver>NiAsterisk: the syntax for 'use-service-modules' and 'use-package-modules' is incorrect. they should be like this: <davexunit>hmm, maybe just a bad network connection so guix is deciding to build everything. <mark_weaver>sorry for the unhelpful error messages. it would be good to preserve the source location information. I wonder what the issue is there... <efraim>what if he wants to take out something from one of the service modules <efraim>if he wants desktop but doesn't want xfce <efraim>or when I finally finish up connman, to use connman and take out wicd <NiAsterisk>but my real issue was tor-service. it still fails, with (tor-service (config-file "/path/to/torrc")) and with just (tor-service "/path/to/torrc").. later gives me: <NiAsterisk>gnu/services/networking.scm:250:0: In procedure #<procedure tor-service (#:key tor)>: Odd length of keyword argument list <davexunit>efraim: %desktop-services is just a list. map/fold/filter as you'd like. <davexunit>re: the email thread about services I just saw <mark_weaver>davexunit: I had to kill some bloated hydra-server processes a little while ago. if you were asking for a substitute at the time, it would have closed the socket prematurely I guess. <davexunit>I stopped the build and restarted and things are back to normal. <mark_weaver>NiAsterisk: the argument to 'tor-service' needs to be a file object, so something like (tor-service (plain-file ...)) or (tor-service (local-file ...)) <mark_weaver>the tor-service is not going to use a config file from a mutable directory like /etc/tor/torrc <NiAsterisk>ah.. now i understand. I guess it will be much clearer once I advanced more in learning lisp and guile. <mark_weaver>instead, the config file will be added to the store based on your specification and will be immutable. <mark_weaver>well, these are guix concepts. a lisper or guiler without knowledge of guix wouldn't know about them. <mark_weaver>if you want a new configuration, you instantiate a new system. that way, things like rollback actually work properly. <mark_weaver>you *could* create a tor service that directs tor to use a mutable global config file, but then you'd lose some of the desirable features of guix <mark_weaver>e.g. if you break it by changing the tor config file, then rollback won't fix that. <NiAsterisk>I'm about to do that, as all my configurations are not on the systems but external. so for understanding and setting up tor to use, I need to understand how file-like object are formed in guix and then change the config.scm of guix accordingly? <mark_weaver>NiAsterisk: sorry, I have to go afk for a while. maybe someone else can help you with your tor-service configuration. <NiAsterisk>guix manual, section 5.6 G-Expressions or the page itself looks like it could help in understanding this? <civodul>(if you read the Info file locally, you can search the index with 'i') <mark_weaver>civodul: we should probably have an example of a service where a file-like object is passed, e.g. (tor-service <file>) <mark_weaver>my current config doesn't have an example of that, nor the example configs in our repo nor in the manual, afaict, and I confess that I've forgotten how to do it. <NiAsterisk>guix is really different. powerfull and different. <mark_weaver>civodul: can you give an example of a 'tor-service' with the optional config-file passed? <mark_weaver>civodul: NiAsterisk tried (tor-service "/etc/tor/torrc"), and from looking at the manual, I think it's difficult for a non-expert to understand what needs to be done. <mark_weaver>to be honest, it's not obvious to me what needs to be done either :-/ <NiAsterisk>I guess with the linking to an documented example it would be easier to understand, I got into writing ebuilds and at first gentoo looked very complex to me. given the right explanations one can start exploring <civodul>agreed, the doc sucks, we should at least add examples <civodul>so it's: (tor-service (plain-file "my-config" "something")) <civodul>or: (tor-service (local-file "/foo/bar/my-torrc")) <mark_weaver>NiAsterisk: just beware that if you put (local-file "/etc/tor/torrc"), what will happen is that the contents of that file will be copied to the immutable store when you build the system. <mark_weaver>the resulting tor-service will not read /etc/tor/torrc, but will instead read the snapshot of it that was copied when you built the system. <NiAsterisk>so when I rebuild the system afterwards, it will use the immutable store file? <mark_weaver>no, each time you build a system, it will make another copy of whatever is in /etc/tor/torrc <efraim>keep it in version control with your config? <mark_weaver>or, if the configuration is small enough, you could use 'plain-file' and embed the configuration directly in the OS config. <mark_weaver>efraim: it'll have to wait until the next core-updates cycle <davexunit>civodul: maybe 'inline-file' would be a better name than 'plain-file' <alezost>I use 'local-file' 6 times in my system config <NiAsterisk>reading the torrc.sample in ~/.guix-profile/etc/tor/ , I could leave DataDir out, but if I would want it, what would be an accurate way to determine the current folder in guix for /gnu/store/$currenttor/var/lib/tor/data ? <NiAsterisk>btw, what about an wiki where the documentation can refer to for individual examples or more detailed explanations etc? <civodul>davexunit: yes, 'inline-file' sounds better <NiAsterisk>petter: re: encrypted system (http://sprunge.us/jNUH) one needs a (mapped-device) list entry for every lvm partition as usual, so with an encrypted swap + boot + rootfs it should be adjusted appropriately(just a guess in theorey, I had no encrypted boot + one larger lvm group on every system so far but not guixsd), but I guess that's what libreboot documentation will do. <NiAsterisk>should've changed the sentence structure, it's intended as a question. <francis7>I'm strongly considering setting up a build server for libreboot, on top of guix, since I know the project is working on reproducibility <francis7>(libreboot is also working on reproducible builds, and needs a reproducible distro to build on. I can't recommend debian to people, so that leaves only guix) <taylan>francis7: nope, reproducability issues pop up in some recipes <petter>NiAsterisk, i don't have any experience with LVM unfortunately <davexunit>francis7: not fully reproducible, but we are always improving. <francis7>mark_weaver, a while ago you were working on integrating libreboot into guix iirc <davexunit>if you want full reproducibility, GuixSD is a good bet. <NiAsterisk>isn't debian working on reproducible builds, or is their debian reproducible project working towards 100% and then merge things into debian? <petter>NiAsterisk, also, LVM is not supported yet in Guix if i remember correctly <francis7>NiAsterisk, libreboot cannot recommend debian to people <NiAsterisk>petter: mark_weaver ah ,right, this was the catch I forgot <davexunit>NiAsterisk: mainline debian doesn't have the reproducible stuff, AFAICT. <francis7>it needs to be build reproducibly on top of an ethical distro <francis7>I'm doing a release soon, and that won't be reproducible for this reason <mark_weaver>francis7: I was talking about it, but I haven't actually done any of the work yet, sorry. <francis7>but for the future, I'm looking at guix as a distro to build it on <francis7>hell I'll probably just start packing libreboot up for guuix <davexunit>francis7: with guix, we could write a package recipe for the libreboot build. <davexunit>and then guix has a tool that can rebuild libreboot N times and see if the results are the same each time <davexunit>which will allow you to start addressing nondeterminism issues. <francis7>We need to fix the SOL part in libreboot <francis7>most of libreboot is actually pretty good/solid <francis7>just a few tweaks to get it building reproducibly fully <francis7>and we already hardcode that in libreboot <francis7>coreboot logs in libreboot.git say coreboot-libreboot-VERSION as the version <francis7>coreboot's build system checks for .coreboot-version file <francis7>could modify it to look also for a .coreboot-timestamp file <mark_weaver>I can understand why people like to embed a timestamp when the build was done, but that desire is fundamentally inconsistent with reproducible builds. <civodul>mark_weaver: it's OK if the timestamp itself is "reproducible", like if it's the date of last commit or something like that <mark_weaver>civodul: how would that be implemented? (date of last commit) <mark_weaver>I agree that embedding the date-of-last-commit is compatible with reproducible builds, but it's not clear to me how to implement it in practice. <fhmgufs>I don't like that the hashs in the store are in front of the real filenames. It would be much easier for finding files outside emacs if they would stand after the filename. <civodul>mark_weaver: the obvious problem is that the thing would need access to the VCS, or to keep it at 'make dist' time <civodul>alternately it could use the mtime of the most recent file <fhmgufs>Is there a special reason for that? (I know that this comes form Nix) <mark_weaver>fhmgufs: well, for one thing, file lookups in /gnu/store are more efficient this way, and there are a lot of those <davexunit>fhmgufs: well, it makes the names more regular. retrieving a base32 encoded hash is as easy as taking the first 32 characters of the file name <fhmgufs>Well, that's true. I think it's not important and it was just a little problem :). <fhmgufs>Normally I look for files in the shell by typing the first characters and use the autocompletition. That's difficult with these hashs. But hopefully I won't have to look for files in the store so often. <davexunit>my concern with the store is reaching inode limits. <davexunit>been the victim of that issue a couple of times, just not with guix... yet. <mark_weaver>fhmgufs: in practice, that doesn't help much because after a while you end up with several store directories with the same package name. <mark_weaver>so you end up needing to know the hash regardless of whether it comes first or not. <civodul>davexunit: i've never had that problem, FWIW <davexunit>civodul: you need a lot of stuff in one directory for it to happen. <petter>i think this depends on the file system <davexunit>mark_weaver: a directory having so many items in it that it reaches the inode limit <mark_weaver>davexunit: I worried about that too, but I looked into it and it's apparently not an issue with modern filesystems. <mark_weaver>e.g. hydra is still running linux-2.6.32, and probably has a bigger store than any normal system would have, and has no such problem, <petter>mark_weaver, which file system does it have? <mark_weaver>ext4, but as I recall I found that it hasn't been an issue for ext3 for many years either. <calher># guix-daemon --build-users-group=guixbuild <calher>-bash: guix-daemon: command not found <mark_weaver>petter: ah, interesting, I didn't know about that one. I guess there might be problems on ext3 after all. <mark_weaver>calher: if you did the binary installation, it sounds like you missed step 6, or else that /usr/local/bin is not in your PATH <petter>yeah, ext3 could run into problems <mark_weaver>calher: sorry, that makes a symlink for 'guix', not for 'guix-daemon'. but the docs recommend to run guix-daemon by: ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild <mark_weaver>but you haven't given us enough context to help you without making guesses... <petter>oh wow, i have almost 13'000 files in /gnu/store <davexunit>civodul: what should I expect from the output of 'guix challenge'? <davexunit>guix challenge --substitute-urls=hydra.gnu.org ruby-i18n <mark_weaver>there are many sorting errors in dist_patch_DATA in gnu-system.am <mark_weaver>ACTION wonders whether he should submit a patch to fix them <mark_weaver>petter: /gnu/store/links will have one entry for every unique file in /gnu/store, which will be a much larger number, but they are normal files, not subdirectories. <mark_weaver>davexunit: yes, but it will likely cause complications with merging and applying patches prepared before the sort fix. <civodul>davexunit: no output is good output! :-) <civodul>i guess we could do better though :-) <davexunit>so, I have a reproducible package identified for my demo. <davexunit>now I need to find an easy enough one to build that isn't reproducible. <civodul>--rounds=N is very useful for that, it catches most of the issues (aka. timestamps) <civodul>mark_weaver: re sorting errors, why not fix it <civodul>davexunit: yes, and other commands as well, IIRC <davexunit>civodul: 'guix challenge' doesn't report it. I'll try it. <calher>mark_weaver: I don't know how to give context! <calher>I did everything the installation instructions said. <mark_weaver>I'm sorry, there are multiple ways to install guix, and I don't know what you mean by "the normal way". did you use the binary install method, or are you building for source, or what? <mark_weaver>step 4 of section 2.1 (Binary Installation) of the manual says to "Create the group and user accounts for build users as explained below (*note Build Environment Setup::)." <mark_weaver>and then step 5 says to "Run the daemon" with the command "~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild" <calher>$(~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild) worked. <calher>mark_weaver: I'm sorry, but building from source is /not/ normal. Grandma does not install programs from source! ***necronian_ is now known as necronian
***kmic is now known as kmicu
***orbea_ is now known as orbea
***the_ktosiek is now known as ktosiek
<injigo>i need to give calher a beating next time i see him, this shit is still compiling <injigo>i asked him how to install icecat, and he told me to install guix, he didn't mention that it would take this long to compile shit <injigo>he was just like "run guix pull" <mark_weaver>it's curious, because from a conversation just a few minutes ago, it sounds like calher doesn't even have a working guix setup. <injigo>i told him i'd blame him if my system took a shit, then he left the channel a few minutes later <mark_weaver>well, guix is a fine way to install icecat, if you enable substitutes. <injigo>how does one enable binary substitution? command parameter? <mark_weaver>it's step 7 in the list of installation steps in section 2.1 (Binary Installation) in the Guix manual. <injigo>i spose i should just let it finish compiling, may as well <davexunit>if you kill it and enable substitutes, you'll keep all of the things that have finished compiling and will get binaries for everything else. <NiAsterisk_>depending on your system, webkit based installations can take from 3 - 12 hours, what I measured with what I had on gentoo systems with webkit-gtk. depends on what it is actually compiling you have <mark_weaver>injigo: if you didn't enable substitutes at all, you'll probably need to leave it compiling overnight. <injigo>any idea how much space it'll take? <NiAsterisk_>not sure about icecat.. webkit, 4GB max for compiling iirc <mark_weaver>it's not just compiling icecat. it does something roughly similar to what "Cross [GNU/]Linux From Scratch" does, i.e. starting from a small set of bootstrap binaries, compiling a full toolchain, C library, all the other libraries and programs needed to build icecat and all its dependencies, etc. <davexunit>injigo: okay, so that is compiling guix from source, but to do that, it may have to compile many other things. <davexunit>can you tell what is being compiled right now? <injigo>mark_weaver: guix pull is the command that initiated all this compiling <injigo>i have no idea what it's compiling atm <mark_weaver>injigo: in the absence of binary substitutes, 'guix pull' needs to first bootstrap the toolchain and libraries needed to compile guix itself. <mark_weaver>I recommend: kill the 'guix pull' process, enable substitutes, and then restart 'guix pull'. <injigo>log output in the terminal? yes i see it, but it's all greek to me and it's moving way too fast to tell <injigo>even if i scrolled up to stop the autoscroll, it's greek anyway haha <injigo>i guess the compile job is containted to the gnu directy anyway <davexunit>injigo: you can usually tell by the file names scrolling by what's being compiled <mark_weaver>it only modifies /gnu/store, /var/guix, /var/log/guix, and creates a ~/.guix-profile symlink. <mark_weaver>injigo: kill it, enable substitutes, and restart it. <injigo>mark, should i wipe the gnu directory? <mark_weaver>injigo: never delete or modify anything in /gnu/store directly <davexunit>on GuixSD we mount /gnu read-only to avoid accidents like that <davexunit>(and the daemon, the one thing program that can touch it, re-mounts in read-write for itself only) <mark_weaver>if you modify anything in there, things will break in non-obvious ways. <mark_weaver>"guix gc" is the tool that can be used to safely remove things in there that aren't referenced from anywhere known to guix. ***ringst_ is now known as ringst
<injigo>mark_weaver: ah okay, i'll keep that in mind <injigo>just ran "guix pull" after enabling binary substitution <injigo>updated GNU Guix successfully deployed under `/home/injigo/.config/guix/latest' <mark_weaver>now you should be able to install icecat much more quickly. <mark_weaver>it should download pre-built binaries for almost everything needed. <injigo>thats good, a while back i tried to install icecat without guix <fhmgufs>I can't wait for trying to install (minimal) GuixSD on my Raspberry Pi. Couldn't there be a release of the Shepherd in the next days? <mark_weaver>fhmgufs: the raspberry pi uses an ARMv6 processor, but Guix targets ARMv7, so it won't work. <fhmgufs>mark_weaver: No, I have a Raspberry Pi 2. <mark_weaver>well, it will take some work to get GuixSD running on ARM. for now, you'll have to settle for Guix on top of another distro. <fhmgufs>I only want an minimal system to do some testing. <keverets>MatthewAllan93: clever way of cross-marketing Free Software. Hope you did a "#join #guix" in #librecmc ;) <NiAsterisk>MPL license is compatible to the licenses accepted in guix, right? <bavier>NiAsterisk: MPL1.1 and MPL2.0 are in Guix <bavier>there's a patch pending for MPL1.0 <NiAsterisk>ah, it's in the headers.. bcrypt told me it's MPLv2, so def. compatible <NiAsterisk>i'm interested in trying the browser by "brave". although there's no privacy policy yet and users might be tracked.. but I guess before I package it, it might become clearer n details. <NiAsterisk>ACTION has too much on the wish & package doing list with too much expectations to fix <bavier>NiAsterisk: how is Brave different from Icecat with HTTPS Everywhere, and Privacy Badger add-ons? <NiAsterisk>it might not be what I personally would prefer, but I do not like windows 10 either and looked into it for curiousity. (bad comparison, i know) <NiAsterisk>advertising is just a giant white bubble ready to burst at any moment. I hope it will burst at some point in the near future. <injigo>just me or are the hydra repo's really busy right now? <davexunit>hydra is pretty much always slow... which is why we're fundraising! <NiAsterisk>at least this time after 1 day cmake downloaded :) <petter>suitsmeveryfine, Cool! I've updated the decryption command in Libreboot. I had "cryptsetup", but it should be "cryptomount" <petter>suitsmeveryfine, yes. I haven't worked any more on it though. Consider yourself a, eh, "gny" pig (however you spell it) <petter>suitsmeveryfine, do tell how things work out, including minor details that you do differently <suitsmeveryfine>great. Will you be around because I'll probably run into some issues? <NiAsterisk>on my laptops I do wpa_supplicant via commandline, then afterwards I run `dhclient $interfacename` iirc <petter>suitsmeveryfine, and by the way. The cryptsetup command is something i "borrowed" from the encrypted_parabola tutorial. It's not what i used myself <petter>suitsmeveryfine, yes, i'll be here the next couple of hours <suitsmeveryfine>NiAsterix: I ran ifconfig enp1s0 up && dhclient enp1s0 and the system told me that internet connection is up <wgreenhouse>NiAsterisk: I don't think brave would be a good fit for tails because, even if the client end is free software, it depends on and is only useful with a proprietary network service (their caching web proxy, which is like a MITM between you and all content). <petter>suitsmeveryfine, did you try a server you know responds to ping? <NiAsterisk>wgreenhouse: okay, to be fair I did not read everything. if I would do it, it would come after trying torbrowser packaging on guix (which has a higher priority for me on my list) <NiAsterisk>it's an exciting "yay, new software" thing where I might consider checking it out, but I seriously considering it would involve waiting for their ToS and Privacy, which will be released later <NiAsterisk>I need more data and information to further comment on this browser I guess. <suitsmeveryfine>petter: after running `cryptsetup luksOpen /dev/<your-luks-partition> guixsd` it's time to create the file system, is it not? <suitsmeveryfine>the libreboot-parabola guide uses LVM and at this point tells me to run 1) # mkswap /dev/mapper/matrix-swapvol and 2) mkfs.ext4 /dev/mapper/matrix-rootvol <petter>oh, right. I completely forgot about file system <petter>it should be just to create this now, yes <suitsmeveryfine>what about swap? shall I just use a file inside / instead of a dedicated /swap <davexunit>I really want to Guix to be able to use PXE to automatically provision non-virtualized systems. <petter>suitsmeveryfine, i went around the swap hurdle and figured i'd just make a swapfile instead <petter>suitsmeveryfine, haven't done it yet though <petter>i guess you need to make the filesystem on /dev/mapper/guixsd <suitsmeveryfine>I see. Well the parabola guide says "mkfs.ext4 /dev/mapper/matrix-rootvol" <NiAsterisk>when the crypt is opened, you use the mapper for interaction until you close it <petter>suitsmeveryfine, ok, then do similarly here, /dev/mapper/<name-you-gave-to-luksOpen> <petter>right, the "guixsd" argument will pop up in /dev/mapper after you run it <suitsmeveryfine>ok, I proceed like this then. I believe the matrix thing was there in the parabola guide because it was using LVM + / + /swap <petter>suitsmeveryfine, it doesn't yet. The matrix stuff is from the Parabola guide <petter>if you do: ls /dev/mapper isn't there a guixsd file there? <petter>do you want to write your own completely from scratch? <petter>copy one of the examples, than modify it then <petter>Ok. It's explained in the GuixSD installation manual, but it could be mentioned here too <suitsmeveryfine>ok I see. Well I think it's goot to have all the necessary steps here until one has successfully shut down and booted the system <petter>I didn't want to make it a standalone guide, just sort of a detour from the GuixSD installation manual <petter>But i think you have a fine point with the config, so let's add that <petter>ACTION waves suitsmeveryfine along <suitsmeveryfine>I guess that it's appropriate to edit the config a bit more, e.g. timezone, hostname and other things <rekado>suitsmeveryfine: about the ping problem: you may want to try to restart the nscd service. <suitsmeveryfine>Maybe here one could refer to the official installation documentation <rekado>some people have reported that failures are cached for too long. <mark_weaver>I used to have problems with nscd caching lookup failures for too long, but I haven't noticed it lately. maybe something changed? dunno. <petter>this belongs in the GuixSD installation guide i think <suitsmeveryfine>"target", a name you make up that will appear in /dev/mapper/ after decryption. We'll refer to this later. Example "guixsd". <petter>this is a block of code you'll add <petter>right, the example config doesn't cover encrypted partitions <petter>yes. This is the HELP section below <petter>first you can add the (mapped-device ...) field <davexunit>mark_weaver: will you be attending tonight's Guix talk at MIT? just curious how many friends I should expect to see. :) <suitsmeveryfine>petter: (source "/dev/<your-partition>") should be (source "/dev/sda1"), right? <mark_weaver>davexunit: I read your slides, and they look good! I'm afraid I can't make it over there tonight though. roped into family stuff.. <parabool>davexunit, i'm not on the same continent, but interested in your presentation. ty <petter>suitsmeveryfine, would it be clearer if it said "/dev/<your-luks-partition>" you think? <petter>suitsmeveryfine, i do provide an example though <davexunit>a couple of my coworkers said they would come. <davexunit>so I won't feel like it's just total strangers <davexunit>parabool: if all goes well, I will have a full recording to share later. <mark_weaver>I liked the picture of the container ship falling over sideways :) <davexunit>I've done a full 90 minute recording using everything I'm going to use tonight, and my laptop handled it OK. let's hope it works again later. <petter>and you have enough disk space now? :) <NiAsterisk>it will be better than the first presentation a friend did, where the 6 screens in the room were very incompatible with his laptop and it took 1 hour to fix everything :) <mark_weaver>petter: the only issue I've noticed (so far) from your HOWTO is that it might not have been clear that the 'target' field of the 'mapped-device' needs to match the /dev/mapper/XXX filename. <petter>mark_weaver, right. I think this is best handled in the (file-systems ...) part, explanation to "device" <petter>mark_weaver, do you have any thoughts regarding the (bootloader ...) part? <mark_weaver>petter: on a GuixSD machine, I don't see any reason to avoid installing GRUB to the MBR. I do it all the time <mark_weaver>and it has the advantage that the drive would be bootable on a non-Libreboot machine. <petter>mark_weaver, this is for Libreboot <mark_weaver>understood. I do it all the time on my Libreboot machines. <petter>ok, so let's just make it the disk we're installing to <mark_weaver>suitsmeveryfine: well, no. on a non-Libreboot machine, /boot would have to be left unencrypted. <petter>suitsmeveryfine, will you try "/dev/sda" as argument to the bootloader? <davexunit>mark_weaver: I'm using "Open Broadcaster Software", available in Guix as "obs" ***nckx is now known as nckx|offline
<petter>suitsmeveryfine, good. Then we'll just use that and drop the drama :) <petter>it isn't supposed to be in the guide when we're done obviously ***Gottox_ is now known as Gottox
<suitsmeveryfine>petter: I've changed locala in the config file but do I need to add services too? <lfam>What should I expect when trying `guix build --rounds`? I did `guix environment hello`, and then `guix build --rounds=2 --no-substitutes hello`, but the compilation only happened once. At least, it seems that way based on the console output. <davexunit>does anyone know of a known non-reproducible package? <civodul>davexunit: see bugs.gnu.org/guix :-) <lfam>davexunit: Ah, I was about to suggest python-2 <lfam>But that will take forever <petter>suitsmeveryfine, i have added some services at least. But i don't suppose you have to <civodul>lfam: there's a gotcha: if your daemon does not support the --rounds functionality, the option is silently ignored <civodul>so you should make sure you use a recent daemon <lfam>civodul: That must be happening. But I could have sworn I'd done `guix pull` as root and restarted since the feature was introduced. I will double-check <civodul>yes, but 'guix pull' does not rebuild the daemon, only the client stuff <civodul>if you use GuixSD, you can reconfigure and you'll get a recent-enough daemon <lfam>This is on a foreign distro <petter>suitsmeveryfine, hm, i'm actually not sure if i've added some modules or if the examples/desktop.scm has changed since i did this <civodul>lfam: in that case, you can "guix package -i guix" in the root profile, if that's where your daemon is ***nckx|offline is now known as nckx
<petter>suitsmeveryfine, yeah, but that's already there <lfam>civodul: "--install", not "--upgrade"? Looks like root still has the 0.9.0 guix in her profile. <suitsmeveryfine>ah, so you think one needs to add other services as well, such as 'bases services'? <petter>suitsmeveryfine, no, i think it should be fine now <petter>i just see that my config.scm has some other modules in (use-service-modules) and (use-package-modules) <petter>suitsmeveryfine, you should be good to go <petter>suitsmeveryfine, have you done "guix system init ..." ? <lfam>mark_weaver: Regarding the test failure in texi2html, the only thing I noticed was a few lines of "S: (no latex2html) tex_in_copying" in the check phase <petter>suitsmeveryfine, what you've done so far is prepare the config. Now it's time to use it <petter>suitsmeveryfine, if you see in the GuixSD installation manual, at 7.1.4 <NiAsterisk>but this might take a while, so you are almost done when running system init <petter>suitsmeveryfine, try "lsblk" and see that your crypt is mounted at /mnt <petter>svenska som dom pratar i Sverige <mark_weaver>suitsmeveryfine: sv_SE.utf8 might work better, dunno. <petter>you can try "locale -a" to print all locales <mark_weaver>lfam: thanks for looking! yeah, maybe that's the problem, dunno. <lfam>mark_weaver: I can try rebuilding it with latex2html as an input. <petter>yes, locale -a shows that you would need to type it like that :) <lfam>mark_weaver: Or something like that. Strange that texi2html would depend on something called latex2html. I wonder if that's an internal function name. I'll look <suitsmeveryfine>Now I just hope that the crappy macbook hardware won't play tricks on me <petter>suitsmeveryfine, can you pastebin your updated version of the guide? <lfam>davexunit: I don't know but I bet it takes a while <mark_weaver>but please don't use pastebin.com, which blocks tor users. <lfam>davexunit: I'm starting a build to get a sense <davexunit>I want to demo 'guix challenge' shortly, but I'm actually having trouble finding something nondeterminstic. <lfam>Yeah, I know :) That's why I'm doing this right now. <lfam>davexunit: I did `guix environment python-2.7.10`, and then built it. It only took a minute or two. Doing --rounds now <lfam>Still a little long to make an audience wait but you could keep talking while it biulds <davexunit>but first I need to GC the one I just downloaded <lfam>Well, let me make sure it's actually non-reproducible (the irony) <lfam>Gah, now the output is alive and I can't `gc -d` it <lfam>Well, I guess not being able to reproduce non-reproducibility is just as bad ;) <lfam>It includes non-reproducible package reports <davexunit>and I'd have to delete it in the right order... <lfam>Hah. Guix is too dependable <mark_weaver>davexunit: if you pass multiple things to "guix gc -D" I guess it will delete them in the right order. <lfam>You could also use a vm-image to have a "fresh" store but that might take too long to set up <davexunit>guix gc --referrers /gnu/store/...-python | xargs guix gc -d <suitsmeveryfine>I'm ready to paste my modified document; which is the preferred paste site? <lfam>You could do paste.lisp.org, I picked that up here <lfam>It has a nice annotation feature <NiAsterisk>this i686 guixsd, with the system init started in the last 30 minutes, is building cmake from source again :/ <lfam>NiAsterisk: Did you do `guix pull`? <NiAsterisk>complete blank fresh new system in the install process <lfam>NiAsterisk: If you didn't do `guix pull` then hydra may no longer have substitutes for the packages referred to on your system. If you are familiar with Debian, `guix pull` is roughly analogous to `apt-get update` <NiAsterisk>damn. I knew there's something I have to get used to <lfam>Maybe when we get a more powerful and hydra with more storage we can keep substitutes around longer. This is an annoying issue for new users. Really it should be an instruction in the manual. <lfam>I have put my last message in my todo list <NiAsterisk>i'll eventually get used to it, it's just repetition <davexunit>I guess I won't show 'guix challenge' tonight <davexunit>alright, off to give the talk. may or may not be back on. later! <NiAsterisk>it makes sense to pull the latest master during system init, and I guess I did so with the last 5 setups, but this is something I need to repeat more I guess. <suitsmeveryfine>the installer tells me to try `--fallback` "to build derivation from source" <mood>I got that network problem many times a few hours ago <mood>I added --fallback, it started running. <lfam>That's means the file transfer got cut off part-way through <mood>Downloads are incredibly slow though <lfam>This is why we have a fundraiser to buy a new server :) <suitsmeveryfine>lfam: anyway, I got the error when running initializing the guix system <lfam>I think it has already been a great success <petter>suitsmeveryfine, thanks for your work on the guide! <mood>suitsmeveryfine: Same here. I retried a bunch of times and it was always at the same package <civodul>lfam: --install upgrades if the thing is already installed <lfam>civodul: So, it's a safe catch-all for "get the latest version" <lfam>Can't believe I never did that with root on this system :p <petter>Regarding the guide i'm not sure where it should start. I see now it starts with keyboard layout and network setup. Personally i think the Libreboot guide should start with preparing the disk. And that good points from suitsmeveryfine before this should rather go on the GuixSD installation manual. What do you guys think? <petter>that's not specific to Libreboot <mark_weaver>petter: fwiw, I agree that the keyboard layout thing should go in the Guix manual. <petter>Should the Libreboot guide be standalone, or an appendix to the GuixSD manual <NiAsterisk>you did run `guix pull` before running `guix system init file.scm /mnt` ? <lfam>Can you give some more context on the build failure? Can you share the console output? <suitsmeveryfine>after downloading a bunch of files from hydra i get: gzip2: compressed file ends unexpectedly <lfam>suitsmeveryfine: Did you try `guix system init --fallback file.scm /mnt`? <lfam>And, which gzip2 archive is truncated? <lfam>If the bad gzip2 archive is in your store, you should try to `guix gc -d` it