IRC channel logs


back to list of logs

<luke-jr>rekado: I'm not willing to run binaries compiled by someone else, on any platform
<civodul>ngz: you're confusing the package name and the module name
<luke-jr>rekado: so even if I were on x86, I would be stuck here
<civodul>the module is called (semver), regardless of whether you're using 'guile3.0-semver' or 'guile-semver'
<civodul>but guile3.0-semver should be renamed to guile-semver
<badair>Using `guix system disk-image something.scm --target=aarch64-linux` cross-compiling from amd64, I get this output on the kernel build: "phase `patch-source-shebangs' succeeded after 2.9 seconds\nstarting phase `configure'\n`ARCH' set to `x86_64'" with eventual failure to find multi_v7_defconfig. Is kernel cross-compilation supported?
*janneke does some very boring sqlite bug bisecting through creating childhurd images
<ngz>civodul: Indeed, I'm just grasping at straws here… I'm not sure why it isn't found, though.
<civodul>ngz: this works:
<civodul>guix environment --ad-hoc guile guile3.0-semver -- guile -c '(use-modules (semver))'
<NieDzejkob>murmr: are you using substitutes? you shouldn't ever need to build the rustc chain
<civodul>janneke: oh, the dump/reload trick didn't yield any result?
<NieDzejkob>badair: perhaps --system would work better? you'd need the qemu-binfmt service, though
<janneke>civodul: dump/reload works
<janneke>i created a patch that does (system* dump) (sytem* reload) "that works"
<janneke>but yeah...
<civodul>badair: --target takes a triplet, such as aarch64-linux-gnu, *not* aarch64-linux
<civodul>it's for cross-compilation
<civodul>janneke: but diffing that on GNU/Linux vs. GNU/Hurd?
<janneke>they're identical
<janneke>only the initially created db does not work on the hurd
<rekado>luke-jr: I didn’t say you have to use any binaries provided by anyone else.
<rekado>but you do need native bootstrap binaries in any case
<janneke>civodul: i think i have it almost cornered
<rekado>however you get there is up to you
<civodul>janneke: woow
<janneke>it's probably during creation, in database.scm
<janneke>either in schema.sql or it's "PRAGMA journal_mode=WAL;"
<janneke>or both
<janneke>so yeah, in "boring bisection" mode
<luke-jr>rekado: I'm asking how to get there
<luke-jr>cp /usr/portage/packages/app-arch/tar-1.32.tbz2 /gnu/store/49xzsbxsvqr5mk794p4w0dmxn7006lq1-tar-1.32.tar.xz <-- didn't do it
<luke-jr>it still thinks I don't have tar
<murmr>NieDzejkob: I had turned it off on a previous configuration, but I was sure substitutions were back on in my current configuration. This is most likely the problem though, thanks for pointing this out. Will give it another try.
<stikonas>luke-jr: that cp command looks suspicious, first of all bz2 is moved to xz
<luke-jr>stikonas: it doesn't look like guix-daemon or guix are even opening it, so :/
<luke-jr>how do I convince them I have tar?
<stikonas>luke-jr: is this a new installation of guix on gentoo?
<stikonas>I used guix ebuild from overlay but I think that one uses guile bootstrap binaries instead of building guile
<nckx>Guix is content-addressed, you can't just copy things into the store like that. The hash won't match, but in this case Guix indeed *won't* see it because it uses a database, and your (invalid) file isn't there. You need to provide different hashes that *match* your tarballs in %bootstrap-executables in gnu/packages/bootstrap.scm.
<nckx>If I could figure it out, anyone can. Good night #guix.
<nckx>(Oh, and use ‘guix download file:///each/of/your/tar/balls’ to properly import things into the store, don't ever use cp.)
<stikonas>^^ that's definitely not true :D I'm sure not every person in the world can replace guix bootstrap tarballs
***jonsger1 is now known as jonsger
<lispmacs[work]>what section of the manual explains how to offload your store builds to another computer?
<luke-jr>stikonas: yes, I'm trying to get it setup at leqast
<luke-jr>using guix download and updating that hash didn't work :/
<stikonas>I'm not really guix expert but what is the error?
<luke-jr>guix build: error: could not find bootstrap binary 'tar' for system 'powerpc64le-linux'
<lispmacs[work]>i was thinking there was a way to authorize a guix daemon on another computer to do my builds, but I'm not sure which section of the manual that is in
<lispmacs[work]>ah, here it is 2.4.2
<stikonas>luke-jr: could it be that gentoo binary package of tar has a different layout?
<stikonas>than what guix expects
<luke-jr>stikonas: guix build: error: could not find bootstrap binary 'tar' for system 'powerpc64le-linux'
<stikonas>I'll try to see if I can reproduce the same error on amd64...
<luke-jr>stikonas: no idea, but it isn't opening the file, so that can't be it
<luke-jr>step forward: it wants the raw binary not the tarball
<luke-jr>substitute: In procedure mkdir: Permission denied
<stikonas>oh, so you did guix download "static tar binary
<luke-jr>to be specific ./pre-inst-env guix download file://`which tar`
<stikonas>ok, thanks
*nckx can't sleep, returns, will probably fall asleep on the keyboard.
<nckx>luke-jr: Yes, the bootstrap binaries are just that. If tar were in a tar file, how would Guix unpack it? It doesn't have tar yet. Etc.
<luke-jr>well, it's part of my OS.. but I get that guix is making it a pain to use it :P
<stikonas>well, I think guix tries not to use things from foreign OS :P
<vagrantc>it's that time of day again, where X marks the spot:
<stikonas>otherwise it's hard to be reproducible
<nckx>You say you won't trust 4 bootstrap binaries obtained from others (laudable), yet want Guix to trust the immense binary that is your OS. Does not compute.
<stikonas>nckx: well, his OS is compiled on his own machine...
<stikonas>although, of course there is always a question of how it was bootstrapped, it definitely involved more binaries than guix uses
<nckx>From a large set of third party binaries, at some point. Much larger than the set Guix uses.
<vagrantc>guix tries to bootstrap from as little as possible, it's a feature!
<stikonas>well, at the moment it's mes mes tools and guile...
<stikonas>oh and those static binaries like tar
<vagrantc>smaller every few months, lately
<stikonas>but those are not used for building
<nckx>If you're bootstrapping from an immense OS (and any modern OS is immense), you're not bootstrapping, that's just ‘building’.
<luke-jr>stikonas: the first steps don't need to be reproducible
<luke-jr>nckx: my OS is already self-compiled securely
<nckx>s/securely/a lot/, not the same thing.
<stikonas>well, self-compiled does not prevent trusting trust attack... Presumably you started from stage3 gentoo tarball
<luke-jr>stikonas: many years ago
<luke-jr>in the meantime, it's gone through many upgrades, a crossdev to a new architecture, etc
<luke-jr>(I used crossdev to build my current system)
<nckx>I know you're talking about DDC & all that but that doesn't change the fact. You built that OS from many hundreds of megabytes of other people's binaries.
<nckx>After all that, it could have been compromised last week.
<nckx>Or last year.
<luke-jr>it would have had to be many years ago
<nckx>Not true, but even that is indeed possible.
<vagrantc>because there were never security vulnerabilities at any point in your system?
<luke-jr>if I was using a supported architecture, I could compare the hashes I end up with to others too
<nckx>And soon you will be. 🙂
<luke-jr>everyone else is using the Guix-provided binaries though, so they can't say the same meaningfully ;)
<stikonas>package hashes are independent of bootstrap binaries, am I right?
<luke-jr>skipping URI with unsupported scheme: #<<uri> scheme: file userinfo: #f host: #f port: #f path: "/usr/portage/distfiles/libunistring/libunistring-0.9.10.tar.xz" query: #f fragment: #f>
<luke-jr>tried to get guix to use my local files automatically :x
<vagrantc>the bootstrap binaries affect the hashes of what they build, which affect the hashes of what they build, etc...
<luke-jr>vagrantc: only to an extent
<nckx>stikonas: No, they are mixed into everything.
<nckx>You change the hash of the bootstrap tar, everything follows.
<vagrantc>in guix the chain of hashes goes all the way back to the bootstrap binaries
*vagrantc learned some of this the hard way with various hacks to try and package guix for Debian
<nckx>Which is why ‘just use this huge-ass clang installation on my box, I trust it’ isn't an option.
<luke-jr>so even if the produced content is identical, you can't get rid of that history? :/
<luke-jr>what if I just build bootstrap-tarballs, and then restart with those?
<vagrantc>you have a new lineage
<luke-jr>so at that point it would match what others use, right?
<nckx>luke-jr: If the bootstrap tarballs are reproducible, and you're saying what I think you're saying… yes? I think?
<nckx>That would be a manual process though.
<stikonas>doesn't sound that difficult though...
<vagrantc>i know for powerpc64(be?) folks were having difficulty getting gcc-bootstrap to build reproducibly
<stikonas>well, hopefully at least arm64 is reproducible
*luke-jr wonders why everyone calls it arm64 when it's unrelated to arm <.<
<nckx>But yes, two utterly identical files will end up in different /gnu/store/<hash> directories if they are built even slightly differently. And that different <hash> will affect everything built with them. Even if (say) /gnu/store/aaaaa-gcc and /gnu/store/bbbbbb-gcc are recursively *identical*.
<vagrantc>long-term goal for guix is to bootstrap from an auditable hex binary...
<vagrantc>which maybe doesn't seem *so* far off...
<luke-jr>nckx: is there a reason to base the hash on more than just the content?
<stikonas>but that would be manual process...
<nckx>The Nix literature calls this the ‘extensional store’ (/gnu/store/<hash of all the inputs, WITHOUT the contents>-foo). The alternative (/gnu/store/<content hash>-foo) would be ‘extensional’ and is, well, a pain. You basically want everything to be reproducible and we're far from that.
<nckx>luke-jr: The hash isn't based on the content at *all*, not even partially, only the inputs.
<stikonas>vagrantc: since guile binary wouldn't be available, you would need to run guix with I guess mes?
<nckx>And not on their content but on their /gnu/store/<hash>! Ad inficetera.
<nckx>(Hm, not quite true when talking about sources, but true for non-bootstrap binaries.)
<vagrantc>stikonas: some little precursors to build up to mes, yes..
<nckx>Sources (‘fixed output derivations’) promise to return content that exactly matches their store hash, so they are effectively ‘inputless’.
<nckx>TL;DR don't ask the tired insomniac to explain things, especially when they volunteer.
<nckx>luke-jr: Did that help at all?
<luke-jr>nckx: I understand it, even if I don't like it :P
<stikonas>luke-jr: well, I guess it's the same with git, hashes depend on previous hashes, not just on content
<pkill9>what does this error mean when running guix copy????? guix copy: error: implementation cannot deal with > 32-bit integers
<nckx>luke-jr: I'd (honestly) love to hear a better suggestion. The catch is it has to work now, in the real (not-yet-reproducible) world. So far all ‘but why don't you just…’ ideas I've heard don't. Don't let that discourage you of course 🙂
<nckx>The Nix/Guix model is damned elegant and robust (double buzzword bingo) (but really: damned robust) but certainly not perfect. As you note, it can easily err on the side of caution and build far too much.
<luke-jr>nckx: accept that the hashes will vary for non-deterministic builds? :P
<nckx>But then how do we hash them?
<luke-jr>content only
<luke-jr>building /gnu/store/46cfd6zgqz8vyd49ljp77lwlqrv0z4as-bash.drv…
<luke-jr>I don't see this hash anywhere; why won't it use the bash I provided
*nckx back. Sorry, the cat was being a shit.
<nckx>luke-jr: The hash is computed, it's not simply /gnu/store/<whatever you wrote in %bootstrap-blah>-bash.
<nckx>luke-jr: It does use it; it can't build bash without bash.
<nckx>luke-jr: What's the point of hashing file contents? I don't get it. The hashes don't mean anything anymore, beyond the tautological ‘we've hashed this file, now we have this file's hash’. You can compare them. ‘This file isn't that file!’ Great. Hours of fun. Babby's first IDS. But we already have those.
*nckx really going to bed now, best of luck. It certainly sounds like Guix is using your bash, since it can't build bash without bash. Bootstrapping! Yay!
<bonz060>Hi. What would you put in the licence field for sth like this:
<pkill9>i needed to authorize the remote machine
<luke-jr>nckx: how is it computed for the bootstrap files?
***jonsger1 is now known as jonsger
<murmr>Hi, is anyone here running Emacs 27 on GuixSD?
<atw>murmr: I am, from the emacs-next package
<murmr>Thank you atw!
<atw>bonz060: looking at that file, I can't say "oh that's definitely FOO license"; it's not an easy call. says it is "distributed under a BSD-style license". I would guess expat?
<luke-jr>looks like my problem is trying to get the right hash in bootstrap-executables
<luke-jr>the comment is wrong :/
<luke-jr>anyone know how to calculate the hash that belongs there?
***dingenskirchen1 is now known as dingenskirchen
<murmr>Hello, is there a way to get GNOME to see packages I've installed using profiles I've created (following the "Basic setup with manifests" guide)?
<firecat>Does anyone run Guix on an Android phone without root?
<firecat>I am trying to use proot to run guix but it will fail due to permission denied.
<firecat>guix build: error: cannot link `/gnu/store/.links/1mj6qhnjizknkf42l0m011xan6079lm2gvjv3dam1m5crbyrkhxd' to `/gnu/store/h1nnwnrbwr7vcllyn1k0p55lkdz0clhh-mirrors': Permission denied
<luke-jr>firecat: I've only been looking at this for a few days, but it seems like you'd need to rebuild Guix to use another store dir
<luke-jr>which will break the substitutes IIRC
<luke-jr>./configure --prefix=/sdcard/guix/ --with-store-dir=/sdcard/guix/gnu/store
<luke-jr>or something like that
<firecat>This looks terrible, I don’t think my Android phone has enough performance to build gcc and glibc, and /sdcard/ does not have enough permissions to store /store.
<firecat>I run these things in termux, and I'm not quite sure that termux's toolchain is enough to build guix.
<firecat>guix pack -RR does not seem to work on armhf-linux and aarch64-linux.
<luke-jr>Guix normally doesn't seem to use the host OS at al
<luke-jr>I suppose you could probably hack up a LD_PRELOAD chroot?
<luke-jr>then Guix would see /whatever/gnu as /gnu
<luke-jr>I suppose Termux's data dir would have enough permissions for it
<jonsger>firecat: did you read
<luke-jr>jonsger: that seems to not help at all? it starts off saying root required
<luke-jr>"Thankfully(?), Android devices are typically not rebooted often." <-- lol
<jonsger>a the device is not root
<luke-jr>requiring root is pretty annoying
<luke-jr>I'm hoping it ends up working without root in practice, cuz I'm not planning to give it root
<firecat>Perhaps should find new ways to fake the file system.
<mroh>how to prevent a service from starting on boot? this doesnt work: (service docker-service-type (docker-configuration (auto-start? #f))
<nckx>bonz060: It's not the expat licence. Free-but-uncommon licences can be specificied with (non-copyleft "file:///" ["optional comment"]).
<rekado_>Guix says that matplotlib has (license license:psfl)
<mroh>hmm, seems ivy update 1ea8160de7 broke a emacs-lispy test
<nckx>luke-jr: No, the comment is not wrong. It's a simple content+exec-bit hash (‘guix hash -r’) as it says, easily verified with e.g. <>.
<luke-jr>nckx: I tried with one of the arm bootstrap bins and couldn't reproduce the hash in the file
<luke-jr>$ ./pre-inst-env guix hash -r /tmp/bash\?id\=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e
<luke-jr>but the hash in the file is 0s6f1s26g4dsrrkl39zblvwpxmbzi6n9mgqf6vxsqz42gik6bgyn
<nckx>No: <>
<nckx>Immediately assuming the comment is wrong instead of you is a dangerous habit, and seldom correct 🙂
<janneke>nckx: well, assuming that what others say is always correct and never questioning anything, that can also be dangerous ;-)
<jonsger>nckx: did you ever tried to install a cups printer with a driver from a ppd file?
<nckx>janneke: True but not my point. And you've been one of my inspirations to become less ranty/blamey (as fun as that can be, it's not productive) by the way 😉 Well, I try to.
<nckx>jonsger: PPDs are effectively upstream. But I've written my own before and got it to work under Guix System.
*nckx → lunch.
<nckx>*effectively deprecated, oops.
<janneke>nckx: oh...sorry for stepping over your point; in fact i much appreciated you making it as it also applies to me.
<raghavgururajan>nckx: Thanks so much for building gst-plugins-bad and its dependencies.
<sneek>Welcome back raghavgururajan, you have 3 messages!
<sneek>raghavgururajan, nckx says: Started. Thank you for giving an exact commit, it removes all uncertainty! (HEAD just means ‘the tip of a branch’, but it doesn't say which branch…)
<sneek>raghavgururajan, nckx says: I would've assumed master and been wrong.
<sneek>raghavgururajan, nckx says: I'm also going to bed. This job is rather big (full jdk bootstrap, again, for reasons I refuse to understand). Don't forget to clear (both) caches before checking for substitutes! Good luck, and good morning.
<raghavgururajan>sneek, later tell nckx: Could you build gtk+-2, gtk+, gtk-doc, gtksourceview and gvfs. REPO: ; BRANCH: temp ; COMMIT: b9b918f4ad. Thanks!
<sneek>Will do.
<jrobst>Hi, I'm having problems getting a NFS client mount to work at boot. I've got a filesystem definition that creates what looks correct in /etc/fstab and it works mounting by hand. But if I have it mount automatically at boot (mount? #t) my guix system doesn't boot. Changing back to (mount? #f) and it boots ok and then I can mount by hand
<jrobst>herd status shows file-system-/users as stopped and herd start file-system-/users (the nfs mount) fails with invalid argument. Any suggestions where I should look ? Thanks
<mroh>jrobst: I like autofs/automount for managing mounts
<jrobst>Yes, I might switch to that later, I'm trying to get some experience with configuring the system and thought this would be a good start
<hwpplayer1>hi people!
<jrobst>mroh ok after some googling it looks like filesystems can't depend on the networking yet so nfs at boot isn't going to work. I see there is an autofs package - how do I setup auto.master and the like in config.scm ? Thanks
<mroh>jrobst: I just made a posting: there I cp the master and config files from a folder named "config/".
<jrobst>mroh - great thanks very much for your help, I will give it a go
<mroh>good luck! ;)
<raghavgururajan>nckx: I will online for next 2-3hrs. Feel free to ping me when you are back.
<raghavgururajan>nckx[m] : Ooo, matrix!
<roptat>hi guix!
<leoprikler>Am I the only one, who gets a 502 on guix pull?
<nckx>raghavgururajan: I'm not available to chat (party time) but have started the jobs.
<sneek>Welcome back nckx, you have 1 message!
<sneek>nckx, raghavgururajan says: Could you build gtk+-2, gtk+, gtk-doc, gtksourceview and gvfs. REPO: ; BRANCH: temp ; COMMIT: b9b918f4ad. Thanks!
<nckx>raghavgururajan: I've corrected it, we'll see.
<raghavgururajan>nckx: Thank you!
*raghavgururajan --> zzZ
<pkill9>what are all the module-import and module-import-compiled derivations?
<raghavgururajan>nckx: Shoot! Was that for gtk+?
<raghavgururajan>*during gtk+?
<nckx>raghavgururajan: It doesn't blok gtk+ (not sure about gtk+@2). It's still building other stuff (--keep-going), currently samba.
<nckx>And gtk+.
<raghavgururajan>nckx: I have recieved substitutes gtk+-2 and gtk-doc. Cool!
<raghavgururajan>nckx: Intresting! I just locally built libical successfully built /gnu/store/gwxp76h6xdm8fgjcxjdkir3455bkdkh0-libical-3.0.8.drv
<raghavgururajan>nckx: Intresting! I just locally built libical successfully built /gnu/store/gwxp76h6xdm8fgjcxjdkir3455bkdkh0-libical-3.0.8.drv
<nckx>Great. And more are being built.
<nckx>Let me check the drv…
<raghavgururajan>nckx: No worries if any of the requested packages fail to build. I mainly needed the dependencies of it.
<nckx>OK. I just meant to wait for more to build while you sleep, no point in your x200 building all night.
<raghavgururajan>nckx: Btw, once this job finishes, could you also build inkscape and webkitgtk? Only if you time though. I dont wanna spoil your party time.
<raghavgururajan>nckx: Haha, even if I want to, I cannot build that many dependencies straight all at once over-night. I tried it before and the deviced turned off due to over heating.
<nckx>No problem. It hasn't started yet.
<raghavgururajan>nckx: I have ordered
<raghavgururajan>This time, I am really gonna sleep. xD
*raghavgururajan ---> zzzzzZZZZ
<nckx>Good night.
<nckx>pkill9: They are the low-level representation/result of #:modules in build-expression->derivation. Basically: the build-side modules, in a handy store directory that can be made available in the build environment.
<nckx>Or #:modules in ARGUMENTS, for that matter.
<alextee[m]>linux 5.7.6 broke ath9k support it seems
<jrobst>mroh - thank you, I have automount working well !
<mroh>jrobst: yay! glad to hear!
<jsoo>alextee[m]: is that external devices only?
<nckx>raghavgururajan: gvfs failed (because of failing dependency gcr/libical), everything else is ready.
***terpri__ is now known as terpri
<pkill9>how fast could guix concievably run with improvements?
<guixy>Hello guix!
<guixy>I'm working on fixing freeorion. I'm getting error output seen here
<guixy>Can anyone help?
<stikonas_>could it be cmake bug?
<stikonas_>looks like generated makefile has invalid syntax
***stikonas_ is now known as stikonas
<stikonas>guixy: can you try building it with ninja instead of make?
<pkill9>nmtui sucks
<pkill9>oh, i am running version 1.8
<pkill9>upgrading to 1.16
<pkill9>that might be why
<guixy>stikonas: ninja is not in my environment.
<guixy> What do I need to do to configure a package with cmake-build-system to use ninja instead of make?
<stikonas>guixy: not sure about cmake-build-system, but you can first try building manually with "cmake -G Ninja"
<cbaines>guixy, there's possibly other packages in the same situation. I'd suggest searching the Guix package definitions for ninja.
<stikonas>guixy: see define-public rdma-core
<stikonas>in linux.scm
<pkill9>meson -build-system uses ninja usually
<alextee[m]>jsoo: not sure
<guixy>I followed the error and found this line
<guixy>freeoriond: Boost::python-NOTFOUND
<nckx>pkill9: <nmtui sucks> Why?
<pkill9>it's failing for me,
<pkill9>and has weird behaviour
<pkill9>like only showing rhe network im connected to
<nckx>But ‘fail’ in the hacker sense or just not working at all?
<nckx>pkill9: I've noticed that too. When connecting to a network all others disappear. It only happens to one 5GHz network, not to the 2.4 one, which is weird.
***familia_ is now known as familia
<pkill9>also i tell it to connect and it just kind of hangs on there
<pkill9>probably doesnt help that my internet has been bad lately, but it's the lack of feedback that makes it suck
<nckx>pkill9: It's done that here but it always turned out to be the driver's fault. Have you used a different connection manager before?
<pkill9>ah ok
<nckx>Anything in dmesg?
<pkill9>no i havent
<nckx>or /var/log/messages.
<guixy>I'm using time-machine to see when freeorion broke. Maybe I can find what broke it.
<cbaines>guixy, if you know where to look, should also have this information:
<guixy>Thank you