<ytc>there are a lot of *popular* packages outdated. this makes me upset.
<cossidini>no need to get upset. it's just a wm and probably easy to update
<dstolfa>ytc: it's a bit of a best effort right now, people who use certain packages update them as they go. usually updating is as simple as just changing the version and the hash, so it's a 2 line change
<dstolfa>but that's usually true for almost any distribution
<cossidini>it's probably a great first attempt at updating a package if you're new to it. like dstolfa said, it's probably just two lines
<lfam>So, you'd also need to change that part. Hopefully a 3 line change overall
<ytc>how can i add my custom packages to /etc/config.scm?
<dstolfa>ytc: you can just import a module (gnu packages) and then use the (package ...) EDSL to define a package. alternatively, you could generate a lot of it with `guix import`, but if you're looking to just test a change to an existing package locally you should be able to just `guix edit` it
<podiki[m]>....speaking of updates, can anyone here look at the libdrm and mesa patches for core-updates? i think they are good to go (been building and using both a lot)
<oriansj>sneek: later tell civodul that live-bootstrap have guile and gcc 4.7.4 (both C and C++ backends) all properly bootstrapped (no pregenerated files unlike the current root) and it might make for a stunning release.
<drakonis>oughta convince them of the advantages of that
<apteryx> note that the .deb is a 'guix pack' format; it's current application is to produce bundles rather than individual packages
<apteryx>and dpkg doesn't allow multiple packages to share the same files, so currently only one such deb pack can be installed with dpkg (dpkg would error on a conflict upon trying to install a 2nd one).
<tissevert>jlicht: you're welcome ! (I'm going to test it too)
<boeg>So i want my hole system to be declarative. At the moment its all using a config.scm, but it's a bit of a toll having to keep it updated and reconfigure a whole new system when I just want to have some simple non crucial piece of software installed. So I have looked at guix home-manager which seems to be able to let me separate my base system from my "home setup". Is that what ya'll are using? Not using anything other than a config.scm?
<boeg>alright, ill probably wait until its merged so refactoring of docs and so on are done and then give it a try
<the_tubular>1.3.0 released not so long ago, so it might take a while for next release though
<mange>Hey #guix! I'm trying to write an origin that will download a single file and mark it executable, so I can refer to it directly in a Gexp in an invoke call. I've tried using a snippet, but it seems to make tar explode in the builder. Is there some way for me to do this?
<mange>I guess I could use computed-file to copy the output of my other origin and make the copy executable, but it feels a bit messy. I assume that would also leave two copies in the store.
<tissevert>the_tubular: I thought people were already talking about the freeze for next release ? Right after the release of 1.3.0, the first estimate date for 1.4.0 was in september, so it shouldn't take that long
<vagrantc>and where do you get your DNS from, anyways?
<dstolfa>lfam: a CA, essentially :), but there's no real good way around that without trusting your CAs. i guess some people just get a bit weary when they see a "download script and run as root" kind of wording
<clemens3>the script downloads and installes a gpg key for further use..
<clemens3>i would prefer i install the key myself and check, be it here on irc or whatever, find someone who knows someone..
<lfam>I think the real reason that <https://guix.gnu.org/install.sh> is not signed out of band with PGP is that it's a dynamic link to the file in our Git repo, which eases deployment of changes and fixes
<dstolfa>to be fair, you can do that by following the manual installation on that same page (and the root of trust is the same, an https website, though one could argue that you could try to independently verify that the website you get is the same across multiple devices and so on more easily)
<clemens3>or who checks https certificates.. I have done so maybe three times in my life
<lfam>The whole point is that you don't have to check
<lfam>The manual verification was shown to be a failure
<dstolfa>in the UK too... i've reported countless numbers already and months later i still get messages/calls from them
<dstolfa>"Your parcel is being held, click this very suspicious link"
<lfam>See, the US postal service doesn't even have your number and couldn't figure out how to call you even if you wanted them to. A win for chaos
<dstolfa>possibly the most sophisticated, and i would even say targeted scam email i got was from a subdomain of barclays bank informing me that i can customize my new debit card as my old one is expiring. it went to a legitimate barclays login page, everything looked 100% legitimate except for the part where my debit card was cancelled by the bank months ago and i got my new one in the mail
<dstolfa>lfam: that's possible, but the barclays subdomain, expiry month, official login page with no redirects and barclays confirming it wasn't them without any other follow-up is just extremely suspicious. to this day i don't know what happened and it's been like 2-3 years now
<lfam>Another tricky thing with regarding Guix security are the sharp edges around the use of Nix's content-addressed cache as a fallback for source code
<lfam>If I still understand correctly, when sources are only available there, Guix doesn't / can't also verify the filename, since Nix doesn't store it
<lfam>So, it's possible to accidentally specify the wrong hash in a package definition and have Guix still accept it. Normally that doesn't work because filenames (especially versions) are part of the specification
<lfam>It's just less transparent than Guix usually is
<dstolfa>or some kind of MITM and the user not verifying things, but at that point there are better & easier targets to compromise i guess
<lfam>It's like, if you update the OpenSSL package, but use the hash of an older OpenSSL source tarball, Guix will (probably) fetch the old source code from tarballs.nixos.org
<lfam>And try to build it. And it will probably build successfully because it's still OpenSSL and it doesn't change very quickly
<dstolfa>well, i guess it's easy to have a litmus test for this
<lfam>The only warning during the build would be that downloading the sources from openssl.org would fail, before falling back to tarballs.nixos.org. And later, if you checked the version with like `openssl_client --version`
<dstolfa>something like a "version" package, which just prints its own version
<lfam>I haven't noticed how the Software Heritage cache works in this sort of case
<lfam>So, you'd have a package that Guix says is e.g. "OpenSSL 3" but it would actually be "OpenSSL 1"
<lfam>I worry about the potential for mistakes around this fallback cache
<dstolfa>yeah, ideally one would just store the necessary things to detect inconsistencies somewhere and somehow
<dstolfa>but i haven't looked at the code so don't know the implications of that
<dstolfa>lfam: maybe one workaround is just a development practice that says "use `./pre-inst-env guix build --really-check-everything-without-cache`" or something
<dstolfa>without needing to address the technical problem itself
<lfam>The tricky thing is that this cache is only used when there is no other source available
<dstolfa>lfam: ah, maybe just not checking it as a part of the development process is enough? e.g. saying `guix build --no-cache` would just fail if it reached the point where it needs to check the cache
<drakonis>nix's whole fetching process is kind of bizarre because you have to zero out the hash otherwise it will fetch an existing build and then tell you the actual hash it wants
<drakonis>there's two edge cases here, if your hash refers to an existing source, it'll try to fetch that, if the hash does not match an existing source but the specified version exists, it'll yield the correct hash and fail
<lfam>drakonis: That sounds like "you have to zero out the hash otherwise it will fetch an existing build and then tell you the actual hash it wants" <-- That sounds like Guix
<lfam>Assuming by "build" you mean "source derivation"