<Kozo>Hey Guix, I am attempting to try out Guix publish but I'm not understanding the import of the public key. 1) I've created the keys on my guix publish server. 2) I've sent the .pub to another machine 3) I've started guix publish on my server using (sudo guix publish --user=<blah>
<nckx>katco: If there's no order that doesn't break in between, combine them. DependencIES sounds ominous though.
<Kozo>I don't understand what prefix is supposed to be here: guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub
<katco>and i think all 3 must be updated atomically, so i'll do one commit. thanks nckx !
<nckx>Kozo: It means ‘prefix to the guix git checkout’ otherwise.
<nckx>Well, prefix of. Whatever. It's a strange word choice but I don't know the context.
<Kozo>nckx: It is from 4.3.2 of the manual and is talking about ci.guix.gnu.org
<nckx>katco: Do these packages follow the same versioning scheme by any chance? It's fine to lock them in step with (version (package-version the-other-package)) if so.
<katco>nckx: one actually comes from the same repo, and i've moved it to inherit from the parent. the other is dependent on this, and i don't think it follows the same versioning scheme.
<Kozo>Now that the key is authorized, what do I do now? The manual talks about running guix-daemon to the new publish server but do I run that on the server or a client?
<nckx>katco: That's already perfect then. If this is something you think is going to happen every time consider adding a comment, so the next (less diligent) person doesn't break things, but that's up to you.
<nckx>Kozo: You add the URL of the substitute server to the daemon configuration and restart the daemon.
<marusich>it's easy for me to become paranoid that i made a mistake
<marusich>at least we know it's certain that gcc compiles differently for different people
<nckx>lle-bout: I expect the problems to be limited to things like Guile load paths and other assumptions about file names and locations. It would be great if you'd end up with a cuirass.service (or whatever) that could be added to the repo.
<Kozo>nckx: Thank you. I am looking at how I do that on the client. When I run the command out of the manual, it just seems to hang and not do anything
<marusich>but yes it seems like a machine specific issue
<marusich>but maybe it's reproducible...on the same machine? :/
<lle-bout>nckx, I use Gentoo for it right now so that would be openrc heh
<lle-bout>marusich, maybe ask the other people for their binary? So you can binary diff?
<marusich>yeah, i asked them in an email to provide that
<lle-bout>nckx, I'll make a change while you don't look then sshh
<nckx>Don't thank me yet. Problem is I don't use %base-services and you probably do, so you'll probably have to use modify-services.
<cbaines>So, it turns out the Guix Data Service doesn't handle narinfo files where the file size isn't provided for URLs. I'll fix that tomorrow, and then I'll be able to load the data from guix.tobias.gr
<marusich>nice! how'd you generate the kernel config? If I were doing it, I guess I would have probably just tried bumbling around manually with the source from "guix build -S linux-libre" and run "make menuconfig" etc. to generate something
<lle-bout>marusich, I took the one from Adelie Linux because it supports ppc64
<marusich>oh ok. that's probably a fine place to begin
<marusich>it is possible you might need some VM-related things to make it work, but we'll see. The existing configs in guix probably have some things enabled like virtio or 9p fs
<marusich>they might just be nice to have rather than necessary
<lle-bout>marusich, strange thing is that I do have vsx on power9 - that user was on power5
<nckx>bdju: Thanks for telling me about upower (I was aware of it but thought it was some GNOME GUI thing). ‘Neither are what I need’: really? upower -e → upower -i <…>/BAT0 gives some useful stats here. More than acpi. Thanks 🙂
<bdju>nckx: I'm still struggling to figure out upower. I've got that service in my config now, made sure it was enabled/started with herd commands. do upower -e and upower -i both need a path after them? and how do I find that path?
<bdju>http://ix.io/2o8M seems like it wants to start a service, but I thought it was started already. perhaps now the issues is that "upower" is in my user profile, even though the service is still in my config.scm
<nckx>Kozo: You might want to set --max-jobs too. --cores only passes -jN to make. --max-jobs will build different packages in parallel, and including source downloads. If you have a 6-core CPU, you can probably afford to set --max-jobs=2 and --cores=6 (or 3 and 3, or… unfortunately there's no way to make Guix always load all cores efficiently, and there's much to be improved.)
<nckx>bdju: No, that's fine. Packages don't have to be in your system profile just to talk to a system service.
<nckx>bdju: If you're using %desktop-services (dbus-service) is already included. Not in %base-services. Similarly, big desktops like GNOME do the equivalent of dbus-launch for you, it's only needed for ‘minimal’ wms.
<terpri_>tor browser should be evaluated for packaging, either as-is or as a friendly fork (which must have minimal changes to prevent fingerprinting)
<terpri_>it has a security mode that blocks js, that could be locked on (or just set as default?) instead of using librejs, and i think discourages addons so may not have all the same freeness issues as regular firefox
<terpri_>(librejs should not be used with tor, again due to making fingerprinting trivial)
<bdju>nckx: okay, so weird situation. dbus was running, upower wasn't. enabled and started upower. ran the command again. same error. herd status shows upower back to disabled and stopped!
<bdju>nckx: oh, update. enabling it works, starting to actually makes it become disabled and stopped again
<terpri_>there's also micah lee's self-updating tor browser launcher, but for guix just packaging tor browser bundle directly is probably easier
<terpri_>if my proposal sounds reasonable, i'll write up a bug report when i have more time
<apteryx>nckx: shepherd expects the service to do its own logging handling (e.g., use syslog), otherwise expects the service author to add a #:log-file argument, IIUC.
<nckx>terpri_: Not that the situation stateside isn't fucked up. Not that you don't have other things to do. But you were arguing so hard above against/for… something, it wasn't clear why. Nobody thinks adding LibreJS to Tor Browser is a good idea (???). Nobody needs to ‘evaluate’ it. It just needs to be packaged, not requested, unfortunately.
<nckx>I wish there was a crack team of packagers just twiddling their thumbs in #guix waiting for packaging idea men, but sadly everyone here is probably not doing as great as they'd hoped a year ago.
<terpri_>nckx, ok, maybe i'll just package it and work out any freedom issues later
<nckx>Unless it's fundamentally unfree (I wouldn't know why) that's a good approach.
<terpri_>i still have some custom vanilla-firefox package definitions for spidermonkey hacking, so it might be pretty easy if most of the dependencies (rust etc.) are up to date
<terpri_>let's see if i can push this boulder up the hill :)
<nckx>terpri_: I can't speak for everyone but I don't know why anyone would opposed a source-built, FSDG-compliant Tor Browser. And as you said, the FSDG part is probably mostly taken care of by upstream. I've heard upstream(?) tell off people who use anything but the precompiled binaries, and that's too extreme for me (and Guix), but if any distribution can make a reproducible TB it's us. Go for it. We have Chromium FFS. The bar is not sky-high…
<terpri_>nckx, yeah i think you're right. thanks for the words of encouragement :)
<nckx>(Or low, depending on your opinion of Chromium 😛)
<nckx>terpri_: I don't think I'll be of much help during this particular endeavour but I'll try to answer any non-where-is-foo-in-the-FF-source-tree questions you might have.
<nckx>apteryx: So it just throws away stdout/err if that's not set?
<apteryx>the logging has been added ad-hoc to the make-forkexec-constructor thing that is used as a start procedure, it's not really integrated in the design of Shepherd
<apteryx>the good news is that Shepherd is about only 10 modules of Scheme code, so it's refreshingly light to hack on it.
<lle-bout>marusich, grub-efi failed to build, that should be normal since ppc doesnt have efi
<terpri_>nckx, sounds good, i'll ping you if i have any general questions
<marusich>lle-bout, shouldn't need an efi for vm anyway
<marusich>I'm still collecting info but at this point I know that final-gcc from (gnu packages commencement) is not reproducible, which could possibly be the cause of our non-reproducible bootstrap binaries (or maybe not)
<marusich>It's actually spelled gcc-final, not final-gcc.
<apteryx>marusich: I've run diffoscope on my gcc result vs yours, and it's too large to be useful
<marusich>Hmmm, if a derivation has two outputs, like "out" and "lib", and if you GC "out" but "lib" remains live (so you can't delete it), will the "lib" output be overwritten if you rebuild the "out" output?
<marusich>i will be able to take a peek at gcc-final's output and hopefully see why it is different, and i am hoping that after cross-building the gcc-static again, I will be able to say "yes, the derivations after gcc-final leading up to cross-built gcc-static are in fact different now, which is suspicious"
<bricewge>lle-bout: Yes, it's a great opportunity to spent even more time contributing to FLOSS
<marusich>s/the derivations/the output of the derivations/
<bricewge>lle-bout: I see the powerpc port is coming up nicely, great work!
<lle-bout>bricewge, I'm so glad you've got that!! GNU Guix is an **awesome** project to contribue to!!
<lle-bout>marusich, heh so much time lost compiling .. crazy
<lle-bout>that's where the dev lag is, not actual work but waiting for compilers
<lle-bout>it would be nice to have a trusted network of machines as a build farm that any contributor could access and contribute machines to after minimum screening of the actual trustworthiness of those machines, in almost all cases a contributor of GNU Guix does so in good faith :P
<marusich>I'd be lying if I said I understood it all clearly, but I think I get the idea, and I'm learning more as I read more.
<marusich>I was a little confused when you talked about how you "provide a primitive to introduce parallelism" in build-accumulator and map/accumulate-builds, since it looks to me like they are not running code in parallel themselves.
<marusich>But I think the idea was that, by quickly collecting the "unresolved" builds, you can delay execution of the more time-consuming stuff until you can batch them all together.
<marusich>Is that basically right? The reason I was confused at first was because it looks to me like the code does not involve concurrency.
<marusich>(The guix-daemon of course may do things in parallel, though, if we ask it to do a bunch of builds in a batch.)
<xelxebar>So I have a channel pointing at a personal repo of mine for random packages I've thrown together. One of these requires an upstream patch which guix build finds with the right -L flag, but installing from the channel complains about a missing patch.
<xelxebar>Do I need to do something to create the effect of gnu/local.mk?
<nckx>mothacehe: Thanks! Now running & logging a cross-build-everything script so I can do more than just grep for obviously broken packages (but there are plenty of those, too, if anyone wants to join in).
<mothacehe>nckx: Great! Some (most) of them are broken because the build-system does not support cross-compilation in Guix (waf, scons, glib ...).
<mbakke>should we open tracking bugs for cross-compilation support in the various build systems? I suppose meson-build-system and python-build-system are the most pressing, perhaps also ruby-build-system (for texlive).
<mothacehe>mbakke: Yes we could do that, starting by meson if you have a WIP patch that you can share :)
<nckx>cbaines: I realised something. While g.t.gr itself doesn't pull anything from other substitute servers, I offload most of my builds to it. When a client that does use ci.guix offloads something [with a dependency] that hasn't been built on g.t.gr, it will be pushed, and this will artificially increase reproducibility numbers. I thought the window in which this could happen was limited, but suspicious results like this one are more common that I expected:
<butterypancake>so alsa-firmware is something that wouldn't get accepted right? From what I can tell, it's mostly gpl, but it's made up of a bunch of .asm files which are there to load the hex files which I can only assume where pulled from devices and no-one actually has the source code.
<nckx>I've never needed firmware for audio but I'm happy with whatever Intel HDA junk's built into the machine.
<butterypancake>yep, basically I want a 3.5inch input jack to my computer. But that jack also needs a builtin amp because electric guitars and bass's send a tiny signal. So you generall end up with a little USB box that needs some firmware junk
<butterypancake>I could in theory just make one (and finally use my engineering knowledge :P) but that'd be a lot of work designing it. Maybe I could do a kickstarter but manufacturing is hard and it's so niche :/
<butterypancake>ok, if I reverse engineered the alsa firmware for my device, I can package that right? That's probably easier than building one myself....
<nckx>butterypancake: If you licence it freely and swear that it was a clean-room job, sure.
<nckx>I hope you didn't look at the blob contents. Don't.
<butterypancake>clean-room job? Like it can't be inspired by the blob? What? How on earth can you reverse engineer without the blob?
<butterypancake>Now I can't even hide my identity and do it because there are chat logs. Also I wouldn't be able to put that work on my resume.
<nckx>I didn't mean to scare you, just advise you not to poke around looking at copyrighted until you decide what to do.
<nixfreak52>Thinking about putting guix on a Desktop system that I want to treat as a NAS , does it make sense to use guix for a NAS ?
<butterypancake>I was reading about Hutchins the other day. I'm already freaked out. I guess that story had a happy ending, but most don't
<nckx>And the FBI doesn't pay a visit because you're reverse engineering, they drop by because people saw you carry Things With Wires and using Devices In Ways Not Authorised By The Vendor (*why* would anyone ever do that???).
<apteryx>nixfreak52: It supports mdadm RAID or btrfs RAID (with some caveats), and has an ieasy way to setup an NFS server, so I guess yes? :-)
<butterypancake>nixfreak52: make sure you hardware has opensource drivers #1. Then 100% yes. guix is designed to be stable
<butterypancake>does guix supports ZFS? If not, maybe freebsd would be an option
<nckx>butterypancake: I think it does, but not as root.
<nixfreak52>Yeah I forgot about that since I have to use nongnu for wireless drivers on my laptop which has been solid
<nckx>nixfreak52: It's solid on its own, and I haven't had to reformat (compare that to not-so-long-ago btrfs, wow) at all, but I do still get the occasional scary backtrace/hang during ‘stressful’ things like hibernation.
<nckx>nixfreak52: Also, GRUB can't read it, so I have a hacky ‘copy the kernel closure to /boot/gnu’ script that runs on reconfigure.
<vagrantc>my guile skills (if calling them skills is even appropriate) aren't sufficient to tackle this ... but i wonder if a defconfig + blacklist + whitelist + overrides approach wouldn't be more sustainable
<nckx>nixfreak52: Now that someone other than me is even interested, I'll take a look at my patches and bang them into shape to be upstreamed.
*vagrantc wonders what the missing pieces for guix root on LVM look like
<ryanprior>I have a repo of packages I've contributed to Guix. I'd like to run a script every so often to `guix refresh` all those packages so I can stay on top of submitting patches for new versions. The hacky way I've done that so far is to grep in files for four spaces followed by "(name" which looks like a package definition.
<kamil_>Hi Guix o/ Anyone having nss stuck at the check stage for an indefinite amount of time?
<ryanprior>Is there a Guile API I should be using instead to get a list of packages defined in a given directory?
<civodul>ryanprior: can't you just pass the package names to "guix refresh"?
<zimoun>since a couple of weeks, I just run: "guix weather <package>" and this 504 returns.
<nckx>zimoun: 1) That request should be entirely optional (my servers don't implement the Cuirass API but guix weather works fine), if it causes guix weather to fail for you I think that's a bug 2) it's asking Cuirass for a list (max 1000) of queued jobs 3) judging by how long it takes to return a single entry (=1) it's no wonder that it can't handle 1000 before nginx gives up.
<nckx>zimoun: Is this a fatal error for you? Honestly, you can just ignore it otherwise.
<davidl>mbakke: yes that pull worked fine. Im now pulling 4bdf418
<zimoun>nckx: what other see? I mean if everyone sees 504 with nr=1000 maybe the default value should be changed. I do not know.
*nckx would give large amounts of cash to be lost in the south of France right now.
<nckx>zimoun: I see 504 too (and even if I didn't the code is clear that it's a server-side problem). I just don't know what the output is supposed to be, it never appears when I query my own servers, so I can't have an opinion about its value.
<ryanprior>civodul: that's what my script ultimately does is pass the package names to guix refresh. But how do I get the package names? Right now I grep for them in files, which is hacky and I'd like to be more precise.
*janneke may have found a way to create /hurd/ during activation, i.e., boot without /hurd/
<civodul>cbaines: fun, we should tell the Savannah folks about it
<civodul>janneke: i hadn't thought about that, when is the first time it's needed?
<nckx>efraim: I had my suspicions. That's a valid reason in itself.
<davidl>civodul: that segfault I had I managed to fix. Im pretty sure that something in my ~/.bashrc wasn't liked by the core-updates merge-commit as I was able to guix pull up to the commit before that. Can I assume this segfault is not interesting to bug-guix anymore?
<davidl>i.e. I moved the .bashrc and then I was able to guix pull past the core-updates merge.
<janneke>civodul: well, mothacehe suggested this on my latest "let's maybe almost merge?" mail