< fanquake>
phantomcircuit: I'm not sure how much smaller we can make it. The diff also looks a lot bigger because we are removing boost macros.
< luke-jr>
dongcarl: I don't see how that would solve it. I think there already is such a package (using third-party binaries of course) though
< dongcarl>
luke-jr: A Guix package built from source, that is.
< luke-jr>
dongcarl: I would be amazed to see it, and happy to do the work to port it to gitian myself ;)
< dongcarl>
luke-jr: Others have done the same (build Guix from source) on debian, Fedora, and Arch Linux. I'm not too familiar with Gentoo packaging, but I'll take a look to see if it's easy enough to do.
< luke-jr>
on x86_64 this time just to minimise issues
< dongcarl>
luke-jr: the bootstrap binaries are used when building binaries *inside* Guix, not when building Guix itself. To avoid them and build from the minimal binary seed, you can just supply —bootstrap to any guix build command
< luke-jr>
dongcarl: using them at all is a problem
< luke-jr>
(unless Guix is run inside a VM, such as gitian would)
< sipa>
so what is the problem with using -bootstrap?
< luke-jr>
I don't recall, my last attempt was many months ago
< luke-jr>
annoyingly, all the spectre mitigations mean I'm still installing deps this time ;.;
< luke-jr>
dongcarl: are guile-lzlib and guile-zlib likely included with guile itself? don't see a pkg for those
< dongcarl>
luke-jr I don’t think so unfortunately... Arch Linux packages them separately
< * sipa>
slams keyboard
< luke-jr>
hmm
< sipa>
In procedure dynamic-link: file: "/home/pw/src/gnutls-3.6.15/guile/src/guile-gnutls-v-2", message: "file not found"
< sipa>
when building gnutls
< * luke-jr>
wonders how he got zlib/lzlib last time
< sipa>
hmm, it seems the guile-gnutls package works, but installs for guile 2.2
< sipa>
and guile-git also works, but install for guile 3.0
< luke-jr>
O.o
< * dongcarl>
looking at packages now
< luke-jr>
looks like a `nix-guix` package overlay has -zlib/lzlib ebuilds that are trivially auditable
< dongcarl>
sipa: guile-gnutls package in Ubuntu?
< sipa>
dongcarl: yes, it works, but it's for guile 2.2
< sipa>
so i'll try installing guile-git (which guix also needs) manually for guile 2.2 as well
< sipa>
because the guile-git ubuntu package is for guile 3.0
< bitcoin-git>
[bitcoin] ajtowns opened pull request #21148: Split orphan handling from net_processing into txorphanage (master...202102-txorphanage) https://github.com/bitcoin/bitcoin/pull/21148
< * luke-jr>
glares at Guix docs for making him hunt for a git uri
< dongcarl>
sipa: Ah I see, it seems like an ubuntu apt repo with the right dependencies + guix would be helpful then...
< dongcarl>
sipa: I does the release tarball work? I will look into the autoreconf now.
< sipa>
dongcarl: oh, grr
< sipa>
i was just trying a broken master branch i guess
< dongcarl>
Also, since the debian folks did a lot of hard work to make Guix work well, it may be easier for APT-based distro users to just get their apt-sources from debian and build the .deb to install
< dongcarl>
They made all the dependencies of Guix work well too, including gnutls, bytestructures, etc.
< luke-jr>
says 3%, guess it will be a bit
< luke-jr>
dongcarl: that part was easy tho :P
< luke-jr>
50%
< sipa>
dongcarl: ok progress, guile-gnutls, guile-git, guile-json, guile-sqlite3, guile-gcrypt, guile-zlib work
< sipa>
next: guile-lzlib
< dongcarl>
sipa: Oh wow!
< dongcarl>
sipa: I honestly didn't expect them to work without the special debian rules...
< dongcarl>
Good news so far I guess :-)
< sipa>
i'm doing --prefix=/usr everywhere; i wouldn't do that on a real OS, but this is a VM to play with...
< sipa>
ok, building!
< * dongcarl>
cautiously excited
< sipa>
11%...
< sipa>
y dis slo
< luke-jr>
u forgot -j80
< dongcarl>
Haha
< luke-jr>
actually I intentionally didn't just in case it has parallel issues
< sipa>
i did -j8 (and my VM should have access to 8 threads)
< luke-jr>
can try -j8 when I rebuild it all again later
< dongcarl>
btw, guix has a handy `./pre-inst-env` script to use `guix` without installing it
< dongcarl>
luke-jr: I usually do -j48, and haven't had problems yet
< luke-jr>
I wonder if I was using master last time
< luke-jr>
I mgiht have been
< luke-jr>
I remember finding a bug
< luke-jr>
are all these .go files not actually go?
< sipa>
i suspect they are "guile object"s
< dongcarl>
It's guile bytecode I think
< luke-jr>
XD
< sipa>
75%!
< dongcarl>
woop woop
< * dongcarl>
half-expects a failure @ 99%
< sipa>
95%...
< dongcarl>
luke-jr: How's it going?
< luke-jr>
65%
< luke-jr>
sipa is faster
< dongcarl>
luke-jr: Oh did you -j1?
< luke-jr>
yes
< luke-jr>
also it's running on my old x86_64 box ☺
< sipa>
threadripper 2950X here...
< luke-jr>
trying to minimise risks so that when something *does* go wrong it's less unclear what
< sipa>
100%... still going...
< luke-jr>
lol
< luke-jr>
101% soon? ☺
< dongcarl>
luke-jr: True, honestly good practice...
< sipa>
ok, done
< dongcarl>
sipa: woo!
< luke-jr>
I suppose the downside is, now I'm getting de-sync'd from sipa
< * luke-jr>
stops a system update in case that helps it pick up some pace
< sipa>
make check fails... due to missing help2man, lol
< luke-jr>
XD
< * luke-jr>
SIGSTOPs chromium cuz Google can't be responsible with CPU time
< * dongcarl>
looking thru issues.guix.gnu.org to see if there are bugs on master
< dongcarl>
sipa: When I ran `make check` in the past, a lot of them failed as well, but normal operation hasn't had many problems. If you send me the output I can go investigate though!
< luke-jr>
so skip `make check`?
< dongcarl>
luke-jr: Yep, but if you provide me a log I can go investigate too (you can do that later)
< luke-jr>
it needs to compile all its packages? O.o
< dongcarl>
sipa: what is the full path for your guix src dir, if you don't mind?
< sipa>
this VM only has access to 8 cores, so 10 should be enough...
< dongcarl>
👍
< sipa>
is guix-daemon --no-substitutes what i want?
< dongcarl>
sipa: sec
< luke-jr>
[ 81%] GUILEC gnu/packages/maths.go
< dongcarl>
sipa: Yup, I would also do `env ADDITIONAL_GUIX_COMMON_FLAGS=--keep-failed` when invoking `./contrib/guix/guix-build.sh` so that we can debug build failures if they crop up
< fanquake>
is it too early to throw ADDITIONAL_GUIX_ENVIRONMENT_FLAGS='--bootstrap' in as well
< sipa>
what's the difference between --no-substitutes and --bootstrap?
< dongcarl>
--no-substitutes disables downloading binary substitutes from guix build farm, but builds from an intermediary group of bootstrap binaries, --bootstrap bootstraps from the absolute minimum set of bootstrap binaries
< dongcarl>
sipa: are you using ./pre-inst-env? Or did you install?
< sipa>
i did sudo make install
< * dongcarl>
looking
< fanquake>
sipa: plz block xuxihai999
< sipa>
fanquake: tis but a word
< dongcarl>
sipa: what commit are you on in bitcoin?
< sipa>
master
< sipa>
merge of 21130
< * dongcarl>
have a lead but still looking
< dongcarl>
sipa: Do you have a longer log I can take a look at?
< dongcarl>
sipa: Did you build git from savannah's git?
< dongcarl>
build guix*
< fanquake>
sipa: needs to be blocked in the gui repo as well. Maybe just from the whole org.
< fanquake>
Yea is spamming docs and & hwi now as well
< sipa>
fanquake: blocking is always org wide
< fanquake>
right. I take it the blocking hadn't happened yet
< sipa>
i did
< sipa>
hmm, does sipa_vm need to have some permissions to speak here?
< dongcarl>
sipa: Looks to be due to an old libgit2 confusing not recognizing that origin/keyring means keyring branch of origin rather than branch named "origin/keyring"... What version do you have installed? http://logs.guix.gnu.org/guix/2020-11-12.log#232527
< dongcarl>
I bet debian just keeps patching the CVEs themselves...
< luke-jr>
chromium has CVEs all the time and often just forces major version bumps..
< dongcarl>
¯\_(ツ)_/¯
< dongcarl>
luke-jr: Are you building on your GPD? XP
< dongcarl>
luke-jr: How's it going?
< * dongcarl>
struggling to keep eyelid open
< * dongcarl>
going to bed
< dongcarl>
sipa: I think that bug with origin/keyring is solved by upgrading to libgit2 1.1 and rebuilding everything that depends on it, let me know if that works!
< * dongcarl>
zzz
< luke-jr>
dongcarl: no, Haswell 4771
< luke-jr>
it finished
< sipa>
dongcarl: 1.1? i think i have 0.28
< sipa>
it works!
< fanquake>
!
< sipa>
mes-boot, gcc 4.9.4, gcc 7.5.0, ...
< fanquake>
was that with --no-substitues and/or bootstrap?
< fanquake>
*--bootstrap
< sipa>
both
< sipa>
i think
< fanquake>
If the build took days, and consumed 150% of you disk, you probably did
< achow101>
what's the command to have guix bootstrap if I already installed it a while ago?
< sipa>
fanquake: i gave it 128 GB disk space; should that be enough?
< fanquake>
achow: For doing a build of Bitcoin Core, something like: env ADDITIONAL_GUIX_COMMON_FLAGS='--no-substitutes --keep-failed' ADDITIONAL_GUIX_ENVIRONMENT_FLAGS='--bootstrap' `./contrib/guix/guix-build.sh (which will build for all hosts)
< fanquake>
sipa: iirc yes it should be.
< achow101>
fanquake: thanks. I think I need to uninstall all of the guix packages for it to rebuild everything then..
< * luke-jr>
watches Guix try to get to the net without permission
< vasild>
sdaftuar: I wonder if it is worth changing SIGNATURE_TYPE=EdDSA_SHA512_Ed25519 to SIGNATURE_TYPE=7 in the request we send? If the buggy i2pd is the latest version which debian stable has...
< ishaqm>
all, does anyone have pointers on compiling bitcoin-core with DEBUG symbols on?
< ishaqm>
i see, I might have phrased my question better I am afraid. I am trying to output debug *symbols* i.e. so that I can run it with a debugger (gdb or similar)
< ishaqm>
ah, the second link is exactly what I wanted, thank you very much michaelfolkson
< bitcoin-git>
bitcoin/master faefed8 MarcoFalke: fuzz: Count message type fuzzers before main()
< bitcoin-git>
bitcoin/master fa4bc89 MarcoFalke: fuzz: Fail if message type is not fuzzed
< bitcoin-git>
bitcoin/master a59e7ed MarcoFalke: Merge #20915: fuzz: Fail if message type is not fuzzed
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20915: fuzz: Fail if message type is not fuzzed (master...2101-fuzzFailMsgType) https://github.com/bitcoin/bitcoin/pull/20915
< prusnak>
dongcarl: is there a Guix Docker image or what's the preferred way to build bitcoin w/ guix on macos ?
< bitcoin-git>
bitcoin/master fa650ca MarcoFalke: Use -Wswitch for TxoutType where possible
< bitcoin-git>
bitcoin/master e498aef MarcoFalke: Merge #20211: Use -Wswitch for TxoutType where possible
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20211: Use -Wswitch for TxoutType where possible (master...2010-WswitchTxoutType) https://github.com/bitcoin/bitcoin/pull/20211
< vasild>
jonatack: wumpus: Thanks! Now lets see what happens with the I2P PR, I think some good simplification will be possible. Maybe the moving of SocketEvents() to a standalone function will not be necessary because it would be possible to use sock.Wait()
< vasild>
SocketEvents() allows to wait for at least one of a bunch of sockets to become ready. If it is just one socket then sock.Wait() may be used as well.
< jonatack>
vasild: looking forward to it :)
< vasild>
The I2P PR used SocketEvents() to wait on more than one socket simultaneously at some point - to issue more than one STREAM ACCEPT, but it turned out that this is SAM 3.2 feature and i2pd only supports SAM 3.1, so IIRC we no longer call SocketEvents() with more than one socket.
< vasild>
So, now we wait for incoming connections on just one socket and there is a tiny interval of time - after we have accepted a connection and before we issue STREAM ACCEPT where we are not listening. I think this is acceptable, though I did not check what happens if somebody tries to connect to us exactly then - would he get an error or just wait for us to issue STREAM ACCEPT.
< * vasild>
brb...
< wumpus>
vasild: i'm pretty sure you need something like socketEvents, after all the P2P code uses async networking, waiting on one socket is not enough
< wumpus>
(or is this only for session setup like the SOCKS5 init?)
< vasild>
wumpus: after we accept the i2p socket (in a i2p-specific way, not like usual tcp sockets via listen() bind() accept()), we give it to the connman like a normal already connected peer, then it uses CConnman::SocketEvents() internally to see if some of the peers has something to say
< vasild>
but lets see...
< wumpus>
vasild: ok so it's similar to SOCKS5 in that regard, there's some initial setup but after that it's simply a TCP connection like any other
< vasild>
exactly
< wumpus>
makes sense thanks
< luke-jr>
-builder for `/home/dev/guix/root/gnu/store/6mx4wp11nwrj886amyb86nwgvws68d03-gzip-1.10.tar.xz.drv' failed to produce output path `/home/dev/guix/root/gnu/store/vgrx621h8750zm0ijlpdfnd9s4igsakp-gzip-1.10.tar.xz'
< luke-jr>
dongcarl: I put the file where it wants it, but it's just deleting it and trying to refetch
< dongcarl>
luke-jr: happy to debug, could you send me logs?
< sdaftuar>
vasild: maybe, or perhaps we should just document the requirements somewhere so that others aren't tripped up? i don't have much of an opinion i guess
< sipa>
luke-jr: your dpaste looks like bzip2 compressed data
< dongcarl>
sipa: could you send me `/usr/local/var/log/guix/drvs/wk/rgrjfkpqdzdvv81nbra7bvskfl9i57-gawk-5.0.1.drv.gz`?
< sipa>
dongcarl: i restarted, and it seems to work now...
< dongcarl>
sipa: Great!
< dongcarl>
One of the things that Guix tries to do is to run as much of the test suite for its packages as possible... Which is great in ensuring that the built product works, but a lot of times reveals just how fragile pacakges' tests are (esp in a multi-threaded environment)
< luke-jr>
`less` automatically decompresses but `wgetpaste` does not >_<
< luke-jr>
if I make the source immutable, it errors with guix install: error: cannot unlink `/home/dev/guix/root/gnu/store/vgrx621h8750zm0ijlpdfnd9s4igsakp-gzip-1.10.tar.xz': Operation not permitted
< luke-jr>
still no explanation why it's trying to delete and refetch it
< sipa>
luke-jr: did starting over help?
< luke-jr>
sipa: no
< * dongcarl>
looking
< dongcarl>
luke-jr: Did you turn off networking for this?
< luke-jr>
sipa: not sure how far I got last time, but it's probably around the same point
< luke-jr>
oh right, it keeps a db of what it has :/
< sipa>
is there a way to make it download everything it will need for a particular build?
< dongcarl>
sipa: I'm guessing if you do `--dry-run` it'll do that?
< * dongcarl>
double-checking
< dongcarl>
FWIW: All guix package builds are offline (enforced by network namespaces I think) and hermetic. The bitcoin build script I wrote also builds in a completely offline environment by default.
< dongcarl>
Of course, pulling out the ethernet cable may be easier to trust...
< luke-jr>
keeping guix itself offline is my only way to ensure it doesn't pull in a blob
< dongcarl>
luke-jr: I'll post on the Guix mailing list about extracting out a list of needed downloads from a manifest, hopefully it's a simple enough Guile script.
< sipa>
dongcarl: if what i've been told about scheme/lisp is true, this should be easy ;)
< dongcarl>
sipa: Hehe true :-)
< luke-jr>
dongcarl: guix ignored that Debian trick
< MarcoFalke>
how much space does a guix build need these days (looks like DrahtBot is running out of disk)
< dongcarl>
MarcoFalke: You can most likely garbage collect and get some space back. One thing on my list is to pin the latest manifest output so that it doesn't get garbage collected, so that you can safely garbage collect everything else without affecting bitcoin builds
< bitcoin-git>
bitcoin/master 25f899c practicalswift: log: Move "Pre-allocating up to position 0x[...] in [...].dat" log message...
< bitcoin-git>
bitcoin/master 937dfa8 Wladimir J. van der Laan: Merge #21041: log: Move "Pre-allocating up to position 0x[…] in […].dat" l...
< bitcoin-git>
[bitcoin] laanwj merged pull request #21041: log: Move "Pre-allocating up to position 0x[…] in […].dat" log message to debug category (master...pre-allocation-up-to-position-0xff-in-foo.dat) https://github.com/bitcoin/bitcoin/pull/21041
< MarcoFalke>
dongcarl: wait? guix can garbage collect? how
< MarcoFalke>
Is it? debian bullseye comes with it and setting it up on other distros isn't too hard either. I think the pain point is to keep it in a working state/learn to use it.
< dongcarl>
wumpus: My general feeling is that if people run into things that are "their own fault" enough times, it's probably best to add an early check.
< warren>
luke-jr: I don't understand why you are asking for gitian support. The purpose of switching to guix is to eliminate the untrackable blob that we had in gitian.
< wumpus>
i had no trouble setting up guix at all, then again an ubuntu VM is probably easy mode
< luke-jr>
warren: as things stand, Guix is a regression in that respect
< sipa>
luke-jr: you can run guix in a VM if you like
< luke-jr>
warren: gitian works just fine without any untrusted blobs on my own system
< MarcoFalke>
Didn't we discuss this last week?
< sipa>
yes
< wumpus>
yes, no need to revisit this
< MarcoFalke>
ok, let's move on for now
< luke-jr>
it still needs to get on the plan
< MarcoFalke>
dongcarl: Do we need to change anything in the ci?
< wumpus>
luke-jr: you can write it yourself and contribute it as well as you want it so badly
< wumpus>
luke-jr: don't demand others work
< luke-jr>
wumpus: first I need to get Guix to work ;)
< MarcoFalke>
Currently we have the windows cross build using focal because gitian uses that
< MarcoFalke>
(windows cross build in the ci)
< warren>
dongcarl: Pre-meeting it sounds like a supported way to pre-populate downloads for guix bootstrap is a priority. The packager of Guix for Debian similarly commented that entirely offline is a requirement for their distro packages. He had to add a ton of unsupported hacks to package Guix for Debian.
< sipa>
i've been setting up guix from scratch in an ubuntu VM, from source, with --bootstrap... it's been a bit of a pain, but running fine now
< MarcoFalke>
So I am wondering how to deal with diverging compilers between the guix windows build and the ci windows build
< * dongcarl>
trying to answer one at a time
< sipa>
MarcoFalke: ideally we have a guix build in CI, i guess?
< MarcoFalke>
sipa: That'd be hard to setup, because you'd have to cache the gnu_store
< MarcoFalke>
for DrahtBot that is 11GB
< MarcoFalke>
11G./temp/scratch/guix/root_store/
< dongcarl>
MarcoFalke: Right, ideally we would have the same... Let me write it down and think about it. Will reach out back to you. Most likely we just cache a fully-GC'd gnu_store
< luke-jr>
wumpus: the only "demand" (more like expectation) is that it be usable without regressions before we switch to it exclusively.. and I've already said I'm willing to help, but I need to get to the point where I can
< sipa>
MarcoFalke: well, let drahtbot do it and comment, rather than actual CI?
< MarcoFalke>
on every pull?
< sipa>
just master would be great already
< dongcarl>
luke-jr: Will continue helping you set up like we've been doing this past 24 hrs :-)
< sipa>
luke-jr: you don't run gitian in a VM (outside; i'm not talking about the VM gitian itself uses internally)
< sipa>
?
< luke-jr>
sipa: not anymore, no; I got rid of that extra layer a while ago..
< sipa>
ok
< warren>
gitian has optional VM or container mode
< luke-jr>
(only did that at first because once upon a time gitian required Ubuntu IIRC)
< sipa>
warren: i know; that's not what i'm talking about
< MarcoFalke>
Maybe for ci we just use the closest version of mingw to guix that is offered by ubuntu/debian?
< dongcarl>
MarcoFalke: I think it'll be easier to do the other way around
< dongcarl>
I'll double-check, I think I made the Guix mingw build correspond to focal when I first set it up
< luke-jr>
are we expecting CI to produce binaries that match Guix? O.o
< wumpus>
no, just to run with the same version of the compiler to find relevant issues
< dongcarl>
No, but I think similar behaviour is good
< MarcoFalke>
luke-jr: Mostly to catch compiler errors before they are in the release
< wumpus>
right
< dongcarl>
I feel like I might have missed some comments up above, let me know if I did
< warren>
dongcarl: "Most likely we just cache a fully-GC'd gnu_store" <--- Is this also the answer to my question above about offline operation?
< warren>
Debian and Fedora require that for builds
< luke-jr>
MarcoFalke: ultimately, I think a full Guix CI is needed to avoid that?
< dongcarl>
warren: Could you detail what you want out of offline operations?
< MarcoFalke>
luke-jr: I think that'd be tricky to set up, as we need to cache the full guix store
< MarcoFalke>
(the part that we are using)
< luke-jr>
MarcoFalke: just DrahtBot is enough..? it's not like we want *all* the CI to use the same compiler ideally
< sipa>
warren: the gnu_store is the result of building all dependencies; i think with "offline operation" you're talking about the ability to fetch the sources beforehand, not the results (which implies trusted binaries)
< warren>
dongcarl: for packaging Guix in Debian in Fedora we're required to bootstrap from source starting with the distro toolchains of those respective distros. The build process cannot download anything from the network so we must pre-populate any downloads that it would expect. The Debian packager added a ton of hacks to enable this to work offline for Debian guix bootstrap.
< sipa>
warren: for CI trusted binaries are fine, we're just mimicking the release process
< warren>
s/Debian in Fedora/Debian and Fedora/
< dongcarl>
warren: Right, I believe those hacks are still required for packing for Fedora. I believe the Debian maintainer just mentioned that he's slowly upstreaming this effort.
< luke-jr>
warren: can you help with that after the meeting? ;)
< warren>
It was unfortunate to learn that Guix does not have a goal of Guix itself being reproducible.
< dongcarl>
I think w/re CI, let's get the versions as close as possible, and we will figure out a way to get a Guix-based CI working.
< dongcarl>
warren: ?
< warren>
dongcarl: the resulting Guix is not 100% identical to bootstrapped in a different way, reason being is reproducibility is not a goal of Guix, only bootstrapability.
< sipa>
you mean the guix-daemon and guix binaries?
< dongcarl>
If you're building Guix from source in $DISTRO, it's not going to be reproducible because $DISTRO's build tools are not reproducible. But once you have Guix built from source, you can reproduce Guix itself, and even challenge the binary tarball released on the Guix website.
< dongcarl>
wumpus: Yup! `guix install guix` works (I think)
< sipa>
we must go deeper.
< wumpus>
like if you compile the compiler using the OS' build tools, then compile the compiler using that compiler, that one should be deterministic
< wumpus>
ok
< dongcarl>
:-)
< dongcarl>
Any other concerns/questions?
< luke-jr>
wumpus: Gentoo actually builds every GCC 3 times :p
< warren>
Should a goal of bitcoin's release reproduce the bootstrap of guix and challenge? Or you expect guix to be already somehow bootstrapped on your own?
< sipa>
warren: i think our goal should be reproducibility; the user can choose what level of trust they have in their own build process
< wumpus>
agree with sipa
< phantomcircuit>
luke-jr, i guess that's why it's so slow
< dongcarl>
Exactly... Especially once Guix bridges into stage0... Bootstrap builds may take a week...
< sipa>
if you guix, presumably you got it in a way you're comfortable with, and if you have that - regardless of how you did so - you can build a reproducible bitcoin core release binary
< sipa>
+have
< wumpus>
it's useful if some people taking part in builds bootstrap guix from ~nothing, but not everyone would need to do this to be useful
< luke-jr>
I'm going to aim to have a gitian descriptor that produces a guix base with most deps at least
< warren>
That'd be fine if Guix had an upstream supported way of doing it offline
< dongcarl>
Guix boostrapping party leggoooo (just a bunch of nerds staring a build logs scrolling by)
< wumpus>
hehe
< sipa>
dongcarl: a bunch of geeks
< sipa>
(that's how guix is pronounced, right?)
< dongcarl>
warren: Let's open a dialogue with vagrantc, he has a full year's experience doing this for Debian and can answer more questions
< luke-jr>
lol
< dongcarl>
Haha yup!
< dongcarl>
NOT goo-iks!
< warren>
k
< sipa>
building python 3.8.2, and guile 3.0.2 now, ...
< sipa>
is there any kind of progress indicator?
< luke-jr>
I'm still stuck on not allowing it to run a 3P bash :/
< dongcarl>
sipa: Yes if it thinks you are on a tty... I might have messed that up with all my nesting...
< sipa>
luke-jr: yes, i'm sure we'll find a way around that
< dongcarl>
luke-jr: Yeah let's talk afterwards
< sipa>
dongcarl: it's printing what it's doing, and what it did; i don't know what it still has to do
< dongcarl>
sipa: Yup, if it thinks it has a tty it'll print "what it still has to do" as well... A good UX improvement... Will note it down
< sipa>
aH
< sipa>
cool
< wumpus>
that would be neat
< dongcarl>
Any other qs/comments?
< * jb551>
ponders a nix guix build
< wumpus>
if not, let's move to jonasschnelli's quick topic
< dongcarl>
👍
< jonatack>
dongcarl: know that you had me at guile (and guix pronounced geeks)
< dongcarl>
hehe
< jonasschnelli>
I think it would be helpful to chime in on #16439 versus (or and) #20273
< gribble>
https://github.com/bitcoin/bitcoin/issues/16439 | cli/gui: support "@height" in place of blockhash for getblock on client side by ajtowns · Pull Request #16439 · bitcoin/bitcoin · GitHub
< luke-jr>
dongcarl: warren: so anyway, I made gnu/packages/bootstrap/x86_64-linux and dropped my bash/mkdir/xz/tar bins there - but Guix is still trying to download the 3rd party blobs
< dongcarl>
luke-jr: Are you running the Test Suite?
< dongcarl>
luke-jr: Debian maintainer seems to think that only the test suite tries to clobber the 3rd party blobs
< jamesob>
hi
< jamesob>
Oh oops, timezones haha
< wumpus>
heh
< luke-jr>
dongcarl: no
< luke-jr>
per docs, I was trying to: guix install glibc-utf8-locales
< luke-jr>
fwiw, the answer we're getting in #guix appears to still be "you can't" (setup Guix without trusted third-party binaries) ☹
< dongcarl>
sipa: Could you send me: /usr/local/var/log/guix/drvs/vh/phki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.drv.gz
< dongcarl>
luke-jr: Right, until wip-full-source-bootstrap is merged, building packages in Guix will require the binary seed. Which is smaller than the Ubuntu distro.
< dongcarl>
sipa: Ah I know this one, looking for best fix right now
< dongcarl>
sipa: Okay this is due to a bug in Gnutls' test suite that tests a certificate, but that certificate expired on 2020-10-24. There's already a fix in Guix master upstream, which I will pull into my branch for our time-machine, but for now, this might work: 1. Disable NTP 2. Set your time to 2020-10-01 3. `guix build
< dongcarl>
/gnu/store/vhphki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.drv` (only builds gnutls) 4. re-enable NTP and check that your time is okay
< dongcarl>
Actually I think it's already fixed as of #21088... Will check