<nckx>And there's probably some obvious deal-breaker I missed, but it was fun to write horrible regexp code.
<somenickname>euouae: No, I just wanted to know if someone can approve that it works or requires additional stuff. Guess I need to enable debug and do some testing for something that should work out of the box but not for me...
<minima>i think it's fine in my context but that's a great point
<minima>also, just to avoid the xy problem scenario, the broader context and objective would be to create an image that i can SSH into knowing what the SSH fingerprint will be
<minima>in other words, i thought of dictating what the SSH key is (or what the keys are) so that when i connect to the image (or machine should i say) i know what SSH fingerprint to expect
<minima>the only way that came to mind was to create the keys separately and manually with ssh-keygen and have them added to /etc/ssh
<parnikkapore>Hi Guix! I'm running a Cuirass instance to build and serve substitutes for my own channel. I'd like to pin the packages in the latest evaluations so that they won't be deleted by guix gc, even after >30 days. What's the best way to do this?
<parnikkapore_xm>my current idea is to gather the derivations in those specifications and pass them to `guix build --root`, but I want to ask first, in case there's an easier way
<parnikkapore_xm>ACTION needs to check if cuirass registers profiles for the evaluations; if it does, then only changing the cleanup script is needed
<adanska>ok, so i've run into the first roadblock. auto-cpufreq depends on the `power` module on pypi which essentially provides a cross-platform method of obtaining power info on your system. my issue is precisely that: it's cross platform, and depends on an objectivec interop library. since guix is really exclusively linux (not including hurd), is it ok if i patch out everything except linux support? how do you guys typically deal with these
<efraim>janneke: thanks, I think my brain is fried
<janneke>it's the linker's repsonsibility to choose the extension
<efraim>sounds good to me. I've already removed the options for building the static library
<radio>When using define-configuration to serialize something, no predicate to test if something is a valid configuration is produced?
<radio>I'm writting a simple configuration for fish abbreviations, since the current alist structure is limitating about which kind of abbreviations you can declare within guix (actually you can just put the flags in the key string of each association, but it's ugly)
<mirai>lechner: “we” may shit on Windows as much as we want but IMO we shouldn't completely dismiss it. There are things that Windows has an advantage and it would be profitable to learn from those parts
<zamfofex>mirai: I feel like regarding proprietary software, although it’s wrong for being proprietary, it’s not like it doesn’t have any value or anything that can be taken from it. Ideally it wouldn’t be proprietary, but that doesn’t mean everything that it does is wrong and should be disregarded. (Though, of course, I wouldn’t endorse it as a whole either in any way.)
<zamfofex>As in, of course being ethical is more important than most other aspects, but that doesn’t mean other aspects (like technical merit, aesthetics, etc.) don’t exist, and so certain things can be learned from some proprietary software.
<janneke>civodul: reconfiguring to test smart hurdloading!
<lechner>Hi, I switched to Guix in April of last year, and just want to say thank you to all contributors. After losing hope in another Linux distro, Guix provided a great technical perspective of what could be. Plus, I like Scheme and no longer use shell scripts or Perl. I think we are the forefront of free software development
<janneke>we've been already doing that, but (short summary) it was still pretty hard to setup, there were bugs, there were problems running childhurds on the buildfarm
<nckx>civodul: I had my goofy fun, which was the point, but '@set GUIX-RELEASE 1.4.0' is probably the simplest way forward.
<ulfvonbelow>civodul: random catch scrolling through the patches, s/offlading/offloading/
<stocastico>hello guixers! does anyone have any exeperience with guix on the pinebook pro? I'm having problems booting the system, not really sure why :( . I rightly get from towboot to uboot but after uboot loads the kernel the screen goes black forever. here is both the configs i tried http://paste.debian.net/1292822/ and here the flashing script http://paste.debian.net/1292811/ i run from an armbian installed on the emmc
<ulfvonbelow>the lowest-level representation of a "build unit" we have. Usually it refers to a regular file plain text store item of a certain format with a filename ending in ".drv", though it can also refer to the in-memory representation in guile, a <derivation> object
<lechner>okay, and how are derivations used in Guix, please? What is their purpose?
<ulfvonbelow>a derivation includes the complete list of input derivations and the output names from each of those that are used, a list of its own output names, a builder, sources (non-derivation inputs), environment variables (some of which are treated specially and interpreted by the daemon), the host system name, and other stuff
<ulfvonbelow>some derivations (like ones that download source code) are "fixed-output", and are consequently allowed access to the network because all non-reproducibility can be detected due to the included content hash
<ulfvonbelow>basically, a derivation is a file that sits in the store, and it's also a node in the directed acyclic graph of derivations that describes how to produce certain outputs
<nckx>Their high-level ‘purpose’ is to serve as the object you ask the build daemon to build, because it has absolutely no concept of ‘packages’, ‘git checkouts’, ‘file-like objects’, and any of that silly abstract nonsense.
<nckx>That's why Guix can use the Nix daemon despite the two projects not having *that* much in common TBH.
<zamfofex>nckx: I wonder how sensible it would would be to just have a Guixy approach that doesn’t use the Nix daemon (or a fork thereof). Something that just directly build Guix objects like packages and operating system records in an environment without needing to go through derivations.
<ulfvonbelow>if you're okay with losing the ability to allow multiple users to share the same store, that would work.
<mwette>guix is a functional package manager; the derivations are definitions for the functions that generate outputs (e.g., executable binary software packages) given the inputs (e.g., software source packages, dependencies, env variable)
<zamfofex>Well, I imagine still having a daemon, though one with Guix‐specific concerns in mind only.
<nckx>That addresses the ‘Guile’ part. I don't see any advantages to ‘raising’ the daemon protocol to higher-level objects, only disadvantages, so you'll have to explain that part further.
<nckx>Having a ‘parse this Aterm file, with these inputs, and build whatever comes out the other side’ is a pretty solid base IMO.
<zamfofex>nckx: I don’t know much to say either way, it just felt it would be a reasonable thing. I don’t see these “disadvantages”, though it’s probably because I’m not as familiar with it in general.
<nckx>I think we've broken the package ABI a good number of times in the past, for example. It's an *extremely* high level of abstraction for what we need and currently have, which is a dumb thing-builder that is very, very good at building things. Dumbly.
<nckx>I don't have a well-articulated response ready though. I've never answered this question before.
<zamfofex>nckx: It is fine. I feel like the daemon being usable across multiple versions of Guix is a very significant advantage! And being able to change the package record definition (and for other things like operating system records too) is also important.
<lechner>ACTION has never heard of GRUB being too new
<lechner>Rovanion / i believe that error relates to grub-install having a different notion of devices from GRUB during boot (perhaps caused by an older BIOS). i would explore the available devices with 'c' if needed and then correct the boot menu in-memory with 'e'. It's probably obvious
<lechner>if you are in the grub rescue shell, you have to find the GRUB files first and then run 'insmod normal'
<nckx>I respectfully disagree with your sincerely held belief.
<nckx>I cannot say for sure since the nearest Windows machine is several miles away, but I expect this Balufus tool to be doing what it considers copying the boot sector to the start of the drive. I don't know, but I don't think that counts as a hole. I understand GRUB quite well.
<degauss>Hi all! I'm following Ludo's blog article "From development environments to continuous integration", "guix build -f guix.scm" works fine, but as soon as I move "guix.scm" into ".guix/modules", change the 1st arg of "local-file" to "../.." and symlink back to "guix.scm", the recursive copy done by "local-file" becomes totally empty. Has anyone come across the same issue or have any hints? Thanks a lot! :)
<nckx>It's weird, even using the psql CLI directly I can't seem to operate on specifications. It just hangs.
<apteryx>nckx: great, thanks for giving me a good reason to stick with dvorak
<nckx>It's one person's experience but I'm not impressed with heatmaps and seemingly-logical stories about finger movement anymore, and nobody does actual studies of long-term use AFAIK.
<ulfvonbelow>I'm using workman right now, so far it's been... whelming. It seems that, like with battery life, race-to-idle tends to overwhelm all efficiency concerns, and it's hard to compete with experience since youth in qwerty for speed.
<nckx>Meanwhile, I killed my entire desktop with ‘pkill -USR1 dd’ because I am very smart.
<ulfvonbelow>I get the sense that I should've skipped alternative keyboard layouts and gone straight to stenography systems
<ulfvonbelow>but I guess this way I'll be the first to know when our gdm finally has a working layout switcher or on screen keyboard
<Rovanion>I started learning stenography and got a fair bit, but then realised that each language has its own system.
<ulfvonbelow>yeah, the reliance on phonetic mapping makes it inherently inconsistent in that way
<ulfvonbelow>it's probably still worth it if you're all-in on english
<nckx>Rovanion: Any other USB drives around? (Or, hell, CDs?)
<nckx>lechner: I cannot find a workable hypothesis where the BIOS finds the USB device to load GRUB, only to then lose track of it completely.
<nckx>Older machines that can't boot from USB are a dime a dozen, but this…
<Rovanion>nckx: Just tried to boot a Ubuntu image and got the same issue so yeah, I'll try some other USB stick.
<Rovanion>nckx: Funnily enough this computer actually has a DVD drive.
<degauss>I think I found the bug in the "Level 2: The repository as a channel" section: the "vcs-predicate?" should be updated to have "(git-predicate (dirname (dirname (current-source-directory))))". I think I'll ping Ludo about this, as the post may need fixing.
<nckx>degauss: Now I've actually tried it out, and take it back: I don't think there's a bug.
<nckx>The blog post suggests using a .guix/modules subdirectory of the Guile git checkout, so why would (GIT-PREDICATE? ".guix/modules") return false?
<degauss>nckx, I'm actually practicing on another package to learn, and it failed regardless of whether "guix.scm" and ".guix/modules/my-package.scm" were include in a git commit or not. While "guix.scm" existed as a file (not symlink) in the project's root (with "(local-file "." ...)"), "guix build -f guix.scm" worked even if "guix.scm" didn't yet belong in a commit. Anyway, no reason to worry about the Guile package, I didn't use it for my tests. ;)
<nckx>If I read your original message correctly, that's not what you expected.
<degauss>nckx, I don't know, maybe "(local-file "../.." ...)" still passes "./README.md" as ".../.guix/modules/README.md" to "vcs-file?" instead of ".../.guix/modules/../../README.md" or ".../README.md"? I'm not familiar enough with Guix to check that myself, however the "(dirname (dirname (current-source-directory)))" seems to work.
<nckx>Yeah, maybe. I'll have to try the full example (which is a bit too much right now).
<degauss>nckx, think I figured it out: "(git-predicate "X")" creates a predicate which is #t for files *under X*. In your example, "((git-predicate ".") "/home/nckx/guile/README" (lstat "/home/nckx/guile/README"))" should be #f. So my "(dn (dn (c-s-d))" works because it creates a predicate for the root of the source directory.
<degauss>(In other words, "X" should be the root of the Git checkout, the dir having the ".git" subdir.)
<degauss>(That is, for "." being ".../.git/modules".)
<degauss>I'll send a patch to Ludo. Thanks nckx for your help!
<nckx>degauss: You're welcome, but that's not what GIT-PREDICATE means (otherwise there would be little use for a dedicated procedure). It should work *anywhere* inside a git repository, and in my example it does.
<nckx>So yes, there is a bug, but I think you might be blaming an ‘incorrect’ usage that is actually a bug elsewhere.
<nckx>But regardless what it turns out to be: thanks for spotting & reporting it :)
<nckx>…I guess not, re: Wayland. That's on other distroes.
<mirai>what's the right way to describe the following “snippet”: (define (foo a) #~(lambda (x) …))
<mirai>I've got "Return a G-Exp containing a procedure that returns a XML Catalog for Docbook-XSL in SXML representation."
<ulfvonbelow>that describes what calling the procedure defined by that snippet does, not the snippet itself, which would add a "define a procedure foo of one argument which when called with that argument will..." to the front of the description
<mirai>oh right, let me refine the question then: does the above work as a docstring for `foo' ?
<ulfvonbelow>aside from the fact that it doesn't mention what foo's sole argument is supposed to be or how it's used