< bitcoin-git>
[bitcoin] sipsorcery closed pull request #16747: msbuild: Add missing classes to the bench_bitcoin project (master...add_missing_bench) https://github.com/bitcoin/bitcoin/pull/16747
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #16750: msbuild: adds bench_bitcoin to auto generated project files (master...autogen_bench) https://github.com/bitcoin/bitcoin/pull/16750
< bitcoin-git>
[bitcoin] michaelfolkson opened pull request #16752: doc: Replace stale URL in test README with alternative Boost resource (master...20190829-boost-url) https://github.com/bitcoin/bitcoin/pull/16752
< wumpus>
fanquake: I guess the idea was to do 0.17.2 soon
< fanquake>
wumpus: Yes I think so.
< wumpus>
is 16638 held up on me?
< fanquake>
wumpus: It probably needs your sign-off / look over again.
< wumpus>
okay!
< fanquake>
I re-pulled some translations, but nothing major.
< promag>
kallewoof: for explicit fee modes conf_target should be required no?
< wumpus>
promag: whoops
< wumpus>
I mean, provoostenator
< wumpus>
I don't think it checks there for @, no
< wumpus>
likely it should :)
< provoostenator>
Next time I'll just say: "ACK, don't at me"
< promag>
it that case it should drop @
< wumpus>
haha "be careful what you say after/before an ACK, the whole line will be in git history forever"
< wumpus>
promag: yes, throwing away the @'s would likely be fine there
< fanquake>
can't stop the spam
< wumpus>
\o/
< provoostenator>
Now that the Github CEO has our ear, we could also just ask them to fix this.
< wumpus>
I think they see it as a feature
< wumpus>
it would be a useful per-user setting maybe, "don't notify me when my name appears in commits"
< wumpus>
(thinking of it, their almost total lack of notification settings already came up before)
< provoostenator>
They should also find a way to discourage recency-bias. The notifications page strongly pushes for a bias to reacting to new stuff
< provoostenator>
The blue dot makes that worse
< wumpus>
yes, though I think this is a problem with the whole internet
< provoostenator>
Sure, fix the internet as well :-)
< provoostenator>
In fact, I'd say it's human nature.
< wumpus>
I mean, they use kind of default user conventions which don't get much thought
< wumpus>
let's fix human nature, now you're talking xD
< TheHoliestRoger>
is there a discussion open about algorithm/mining at all?
< TheHoliestRoger>
just out of curiosity, i'm not trying to troll or shill anything
< wumpus>
TheHoliestRoger: the bitcoin-dev mailing list archives would be the place to look for that
< TheHoliestRoger>
thanks wumpus, is it a discussion still ongoing or is it put to bed?
< wumpus>
TheHoliestRoger: I'm sure people are still talking about it somewhere, but not sure anything changed for years regarding that
< TheHoliestRoger>
wumpus: just been reading the list, i see various people trying to talk about eco friendly options but they're just met with resistance explaining the flaws rather than ideas of hwo to make it viable
< TheHoliestRoger>
it's a shame, we can't keep doing this forever
< TheHoliestRoger>
(i am all for btc btw, i'm just losing faith in cryptocurrency in general)
< bitcoin-git>
bitcoin/master fa60583 MarcoFalke: ci: Pass down $MAKEJOBS to test_runner.py
< bitcoin-git>
bitcoin/master fa27372 MarcoFalke: ci: Move CCACHE_DIR and test_runner tmp dir into ./ci/scratch/
< bitcoin-git>
bitcoin/master 1f77c5c Wladimir J. van der Laan: Merge #16739: ci: Pass down $MAKEJOBS to test_runner.py, other improvement...
< wumpus>
nothing can be done forever, things always change, circumstances always change, who says it's needed forever ? in any case, this is not the place for such discussions, the channel is for day-to-day development of the code base
< bitcoin-git>
[bitcoin] laanwj merged pull request #16739: ci: Pass down $MAKEJOBS to test_runner.py, other improvements (master...1908-ciScratch) https://github.com/bitcoin/bitcoin/pull/16739
< bitcoin-git>
bitcoin/master d53d591 Aaron Clauson: Added the bench_bitcoin project to the list automatically produced by the ...
< bitcoin-git>
bitcoin/master dcfd85a fanquake: Merge #16750: msbuild: adds bench_bitcoin to auto generated project files
< bitcoin-git>
[bitcoin] fanquake merged pull request #16750: msbuild: adds bench_bitcoin to auto generated project files (master...autogen_bench) https://github.com/bitcoin/bitcoin/pull/16750
< bitcoin-git>
[bitcoin] theStack opened pull request #16753: wallet: extract PubKey from P2PK script with Solver (master...extractpubkey_with_solver) https://github.com/bitcoin/bitcoin/pull/16753
< wumpus>
FYI #16754, this has been dragging on for multiple releases, I think it's time to change to a new transifex org if this can't be resolves. So please: if anyone knows seone, or can contact them, let me know
< fanquake>
Just realised the meeting is tonight. Likely wont be there so someone else can discuss.
< wumpus>
well can bring it up at least
< luke-jr>
#proposedmeetingtopic macOS/GNOME developers pushing their UI on everyone else
< luke-jr>
though I have to pick kids up at school during meeting as usual :x
< promag>
luke-jr: imho we have so few menu items - in contrast to other apps like design/3d/video/music/word where the icons help moving fast - that icons don't really matter and they don't improve accessibility that much either
< luke-jr>
promag: yet they are part of KDE/Windows UI design, and someone is willing to maintain them
< promag>
yeah kde/win support icons but it's optional
< promag>
fwiw I don't care that much if icons are added back, but its like jonasschnelli said, there's a lot of ui/ux improvements and icons seem the wrong place to spend energy
< luke-jr>
if nobody wants to do it, I don't care, but in fact someone does
< wumpus>
it kind of only makes sense if it'd use icons from the system theme
< wumpus>
bitcoin-qt using its own menu icons was kind of silly, and doesn't help at all with the purpose of icons to make things more familiar
< luke-jr>
KDE HIG: "Provide icons for all menu items. Don’t re-use the same icon for multiple items."
< promag>
luke-jr: kidding.. I just think the common denominator and the least controversial choice is to have no icons
< wumpus>
no *menu* icons
< luke-jr>
GUI maintainer forcing his particular platform's HIG on everyone else, is an abuse of position
< wumpus>
I don't think anyone is arguing to remove all icons
< luke-jr>
promag: people who don't want icons don't see them
< luke-jr>
Qt deals with this already
< wumpus>
it's just giving way too much discussion, especially if you'd want to follow the KDE guideline to have an icon for every item
< wumpus>
I mean there was a PR disussing whether to use a box with an arrow or floppy for a save action
< luke-jr>
then ignore those PRs..
< wumpus>
how is that in any way conductvie to this project
< luke-jr>
using theme icons will reduce that kind of debate too
< wumpus>
it's just not worth it, I'm sure you'll want to do it differently in knots, that's fine :)
< luke-jr>
actually, I can't easily add icons to Knots because they're binary files and Core doesn't do SVGs.
< luke-jr>
for some minor things, I have some tooling to render SVGs at build time, but doing it for all the menu icons would be sufficiently painful that I probably just won't
< wumpus>
yes, I think using theme icons would be considerably better, the problem is that once you do that, you can only use theme icons because any custom ones will always conflict with the theme
< wumpus>
I think it was even tried once to replace the icons by theme ones, but there were some issues, like the theme icons not being the same ones nor available on all platforms, it's not as easy and consistent as it sounds
< wumpus>
but you're welcome to try, I mean, fall back to no icons if they're not available in the theme is fine I guess
< wumpus>
(as this is basically to accomodate KDE now)
< luke-jr>
Windows also
< wumpus>
windows definitely has no theme icons
< wumpus>
that's a linux distribution thing
< luke-jr>
anyway, my point isn't to get into the details here - just to get past blocking it because their particular platform doesn't use it
< wumpus>
I just mean: if you can make a patch to add back icons for KDE, taken from the theme, so it doesn't have to clutter the repo nor generate discussion about particular icons, it'll probably be an easy ACK for me
< wumpus>
luke-jr: maybe, but it elevates the noise thrshold for everyone, I think it is good to take away things that create a culture in the project of bikeshedding
< luke-jr>
maybe a separate UX-specific repo that UX-concerned people can work at, with a per-release PR to the main repo?
< wumpus>
I don't think anyone is interested in going that far
< wumpus>
I mean, I'm not against anyone doing that, if they can make it work, but it seems a lot of coordination and work for something pretty far down the ladder of concerns for the project overall
< wumpus>
(I remember something like that was tried for "trivial" PRs once, like those that fix typos in comments and such, but it broke down pretty quickly)
< wumpus>
anyhow, if someone *would* solve long running, fundamental issues like the UI lag issue I'd be very inclined to pay more heed to their ideas about icons as well :)
< luke-jr>
seems like two things at fundamentally different skill levels :/
< wumpus>
it's true, but one is a path toward UI maintainer, the other is not, I mean
< luke-jr>
already too many people get the impression contributing to Core requires high skill
< promag>
not "different skill levels", just "different skills"
< wumpus>
sure, and that again is still a very different kind of skill than say, contributing to consensus code
< promag>
good icons are made by skilled designers
< wumpus>
this isn't about icon design really
< wumpus>
I thnk if you'd really want a designer involved with bitcoin's gui you'd want to start from the top, the layout and such, not from minimal things like the icons ... but usability is more important than design that's clear, it's what people actually struggle with now
< promag>
it's what people actually struggle with now -> is there a place to see the complaints?
< wumpus>
heck even the developers stuggle with the lag issue
< wumpus>
anyhow I"m tired of this, no longer going to argue, it just goes on and on and on
< jonasschnelli>
Regardless of icons yes or now. There is a very low probability that we revert something we jjust got 7 acks for. That's the reason why I closed the PR.
< wumpus>
yes
< jonasschnelli>
If one has a new approach, better, that is not just reverting a 7-ack PR, bring it!
< tryphe>
jonasschnelli, personally i'm not even sure why icons even matter when most of the gui UX seems in infacy still. to me it's a stylistic but non-functional change, sorta like changing a bunch of code from snake case to camel case because it looks cooler for some undetermined minority.
< jonasschnelli>
Yeah
< wumpus>
tryphe: I think we yet again all agree except for luke-jr :)
< jonasschnelli>
I vaguely remember luke-jr did also raise concerns when we change the icon to the bw-icons back in 2013.
< tryphe>
wumpus, jonasschnelli: and on the topic of accessbility, i don't think icons ultimately matter too much since there are already accessibility tools offered by most OS. for example, if the person has dyslexia, there's already fonts out there for that. and if they are blind they could use Linux Screen Reader.
< bitcoin-git>
[bitcoin] laanwj closed pull request #15965: check bad-prevblk is right error for invalid descendants (master...bad-prevblk) https://github.com/bitcoin/bitcoin/pull/15965
< jonasschnelli>
tryphe: if one can't read the text next to icons, how should one manage to send or receive coins?
< jonasschnelli>
:-)
< jonasschnelli>
(I mean without further accessibility tools like screen readers, etc.)
< tryphe>
jonasschnelli, yeah, and Qt is extensible enough to where even if they couldn't read the text, they could modify their OS settings so they can (assuming they know how to read)
< warren>
FYI ... libfaketime-0.9.8 is released upstream. It works with newer glibc Linux distros out of the box. But ppc64le and aarch64 require you to build it with non-default flags to use different ifdefs in order to workaround issues. Upstream lacks automake/autoconf so it can't detect if it needs those ifdefs are needed automatically.
< wumpus>
we don't build faketime from source, do we? at least not in depends
< warren>
dunno, we blindly using the version in Ubuntu? we should build it ourselves because it intercepts a bunch of syscalls during build
< wumpus>
I don't think that matters for gitian, maybe for guix
< warren>
dongcarl: let me know when libfaketime is being updated for guix, due to the lack of auto* tooling it needs different build flags for different archs =(
< dongcarl>
warren: We don't need libfaketime at all for guix
< warren>
dongcarl: oh, good.
< dongcarl>
maybe for the win/osx builds tho, still working thru windows
< wumpus>
oh that's very good
< wumpus>
with tools becoming deterministic, the need for faketime should be less and less
< jonasschnelli>
Could contacting transiflex eventually help?
< jonasschnelli>
They may help in such cases when the administrator left...
< sipa>
never heard of that person
< wumpus>
I don't know, my proposal is to move the translations to the bitcoincore org, which already has the website translations
< wumpus>
or at least, create them there starting with 0.19
< jonasschnelli>
would loosing contributors be a problem? or any other downside when moving to bitcoincore?
< sipa>
well would there be any overhead from the transition?
< wumpus>
contacting transifex might help, but may take a long time to resolve
< wumpus>
we're losing contributors now because I don't have access to the team page
< wumpus>
and can't set language coordinators andsuch
< jonasschnelli>
Oh. Good point.
< jonasschnelli>
ack on moving from my side
< provoostenator>
ACK on moving or starting from scratch
< wumpus>
I had hoped someone simply knew seone, I've tried contacting them through the site a few times but I think their last activity was in 2017 or so
< meshcollider>
You could contact transifex and just give it 3 days or so just to see what happens without waiting forever
< wumpus>
not aware of any IRC or github nicks
< warren>
In the past I knew the owner of Transifex personally but we haven't talked for years, maybe I can get his attention now.
< wumpus>
oh someone on the inside of transifex would also help
< warren>
let's set a timeout, if we can't get help by _______ then we move
< wumpus>
the problem is that 0.19 translations are supposed to open in 3 days
< wumpus>
so that means we skip this for 0.19, which is fine, I guess we can mess around as we did for another release
< wumpus>
so are you sure enough this will work warren that it's worth that?
< warren>
wumpus: I don't know, I haven't tried to talk to him for many years now. Transifex started as a Fedora project over a decade ago, that's how I know him.
< wumpus>
oh!
< warren>
actually we talked maybe 4 years ago
< warren>
would it be a pain to move to the other org? would it confuse people?
< wumpus>
that's longer ago than when I talked to seone :-)
< provoostenator>
So we wait 3 days to see if move can happy quckly, otherwise do 0.19 from a fresh account (maybe a day or two delayed)?
< wumpus>
nah, could just throw a notification in the old organisation that the translations have opened, in another place
< provoostenator>
Given that we have to handle backports for a while, it's nice to do 0.19 the righ tway
< wumpus>
I think a notification on transifex results in a mail for everyone that participates
< wumpus>
but yes, let's wait a week then
< warren>
wumpus: it's thursday now. if I can't get a response by end of Friday then assume we won't get an answer in time and plan on moving?
< wumpus>
any other topics?
< wumpus>
warren: sounds good to me!
< warren>
a week? OK i'll try
< wumpus>
yeah it's not a problem to open the translation a few days later, that's definitely happened before
< wumpus>
no other topics, going to close the meeting then, thanks everyone
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Aug 29 19:23:10 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< harding>
On BitcoinCore.org, I can make the &tr=blah;&tr=blah part of the URI a part of the template so wumpus doesn't need to provide it and it can be updated across the whole site with just a +1/-1 diff.
< wumpus>
harding: oh sounds like a good idea, ah yes for magnet URIs it's not encoded but simply appended to the URI
< wumpus>
though I'm not sure that will work
< provoostenator>
Also, as I pointed out in the github issue, I made my own tracker: udp://tracker.bitcoin.sprovoost.nl:6969 Happy to whitelist releases.
< wumpus>
don't I have to announce to the trackers?
< wumpus>
simply replacing the trackers in the URI, replacing them with others, might mean they don't know about it? (sorry I know very little about how torrent works so may be wrong)
< wumpus>
provoostenator: let's use that one too then :)
< provoostenator>
Thanks, just note that it's whitelisted, because I'm not in Pirate Bay mood. So just ping me the info hash of each release.
< harding>
wumpus: anyone who is seeding announces it to the trackers, I believe.
< harding>
wumpus: oh, I see what you're saying.
< wumpus>
I'm the initial seeder :)
< harding>
Maybe we just keep doing it the current way. Currently, BitcoinCore.org only shows the magnet for the latest version, so just updating the tracker list at each release (if any of them die) is probably fine. There's no old magnet links with all dead trackers to worry about.
< provoostenator>
I can seed them as well, but I set an obnoxious low upload speed limit.
< wumpus>
I use a VPS with pretty fast network for seeding so it's ok
< wumpus>
though it never hurts if more people do so
< provoostenator>
OpenTracker (the tracker, not the software by the same name) has a whopping $1 / month Patreon support. That should help their "goal is to create a torrent tracker that will stay alive"
< provoostenator>
So we could probably use a few more bitcoin specific torrent trackers.
< warren>
anyone know what is wumpus' transifex username?
< instagibbs>
just a heads up, I've been granted merge permissions on HWI
< warren>
found his transifex account name
< warren>
Wrote e-mail to Transifex CEO. If I don't hear back by Monday I'll try to call and/or stop by their office nearby.
< warren>
LOL he responded in our github ticket and already fixed now.