IRC channel logs


back to list of logs

<paroneayea>postgres reall just works nicley with like, 0 config steps?
<paroneayea>ACTION amazed!
<paroneayea>hey how do we deal with things that have git submodules in guix?
<paroneayea>can we......?
<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>see guix/git-download.scm and guix/build/git.scm
<paroneayea>mark_weaver: whee! thank you :D
<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.
<kqb>mark_weaver: np
<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.
<rekado>(today was one of these times)
<kqb>kqb: "a function is a machine that produces the same output for the same
<kqb> input" is what I meant
<rekado>slide 6:
<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>it's okay for wip-* branches
<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'
<paroneayea>mark_weaver: aha, got it. thanks!
<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>for guix compatibility
<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: ouch
<Jookia>paroneayea: the 'proper' way to do this is using something that replaces shebangs
<paroneayea>Jookia: huh?
<Jookia>like autotools or whatever
<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 in my user's profile? Oh well, it's welcome there anyway...)
<mark_weaver>paroneayea: it comes with guile
<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>hydra just finished building it for x86_64
<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
<paroneayea>ACTION updates
<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>the comments on this are concerning/sad:
<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.
<rekado>this is a very sad development
<Jookia>Popularity is all that matters?
<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.
<rekado>this has gone much too far.
<mordocai>Welcome to cargo cult computing
<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.
<nckx>lfam: indeed.
<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?
<Jookia>mordocai: I mean contributing'
<mordocai>Jookia: Oh okay. yeah that's fine
<rekado>yeah, contributing is a pain.
<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
<rekado>yay for email-based workflows
<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
<Jookia>GNU Mailman 3
<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>lemme check
<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
<rekado>I followed the link from where it says "You can also download the archives in mbox format."
<mordocai>mesa has so many options...
<mordocai>I just want opengl 3.3 support dangit!
<jlicht>rekado: that was quite obvious. Shame on me for never reading the top part of pages properly when I'm hunting for content
<mordocai>jlicht: i'm not the only one!
<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.
<rekado>just needs some glue, methinks
<mordocai>GNUS master race
<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!
<mordocai>Nice Jookia!
<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
<nckx>lfam: perfect!
<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
<Jookia>ah, i see
<nckx>lfam: -devel, you say? I can't seem to find anything. But then my oldest message is from 4 hours ago.
<lfam>You're right. I didn't notice it was in a bug report.
<nckx>lfam: thanks! Hah. That's easier to copy by hand than copy to my Guix machine.
<mordocai>Anyone here know enough about mesa to tell me what flags I need to put in my personal config to get opengl 3.3 shaders support? I'm using radeonsi(which requires a non-free blob) so this is unofficial personal work. I'm also on top of debian testing. Current WIP is here:
<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
<Jookia>Looks like ... lots of things!
<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
<Jookia>codemac: Are you on ARM?
<codemac>Jookia: no I'm on an intel celeron 3205 (broadwell x86_64)
<Jookia>Hmm, I'm out of ideas then
<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+
<mordocai>Actually opengl 4.1
<lfam>codemac: Could you build from an older git checkout and work from there?
<Jookia>mordocai: Fantastic (kind of)
<mordocai>Jookia: Yeah, i'll get a more freedom respecting card in the future but I want to do some game dev now :)
<davexunit>oh, nonfree drivers. bummer.
<davexunit>I recind my yay.
<mordocai>davexunit: Well the drivers are free but a non-free blob
<mordocai>So yeah, less/no yay depending on your views
<davexunit>yeah, boo nonfree firmware
<dmarinoj>Who here runs libreboot?
<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)"
<mark_weaver>sounds like your load path is bad
<Jookia>It only happens when I run 'vm-image', it works in the usual 'init'
<mark_weaver>oh, I see
<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
<mark_weaver>what are you trying to do?
<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>I think we'll have to avoid that, actually
<mark_weaver>the build side code in general doesn't deal with high-level objects like package objects, and the grub-configuration includes those.
<Jookia>Hmm, I see.
<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.
<Jookia>Not a record?
<Jookia>(Haskeller here)
<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>Okay, sorry. :)
<mark_weaver>no worries, and no need to apologize.
<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.
<Jookia>I see
<mark_weaver>and partly it's that right now I'm trying to focus on making Guile's macro expander deterministic.
<Jookia>Oh wow, that sounds awesome
<yvm>There is no DRI in GuixSD? :<
<lfam>yvm: What's DRI?
<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?
<Jookia>Well, others have DRI I assume
<xd1le>yvm: because guixsd doesn't have any nonfree software
<Jookia>What card is it?
<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
<Jookia>qemu supports DRI?
<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.
<lfam>based *on* linux
<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?
<yvm>Doh. Never mind.
<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:" for a really long time.
<phant0mas>rekado: I had the same issue yesterday
<phant0mas>I thought it was a local network problem
<rekado>yeah, me too.
<janneke>I use this hack to boot into Debian:
<efraim>I had it yesterday
<janneke>how do you specify other OSs?
<fhmgufs>What is needed if an application says 'Couldn't recognize the image format of file: asdasdaqwertz.svg'?
<fhmgufs>imagemagick - no, *svg* file.
<efraim>inkscape then?
<efraim>I don't do a lot with image files
<df__>imagemagick supports svg
<fhmgufs>inkskape? Maybe - I'll try.
<fhmgufs>Really? interesting
<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?
<iyzsong>what's the application?
<janneke>possibly install libsvg first and configure/pkg-config might pick it up
<davexunit>this is basically what I want for Guix
<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.
<davexunit>that was it.
<NiAsterisk>let me find the cpu details.. I want to be sure
<NiAsterisk>it's a t9400 core 2 duo cpu, that's all i know right now
<NiAsterisk>and VME is for virtualiztation iirc
<NiAsterisk>that's all i can spot in the flags