IRC channel logs


back to list of logs

<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
<suitsmeveryfine>macbook2,1 port
<_`_>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>mark_weaver: yes, I know it's a bug in the latest unstable images
<suitsmeveryfine>a regression
<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>_`_: hmm, interesting.
<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?
<mark_weaver>oh well
<_`_>even the cross compilers use xcode
<mark_weaver>ACTION goes afk for a while
<_`_>(packaging the sdk)
<_`_>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.
<suitsmeveryfine>going to bed now! good night
<mark_weaver>_`_: indeed, I think that's a showstopper
<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.
<mark_weaver>e.g. there are no bootstrap binaries available in, and i686-hurd is not in the GUIX_ASSERT_SUPPORTED_SYSTEM macro in m4/guix.m4, etc.
<NiAsterisk>what is the XNU kernel?
<paroneayea>xnu's not gnu
<paroneayea>NiAsterisk: the kernel mac OSX uses, apparently
<codemac>xnu is mach+bsd posix+rando stuff
<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?
<Jookia>Proprietary software skills? :(
<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>ACTION packages v4l-utils
<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
<Jookia>xd1le: Oh?
<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>like you for it
<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>pressure on them to switch
<mark_weaver>Jookia: they can use a non-free VM system on it
<xd1le>(and also ofc, you will probably need to spend time on supporting a system
<xd1le>you don't care about)
<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>Jookia: Does Guix support which systems?
<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.
<xd1le>Jookia: probably?
<mark_weaver>Jookia: if the VM system faithfully emulates hardware supported by Linux, then I guess the answer is yes.
<Jookia>Cool then
<xd1le>oh, by "nonfree systems" above i was referring to "non free operating
<xd1le>systems" above
<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.
<Jookia>mark_weaver: Me either
<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
<xd1le>software on gnu, right?
<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
<xd1le>keeping their legacy
<xd1le>Jookia: yeah good point
<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>what? how come?
<xd1le>i mean they don't
<xd1le>but from a user point of view
<xd1le>from a guix 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>they use
<xd1le>good point
<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>windows/reactos anyway
<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
<xd1le>wait, but why do you care?
<xd1le>i thought you didn't
<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
<xd1le>so there's no point
<Jookia>Hmm, is Guix just for GNU?
<xd1le>also see
<xd1le>Jookia: yes, of course!
<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>well then we're all fucked
<xd1le>if GNU dies
<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>that that doesn't happen
<xd1le>so we that free software infects like a cancer
<xd1le>Jookia: It is.
<xd1le>because the free BSDs aren't copylefted
<Jookia>xd1le: We can't do better in design, maybe make a GNU2?
<xd1le>good point
<Jookia>GNU Hurd is awesome but it's still stuck with POSIX
<xd1le>GNU/Linux isn't that bad
<xd1le>definitely better than Mac or Windows
<xd1le>not sure about the free BSDs
<Jookia>I use GNU/Linux exclusively :D
<xd1le>or other alternative free systems
<xd1le>like plan 9
<Jookia>Plan 9 has some really cool ideas
<xd1le>i guess if computers really change in how they work in the future
<xd1le>at the chip level that is
<xd1le>maybe personal quantum computers some day
<Jookia>Either way, Guix <3
<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 ;)
<Jookia>I don't understand systemd
<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
<NiAsterisk>it is visible at (or ) and what I am not so sure about is the first quoted section vs the one I use, what belongs into (use-service-modules) and what does not?
<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>i'll try again and see where it complaints
<NiAsterisk>ah. i guess it broke because I had it inside (use-modules)
<davexunit>that would do it
<davexunit>invalid syntax
<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
<NiAsterisk>more likely, yes
<mark_weaver>can you show me the config file that you're trying to use now?
<NiAsterisk>yes, one sec
<NiAsterisk> /
<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:
<mark_weaver>(use-service-modules desktop networking ssh base)
<mark_weaver>(use-package-modules xfce ratpoison certs)
<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
<davexunit>efraim: what do you mean by "take out"?
<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
<davexunit>efraim: xfce isn't part of a service
<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.
<efraim>sounds good :)
<davexunit>efraim: and it's *not* an alist
<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>okay, no problem
<NiAsterisk>guix manual, section 5.6 G-Expressions or the page itself looks like it could help in understanding this?
<civodul>NiAsterisk: yes, see
<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>last time I did it, I remember it being unintuitive
<mark_weaver>civodul: can you give an example of a 'tor-service' with the optional config-file passed?
<NiAsterisk>like in monadic procedure: text-file* ?
<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"))
<civodul>NiAsterisk: ↑
<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.
<NiAsterisk>what's the consequence of this?
<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
<NiAsterisk>is there a way you would recommend?
<efraim>keep it in version control with your config?
<mark_weaver>efraim +1
<mark_weaver>or, if the configuration is small enough, you could use 'plain-file' and embed the configuration directly in the OS config.
<NiAsterisk>that was what I just wanted to ask
<NiAsterisk>this seems doable for me for some systems.
<NiAsterisk>thanks civodul mark_weaver
<mark_weaver>you're welcome
<efraim>coreutils-8.25 was released
<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>ACTION likes 'inline-file'
<alezost>I use 'local-file' 6 times in my system config
<davexunit>efraim: 'local-file' is for a file on disk
<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 ( 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>is guix fully reproducible yet?
<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
<mark_weaver>NiAsterisk: iiuc, LVM is not yet supported in Guix
<francis7>NiAsterisk, libreboot cannot recommend debian to people
<francis7>it would contradict our stated goal
<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
<NiAsterisk>francis7: okay, I understand
<francis7>currently,it is built on trisquel
<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
<mark_weaver>sounds good
<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.
<francis7>if I get the time for that
<davexunit>and then guix has a tool that can rebuild libreboot N times and see if the results are the same each time
<francis7>grub builds reproducibly in libreboot
<francis7>coreboot does not, but can
<davexunit>which will allow you to start addressing nondeterminism issues.
<francis7>upstream coreboot does this:
<francis7>if git: get timestamp from commit
<francis7>if not git: you're SOL
<francis7>We need to fix the SOL part in libreboot
<francis7>most of libreboot is actually pretty good/solid
<mark_weaver>francis7: why is the timestamp needed at all?
<francis7>just a few tweaks to get it building reproducibly fully
<francis7>mark_weaver, for debugging purposes
<francis7>actually, I don't know
<francis7>only the version is needed IMO
<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>francis7: this is the solution that Debian has adopted:
<mark_weaver>I guess that's probably the way to go here.
<mark_weaver>also see
<mark_weaver>or just remove the timestamp entirely
<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
<civodul>though that is tricky
<fhmgufs>Is there a special reason for that? (I know that this comes form Nix)
<mark_weaver>civodul: right
<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.
<davexunit>64k inodes IIRC
<petter>i think this depends on the file system
<mark_weaver>davexunit: what problem are you referring to?
<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.
<davexunit>okay so maybe I'm worried for nothing :)
<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.
<petter>"lift 32000 subdirectory limit imposed by i_links_count" --
<calher>WTF --
<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>I got no output. is that good? ;)
<davexunit>guix build --no-substitutes ruby-i18n
<davexunit>guix challenge ruby-i18n
<mark_weaver>there are many sorting errors in dist_patch_DATA in
<mark_weaver>ACTION wonders whether he should submit a patch to fix them
<davexunit>can you make emacs sort them correctly?
<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! :-)
<davexunit>civodul: cool!
<davexunit>thanks :)
<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)
<davexunit>that's for 'guix build' right?
<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.
<davexunit>well, guess it doesn't make sense there.
<davexunit>since it doesn't build.
<mark_weaver>civodul: okay, will do
<calher>mark_weaver: I don't know how to give context!
<calher>I did everything the installation instructions said.
<mark_weaver>calher: how did you install guix?
<calher>The normal way.
<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!
<mark_weaver>I didn't know you were Grandma
<injigo>calher: scrublord
<petter>hah ;)
<davexunit>"the normal way" is definitely vague
***necronian_ is now known as necronian
***kmic is now known as kmicu
<mark_weaver>hmm. where is the test failure here?
***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
<mark_weaver>injigo: what does that have to do with calher?
<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
<mark_weaver>injigo: did you enable binary substitutes?
<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.
<davexunit>calher may be a little overzealous...
<injigo>not surprising, mark
<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>thanks, mark
<injigo>i spose i should just let it finish compiling, may as well
<davexunit>depends on what it's compiling
<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
<NiAsterisk_>*installations=compiling i meant
<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
<NiAsterisk_>that's if icecat is webkit based?
<davexunit>icecat doesn't use webkit
<davexunit>it's firefox
<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.
<injigo>i just did guix pull
<injigo>it's not just icecat
<mark_weaver>injigo: oh, you should definitely do 'guix pull'.
<mark_weaver>and yes, that compiles guix
<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?
<mark_weaver>ah, that's true.
<injigo>mark_weaver: guix pull is the command that initiated all this compiling
<davexunit>injigo: what is it compiling?
<injigo>i have no idea what it's compiling atm
<davexunit>you should see log output
<davexunit>well, maybe not for guix pull...
<davexunit>kill it. use substitutes.
<mark_weaver>davexunit +1
<davexunit>for your own sanity.
<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>and that's a *lot* of stuff.
<mark_weaver>almost no one does that.
<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
<mark_weaver>yes, guix is very non-intrusive
<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.
<injigo>it's compiling perl
<NiAsterisk_>is it me, or is producing (Error code: sec_error_ocsp_server_error) when accessing it?
<mark_weaver>injigo: kill it, enable substitutes, and restart it.
<injigo>will do
<injigo>NiAsterisk_: not for me
<mark_weaver>NiAsterisk_: works for me too
<injigo>mark, should i wipe the gnu directory?
<mark_weaver>injigo: no, leave it
<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>ah, good
<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>haha awesome
<injigo>dang nice
<injigo>thats good, a while back i tried to install icecat without guix
<injigo>on an ubuntu base
<injigo>didn't get very far
<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?
<MatthewAllan93>#join #librecmc
<injigo>hey MatthewAllan93
<MatthewAllan93>Hey injigo :)
<MatthewAllan93>Sorry about that was meant to join another channel haha.
<injigo>i figured
<MatthewAllan93>how are you anyway :)
<injigo>pretty well
<MatthewAllan93>Oh good :), I am really good thanks :).
<injigo>Good to hear :)
<injigo>what's librecmc?
<fhmgufs>I'm also interested in, now.
<MatthewAllan93>It's a fully free embedded distro usually for routers :).
<injigo>oh sweet
<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>ah, okay
<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 know, I know.
<fhmgufs>I'll try it.
<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
<suitsmeveryfine>petter: Hi! I'm trying out your install notes now
<suitsmeveryfine>have you made any changes since yesterday?
<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>idk, but i'm curious about trying new software
<davexunit>Brave actually replaces ads with... ads.
<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.
<suitsmeveryfine>Is there a way to change keymap in the installer?
<NiAsterisk>loadkeys $langage
<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 :)
<suitsmeveryfine>if the network is up, shouldn't it be possible to use ping?
<petter>suitsmeveryfine, Cool! I've updated the decryption command in Libreboot. I had "cryptsetup", but it should be "cryptomount"
<suitsmeveryfine>petter: is that the only change?
<MatthewAllan93>keverets: haha ;), fhmgufs did :).
<NiAsterisk>suitsmeveryfine: me?
<NiAsterisk>or initial guixsd setup in general?
<petter>suitsmeveryfine, yes. I haven't worked any more on it though. Consider yourself a, eh, "gny" pig (however you spell it)
<suitsmeveryfine>NiAsterisk: from inside the guixsd installer
<suitsmeveryfine>I'm trying to install here on a librebooted macbook
<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).
<wgreenhouse>NiAsterisk: er a good fit for guix :P
<suitsmeveryfine>but then I tried to run ping but got unknown host back
<mark_weaver>petter: it's "guinea pig", btw :)
<petter>suitsmeveryfine, did you try a server you know responds to ping?
<petter>mark_weaver, thanks! :)
<suitsmeveryfine>petter: yes of course
<suitsmeveryfine>it worked in the parabola installer yesterday, on the same hardware
<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
<suitsmeveryfine>shall I just run mkfs.ext4 /dev/sda1
<petter>oh, right. I completely forgot about file system
<suitsmeveryfine>I'm working on filling out the gaps here :)
<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
<suitsmeveryfine>ok, that's fine. So when I ran the command I got this response...
<suitsmeveryfine>/dev/sda1 contains a crypto_LUKS file system. Proceed anyway (y, n)
<petter>i guess you need to make the filesystem on /dev/mapper/guixsd
<petter>let me look it up
<NiAsterisk>/dev/sda1 is encrypted, mapper unencrypted
<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
<suitsmeveryfine>thanks, but what is the matrix for?
<Gallomimia>that's their name for the volume
<Gallomimia>you sub in your name
<Gallomimia>which is guixsd
<petter>suitsmeveryfine, ok, then do similarly here, /dev/mapper/<name-you-gave-to-luksOpen>
<suitsmeveryfine>but I did just
<suitsmeveryfine>cryptsetup luksOpen /dev/sda1 guixsd
<petter>right, the "guixsd" argument will pop up in /dev/mapper after you run it
<Gallomimia>that decrypts sda1 to become mapper/guixsd
<Gallomimia>sda1 is still an encrypted fs
<suitsmeveryfine>ok, I proceed like this then. I believe the matrix thing was there in the parabola guide because it was using LVM + / + /swap
<Gallomimia>i use lvm and crypto
<Gallomimia>the matrix is probably the volume group name
<suitsmeveryfine>I thought guixsd didn't support lvm
<Gallomimia>and the logical volume is root or something
<Gallomimia>what is guixsd? a bootloader?
<suitsmeveryfine>it's a GNU/Linux distribution
<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?
<suitsmeveryfine>yes it is, so I proceeed
<suitsmeveryfine>petter: I'm now at "Grab one of the example configurations"
<suitsmeveryfine>Can I skip that part and move directly to Edit the config.scm
<suitsmeveryfine>in which I enter the example code that you've provided?
<petter>do you want to write your own completely from scratch?
<petter>copy one of the examples, than modify it then
<suitsmeveryfine>ah, so there is just two
<suitsmeveryfine>I guess that desktop.scm is appropriate for a laptop computer
<petter>yes. It's the one i used
<suitsmeveryfine>cool; I'll just add this to the guide
<suitsmeveryfine>so that we get ALL the steps covered :)
<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
<suitsmeveryfine>and that for further configuration one can refer to the guixsd docs
<suitsmeveryfine>just my opinion
<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
<suitsmeveryfine>ok, so I'll continue now :)
<petter>You are cleared to proceed!
<petter>ACTION waves suitsmeveryfine along
<suitsmeveryfine>one needs to create the /etc/ dir also, so I'll add that
<petter>ah, yes. Good!
<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.
<suitsmeveryfine>rekado: how do I do that?
<rekado>as root: "deco restart nscd"
<davexunit>rekado: I think I've noticed that as well.
<davexunit>kind of annoying sometimes.
<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.
<suitsmeveryfine>rekado: It worked! Thank you!
<suitsmeveryfine>I'll add this to the documentation too :D
<suitsmeveryfine>until you fix that issue
<petter>this belongs in the GuixSD installation guide i think
<suitsmeveryfine>petter: you write "Update the following fields:
<suitsmeveryfine>"source", your encrypted partition. Example "/dev/sda1"
<suitsmeveryfine>"target", a name you make up that will appear in /dev/mapper/ after decryption. We'll refer to this later. Example "guixsd".
<suitsmeveryfine>but that's not how it looks like in `config.scm`
<petter>this is a block of code you'll add
<suitsmeveryfine>instead, there is:
<suitsmeveryfine>(bootloader (grub-configuration (device "/dev/sdX")))
<suitsmeveryfine>Don't I need to change what's after device?
<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. :)
<davexunit>I have a final draft of my slides available, for any last minute comments/corrections people might have:
<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..
<petter>suitsmeveryfine, yes
<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?
<suitsmeveryfine>not sure, people might mix this up with /mapper/
<petter>suitsmeveryfine, i do provide an example though
<suitsmeveryfine>ah, sorry, haven't gotten there yet!
<suitsmeveryfine>I see now
<davexunit>mark_weaver: that's cool! just curious. :)
<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 :)
<mark_weaver>davexunit: ^^
<davexunit>hehe yeah I'm hoping that gets a laugh
<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.
<mark_weaver>ooh, nice!
<mark_weaver>what program are you using to record?
<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 :)
<parabool>davexunit, perfect :)
<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.
<suitsmeveryfine>mark_weaver: would it be bootable even with full disk encryption?
<suitsmeveryfine>incl. /boot
<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.
<suitsmeveryfine>so what you say is not relevant for this particular guide
<suitsmeveryfine>I believe
<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
<davexunit>it's working very well for me.
<suitsmeveryfine>petter: I can try that yes
<petter>suitsmeveryfine, good. Then we'll just use that and drop the drama :)
<suitsmeveryfine>what drama?
<petter>the HELP paragraph
<petter>it isn't supposed to be in the guide when we're done obviously
<suitsmeveryfine>ok, I do as you say here
***Gottox_ is now known as Gottox
<suitsmeveryfine>petter: I've changed locala in the config file but do I need to add services too?
<mark_weaver>davexunit: ah, cool, thanks!
<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?
<davexunit>(that doesn't take forever to build)
<civodul>davexunit: see :-)
<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
<lfam>Oh! What should I do?
<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
<suitsmeveryfine>petter: the config file says "use the 'desktop services'"
***nckx|offline is now known as nckx
<suitsmeveryfine>(services %desktop-services)
<suitsmeveryfine>so I guess that this should be already configured
<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
<suitsmeveryfine>no linux-libre bootstrapping and stuff?
<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
<suitsmeveryfine>so I just save, close the luks partition and run 'halt'?
<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
<suitsmeveryfine>petter: no?
<petter>suitsmeveryfine, what you've done so far is prepare the config. Now it's time to use it
<suitsmeveryfine>I see
<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
<suitsmeveryfine>petter: shall I just run:
<suitsmeveryfine>guix system init /mnt/etc/config.scm /mnt
<suitsmeveryfine>not replace /mnt with something else?
<petter>no, this should be good
<petter>check that you have it mounted
<petter>suitsmeveryfine, try "lsblk" and see that your crypt is mounted at /mnt
<suitsmeveryfine>error: system locala lacks a definition
<petter>what did you use?
<petter>svenska som dom pratar i Sverige
<suitsmeveryfine>ja, just det
<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.
<suitsmeveryfine>No it seemed to work with mark_weaver's suggestion
<suitsmeveryfine>but thanks anyway
<lfam>mark_weaver: I can try rebuilding it with latex2html as an input.
<mark_weaver>lfam: that would be great, thanks!
<petter>yes, locale -a shows that you would need to type it like that :)
<suitsmeveryfine>downloading packages....
<suitsmeveryfine>this feels very cool
<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
<davexunit>lfam: how long does building python take?
<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, which blocks tor users.
<suitsmeveryfine>right now?
<petter>are you going to work on it?
<suitsmeveryfine>petter: no I don't need to do that right now, only one thing
<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.
<davexunit>which I guess is a good problem to have.
<lfam>Yeah, I know :) That's why I'm doing this right now.
<davexunit>rekado: does guitarix take long to build?
<lfam>davexunit: I did `guix environment python-2.7.10`, and then built it. It only took a minute or two. Doing --rounds now
<davexunit>oh sweet
<lfam>Still a little long to make an audience wait but you could keep talking while it biulds
<davexunit>I'll have it pre-built
<davexunit>and just do guix challenge
<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>Here is Debian's list of bugs relating to this subject:
<lfam>It includes non-reproducible package reports
<davexunit>yeah, my python is live now too
<davexunit>and there's a *lot* of stuff to delete
<davexunit>and I'd have to delete it in the right order...
<lfam>Hah. Guix is too dependable
<davexunit>lol yeah
<mark_weaver>davexunit: if you pass multiple things to "guix gc -D" I guess it will delete them in the right order.
<davexunit>mark_weaver: it didn't, actually.
<davexunit>I did
<lfam>You could also use a vm-image to have a "fresh" store but that might take too long to set up
<mark_weaver>oh, that's a drag :-(
<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, 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`?
<davexunit>then something has changed
<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.
<davexunit>we just can't right now.
<davexunit>not enough disk.
<lfam>I have put my last message in my todo list
<suitsmeveryfine>petter: here is the new document
<NiAsterisk>i'll eventually get used to it, it's just repetition
<davexunit>I guess I won't show 'guix challenge' tonight
<davexunit>but I'll mention that it's cool!
<suitsmeveryfine>I got another system error: build failure
<suitsmeveryfine>probably a network issue it says
<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
<suitsmeveryfine>bzip2: compressed file ends unexpectedly
<mood>I added --fallback, it started running.
<suitsmeveryfine>mood: what can I do?
<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 :)
<lfam>And to host it
<suitsmeveryfine>I see!
<suitsmeveryfine>I hope the fundraiser will be successful
<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
<suitsmeveryfine>petter: and thank you! but I've not yet succeeded
<civodul>lfam: --install upgrades if the thing is already installed
<civodul>lfam: so either way is fine!
<lfam>civodul: So, it's a safe catch-all for "get the latest version"
<suitsmeveryfine>can I run guix system init /mnt/etc/config.scm /mnt --fallback
<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?
<NiAsterisk>you need the keyboard layout first imo
<petter>that's not specific to Libreboot
<mark_weaver>petter: fwiw, I agree that the keyboard layout thing should go in the Guix manual.
<mark_weaver>I have to go afk for a while.
<petter>Should the Libreboot guide be standalone, or an appendix to the GuixSD manual
<suitsmeveryfine>could you please give me some advice with "build failed"?
<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>I can take a photo of the screen
<suitsmeveryfine>not sure where to upload it
<petter>suitsmeveryfine, try this,
<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?
<suitsmeveryfine>hold on
<lfam>If the bad gzip2 archive is in your store, you should try to `guix gc -d` it
<lfam>To get rid of it
<suitsmeveryfine>that last line is the last command I ran