IRC channel logs
back to list of logs
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@2001:470:69fc:105::2:34a4
***havershayer[m] was kicked by litharge (You are banned from this channel (by nckx))
***litharge sets mode: -o litharge
<acrow>So, if we fail to reproduce ci knows to stop further builds? until the package is updated? <nckx>No. It will rebuild each change to the package (or a transitive input). Reproducibility is not tracked. <vagrantc>we can dream of a better future, though! :) *nckx describes the world as it is, dreams cost extra. *vagrantc rummages around in the couch cushions for spare change <nckx>Nope. Just more guix lint. <nckx>vagrantc: Is there a theme to R irreproducibility? <acrow>Ah, so all these mismatched checksums could be caused by changes in transitive inputs? Although when there are many builds and none match; well, the source emerges as the culprit because the inputs are relatively stable. <vagrantc>acrow: no, those are for a given guix commit. <nckx>acrow: Not quite, I think, although I'm not sure what you mean. <vagrantc>does guix publish publish the public key used to sign it's packages, or do you have to publish that independently? <nckx>vagrantc: It does by default, yes. <nckx>There's a ‘welcome page’ at / and the key is at /signing-key.pub by default. <cbaines>I think it's meant to be available at /signing-key.pub but maybe NGinx on ci.guix.gnu.org doesn't reverse proxy requests at that path <oriansj>unmatched-paren: I'll add that to my todo list, probably somewhere after solving the Linux bootstrap problem and finishing the GHC bootstrap in C <vagrantc>i wonder if i could hide that somehow ... <acrow>Ok, I should've thought about it more. the derivation checksum is calculated from the checksums of the derivations of the inputs (so when an input changes, we have an entirely new deriviation to build from) .. So, we are building derivations and there should be no variation in the output checksums. I was thinking about how changes in the inputs affect things. IIUC, derivations are reproducible, no? <acrow>well, at least, they ought be. <oriansj>and unfortunately some absolutely are not <nckx>acrow: The derivations ‘themselves’? Yes, indeed. <vagrantc>i want to set up a build garden (not big enough to be called a farm) and keep it's signing keys a secret ... <vagrantc>nckx: if you can successfully download packages from it that match the signing keys of ci or bordeaux, you know it's at least marginally reproducible :) <nckx>(FYI nginx does an acceptable job of proxying guix publish, if you have nowhere to start.) <cbaines>vagrantc, narinfos actually include the full signing key in the signature, so you'd want to not sign nars entirely <vagrantc>is that ... an option with guix publish? <nckx>Is secrecy really required for that? <vagrantc>i've never managed to get guix publish to start without a key <nckx>I don't think so, hence my scepticism. <oriansj>vagrantc: you need only hide the secret key, not the public key <vagrantc>nckx: you could just not trust that key, true <vagrantc>oriansj: in this case, i'd like to hide both, but that seems maybe a non-options <oriansj>well, if you are willing to setup a proxy then it is a non-issue <vagrantc>heh. or publish the private key as proof you should not trust the signing key :) <oriansj>as you can just make the proxy return a rick-roll video anytime someone tries o get your private key <nckx>oriansj: The key is in the .narinfos. <vagrantc>but if it's embedded in the narinfo, as cbaines said, it's not so easy <nckx>You can rewrite those to contain a roll, but that needs a pretty heavy level of proxy. <nckx>Better off modifying guix publish directly to skip the middleman (and overhead). <cbaines>I think unsigned narinfos are a thing, but I'm not sure what the support in guix publish for that is like <vagrantc>i'm not much for dinner rolls, all for aikido rolls ... <nckx>They are at the very least lightly tested. :) <vagrantc>yeah, ideally it'd just be unsigned narinfos ... that solves a lot of this needless complexity <cbaines>maybe have a look at tweaking guix publish if it doesn't support not signing things <oriansj>vagrantc: well the signing keys aren't for secrecy so much as enabling trust <vagrantc>oriansj: right, but this should be an untrustable server <vagrantc>and if they're unsigned, that would be perfect <oriansj>I wonder what passing: --private-key=/dev/null would do <vagrantc>presuming that doesn't botch the hash matching the signed ones from ci and bordeaux <vagrantc>cbaines: and huge thanks for the data.guix.gnu.org reproducibility stuff ... it really streamlined a lot of work i had been meaning to get around to <cbaines>vagrantc, good good, I'm glad it's being used, and being useful :) <vagrantc>took me a while to get around to it, but it would have taken at least an order of magnitude longer to do the stuff i did earlier this month <vagrantc>and i thought those issues were fixed upstream <nckx>apis_and_ipas: Nice nick. <vagrantc>nckx: most of them kind of look like ordering issues ... but i'm not sure <nckx>vagrantc: That server is either very slow or there's something wrong with my connection, but thanks! <nckx>So it's generally in embedded data, not in bytecode? <vagrantc>some look vaguely like they could be PIDs *vagrantc goes on wild hunches sometimes <nckx>I don't think so, but your guess is absolutely as good as mine. <nckx>The .rdb differences are what puzzle me though. <vagrantc>likewise, which is why i marked them "unidentified issue in .rdb" :) *yewscion is back (gone for 01:00.57)
***aeka` is now known as aeka
<unmatched-paren>how can i check whether a package is in my profile or used as an input by one of the packages in my profile? <lilyp>you could also grep for elogind in the manifest <lilyp>I'm pretty sure guix gc also has some options available to check what's referenced <unmatched-paren>and it all leads up to inkscape. which is necessary to convert the SVG grub background to png. <foobarxyz>Hi, is there a convention as where to output or name the platform dependent shared libraries, e.g. lib/amd64 for amd64 perhaps? <lilyp>why the hate on elogind tho? <maximed>foobarxyz: We usually just put them all in 'lib', without architecture-specific subdirectories. <maximed>vagrantc: I would keep the narinfos signed (even if the authorised key is not authorised), to allow later for things like multisig systems -- e.g., client only accepts a substitute if signed by two different authorised keys or such <maximed>* even if the authorised key -> even if the key <foobarxyz>maximed I see, thanks. I suppose this is because there will be only one guix instance running at the time as far as archs are concerned, so we can't have both x86 and amd64 packages at the same time <maximed>foobarxyz: You can have both i686 (as we name it in Guix) and x86_64 in the same ‘Guix instance’. <maximed>Depending on what you're doing, exactly. <maximed>foobarxyz: FWIW, if you have built a package 'glibc' twice, once for x86_64 and once for aarch64, <maximed>then glibc-for-aarch64 is put in /gnu/store/HASH1-glibc-VERSION/lib and glibc-for-x86_64 in /gnU/store/HASH2-glibc-VERSION/lib <maximed>so not necessarily a problem (although installing two variants in the same profile probably won't work). <maximed>Also, Guix supports cross-compilation arbitrary packages to any (supported) architecture: "guix build hello --target=aarch64-linux-gnu", which implies that you can have multiple architecture variants of the same thing on your system. <foobarxyz>maximed: thanks, I'll have a look at the --target option and see how it behaves exactly
***tox is now known as vier-littleme
<sammm>simple question I hope, how can I have a shepard service (using requirement array) depend on something like the docker-service-type (which isn't a shepard service AFAICT) <sammm>in short, my shepard services which were running docker run failed to start as docker wasn't yet running. <arjan>has anyone encountered this at an initial home reconfigure? "guix home: error: mkdir: Permission denied" <sneek>Welcome back arjan, you have 1 message! <arjan>the home configuration is minimal and does build successfully, but cannot be applied apparently <stampirl>Hi #guix. I have a problem with my Guix SD. Docker stopped working and is spitting out this error ` Unknown runtime specified` <mbakke>emacs tramp is asking for username for a host defined in ~/.ssh/config, what gives? It manages to resolve the alias and ProxyJump from the same file, but not User <lilyp>mbakke: Is this new or did you just now try tramp and notice it for the first time? <mbakke>lilyp: I've used Tramp occasionally for years, but not since I reinstalled my machine due to fatal btrfs corruption a few weeks back, perhaps I missed something? Also migrated to Guix Home, so many moving parts :P <lilyp>there's also Emacs 27→28, which already broke some tramp thing
***wielaard is now known as mjw
***toluene4 is now known as toluene
<maximed>I noticed some discussion about distributions and package manages & rust <maximed>Something that I think has been neglected in these kind of discussions: <maximed>(Except for the bundling and pre-compiled things that occassionally happen), I actually like things like crates.io and pypi and contentdb <maximed>I think we should make a distinction between distributions and ‘package registries’. <maximed>Package registries like pypi and crates.io (with their metadata like whatever pypi has and Cargo.toml for Rust) are useful for distributions for being a clear source on <maximed>- what, exactly, does 'foobar' refer to? <maximed>- where can I find the source code? (tarball, version control repo, whatever) <maximed>- and what are the dependencies (+ guess on minimum version and maximum version, though often those are inaccurate and can be widened by the distribution <unmatched-paren>perhaps there should be a common protocol for describing packages from package registries? <maximed>unmatched-paren: Yep (on the centralisation) <maximed>though FWIW, in case of ContentDB (for minetest mods), we currently download the actual mods from upstream's git repository <maximed>so if ContentDB goes down, not a huge problem <unmatched-paren>I don't see the point of storing source code on crates.io. If you're worried about archiving and longevity, there's swh... <maximed>OTOH, aren't the individual distributions Debian, Guix, ... examples of centralisation? <maximed>unmatched-paren: Then SWH becomes a single point of failure though ... <maximed>Though FWIW, I'd like to not only include crates.io, <maximed>So we have upstream's website, crates.io, SWH, web.archive.org, ... <maximed>(also: ci.guix.gnu.org saves some tarballs)
***toluene1 is now known as toluene
<maximed>(I'd like to add "gnunet://fs/..." URIs to package origins someday, but the gnunet-scheme code isn't there yet ...) <maximed>bjc,lilyp: Antioxidation levels are at 97% (if you don't me having changed how packages are submitted to ci.guix.gnu.org, before that, it was more like 65% or something) <maximed>With caveats: no tests yet, optimisation settings are just -O0 for now, ...
***mark_ is now known as mjw
<apteryx>what should the reply from openssh look like when attempting to login as root? <apteryx>we have 'permit-root-login’ (default: ‘#f’)', but I get to the passhprase or public key challenge anyway <apteryx>OK, it does work though. Probably SSH accepts the connection and then it is rejected by PAM.
***pi2 is now known as johnjaye
<apteryx>I tried adding a static-networking-service for hydra-guix-129, and ended up in such a situation <apteryx>oh, %base-services already defines a static-networking-service-type for the loopback *civodul goes through a terrible week with little hack time <ternary>What's the best way to test a shepherd service that I am making in a custom channel without having to commit/push/guix pull? <apteryx>is someone extending static-networking-type? i'm trying but failing so far <apteryx>if I remove the static-netorking-service-type modification, the config builds fine <maximed>ternary: You can use channels without channels. More concretely: <maximed>You could remove the channel from your list of channels, and instead tell guix with each command where to look for extra stuff: "guix build -L /location/of/git/checkout/of/channel channel-package" <maximed>"sudo guix system reconfigure -L /location/... configuration.scm" <maximed>(Removing the channel is not necessary per se, e.g. I haven't needed to do it for antioxidant, but seems rather fragile to have it both in your list of channels and in -L w.r.t. which module ‘wins’ etc.) <ternary>Oh I didn't realize a reconfigure worked with a local path. That removes some of the pain for sure <ternary>I assume I can't test the service without doing a reconfigure though <maximed>ternary: You can, to some degree, with VMs! <maximed>"guix system -L$THE_DIRECTORY vm the-configuration-of-the-vm.scm" <maximed>Unless I got the wrong subcommand, it will output the location of a shell script that you can run to automatically start a VM with the given system configuration. <maximed>Warning: if it does anything graphical, chances are that the default memory limit is too low, so you might need to add a -m3G or such somewheere. <ternary>Oh that's a cool idea. I'll have to give that a shot <maximed>Also there's some kind of number of cpus option you can add, which makes things much faster. <maximed>Don't recall the exact way to add -m and the cpu option though ... <ternary>I mostly just want to test if it starts and gets configured properly, so I shouldn't need any of that <maximed>You can, of course, just do "guix system -L... reconfigure" on your system, outside a VM (simple!) <maximed>though sounds rather daring to do things directly on an important ‘live’ system to me <maximed>nevermind, you probably referred to -m and cpus <apteryx>rekado_: I understand why you did it manually, I've been going at this for at least an hour with no solution in sight <civodul>it's not an extension, but you could also extend <civodul>as in: (simple-service 'ext static-netorking-service-type (list (static-networking ...))) <civodul>(untested but with 80% confidence :-)) <apteryx>does extending remove the requirement to set provision to some value? <apteryx>I think it either should accept no provisioning or document that it's needed but be careful to not provide 'networking multiple times because that's the default, or something, as seems to have bitten here: https://issues.guix.gnu.org/52511 <apteryx>civodul: few, it works. thanks for saving my sanity <apteryx>the problem was indeed (provision '()) <maximed>I'm thinking of setting the optimisation flags of rustc appropriately. <maximed>there's a 'thin' and 'fat' version of LTO <maximed>I'm thinking of using the default thin-local LTO, and setting opt-level=3 (the cargo default)? <rekado_>apteryx: have you successfully done it manually yet? <apteryx>first manually, and now via the config <apteryx>it works, but something's missing to reach iDRAC yet <maximed>Alternatively, I could go for space savings with opt-level=s/z <rekado_>guess I should retract my request for help from the networking team <maximed>Will go for Cargo's default opt-level=3 for now (which enables LTO by default IIUC) <apteryx>yep, you can try SSH'ing to it, it will only allow SSH keys now <apteryx>rekado_: I've pushed the config now, will send an email <maximed>What level of debugging information would be desired? <maximed>The default is no debug info at all. <maximed>I would go for at least line tables?