IRC channel logs
2016-02-12.log
back to list of logs
<paroneayea>postgres reall just works nicley with like, 0 config steps? <paroneayea>hey how do we deal with things that have git submodules in guix? <kqb>Hello, I have a machine-global guix setup. When I run "$guix pull" and "#guix pull" ("#" is the root shell and "$" is a user-shell) it pulls the image *twice*. Please give me a documentation reference of how I get guix to only pull this *once*. <mark_weaver>paroneayea: set the 'recursive?' field of the git-reference record, and then git-fetch will fetch the submodules <mark_weaver>kqb: I'm not sure what's going on there, and I've not investigated since I *never* use "guix pull" (I run guix from a git checkout instead), but I can tell you a workaround. <kqb>mark_weaver: go on, please <mark_weaver>kqb: "guix pull" makes a $HOME/.config/guix/latest symlink that points to the freshly built guix <mark_weaver>you can make that symlink yourself, and have it point somewhere else <kqb>mark_weaver: I think we had this conversation before, sorry for interrupting <mark_weaver>e.g. you could make ~root/.config/guix/latest point to ~foo/.config/guix/latest <mark_weaver>and then you can just run "guix pull" as user 'foo' and root will use that version as well. <mark_weaver>or make the symlink point the other way if you prefer to run "guix pull" as root. <mark_weaver>(in my case, I have both ~root/.config/guix/latest and ~mhw/.config/guix/latest pointing to my built git checkout of guix) <kqb>mark_weaver: I'll poke around in /gnu/store <mark_weaver>kqb: make sure to never mutate anything in /gnu/store, btw. <kqb>mark_weaver: I was thinking about *looking* first. Maybe my daemon-configuration is wrong, or some build is not registered as *valid*. <kqb>mark_weaver: Shouldn't "never mutate anything" be mitigated by "$guix gc --verify"? <mark_weaver>kqb: well, it should be detected by "guix gc --verify=contents", but just don't do it or else things will break in non-obvious ways. <mark_weaver>e.g. when you build new things that can make use of shared old things, guix will assume that those old things haven't been modified. <mark_weaver>so you can get into a state where you keep trying to build new things but they just keep coming out broken, etc. <mark_weaver>kqb: I don't think it's an issue specific to you. we've heard other reports of this as well. <kqb>mark_weaver: I am trying to figure out if I just misconfigured the daemons. What kind of error to they produce, if the cannot put stuff in the store? <mark_weaver>kqb: I'm sorry, I don't have time to help you debug this. <rekado>can't sleep. Thinking about ways to explain the gist of Guix and functional package management in a series of 2 min videos. <rekado>much like the "emacs rocks" series. <kqb>rekado: how much does the audience know beforehand? <rekado>"emacs rocks" just demonstrates one really cool feature in a really short video. <mark_weaver>kqb: anyway, I don't think it's a daemon issue. it probably has something to do with the way that "guix pull" works, but I've never learned much about that since I never use 'guix pull' and think that using git is a far superior method <rekado>we could have a video for one of the uses of "guix environment" <rekado>then another for "guix package --roll-back" <rekado>another for the emacs interface. <kqb>rekado: does the audience know what a mathematical function is? <rekado>if they know addition this could be sufficient. <kqb>rekado: do they know it can be described as a function/mapping/operator? <rekado>"a function is a machine that produces the same output for the same input" <rekado>kqb: are these rhetoric questions? <rekado>I don't want to make this more complicated than it needs to be. <kqb>rekado: no, I teach people who start learning programming, and understanding what a *math.* function is, is fundamental to *functional* programming <rekado>I think my slide on functional package management is almost sufficient. <rekado>I presented that many times already and people always understood. <kqb>kqb: "a function is a machine that produces the same output for the same <kqb> input" is what I meant <rekado>the key to understand this is just that the output only depends on the inputs, nothing else. <rekado>doesn't matter if it's spring or autumn, or if you had tea for breakfast or coffee. <kqb>rekado: seems to cover everything of fundamental importance <Jookia>So here's a question that's probably going to make no sense: Can I do 'regular' let statements in mlet*? Or do I need yet another let? <paroneayea>mark_weaver: do you know if it's okay to push --force a rebased wip-foo branch? <paroneayea>I assumed it was okay and rebased wip-mediagoblin but I seem to be blocked from that <mark_weaver>paroneayea: I think you need to first delete the branch, using "git push origin :wip-foo" and then push it again. <mark_weaver>Jookia: as the docs for 'mlet*' says, (var -> val) will make a normal binding. <Jookia>Oh I see, you can use "->" in mlet* to get 'pure' <Jookia>mark_weaver: Haha thanks, I figured it out a minute ago after reading some other code and grepping :) <paroneayea>today I removed the "#!/usr/bin/env bash" from MediaGoblin and switched to #!/bin/sh <paroneayea>it was pointed out that just a few weeks ago, I merged a patch *adding* the env stuff for bsd/solaris compatibility! <Jookia>paroneayea: the 'proper' way to do this is using something that replaces shebangs <paroneayea>you mean like bootstrapping autoconf for bsd vs gnu <paroneayea>Jookia: but even for that you need a bootstrap script I guess :) <Jookia>I mean like 'have a script that during builds will change the shebangs in the output files' <paroneayea>. o O (How did I get r5rs.info in my user's profile? Oh well, it's welcome there anyway...) <mark_weaver>and in general, items in your profile are symlinks, and by looking at the symlink you can see where it came from <lfam>Has anyone tried using the btrfs-progs patch yet? <mark_weaver>paroneayea: (although if an entire directory is from a single package, the directory will be replaced with a symlink and then the individual files within won't be symlinks) <mark_weaver>everyone should update their 'icecat' package ASAP, to get the fixes in the bundled graphite2 library. <mark_weaver>(note that the system-wide graphite2 fixes are in the security-updates branch only for now, pending rebuilds) <paroneayea>mark_weaver: ah yes, duh, could have looked at symlink <nckx>lfam: feedback welcome :-) <rekado>Remember that Sunday is "I love free software" day. I hope we will find many blog posts and microblogging statements of appreciation for Guix. <rekado>you could get the feeling that moving away from Github and hosting elsewhere is the code equivalent of leaving Facebook: you become invisible and people stop caring about you. <mordocai>Yeah, I also read through those comments and was sad <rekado>it's farcical how in some comments the UI of alternatives are rated according to how close it is to Github (not how usable it is) --- what matters is "familiarity for Github users". Wow. <paroneayea>rekado: I've gotten several times since being on this retreat "Don't you think you could get more contributors by being on github?" or "where are you on github?" <Jookia>"That we have computers to solve those problems." <- implying computers can solve problems <rekado>paroneayea: yeah, I heard that too. <Jookia>Computers just do what humans do but faster <rekado>I have a soft spot for computers, but humans using them ... I don't know, they mostly just make me want to stop using computers. <jlicht>rekado: you should sell mugs with that quote on it ;-) <lfam>nckx: It looks good and I can do basic stuff inspecting my filesystem with it. Did you try creating a filesystem with the tools installed by the package? <rekado>or maybe I should pick up pottery. <jlicht>and although I get and agree with your points, github does make it laughably easy to find and just passively follow projects you're interested in. <Jookia>jlicht: if you use github, that is <rekado>jlicht: I found that I mostly don't really care about projects on Github. To me they are a bit like funny images on the internet. <mordocai>Is there anything known in guix that would break icecat firefox sync? It looks like they had a bug in 38.3.0 but 38.6.0 should be fine. <rekado>they entertain me when I stumble upon them, but I wouldn't really notice if I had not encountered the. <lfam>nckx: Okay, cool :) I made the test suite pass. <Jookia>It's impossible to use github with only free software so it's pretty much useless for people like me <mordocai>Well watch what you install through guix Jookia. Lots of stuff that comes from github per my quick search :) <rekado>(I find most stuff that I end up really caring about with plain web searching or by being part of certain communities that produce stuff that I'm interested in) <nckx>lfam: whoops, that's a left-over copy-paste... So there is a test suite? <lfam>nckx: Yes, I had to set the #:test-target to "test" and make sure tests did not run in parallel. Parallel tests failed repeatedly on 002-uuid-rewrite. <jlicht>Jookia: ah, that clarifies a lot about your stance. I know it can't be easy, for both you and guix, always having to answer the same questions regarding why "you're not just on github already" <mordocai>ugh, I accidentally just replied to one person with my mailing list email... guess they'll get it twice. <Jookia>jlicht: *shrug* it's the reason I'm moving from nixos to guix, it's basically impossible to get a patch in without github <dmarinoj>rekado: Yeah, I love lurking on the mailing list just to see what is happening with the project <jlicht>reading/searching through mailing list archives using the web interface is still a pain though, unless I'm Doing It Wrong <lfam>I'm curious, what do you think would be a really good interface for that? <nckx>lfam: thanks a lot. I'll add that, run the tests, and submit a V2. <rekado>jlicht: I agree, this could be a lot nicer. <lfam>nckx: No need, I can make those changes and push while keeping you as the author. <lfam>Unless you'd prefer I not <nckx>lfam: no, that would be excellent! <jlicht>lfam: I would probably just want to 'import' the archived emails in a news reader/email client. Seeing as it is an archive anyway, I won't be replying to it anytime soon. <jlicht>and I like to have a unified interface for consuming information <rekado>I had the same desire and asked around for how to do this best with Emacs. <lfam>jlicht: I have wished for the same thing. I like the interface of my mail reader and like searching with the tools I have <rekado>the recommendation was to use gnus and gmane. <nckx>ACTION hopes to learn enough to add btrfs root support before 0.9.1, but, heh, we'll see. <lfam>Wow, I think we found a common source of pain <rekado>but I find it hard to justify learning gnus when I use mu4e for email. <rekado>it's possible to download an mbox, too, I think <lfam>nckx: It would be cool for the release but if it doesn't cause mass rebuilds it can be added at any time <lfam>You can download a mbox of the guix-devel archives? <jlicht>rekado: please do elaborate on where to find this mbox. Is this only for guix mailing lists? <rekado>jlicht: ftp://lists.gnu.org/guix-devel/ <rekado>this is probably available for all GNU mailing lists, maybe even for all mailman lists. <lfam>Thank you :) I have wasted some time searching on the web site <jlicht>rekado: that was quite obvious. Shame on me for never reading the top part of pages properly when I'm hunting for content <rekado>you can read them with rmail: "M-x rmail", then "i", then "/path/to/mbox/file", then "h". <Jookia>jlicht: Don't worry, it's only when you're hunting for a link to the listinfo from the archives that it becomes a nightmare <rekado>hmm, rmail is not so bad as an archive reader. <jlicht>rekado: thanks for the 'batteries-included' advice. The nice thing about emacs, but also in guix up till now, is that I always keep learning usefull stuff from interacting with people <Jookia>Ooh my vm refactoring code is almost done! <nckx>Hmm. How can I create an installer image on a system without KVM support? ’guix system disk-image’ barfs without it. :-/ <lfam>All the time I am getting expiration notices from Let's Encrypt from all the certs I generate while testing our letsencrypt package :) <lfam>nckx: I sent a crude patch to guix-devel in the last few hours for that <lfam>If it works then we should make some kind of command-line switch to do it <lfam>A crude patch that works on my KVM-enabled system, that is. Please report back! <Jookia>lfam: works on my machine (i made an identical patch independently) <lfam>Jookia: Yes, it's really a trivial change <Jookia>lfam: it'd be better to check if the kvm module is loaded and tell people who don't want to use it to rmmod kvm <lfam>Jookia: What do you mean? <Jookia>lfam: if you forget to run --disable-kvm you'll panic your broken libreboot machine <lfam>Right. It would be good to both things :) <Jookia>yeah, but it's one 'i didnt read the manual' away from a kernel panic :P <lfam>Yes, I am agreeing with you :) <lfam>It would also be good for people like me to be able to turn it off with a switch <nckx>lfam: -devel, you say? I can't seem to find anything. But then my oldest message is from 4 hours ago. <nckx>lfam: thanks! Hah. That's easier to copy by hand than copy to my Guix machine. <nckx>Booting a VM to generate an installation image is at once weird and strangely elegant. Anyway, lfam, it works! <Jookia>Woo time to run the test suite to see what's broken because of my changes <codemac>has anyone had guix fail with "illegal instruction" with the most recent guile from hydra? <codemac>My guix install is pretty messed up now, it worked as of the 0.9.0 bootstrap binaries <codemac>Jookia: no I'm on an intel celeron 3205 (broadwell x86_64) <codemac>I can't rollback either because I can't run the guix program :( <codemac>I'm searching around for an older version of the guix program in /gnu/store to try and fix things up. <Jookia>Have you tried booting an older GuixSD? <mordocai>Woot, managed to get my evil hardware to work with opengl 3.3+ <lfam>codemac: Could you build from an older git checkout and work from there? <mordocai>Jookia: Yeah, i'll get a more freedom respecting card in the future but I want to do some game dev now :) <mordocai>davexunit: Well the drivers are free but a non-free blob <mordocai>So yeah, less/no yay depending on your views <nckx>lfam: scratch that. Kernel panic, inside the VM. Probably a different issue. And with that, I'm off to bed. o/ <lfam>nckx: Better luck another day! <mark_weaver>codemac: choose an older version of the system from the GRUB menu <codemac>I'm not on guixsd :( but I think i'll have something figured out soon :) <Jookia>Woo, cleaning up and documenting a patch series for Guix :D <Jookia>Uh-oh it seems I can't include 'gnu system grub' in the build directory <Jookia>mark_weaver: Would you happen to know why include 'guix packages grub' in gnu/build/install.scm causes guix to say "guix: system: command not found Try `guix --help' for more information.", or why it finds no code for 'gnu system grub'? I have a feeling this is to do with build isolation <mark_weaver>Jookia: the module name is (gnu packages grub), starting with 'gnu' not 'guix' <Jookia>mark_weaver: (gnu packages grub) gives this error: "no code for module (gnu packages grub)" <Jookia>It only happens when I run 'vm-image', it works in the usual 'init' <Jookia>I'm also under the impression it's a bad idea to include things from outside build directories when you're in one <mark_weaver>(gnu build ...) is build-side code. the (gnu packages grub) module is not available in that restricted environment <Jookia>I want to use the grub-configuration data type when building <Jookia>I'm trying to directly pass grub-configuration to install-grub <mark_weaver>the build side code in general doesn't deal with high-level objects like package objects, and the grub-configuration includes those. <mark_weaver>and data that is passed from the client side to the build side ends up being serialized in the inputs to the derivation <Jookia>Instead of passing grub-configuration would it be better to have a grub-build-config that reads that? This seems perhaps a bit overkill though having an intermediate format <Jookia>I'm coming at this from two angles: Changing/adding things to be used when install-grub is run, and also down the line being able to replace install-grub and grub-configuration with install-uboot and uboot-configuration, for example. <Jookia>Though thinking more about it, it may be a better idea down the track in my hypothetical land to not have multiple -configuration but instead use grub-configuration (or renamed to boot-configuration) for u-boot and have some install-specific flags <mark_weaver>Jookia: if we want to pass down a composite, extensive object, it should probably be either an association list (i.e. a list of key-value pairs) or a keyword list, similar to 'arguments' in packages. <mark_weaver>well, you can ask civodul, and admittedly this is an area where my knowledge of guix is not strong, but although civodul is reasonably fond of using records for things, I notice that he has not so far used records for passing data between the client side and build side, and I guess he has a reason for that. <mark_weaver>one complication is that Guile's reader cannot read records as data. <mark_weaver>the main difficulty is that at read time we don't know the set of record definitions. <mark_weaver>the reader needs to be able to do its job without knowledge of the set of bindings or record types, etc. <mark_weaver>on the other hand, we could generate an expression that, when run, calls the record constructor to create the record. <Jookia>I see. So with a composite object, is it possible to define it's schema or a constructor, similiar to a record? I assume it'd just be a function, yes? Then I could put that in the build-side code which the host-side code can read, then in the host-side make a grub-configuration -> that-record and pass it <mark_weaver>I'm sorry, I don't have time to think about this more right now. Please ask civodul. <Jookia>I certainly don't want to overload you or #guix with newbie questions. :P <Jookia>Or rather, thanks for you help. :) <mark_weaver>partly it's that I know that civodul already went over thinking about these issues when he wrote core guix, and can probably answer your questions much more efficiently, whereas I would need to think it through myself. <mark_weaver>and partly it's that right now I'm trying to focus on making Guile's macro expander deterministic. <yvm>There is no DRI in GuixSD? :< <Jookia>yvm: Does your card need nonfree firmware? <yvm>Direct Rendering Interface. <yvm>Interface of DRM/KMS. <yvm>No, my card doesn't need nonfree firmware. Why? <xd1le>yvm: because guixsd doesn't have any nonfree software <yvm>I see there is DRM in default kernel compiled as module. <yvm>Why we talk about my videocard and nonfree software? <Jookia>yvm: Most likely if something doesn't work it's because your card isn't supported <yvm>Qemu has "Cirrus Logic GD5446 Video card." as default video card according to manual. <xd1le>yvm: you asked why Jookia asked if your card requires nonfree firmware <lfam>yvm: GuixSD uses the linux-libre kernel, which is based in linux but removes all the non-free parts, many of which are drivers. If your video card can work with free software, then it should be possible to make full use of it in GuixSD. <yvm>DRM/KMS should support Cirrus Logic GD5446, qemu doesn't need to support linux kernel's subsystems, AFAIK. <lfam>Oh, so you are having this problem in QEMU? <lfam>What was it? :) Something we can improve in our QEMU settings? <rekado>does anyone else experience a very long delay when pushing to savannah? <rekado>it usually gets stuck at "remote: Sending notification emails to: guix-commits@gnu.org" for a really long time. <fhmgufs>What is needed if an application says 'Couldn't recognize the image format of file: asdasdaqwertz.svg'? <efraim>I don't do a lot with image files <df__>imagemagick supports svg <janneke>fhmgufs: then the application has been built without support for svg... <fhmgufs>Yes - that's the question, how do I add support for svg? <janneke>read what ./configure --help has to say about it? <janneke>possibly install libsvg first and configure/pkg-config might pick it up <davexunit>we can use the XPRA X11 bridge to do things like run IceCat in a container (via call-with-container, of course) and only share particular pieces of the file system with it. <davexunit>isn't it a little worriesome that your web browser *could* read your ssh/gpg keys or anything else in your home directory? <taylan>it most certainly is, perhaps more than a little :P <NiAsterisk>hi! just a quick question before I leave for the hackerspace for flashing (no equipment here at my home yet) libreboot, I read about some virtualization issues o gm45 hardware with libreboot, is qemu | kvm somehow involved and/or required with one of guix environment subcommands? <davexunit>NiAsterisk: I think the issue is that we currently hardcode the kvm stuff into our qemu VM stuff, but someone has proposed to make it optional. <davexunit>and AFAIK, librebooted intel laptops have no hardware virtualization support due to lack of microcode <NiAsterisk>oh wait a sec. right. I bought one of the last intel CPU generations without it :D <mark_weaver>The Libreboot X60 and T60 has virtualization support <mark_weaver>on the Libreboot X200, T400 and similar, the problem is buggy microcode in the CPU, iiuc. <davexunit>cool, but I swear I read in here that at least one model doesn't work. <NiAsterisk>it's a t9400 core 2 duo cpu, that's all i know right now <rekado>davexunit: I'd also like to isolate the browser. It's fine to read/write to ~/Downloads, and read its config files, but I don't want it to be able to mess with anything else in my $HOME. <rekado>in the past I tried to isolate it with SELinux, but that was very hard. <davexunit>rekado: we can definitely do it with call-with-container, XPRA, and a CLI. <davexunit>ACTION brainstorms a bit about what a remote GuixSD deployment would look like <davexunit>VM daemons need some disk image to boot, but I don't think that each deployment should make a fresh disk image since it's wasteful. <davexunit>perhaps a minimal VM image is created to boot the machine, and then it is reconfigured with the correct system once it's booted. <davexunit>so yeah, I guess pretty much every config management system does this <davexunit>in our case, we'd build the base image automatically without relying on some random base image a la Docker. <bavier>and we'd bake into the base image a system config file to reconfigure itself with? <bavier>or you'd send that over once the vm is booted and accepting ssh <davexunit>but for the sake of bootstrapping, a hardcoded base system is fine. <davexunit>from there we can do an RPC to guix-daemon over an SSH tunnel to copy the system closure. <davexunit>the goal for me would be to not rely on the version of the guix client code running on the remote machine. <davexunit>I'd like to just copy the system closure and copy the necessary code over that will trigger the reconfigure machinery <bavier>davexunit: it might be useful to not have a strict master-slave interaction <davexunit>like how hydra doesn't care what version of guix hydra's build slaves are running (provided the daemon protocol hasn't changed) <davexunit>bavier: I'm explicitly trying to avoid what I believe are problems with config management systems like Chef and NixOps with this. <davexunit>for Chef, there's a centralized server that stores all of the scripts and node information. it sucks. <davexunit>for NixOps, there is a state file that needs be kept up-to-date on every workstation that uses NixOps <bavier>I was just wondering whether the remotes could do a standard reconfigure, where the master is configured to publish its store <bavier>it's perhaps too early to think about cluster provisioning, but if remotes could serve their stores to other remotes, it might help scalability <davexunit>bavier: I think what would be best is that we send the system derivation to the remotes and build + instantiate it <davexunit>the drawback on my first proposal is that the workstation has to transfer a potentially huge system closure to tons of nodes <davexunit>which definitely sounds like a scaling issue. <davexunit>the drawback for the second proposal is that remotes are doing redundant work, unless a CI system is pre-building the system and publishing it. <avoine>davexunit: you would use the same RPC technique to add and configure a software on a remote machine? <davexunit>this would allow derivations to be copied from local machine to a remote machine easily <mark_weaver>hmm, gst-plugins-good consistently fails its test suite on my i686 box :-( <bavier>redundant work on remotes seems more appealing than monolithic broadcasts from a single point <davexunit>but here's a tricky scenario: you send a over bad system config that fails to build. <davexunit>if the system was first built on the client, it would be easier to do error handling. <bavier>and the store would be primed for publishing <davexunit>I don't want the client machine to be publishing, necessarily. <davexunit>for a number of reasons, but primiarly network security <avoine>davexunit: It might be too early to think about that stuff but would it be possible that machine A use a derivative built on a machine B? <avoine>like generates a mysql database + user + password on machine A and ship it to my django on machine B <davexunit>hard to explain, but passwords are state, they are not part of the declarative system configs we're talking about <davexunit>I think copying a derivation to each remote and telling it to build it is best from a decentralization and parallelization standpoint. <davexunit>it leaves some open questions, but they can be dealt with. <davexunit>using substitutes is purely an optimization. in a "production" system, you would pre-build the systems on the build farm or otherwise make sure they pass a test suite before you go live. <davexunit>2 error scenarios to consider: what happens when the derivation fails to build on a node? what happens when the system fails to instantiate on a node? <davexunit>I think the answer to the first may be "roll back on all nodes" <davexunit>the second is more difficult, because we enter the stateful world. <davexunit>er, "roll back" was the wrong phrase to use. if any node failed to build the system, we could stop there and not instantiate it on any node. <davexunit>if instantiation fails, the best thing to do may be nothing, dunno <NiAsterisk>ah! I disabled kvm in the bios long time ago. so it worked up to now with guix, so I should be all good. just looked at /var/log/messages <NiAsterisk>although.. bios will get replaced. well, we'll see. <jin>hi guix, how can i replace or modify standard-phase for ./configure?, i've issue with 'CONFIG_SHELL' <bavier>jin: (arguments `(#:phases (modify-phases %standard-phases (replace 'configure (lambda* ...))))) <jin>bavier: i will try, thanks <pecg>Following this guide: http://sprunge.us/PMib , I get: Path '/mnt/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting <pecg>"guix system: error: failed to install GRUB on device '/dev/sda' " <pecg>This happened after guix system init /mnt/etc/config.scm /mnt <pecg>With encrypted root, and two partitions /dev/sda1 and /dev/sda2 <pecg>First one for /boot and second one for / <pecg>What could be causing the error? I can think of guix not knowing that /dev/sda1 is for GRUB <mark_weaver>the issue is that GRUB is stored in /mnt/boot/grub, and grub-install realizes that it won't be able to load itself if /mnt/boot is encrypted <mark_weaver>so this is a real problem unless you're actually going to use a different GRUB, e.g. the one burned into the boot flash with Libreboot. <pecg>That was what I was thinking (sort of) <mark_weaver>pecg: if you intend to use the GRUB on the hard disk, then you'll need to make a separate partition for /boot that's not encrypted. <pecg>What I was thinking is to delete mount /dev/sda1 inside /mnt/boot <mark_weaver>and declare it as a filesystem in your OS config, and reinstall <pecg>Sorry, only mount /dev/sda1 (which is the non-encrypted boot) inside /mnt/boot <pecg>mark_weaver: got it, going to try to do that. <pecg>do I have to format the whole /dev/sda2 again? <mark_weaver>you might need to wipe what's currently in /mnt (making sure not to blow away your config) <mark_weaver>starting from scratch certainly works. as for short cuts, I'm not sure what works and what doesn't. <pecg>I format everything again, not a problem. <pecg>I will write again the config.scm <mark_weaver>the cow-store puts something on /mnt, and it might be bad to blow that part away <mark_weaver>or at least it would probably require rebooting the USB installer <rekado>finally got around to setting up guix over network for the cluster users. <rekado>one comment says: "this is exciting like the first time I discovered `sudo apt-get install`" <rekado>(after that user tried installing as a user and --roll-back) <rekado>I'm going to polish this a little and then write about it. <rekado>I would actually like this to be part of Guix. <rekado>right now it's a wrapper that starts socat for socket redirection over TCP, tells guix to use that socket, and then runs guix, and cleans up after itself (to be sure that no stale sockets remain and no socat processes keep running) <alezost>rekado: oh great! ISTR you faced some big problem on this "guix over network" way <rekado>yeah, for a long time IT didn't mount the profiles read-writeable, so I couldn't do anything. <rekado>we're still having a lot of trouble with the network, and performance over NFS is still abysmal, but with a switch upgrade next week this *might* change. <rekado>profiles with many files take a very long time to be upgraded. <rekado>having libreoffice installed in a profile is enough to slow down building the next generation of the profile considerably <rekado>(on the order of 10 minutes waiting time) <rekado>most time seems to be spent doing lstat over NFS, and a misconfigured network (as we seem to have inherited from previous generations of sysadmins) is can slow this down to a painful crawl. <rekado>if it isn't better after the switch upgrade I'll spend more time measuring rather than packaging. <alezost>oof, happily I don't have a need in libreoffice currently (and thanks god in texlive as well) <alezost>yeah, now I recall this performance issue, thanks for describing it <rekado>luckily(?) it's not just the guix-daemon that is slow over NFS, so I have hopes that *eventually* this will be fixed centrally. <CompanionCube>ACTION once made the mistake of having both texlive and the texmf package in the same profile <a_e47893>CompanionCube: texmf is just a subset of texlive. So everything collides... <a_e47893>Actually, I think we should make texlive-texmf private. <a_e47893>Initially I had kept it public so that one could more easily download the binary package that takes a while to compile from hydra, and build texlive-texmf locally. <a_e47893>But the step from texlive-texmf to texlive is really trivial. <a_e47893>It would be enough to keep texlive-bin public. <CompanionCube>I built texlive-texmf locally because no way in hell would I download the ~3GiB of texmf from hydr <a_e47893>guix download file:texlive-...texmf.tar.xz <a_e47893>This will also build texlive-texmf locally as an input to texlive. <davexunit>rekado: oof. profile unions need to be made faster... somehow. <paroneayea>yeah I noticed the profile union slowness yesterday when showing guix to a friend <paroneayea>interesting that showing others helps us see problems that we can overlook when it's just us... <pecg>mark_weaver: in order to make /dev/sda1 for /boot, config.scm needs to have filesystem definition in (file-systems (cons )), am I right? <pecg>so the file-systems symbol can get a list (constructed list, thus cons) that has the definition for the encrypted root and the unencrypted boot <pecg>are these systems the same ones that are mounted during boot? <pecg>The same ones I used to put on /etc/fstab, when using other distributions? <pecg>Maybe I wrong, but I'm almost certain that (file-systems) is a function that takes a list argument used to (among other things) generate /etc/fstab, tell GRUB what filesystems to look after, and so on <pecg>or am I over thinking and over analyzing everything? <mark_weaver>pecg: it's true that 'file-systems' takes a list argument. <mark_weaver>however, 'file-systems' is not a procedure, but rather is a field of the 'operating-system' record that you're constructing. <yvm>Is there a howto how to build custom kernel in GuixSD? <mark_weaver>it should be (file-systems (cons* (file-system ...) (file-system ...) %base-file-systems)) <mark_weaver>yvm: no howto, but just add a package definition for your kernel and specify it via the 'kernel' field of the 'operating-system' <yvm>Got it. Thanks. I think I just need to read manual more. <pecg>mark_weaver: Great, I have it, just like that <pecg>yvm: The manual is incredibly good written <pecg>Of course it can be improved, but the basic documentation in order to build the OS is already there <pecg>Which is amazing (at least for me) considering the majority of contributions (if not all) are made by volunteers <pecg>mark_weaver: What is the difference between cons and cons*? <pecg>the internet doesn't yield anything <pecg>mark_weaver: Yep, it is there <mark_weaver>basically, cons can only add one thing to the front of a list, but cons* can add more than one. <mark_weaver>cons is the fundamental list constructor (actually, the 'pair' constructor) <pecg>guix system init was failing, with cons* <davexunit>yes, ludo fixed the testing issue with my environment profiles patch and pushed it! <davexunit>now 'guix environment' won't build/download unnecessary things <davexunit>and we're a step closer towards saving environments for later re-use. <mordocai>davexunit: That is awesome news. I was wondering why environment seemed to sometimes do unnecessary work <davexunit>mordocai: yeah, it was a flaw in the initial implementation. this patch has been blocked for a long time by difficulties with the integration tests. <davexunit>I wrote it several months ago, and ludo figured out how to test it properly. <janneke>i've been wondering about querying an environment you created for the packages in it, to "save" it <davexunit>janneke: that wouldn't work well, but there's a way that will work well. <pecg>mark_weaver: Installing again, guix is complaining that GRUB cannot be embedded, it tried to, since I defined a GPT for the disk but didn't make a BIOS partition <paroneayea>sqlalchemy is failing to run tests correctly here for me... <fhmgufs>Can I build a GuixSD system without GRUB and without the kernel? <paroneayea>oh, I see there are some emails on the list about this <paroneayea>fhmgufs: you can build without grub... what would buildding without the kernel mean? <paroneayea>it's actually excellent software in many ways except <paroneayea>for all the ways that have made me miserable for years <davexunit>I knew you'd have something to say about it :) <paroneayea>we're probably dropping sqlite as a production db for mediagoblin <paroneayea>well over half of our devtime I'd say in mediagoblin is probabably wasted on two things: <cbaines>I have tried to add a new package to gnu/packages/pulseaudio.scm, and am trying to build it, but cannot work out how? <cbaines>The package is called paprefs, and running guix build paprefs just tells me "unknown package" <fhmgufs>cbaines: Where's the package definition located? <davexunit>cbaines: are you use the pre-installation script to run guix? <cbaines>fhmgufs, at the bottom of gnu/packages/pulseaudio.scm <cbaines>davexunit, That just gives me an error regarding failure to connect to the daemon, which might be as I am currently using GuixSD? <fhmgufs>Do what davexunit said and then run './pre-inst-env guix-daemon --build-users-group=guixbuild' <fhmgufs>cbaines: Or, if you're on GuixSD there's no need to start the daemon. Just do the './configure --localstatedir=/var' <cbaines>Yep, just running guix environment guix, and then ./configure --localstatedir=/var seems to have been sufficient <mark_weaver>cbaines: if you're on GuixSD, then the guix-daemon should already be running. <cbaines>Its now downloading lots of stuff... <fhmgufs>Back to my question: Maybe you didn't understand what I mean: I would like GuixSD to manage everything starting from PID 1 to the user interface but not the things below (firmware, bootloader, kernel). <mark_weaver>fhmgufs: out of curiosity, why don't you want GuixSD to manage the kernel? <mark_weaver>I suppose you could just let it build its kernel and then not use it <fhmgufs>Because I'm still on my Raspberry Pi and want to use the official prebuilt kernel. <CompanionCube>ACTION is thinking of resizing a btrfs partition to make room for guixsd <fhmgufs>But building the kernel takes about one day. <fhmgufs>I thought that the kernel parameter is a normal package. <mark_weaver>make a dummy kernel package and specify it in the OS config. <mark_weaver>or better yet, make a kernel package that builds a kernel suitable for your device <fhmgufs>There's a git repo qith prebuilt firmware including bootloader and kernel which I could put in the package definition. <fhmgufs>I know that there are problems with non-free software. But I can't use it without and don't want to throw it away now. <fhmgufs>You must know, that I used to use MS Windows two years ago, switched to Linux than and now I'm using GNU since about one year. <fhmgufs>So I'm new to the free software movement. <fhmgufs>And by the way: How can I find out, how much packages depend on a package? <lfam>fhmgufs: `guix refresh -l` should tell you. If the package is only in your local source tree (for example, if you are working on a new package or are changing an existing package), then `./pre-inst-env guix refresh -l` <lfam>It won't list *every* package in the dependency graph. To be honest I don't understand exactly what it tells you. Perhaps it lists the "leaves" of the package in question <lfam>But my understanding is that it reuses the code from `guix graph` which I think is pretty cool :) <mordocai>Reminds me of one time we printed out the dependency graph of a giant application at work that used debian packages for everything. It took up a wall. <lfam>I (try to remember to) notify upstream when I package their software for Guix, and I include the output of `guix graph`. I think it's scared more than one of them ;) <lfam>It's also uncovered a bug in one of my packages! <mark_weaver>fhmgufs: it depends whether you want to know the build dependencies or the run-time dependencies. <janneke>can I refer to a packages' out/store location in the (native-search-paths) section? <mark_weaver>fhmgufs: "guix size" can show you the runtime dependencies <lfam>janneke: I think something was wrong with the encoding of my patch. It works now with no other changes. Very strange! Is it okay for me to push that patch series (fixing the errant tclxml bit)? <mark_weaver>janneke: native-search-paths specify relative locations within a store directory or profile. I'm not sure how the store location would be useful for generating those. <lfam>I can also send it to the list again and you can test it one more time. <lfam>janneke: Sure, thanks for your work and your patience :) <janneke>mark_weaver: to set FOO_HOME=/gnu/store....package-0.0 <janneke>ACTION has a package that wants to be told where it lives <mark_weaver>if you install it in your profile, then that directory will be merged into the resulting profile, so I guess that maybe this is what you need: <mark_weaver>however, it might be better to instead use a wrapper around the program that sets that variable. <lfam>This is somewhat off-topic, but the merging of all those store directories into the resulting profile makes me think of The Aleph by Borges. <lfam>"In Borges' story, the Aleph is a point in space that contains all other points. Anyone who gazes into it can see everything in the universe from every angle simultaneously, without distortion, overlapping or confusion." <pizzaiolo>has the 'deco' command already been renamed to 'herd'? <janneke>mark_weaver: if I do that '("."), it becomes a huge path <lfam>pizzaiolo: Yes, of course for you it depends on whether or not you've updated your system since the change <mark_weaver>janneke: if it's just a small number of programs that need to be told their HOME location, then maybe use 'wrap-program' within a custom phase, to create wrapper shell scripts for each of those programs that runs the real program with FOO_HOME set appropriately <janneke>mark_weaver: it seems this does work, thanks! <mark_weaver>janneke: anyway, search paths aren't the right tool for variables like FOO_HOME that can only take a single path.