< fanquake>
You'll need to nuke the output/ and windeploy/ dirs
< dongcarl>
sipa: Yeah this is an unfortunate UX error
< dongcarl>
I'm writing a guix-clean script as we speak
< sipa>
when do i need to nuke them?
< fanquake>
Basically after each build. You could also remove the distsrc-hash-* dirs.
< sipa>
deleting the relevant distsrc-hash directory results in it at least being able to build again (otherwise it just says it already exists and aborts), but i get the same error at the end
< dongcarl>
you have to remove the distsrc-hash directories, and the output and windeploy dirs
< sipa>
what if i don't want to remove output?
< sipa>
do i need rename and move over afterwards?
< dongcarl>
Right, for now that is what you have to do.
< sipa>
yuck.
< dongcarl>
Hmmm
< dongcarl>
Actually
< dongcarl>
I'm not sure you need to remove output
< fanquake>
Yea I think it might just be windeploy, and that's where unsigned lives
< sipa>
also: fatal: no tag exactly matches 'c33b199456e57d83c21eacd36d3c56d0a123b0d0'
< fanquake>
Ideally this will all be cleaned up to the point of never needing manual intervention
< dongcarl>
fanquake: If I just change that mkdir to `mkdir -p`... that should fix it right?
< sipa>
that's harmless?
< dongcarl>
sipa: Right, harmless
< sipa>
fatal. harmless. got it.
< sipa>
;)
< dongcarl>
Hehe
< fanquake>
dongcarl: I think so
< dongcarl>
I've got some local branches that fixes a lot of these...
< dongcarl>
Promise they're coming soon :-) And thanks for the patience
< fanquake>
dongcarl: you're on thin ice
< dongcarl>
:O
< sipa>
that's a nice build system you got there
< dongcarl>
XP
< sipa>
yeah, deleting distsrc and windeploy works
< sipa>
this seems similar to the access travis and appveyor have
< fanquake>
is that just in the HWI repo?
< sipa>
it seems to be something at the org level, which confuses me a bit
< achow101>
strangely it was already available for the bitcoin org but not bitcoin-core
< bitcoin-git>
[bitcoin] S3RK opened pull request #21302: wallet: createwallet examples for descriptor wallets (master...create_descriptor_help) https://github.com/bitcoin/bitcoin/pull/21302
< wumpus>
neither bitcoin nor bitcoin-core has any private repositories at least
< wumpus>
but no idea what 'private resources' means here either
< wumpus>
but if it is read-only i suppose it's harmless
< sipa>
i can't actually tell if it is read-only or not
< wumpus>
i found the page but don't entirely get it either, it doesn't seem to be individual permissions just a blanket allow on/off
< sipa>
yeah, but it seems to be something about oauth
< wumpus>
i think i understand now: bitcoin-core has a policy enabled where third-party applications (enabled by organization members) have restricted access to the repositories in the organization, by adding an exception to that page, they can at most get the same permissions as the member (but up to what they actually grant)
< wumpus>
the bitcoin organization does not have this policy enabled at all
< wumpus>
it's a protection against accidental over-granting by members affecting the organization's repoistories
< wumpus>
pretty meta
< wumpus>
but in any case, with the exception enabled, it's stil up to achow101 what to grant and he cannot grant more than the access he has himself
< sipa>
ah, i see
< MarcoFalke>
An organization owner has approved the following application to access private data in the Bitcoin Core organization:"Travis CI" from Travis CI GmbH
< MarcoFalke>
Just got that mail ^
< MarcoFalke>
any idea what is going on. ping sipa wumpus
< sipa>
i didn't do anything for travis
< sipa>
i approved achow101's request for readthedocs.org
< wumpus>
MarcoFalke: which one do we need to allow "Travis CI" or "Travis CI for Open Source"?
< sipa>
are we still using travis?
< wumpus>
i have the second one enabled now, i disabled the first
< MarcoFalke>
we don't even use travis ...
< wumpus>
(it said something about being requested by btcdrak)
< wumpus>
ok, will disable them both then
< sipa>
yeah, when i looked earlier there was a request by btcdrak pending
< sipa>
which is now listed as denied
< wumpus>
right, I rejected that one
< MarcoFalke>
ok, I can see travis is removed from the apps
< dongcarl>
I find myself writing some utility functions in bash which is useful to other scripts, would ./contrib/bash-snippets be a good place to put them?
< hebasto>
dev-wiki?
< dongcarl>
hebasto: Meh, what I mean is functions which can be sourced and used so that we don't repeat them everywhere
< hebasto>
I see
< shesek>
what are the standardness rules for bare multisig? there's N<=3, valid pubkey first byte and size (according to CpubKey::ValidSize) and NULLDUMMY, did I miss anything?
< shesek>
(NULLDUMMY being validness rather than standardness as of bip62)
< sipa_>
bip62 is not consensus
< shesek>
oh oops, yes, I was confused
< sipa>
you may mean bip147
< shesek>
yes, I did, mixed some things up
< shesek>
are there any checks besides these I mentioned?
< sipa>
you'd need to distinguish between output creation time and spending time
< sipa>
at output creation it needs to match the bare multisig template exactly (or one of the other templates)
< sipa>
i don't think the contents of those keys matters
< sipa>
dongcarl, fanquake, wumpus: i now also did a guix build of 21298 in my debian vm with guix-master-a-week-ago-installed-from-source, and i get a mismatch on osx-unsigned.tar.gz
< sipa>
the machine also crashed while building, which may mean it's just corrupted
< * sipa>
redoes build
< dongcarl>
sipa: Oh! Yeah I'd love to take a look at that
< dongcarl>
sipa: Also, does `journalctl -b-1` tell you anything about what caused the crash?
< sipa>
the dmg is a match, however
< sipa>
dongcarl: the host machine crashed, taking the VM with it
< dongcarl>
Oh okay heh
< sipa>
size is 2 bytes difference
< dongcarl>
sipa: Huh... Do you still have the output or did you nuke it?
< sipa>
i have the output, comparing the contents of the tar now
< dongcarl>
sipa: If you use diffoscope, you can use the `--json output.json` option to encapsulate just the diff, and I can take a look if you want
< sipa>
pagestuff and codesign_allocate differ...
< dongcarl>
sipa: Oh! We don't need those anymore, right?
< sipa>
i believe we don't
< dongcarl>
Okay, if that's everything then we're good :-)
< sipa>
is it worth investigating what's causing the difference regardless?
< dongcarl>
I think so, but I'm trying to prioritize what I do so I can keep to my timeline... If you upload the tarball somewhere I will take a look!
< michaelfolkson>
Hey. Does anyone have views on a config option released in Core such that the user could change lockinontimeout (lot) from false to true? (assuming lot was set to false by default)
< michaelfolkson>
I'm looking for Concept NACKs ideally if anyone has one
< michaelfolkson>
"I like a hidden option in Core which is always there from day one, which is lot=true or taproot-bip8-lot-true or something that would change lockinontimeout to true and also change the default user agent string so you can tell people are running it. That’s good because by the time 6 months comes almost everyone has upgraded anyway, they’ve just got to change their config." (From the Sydney Socratic)
< bitcoin-git>
[bitcoin] dongcarl opened pull request #21304: guix: Various user workflow improvements (master...2021-02-guix-clean-script) https://github.com/bitcoin/bitcoin/pull/21304