<mark_weaver>calher: '1' jumps to the first menu item, '2' to the second, etc.
<lfam>There are security updates for Kerberos on the ML for anyone who would like to test or push them. I didn't push since the patches are "cherry-picked" and I don't know how to test the functionality of Kerberos.
<mark_weaver>calher: there's an extra closing parenthesis on the line with "%desktop-services". that's the only problem I see with it.
<mark_weaver>Jookia: maybe, instead of 'libreboot?' being an option, we should just *always* install both grub.cfg and libreboot_grub.cfg, and instead arrange that if the grub-install fails, only a loud warning is issued and not a failure.
<nckx>Building gtk-doc on master returns: ‘configure: error: could not find DocBook XSL Stylesheets in XML catalog’
<mark_weaver>here's the thing: I *want* GRUB installed to my hard disk, even though I'm on Libreboot, because if my Libreboot machine dies, I'd like the option to take my drive and put it in another machine that might not have Libreboot.
<mark_weaver>and similarly, if someone initially installs on a non-Libreboot machine, they should be able to take the drive and put it in a Libreboot machine and boot it.
<mark_weaver>the reason is that technically it's somewhat incorrect to load a grub.cfg that was meant to work with a GRUB binary that the OS installed, because it will do things like try to load modules and so on.
<Jookia>This is true- though I'd like to think the difference is they shoot you AFTER you give the password, not after they take your laptop
<mark_weaver>anyway, it's probably more efficient to obtain your disk password via surveillance
<mark_weaver>or by modifying your machine (if you don't carry with you everywhere) to install a keystroke logger or something.
<calher>mark_weaver: -bash: herd: command not found
<mark_weaver>but anyway, I spoke to someone else here today who isn't running Libreboot, but wants to use full disk encryption and wants to avoid installing GRUB on the hard disk. they will instead use GRUB installed on a USB stick.
<Jookia>mark_weaver: Can that already be done by changing the device?
<mark_weaver>calher: ah, your guix is from before the dmd -> shepherd transition. in that case: deco status tor
<petter>i'll refine that bit, i had the idea of doing a simple install first to get a system running. Then do a post-installation where desktop and such where added. But i don't think it's such a good idea
<mark_weaver>it didn't occur to me that people would want to be doing things like access external bazaar repos with SSL in between getting the bare-bones config installed and a nicer one.
<mark_weaver>it's just that I know from experience that when people make a mistake in their initial installation, it tends to be painful, whereas it's much cheaper to make mistakes with later "guix system reconfigure" operations because of our roll-back feature.
<Jookia>mark_weaver: I think the 'right' solution here is to change the 'device' data structure in some way to allow specifying intent- ie "(device ('libreboot)) "(device ('disk "/dev/sda"))" "(device ('none)"
<calher>mark_weaver: IDK, Bazaar seemed to demand SSL.
<mark_weaver>but I don't know, maybe it's better to instead recommend a basic desktop config with minimal changes made by the user, to minimize the probability of errors without forcing users to deal with text consoles.
<calher>mark_weaver: sorry about the bazaar thing; i kept my config.scm in there to track revisions
<Jookia>mark_weaver: Honestly it'd be nice if GuixSD came with GNOME or something by default
<mark_weaver>yeah, it was probably a mistake to suggest starting with the bare bones config. sorry about that.
<calher>and i made the mistake of not learning the bzr CLI before Bazaar Explorer. But Bazaar Explorer is so easy and convenient.
<petter>mark, personally i think a minimum-to-get-a-booting-system approach seems good, for the reasons you said. But there was resistance when i asked her previously
<Jookia>bzr seems like such an odd choice for a vcs these days
<calher>(1) its version numbers are human-readable; (2) it's GNU.
<mark_weaver>petter: if the X server fails to start, in the overwhelming majority of cases, the text console will still be available and usable.
<vaeringjar>I might have come late to the conversation, but why not just use the emacs vc instead of bazaar?
<mark_weaver>so now I'm leaning toward providing a few example configs and suggesting that the user starts with one of those with a minimum of modifications.
<kristofer>Jookia: I like the idea of specifying the intentended boot type.. I struggled for a few days trying to get grub to efi boot with no luck.. there could be a setting for boot-style or something, mbr, efi, some others I'm unfamiliar with
<calher>Jookia: "Revert the repo to revision six bee eff zero one eight cee two"
<mark_weaver>in my case, I make both of those a symlink to my git checkout
<petter>mark_weaver: ok, doing a little thinking here... the primary reason for recommending bare-bones in the draft was that there had been quite a few reinstallations. And with bare-bones it's quicker to reinstall and less to go wrong. But these are current (past?) problems that will be ironed out. A installation manual should be based on things working as they should i think now.
<mark_weaver>calher: I'm interested in the rights of individuals, not the rights of "owners"
<mark_weaver>calher: anyway, the thing to be careful of is that when you run "guix package" as your normal user, you'll be using ~USER/.config/guix/latest, and when you run "guix system reconfigure" as root, you'll be using ~root/.config/guix/latest
<mark_weaver>and that means that either you need to run "guix pull" as both root and your normal user, or else you'd better make one a symlink to the other.
<Jookia>civodul: I've thought a lot more about the Libreboot code and figured two things need to be done: GRUB code needs to be refactored enough to have the GRUB-specific stuff called from grub.scm. This will make it easier to add other bootloaders in future, but more importantly, means grub parameters aren't threaded around. Perhaps this is overboard? Secondly, libreboot? is the wrong flag- we need a 'platform' flag which could be 'none, 'libreboot, 'pc or even one
<civodul>Jookia: the 2nd point makes sense to me, and it's easily implemented
<civodul>my first reaction about the patch was that threading #:libreboot? around was indeed not so great
<civodul>but then i couldn't think of anything great
<civodul>the refactoring you suggest seems like a better way
<civodul>though maybe it'd be enough to pass the 'grub-configuration' object around?
<Jookia>civodul: It may have been easy to but that feels like something GRUB should do
<Jookia>I *may* be biased since I want to implement u-boot sometime and want to make the refactoring easier on later. GRUB should be handling its grub data in its own functions- like passing it what it needs once somewhere
<civodul>right, but we should not conflate the two problems i think
<civodul>i mean, a first step could be a patch along the lines of what you posted
<Jookia>This is true- the reason I'm refactoring is that I went to pass grub-configuration around but then it'd have to pass both it and grub.cfg, so it seemed like a better idea for grub.cfg to be generated by grub internally
<Jookia>If you're up for the code threading both grub.cfg and grub-configuration around, I can do that but it seems... odd
<civodul>instead of threading both grub.cfg and the grub-configuration, we could thread just the grub-configuration object and instantiate it only where needed
<civodul>i think this part of (guix scripts system) needs love
<civodul>there are several things that aren't nice
<civodul>efraim: did you have a chance to look at my package-with-python2 proposal?
<Jookia>civodul: hmm- i'll finish my light refactor and post it and also do a patch of your idea if that fails
<efraim>civodul: I did but not closely, I'll take a good look at it in the next day or two but I like the way its going. We'll have to decide also about making python2-setuptools an automatic part of python2 packages
<myglc2>mark_weaver, petter: re: GuixSD works on GPT. ~ 10 days ago when I tried GPT I got GRUB embed errors that went away when I switched to doc/MBR, so I thought it didn't. Sorry for the misdirection.
<rekado>sad to see free bioinformatics software relying on the proprietary CPLEX :-/
<rekado>Guix will get a dedicated paragraph in the 2015 research report of our institute.
<davexunit>boegel: I can only imagine! I just wanted to make it clear that disappoint about losing some talks that I am *very* appreciative of the work that goes into recording these sessions for FOSDEM>
<boegel>rekado: I'm glad you accepted my invitaton to submit a talk (and that it got selected)
<davexunit>Steap|DevConfCZ: we need to absorb those features.
<NiAsterisk>Steap|DevConfCZ: I like this article about a thing which was built on top of Docker to improve Docker.. isn't Docker supposed to be the fix? feels like broken tech all over again, patches upon patches
<davexunit>I desperately need help improving our container implementation.
<davexunit>we all know purity is cool, but I get a lot of mileage out of Guix by using 'guix environment --ad-hoc' to extend my current set of environment variables by a single package for some quick hack.
<davexunit>for debian, we could use the metadata to populate name+version+home-page+etc., but I don't know how much more value we'd get than that. maybe patches? but then again debian patches thing that we may not want to patch.
<rekado>but it makes it easier to start: you get a synopsis/description, some of the inputs, download URLs.
<davexunit>yeah, that's a good point. importers are meant to cut down on boilerplate, not produce a 100% working expression automatically.
<mark_weaver>davexunit: I think he's referring to a conversation that happened between me and someone here on IRC, where they observed that attempting to set the "Style" in the Settings -> Appearance menu of Xfce seemed not to do anything. I looked and agreed that it doesn't seem to work for me either.
<mark_weaver>I'm not sure what the issue is, or even what that's supposed to do, so it might be a bug or a misunderstanding, dunno.
<petter>pizzaiolo: what mark said. Nothing happens.
<davexunit>I took a look at some examples, and the code looked very similar to my render combinator interface for my game engine.
<davexunit>I'm trying to design a case for something and naturally, as a programmer, I want to write a series of procedures that can calculate all the various dimensions for the parts based on some initial constraints.
<kristofer>sly? I'm trying to work with that currently and I'm having some difficulty
<mordocai>How hard would it be to make to where when I build things on my home desktop substitutes are published but through my vps server? Would I be able to just setup the vps server to publish substitutes then rsync or something?
<nully>speaking of which, does anybody know who is looking into that?
<lfam>However, there was a problem in the past where if you had used multiple substitute servers, and the first one did not have the desired substitute, the later servers would not be queried. I'm not sure if that was fixed.
<lfam>I get that warning when downloading substitutes as well. The applications I have installed through Guix do get the proper locale. It's just something in the environment that the substituter is using and I think its harmless, although annoying.
<mordocai>Just to check it isn't me using stuff wrong, i'm just sitting in a standard bash shell on debian and running guix environment guix and that locale message comes up after each substitute is downloaded.
<mordocai>lfam: Ah okay. If it isn't actually a problem then i'm good for now
<Jookia>I'm on siducer and I don't have this error
<mordocai>So i'm confused. I did guix pull then guix environment guix as root. I then switched to my regular user(having never done anything with guix) and ran guix environment guix again and it looked like it downloaded a bunch of substitutes again. However, if it did, it didn't seem to increase my disk space usage by much/at all. What's up with that?
<lfam>mordocai: Everything in Guix is per-user, including `guix pull`
<mordocai>lfam: I thought it was supposed to share everything possible though
<mordocai>Yeah. I have a theory now though. I didn't do a guix package -u after guix pull as root.
<lfam>If the git master didn't change between root's and user's invocation of `guix pull`, then the packages needed for each user's `guix environment guix` will be the same and should not need to be downloaded again.
<lfam>But, if you didn't pull as your user, then your user would need a different set of packages.
<mordocai>Well, in any case I ran guix pull on both users and guix package -u on both and at this point everything seems to be the same.
<mordocai>As in everything is linking to the exact same binaries
<mordocai>My disk usage also halved so at one point I definitely had different versions for each user
<lfam>One thing to consider is that the instructions in the manual suggest making `guix` available globally with a symlink in /usr/local/bin. That is one thing that would not be per-user. Of course, you can do `guix package -i guix` as your user and not use that symlink.
<mordocai>Yeah. I did the symlink but now have guix package -i guix for both users and .guix-profile/bin in path.
<lfam>I'm not sure why it tried to redownload the substitutes. Something must have been different.
<lfam>Running `guix package -i foo` is like `apt-get install foo` except it is per-user rather for all users. `guix environment foo` is what you would do if you wanted all the dependencies of foo in your environment while hacking on foo.,
<mordocai>Idk, it just seems like the obvious thing from my non-informed point of view
<mordocai>I'm sure i'll figure it out as I use guix more anyway
<lfam>Your guix-profile is a collection of symlinks that ultimately point to things in /gnu/store. The programs in ~/.guix-profile/bin are typically accessed by invoking their basenames, for which ~/.guix-profile/bin must be in your $PATH. `guix environment`, rather than writing symlinks to disk, directly creates a new shell with new environment variables. It's more ephemeral, and the packages built for `guix environment` are not protected against