< sipa>
achow101: have you tried creating a wallet with the latest sqlite, and then opening it with a verdion that uses an older one?
< sipa>
or is that exactly what you're tesfing here
< achow101>
sipa: that's exactly what I did
< achow101>
(as well as run all functional tests)
< sipa>
cool
< luke-jr>
what if new sqlite exits uncleanly?
< achow101>
luke-jr: I'd guess that it'd work fine, but I'm not sure how to test that
< achow101>
i'd have to kill bitcoind in the middle of a write somehow
< luke-jr>
gdb breakpoint and the kill command? <.<
< achow101>
hmm, ok..
< achow101>
luke-jr: handles it just fine
< luke-jr>
+1
< hebasto>
ja: #13478 is linked to #20104 as it is the recent discussion about minimum Qt version, and it lists arguments that should be considered in upcoming discussion
< vasild>
anyway - opened a PR, lets figure it out there
< sipa>
vasild: added in #4089
< gribble>
https://github.com/bitcoin/bitcoin/issues/4089 | devtools: add script to check symbols from Linux gitian executables by laanwj · Pull Request #4089 · bitcoin/bitcoin · GitHub
< vasild>
"This makes sure they are still compatible with the minimum supported Linux distribution versions."
< sipa>
yeah, if we'd accidentally introduce a dependency on a symbol that's only available in a recent glibc for example, you can't run the binary on old systems
< vasild>
I see
< kallewoof>
sipa: maybe you realized, but you did s/fSuccess/fuccess/.
< sipa>
kallewoof: i guess there will be an "Updates 2020/10/12" in that case :)
< sipa>
i shouldn't be making these changes at 2:24 am
< kallewoof>
haha
< sipa>
wait
< sipa>
of course i was just testing if anyone was paying attention!
< jonatack>
willcl_ark: indeed, it's been the case for a few days now, only the number of hidden comments keeps growing. i'm reviewing without the discussion.
< jonatack>
hebasto mentioned it as well last week
< willcl_ark>
jonatack: ah I see. How irritating for review.
< wumpus>
that's *really* bad
< wumpus>
did anyone report this to github yet? we can't keep using the platform if this is the case
< fanquake>
I have reported it to GitHub, and followed up with an employee today.
< michaelfolkson>
Anyone know if GitLab suffers from this problem (hidden comments)? This specific bug should be resolved but they never get round to addressing the terrible hidden comments UX either
< michaelfolkson>
I've never used GitLab
< luke-jr>
sipa: imports vs exports?
< luke-jr>
michaelfolkson: I have a GitLab repo that exceeded an arbitrary repo size limit years ago; opened an issue on their tracker, no response; pokes on Twitter, was told they'd look at it, still no response.. years later
< michaelfolkson>
Fair enough. So that wouldn't improve the situation
< luke-jr>
well, no idea if they have this issue, but it seems getting support is at least not likely
< hebasto>
could gh cli show all comments?
< luke-jr>
lol mishmash License: MIT Apache-2.0 BSD BSD-2 MPL-2.0
< michaelfolkson>
Linus quote from Working in Public book. GitHub is "fine for hosting, but the pull requests and the online commit editing are just pure garbage" :) Old quote though
< hebasto>
michaelfolkson: so it's useless for that
< michaelfolkson>
I think so. At least from looking at the docs. They seem to pushing a workflow where you approve the PR using the CLI but where discussion and review is done outside of the PR
< jonatack>
hebasto: i use gh cli a little and keep updating it, but the features added so far aren't what i'm hoping for. no getting the comments yet.
< jonatack>
michaelfolkson: exactly
< jonatack>
michaelfolkson: the globocorps and startup missions i was on until late 2018 used gitlab and mattermost instead of github and slack, which i was happy about, and we didn't have any issues at all -- i definitely preferred gitlab
< jonatack>
s/used/mostly used/
< jonatack>
michaelfolkson: but iirc the idea was to move away from any centralised service, if a migration were to happen
< michaelfolkson>
Right. GitHub seems to be deteriorating to me. Often happens post acquisition by megacorp.
< wumpus>
michaelfolkson: gitlab seems to handle things fine, e.g. freedesktop uses their own gitlab instance to host some active high-profile projects such as Mesa, no big issues from what i know
< michaelfolkson>
Maybe I should try it if I am going to have an informed view rather than a speculative view...
< wumpus>
they were also really, really careful to transition from olle mailinglist-based FOSS development, they never trusted github
< wumpus>
(possibly because of Linus' opinion as you quoted :-) )
< wumpus>
jonatack: being able to see the diff in-line *with reviewer comments* in the terminal would be a great cli feature, wish it could do that
< wumpus>
would save me a lot of switching between browser and terminal
< jonatack>
yesss this is what i was hoping gh cli would add
< jonatack>
whoever the PM is who is driving their features roadmap has very different priorities than ours
< achow101>
hebasto: I don't think that's a problem for us. we don't use replace or auto-vacuumed databases
< luke-jr>
is there a way we can more strongly mark #18818 as a blocker? let's not forget part was backported to 0.20 …
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20137: tests: Update UBSan suppressions file with suppressions needed for clang 12 (current trunk) (master...clang-12-ubsan-suppressions) https://github.com/bitcoin/bitcoin/pull/20137
< luke-jr>
sipa: ah, but did you compile your compiler yourself? ;)
< luke-jr>
I guess step 1 to migrating to a decentralised system would be to write a nice GUI app for GitHub's API?
< luke-jr>
(not Android because who wants to dev on their phone? XD)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20138: net: Assume that SetCommonVersion is called at most once per peer (master...2010-netVersionOnlyOnce) https://github.com/bitcoin/bitcoin/pull/20138
< MarcoFalke>
Ugh, is there any reason why GitHub would delete whole issues? #17298 is gone
< aj>
is what i get when i delete an issue; not a 404
< aj>
and comments go away
< bitcoin-git>
[bitcoin] sipa opened pull request #20140: Restore compatibility with old CSubNet serialization (master...202010_subnet_ser_compact) https://github.com/bitcoin/bitcoin/pull/20140
< sipa>
aj: definitely looks like a github issue...
< sipa>
MarcoFalke: we should report this
< achow101>
can confirm, doesn't look like spam
< gwillen>
hmmm, none of the submitter's comments seem to appear in /comments
< luke-jr>
aj: test the dangling label theory?
< gwillen>
I think I was mistaken about the dangling label, I think the ID it's complaining about is the issue itself
< gwillen>
(github uses numeric IDs for the REST API, but string IDs for the graphQL API)
< gwillen>
who was the submitter of the bug? I see a reply to a user named "StevenLee-CG" -- was that the submitter? That account doesn't seem to exist.
< gwillen>
Which makes me wonder if what happened was they deleted the account, with prejudice, and all associated objects, or something.
< sipa>
that seems plausible
< gwillen>
seems kind of rude.
< sipa>
aj: so your suggestion is removing the final commit from #19988 ?
< luke-jr>
aj: I mean make an issue, give it a label, then delete the label
< luke-jr>
but gwillen thinks it's not an issue, so..
< aj>
sipa: moving that commit to a separate PR maybe? are there any benefits to that patch other than simplifying/deleting code?
< achow101>
gwillen: when a user deletes their account, the issue should go to the "ghost" account
< gwillen>
I don't think this was a voluntary deletion
< gwillen>
I think this was some kind of aggressive admin deletion, like "account deleted for being a spammer" or for copyright violation or something
< gwillen>
otherwise it would be weird for it to leave the database in an inconsistent state like this (although ... that's weird anyway, and perhaps their code is just bad)
< achow101>
gwillen: perhaps. the user doesn't seem like a spammer though
< gwillen>
do we have an example of a comment or issue filed by a subsequently-deleted user?
< sipa>
aj: timing going backwards significantly seems like a problem in both variants really
< sipa>
aj: and the only real solution is using a steady clock
< sipa>
i'd say the code is a bit simpler now with the "now-monotonization" in it, and people have already looked at it
< sipa>
so i'd rather keep it
< aj>
sipa: in the original code it just means some announcements sit around until time catches up (in DELAYED or in REQUESTED if a notfound/tx doesn't come in) which doesn't seem a big deal?
< sipa>
or all timeout instantly
< sipa>
when it jumps forward
< aj>
sipa: right, that's jumping forward. but it only means the single thing that's "next" will get queued up, which seems fine?
< sipa>
i guess my comment is more about time jumping, not so much the backwards aspect of it
< sipa>
hmm, true
< sipa>
jnewbery: here?
< aj>
sipa: (hidden motivation is that i don't want to re-review all the original code to update my ack while knowing that it's about to be removed and the logic switched around in the last commit)
< sipa>
ok that's fair
< jnewbery>
sipa: hi
< sipa>
jnewbery: i'm inclined to just remove the monotonic time last commit based on aj's comments above
< sipa>
wdyt?
< jnewbery>
fine by me. I have no strong opinion. I ACKed it before, I ACKed it after
< jnewbery>
I would like to freeze the PR soon and get it merged (as I'm sure you would). Seems ready, and any loose ends can be tidied up after feature freeze
< sipa>
jnewbery: regarding the invariants (but this is for a future PR), if TxRequestTracker maintains its own time (which it can do even if backward/forward at both allowed), then it's indeed possible to just enforce the invariants all the time with no real API complication
< sipa>
so i like that idea
< jnewbery>
sipa: yeah, the only thing I think we might need to be careful about is whether that increases to cost of ReceivedInv() and RequestedTx() in the worst case, and whether that can be exploited
< jnewbery>
but I think it's ok
< fanquake>
sipa: unsure. I can bring it up with GitHub if someone hasn’t already