<lfam>I'm playing around with `guix system vm`. What is the significance of the bootloader field in this case? I copied the bare-bones example that sets the grub-coniguration device to /dev/sdX, but that seems like it is meant to be changed by users. However, the system seems to work fine <davexunit>lfam: bootloader is ignored for VMs and containers <davexunit>I'd like to change things so that the bootloader field need not be specified at all in these cases. <lfam>Oh, it will fail if I remove it? <lfam>Ha, interesting. It seems very wrong to require a dummy argument <davexunit>the thing is that you can use a bare metal config for a VM and it should "just work" <lfam>That is ideal. I want to get a config in order in advance of receiving the actual bare metal that I want to run it on <davexunit>I'd like there to be something in place so that configs that are only for VMs or containers need not specify the bootloader field at all <lfam>Hm, it's quite annoying to provide entropy seed each time I boot the VM. <davexunit>VMs created by 'guix system vm' are ephemeral <lfam>Yes, I also know about vm-image, which would solve this issue. I guess I should use that and then reconfigure on each change to the configuration <sprang>is there something like patch-source-shebangs that will let me iterate every file and replace "/usr/bin/env" with (which "env")? <sprang>I tried "(substitute* (find-files "." ) (("/usr/bin/env") (which "env")))" but I think I need something more nuanced (complained about encoding error) <lfam>There are examples of that in gphoto2 and sbcl. Possibly more, I stopped looking. <sprang>right, but those explicitly list the files, right? <sprang>there are quite a few and the filenames don't fit a nice regular expression <lfam>Did you look at the definition of (find-files) in guix/build/utils.scm? I think it takes, first, a directory argument, and second, a pattern. So, how about (find-files "." ".*")? <lfam>My Scheme is still pretty weak so I'm just looking at what's already there and adapting it. <lfam>Also, there is font-gnu-freefont-ttf, which does (find-files "." "") <sprang>unfortunately, some of the files I need to process have no extension... I basically need to check every ascii file <lfam>".*" is a regex that matches anything <lfam>It's not matching files with extensions <sprang>(find-files ".") already matches everything, I believe <sprang>substitute* barfs on files that aren't ASCII, from what I can tell <lfam>That's what you want, right? <sprang>anyway, I think I can hack something that will do what I want, just wondered if there was a handy existing procedure <lfam>Come back when the Scheme experts are around ;) <lfam>I think the example in sbcl should work if you change the predicate of (find-files "." "\\\\.(lisp|sh)$") to "" or ".*" <sprang>nope, it still errors when it processes a file that's not ascii <lfam>Can you make the loop not die on error? This is really at the limit of my knowledge. Maybe try in #guile <mark_weaver>sprang: wrap the 'substitute*' call with (with-fluids ((%default-port-encoding #f)) ...) <mark_weaver>although it would be better to avoid 'env' altogether in most cases, ***francis7 is now known as francis
***francis is now known as francis7
***francis7 is now known as fchmmr
***fchmmr is now known as francis7
<sprang>mark_weaver: thanks, I will try that out <alezost>wingo: re: "guile, guix mode and incorrect indentation": I suppose you mean 'guix-devel-mode'. It is enabled in any 'scheme-mode' buffer by default. And it can be disabled by (setq guix-devel-activate-mode nil). But what "incorrect indentation" do you mean? It should be fixed <sneek>Welcome back alezost, you have 1 message. <sneek>alezost, rekado says: Thanks, I'll try that. <alezost>arr, this variable should be renamed to `guix-devel-mode-activate' <civodul>i was trying to forcefully reload emacs/*.el <civodul>but that hangs while loading guix-hydra-builds.el <wingo>i guess i don't understand what guix has to do with developing non-guix things in guile <civodul>alezost: from dired i selected \\.el$ and pressed L :-) <wingo>i understand that on guix this is a minority position :) <alezost>wingo: but how can you distinguish guix and non-guix things when you are editing a guile file (it could be "my-packages.scm" which is outside a guix tree). I actually think that guix-devel-mode shouldn't be enabled by default. But what incorrect indentation did you have? <wingo>i was having incorrect indentation when working on guile's compiler -- match on structures was indenting differently than before (aligning with first field instead of vtable) <wingo>and for some reason the indentations specified by the .dir-locals.el in guile weren't working <wingo>there is a rule that ($kargs names syms body) will indent the body, if the body is on another like, with the $; that wasn't working. i hadn't changed anything but noticed the guix mode active and so blamed that <wingo>it could be that i am not blaming the right culprit :) <wingo>more generally i wouldn't assume that a .scm file is a guix file, but that's just me :) <wingo>i understand this isn't an actionable bug report, sorry about that :) <wingo>i think i would try to identify a guix file via file-local vars though. either dir-locals from the guix sources, or from a specific file-local vars block if working on an out-of-tree guix package <alezost>civodul: I think this is intended only for loading .el files that has not been loaded yet. AFAIU you can't just reload emacs packages like this (for example, 'defvar'-s do not change their values). But if you want to do it, there is 'unload-feature'. <alezost>Anyway, I've just tried your recipe and no hangs for me. <alezost>wingo: Happy New Year! I believe you blame a wrong culprit, but it's just a blame from my side :-) also .scm file is not a guix file and it is opened in `scheme-mode'. `guix-devel-mode' is just a minor mode that can be disabled. <wingo>alezost: cool :) i'll see about disabling the minor mode and see if that fixes it, next time i'm working with that code. cheers :) <alezost>civodul: Oh, did you mean you reload emacs/*.el files after the code has changed (after merging hydra stuff)? Then it can't work!, because the code has changed completely. There is a chance it could work after running `unload-feature' on some guix-... features, but it's better to restart Emacs (or run another emacs instance) <alezost>wingo: I've just opened .../guile/module/language/cps/constructors.scm file and checked that '$kargs' is indented properly for me (as described in .dir-locals.el). 'guix-devel-mode' was enabled (it really shouldn't change any non-guix editing behaviour). <alezost>wingo: Perhaps you changed `enable-local-variables' or another variable that prevent loading .dir-locals <wingo>you could be right alezost, my apologies for coming with a half-baked bug and pointing fingers <wingo>i'll take a look when i'm back on that computer <alezost>wingo: no problem, please tell when you find out what's the problem, I'm interested :-) <cajg>Hi, I've not used GuixSD, just thinking of giving it a go... on a Lenovo Thinkpag t410 <cajg>or does that just relate to QEMU? <rekado>I'm having a problem with git on a system where user accounts are not in /etc/passwd but checked for by sss. <rekado>/etc/nsswitch.conf says that names should be looked up in "files" first, then "sss". <rekado>git then first tries to look up the username in /etc/passwd and fails. <rekado>then tries to open /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/libnss_sss.so.2 <rekado>then fails to look up the name via sss. <rekado>then git aborts with: fatal: unable to look up current user in the passwd file: no such user <rekado>the system is a foreign distro set up to use SSS. <rekado>I probably won't be able to just use the host system's libnss_sss because of the glibc ABI mismatch. <wingo>that's crappy, all the solutions i can think of involve rebuilding glibc :/ <wingo>is adding sss support to guix's standard glibc an onerous thing? if not, that's probably the answer <wingo>if it's just a protocol with no dependencies, anyway <rekado>yeah, I also think that glibc must be rebuilt. <rekado>I can try to preload the system's libnss_sss, but I'm quite sure that this isn't going to work because of differing glibc versions. <rekado>or maybe this is independent from glibc. I don't think glibc provides libnss_sss; that's done by SSSD. <rekado>only the search paths have to be rewired, so that our glibc can find libnss_sss. <wingo>i suppose another environment variable could be the thing, to tell glibc to search for nss resolvers in the profile <roelj>How can I get the location of the tarball of one of the inputs of my package? <roelj>Then I'm probably approaching this wrong.. Sorry for the disturbance.. <efraim>roelj: do you mean where does it go when it gets downloaded? <roelj>efraim: No, I have a package in native-inputs that should be unpacked in a specific subdirectory of the main package I'm describing. <roelj>efraim: But it seems to work with (assoc-ref inputs "<specific-name-here>") <rekado>roelj: (assoc-ref inputs "something") gets you the store path for the input item labelled "something". <roelj>rekado: Sorry for the things I could've fixed before sending in the LDC patch.. I just sent a new (better) one. <civodul>alezost: i think on GuixSD what happens is that, by default, we automatically get guix.el from /run/current-system/, right? <civodul>and in this case, it predates the Hydra-related rewrite <mark_weaver>roelj: if you need the _source_ of another package, then you need to include that source as an input, not the package itself. <civodul>rekado: there's no problem *if* nscd is running, because nscd will load libnss_sss on behalf of applications <mark_weaver>e.g. something like (native-inputs `(("foo-source" ,(package-source foo)))) <mark_weaver>if you only include 'foo' as an input, then foo's source code will simply not be available from the chroot where the build happens. <mark_weaver>(unless the output(s) of 'foo' retains a reference to its source code, which is rarely the case) <roelj>mark_weaver: I confused "package" with "source tarball". <alezost>civodul: do you mean it happens for you on a freshly started Emacs? <mark_weaver>roelj: out of curiosity, which package are you working on? and what other source tarball is needed by it? <roelj>mark_weaver: I just submitted a new patch for LDC. That's what I was working on. The project has a Makefile that looks for other sources at specific locations in its own project root.. <roelj>phobos and druntime in this case. <roelj>I really wished people would use "complicated" build systems to properly separate pieces of a project.. :) <mark_weaver>roelj: okay, so as I wrote above, use ,(package-source foo) instead of ,foo in the inputs <rekado>civodul: ah, I remember that there was a similar issue before that was solved by running nscd. <roelj>mark_weaver: Thanks. That makes sense :) <mark_weaver>and then (assoc-ref inputs "foo-source") will be an absolute pathname to the source, which is typically either a tarball or a directory. if the 'source' field of package foo refers to a tarball, then (assoc-ref inputs "foo-source") will be a tarball. if the 'source' field refers to a git checkout or similar, then it will be a directory <alezost>civodul: I actually use "export EMACSLOADPATH=" as I like to set up everything on my own <civodul>alezost: sounds reasonable, i'll do that to <civodul>is it equivalent to "unset EMACSLOADPATH"? ***fitzsim`` is now known as fitzsim
<alezost>civodul: hm, maybe, I don't know about "unset" actually <civodul>rekado: can you merge the gtk branch? <civodul>hopefully most of what was built is still valid <rekado>civodul: okay, I'll do that in a couple of hours. <NiAsterisk>(offtopic) is fosdem usualy on time with schedules? I could take the bus and arrive at 11AM if all goes well (and sleep longer) or take the train and arrive on time for the opening talk (but start the journey at 4.30 AM). <civodul>NiAsterisk: it has to be on time because there are so many parallel tracks <NiAsterisk>okay. thanks civodul . then I'll book the train this week. <rekado>efraim: about your patch series for python-pytest-cov and others: I saw that you pushed a bunch of them, but not all. Are you taking care of the rest or is there still something I should do about them? <efraim>rekado: I pushed the first 3 three so I could update python-requests, the others I'm holding off on until I can get git-annex-remote-hubic actually working <efraim>I don't really have a way to test them, other than to see if git-annex-remote-hubic works or not, and although they build and pass their tests, I didn't want to push them yet <cehteh>apropos installer .. anyone worked on some method to describe the installation procedure in guix, a level below the system config, how disks shall be formatted etc <taylan>cehteh: is (info "(guix) System Installation") insufficient? <cehteh>i am thinking about reproducible deployment/installation .. later maybe even have a proper installer which as first step generates this system description <rekado>efraim: okay. As the patches have already been reviewed feel free to push them when you're ready. <cehteh>later one only needs to run the installation which partitions/formats the disks and installs guix <taylan>there was some talk of a 'guix deploy' command a while back IIRC <rekado>when I'm asked for a password I get this: <rekado>Password for 'rwurmus': Can't locate Term/ReadKey.pm in @INC ... <civodul>could be svn itself that's broken, no? <rekado>could be that my clone of Guix is too old. <rekado>I don't have perl-term-readkey on that server yet <rekado>subversion-1.8.15/tools/dist/backport.pl uses Term::ReadKey, so perl-term-readkey should be an input to the "subversion" package. <lfam>efraim: I found your comment about how your country only sets its timezones a few months in advance very interesting! Can you point me to any resources on that subject? It sounds fascinating! <efraim>the wikipedia article ends before ~18 months ago when no one's credit cards worked for an entire day because the week before we extended an extra week and all the times on the POS systems were off <efraim>my favorite line is "In the past, the unpredictability of IDT in Israel became frustrating enough that Microsoft Windows stopped trying to track changes and just made Israeli time be Greenwich Mean Time plus two hours (GMT+2) (and disabled the daylight saving option)." <lfam>Wow, that is just wild! I like Microsoft's approach ;) <lfam>Is that a typo? "the week before we extended an extra week" <efraim>there was some political compromise that was reached a week before we were supposed to go off daylight savings, to extend it for an extra week <efraim>so a 25 hour fast would end at 6 pm instead of 7 pm <efraim>or the other way around, it was too absurd <lfam>Ah, an extra week of daylight savings. Not an extra week in the year. <lfam>The strange little joys of small countries, I suppose <lfam>I kind of like it when things get messed up like that. It brings everyone out of their routine. Not sure if anyone else agrees with me, though <efraim>it was funny watching everyone scrounging for cash <lfam>I grew in Miami aka hurricane-ville. Getting cash is a major priority in the days before the storm. We had a big storm in Philadelphia a few years ago and my roommates didn't understand why I had a bunch of cash. <lfam>But no electricity = no ATM or card processing <efraim>python-minimal failed its tests on core-updates <lfam>I'm working on our w3m (ncurses web browser) package. Any ideas how I can which ssl/tls protocols the browser supports in practice? The ssllabs.com test page doesn't work. <lfam>And I don't really trust the ./configure flags to do their job based on the last feature I tried to configure <efraim>python-minimal depends on zlib, openssl, perl and pkg-config <efraim>when I was working on connman, I found that including packages didn't help unless I also added the configure flag to add it also <lfam>BTW I'm really glad are working on connman. I prefer it. <m_kim>Hello, when I try to run "guix build --check irssi" on GuixSD I get error "guix build: error: build failed: unsupported build mode". Guix daemon used from /gnu/store/62ndhk4ky9vbshvrdd8d7cci51s0ay6y-guix-0.9.0.5c36edc/bin/guix-daemon. Do you know how to make "guix build --check" workable? <m_kim>I hour ago made "guix pull ; guix system reconfigure /etc/my-config.scm ; reboot" <lfam>jubalh: Hey, got a question? <jubalh>not yet, just stumbled about guix and reading up on it :) <jubalh>I have been using Funtoo Linux before and am currently running openSUSE <jubalh>lets see if i can get my head around guix <jonsger>what is the status of the foundrasing campaign, so the amount of money? <civodul>jonsger: i've asked the FSF for the exact figure, but we're somewhere above $3000 <civodul>we should announce it on the web site <civodul>yeah now is probably a bit too early <davexunit>they told me that I have 90 minutes + 15 minutes for Q&A <davexunit>I don't think I can possibly present for 90 minutes <davexunit>mogorman: oh cool you're in the boston area? <mogorman>ill be sure to heckle you to stretch the time <davexunit>I need to start preparing my slides and demos <civodul>it's at MIT even, world-class prestige ;-) <davexunit>I've never been to a BLU meetup. I hope it's a good time. <mogorman>i was looking for stuff to do in the area <mogorman>havent found anything to replace my old hackerspace yet <mogorman>i went to a libreplanet meetup at the fsf the other day <mogorman>disappointed i missed call for papers for that conference <mogorman>guix/nix style packaging needs to be spread <jubalh>am i correct that the main difference to nixos is that guix only contains free software + uses scheme instaed of nixoss own thing? <mogorman>to me the main difference is guix is lisp nix is a dsl <mogorman>i dont have any nonfree software on my nix boxes <mogorman>but aside from that i dont think it promotes nonfree, it just allows it, like how debian does <davexunit>we argue that using Guile rather than a custom domain-specific language creates an environment that is easier to build, hack, and extend. <davexunit>you'll find Guile code in various layers of GuixSD: the initial RAM disk, the init system, and of course, the package manager. <davexunit>the package recipes are Guile, the build scripts are Guile, the client code is Guile. <mogorman>id say that is a big difference between nixos and guixsd then <jubalh>very interesting to learn about this difference <mogorman>im beginnning to love systemd, or at least how i can make services with it and nix <rekado>civodul: sorry, I didn't find the time to merge the gtk branch into master :-/ <rekado>is there still time if I did this tomorrow morning? <davexunit>mogorman: you may find GuixSD's service API interesting as well <rekado>civodul: okay, will do it tomorrow morning. <civodul>rekado: before pushing and after merging, check whether enough substitutes are available (like gimp, inkscape maybe) <mogorman>davexunit, there certainly seems to be a whole lot of overlap in ideology <davexunit>mogorman: there's a good deal of overlap, but a lot of significant differences too. <mogorman>im sure, otherwise why work on one over the other ^_^ <civodul>rekado: i see mark_weaver just merged it actually :-) <civodul>(we say "to sleep on one's two ears" in French, i wonder what the English equivalent phrase would be) <civodul>looks like i didn't put my name in Penta or something <lfam>civodul: That's an interesting idiom <lfam>davexunit: I'd be interested to see a presentation on the service api <Steap>yours is right after mine, might miss it <Steap>btw, I have to write slides for this :D <Steap>but I'll also do a presentation of tox <Steap>and iirc this must be longer than what I did at PyCon <Steap>Then we'll run Guix Ltd. and make a shitload of money.