< MarcoFalke>
I'd prefer to move to target-based seeds instead
< MarcoFalke>
It is just a hassle to have only one type of seed for all targets
< MarcoFalke>
It is hard to fuzz just one subtarget without modifying the code
< MarcoFalke>
And if the modification is done in the wrong way and the fuzzer is instructed to discard seeds that don't increase the coverage, they are incorrectly lost
< MarcoFalke>
With separate targets people could also easily contribute coverage for a specific target (without having to run meaningless serialization fuzzers or modify the code)
< MarcoFalke>
I will maintain a repo for our fuzz seed corpus for that
< wumpus>
putting the corpuses into a (separate) repo sounds like a good idea
< cjd>
For cjdns, I used the first 4 bytes of the seed as the test id
< cjd>
then I just made a bunch of files which were plausible data for each of the tests and started up AFL with all of them
< cjd>
I'm partial to the idea that every test which can plausibly make use of random data should use a fuzz api and then be reachable from AFL
< wumpus>
we have the test id as part of the data now, the idea in 15043 is to move away from that as it's easier to manage
< wumpus>
I don't have enough experience with fuzzing to have a strong opinion on that
< cjd>
"the fuzzer needs to "learn" how the fuzz targets are organized" I don't really understand this
< cjd>
It seems that unless there is a significant cost to doing it this way (fuzzer has more difficulty finding new paths), the benefit of having one fuzz entry point for someone to point AFL at outweighs the cost of cross-test type pollution
< wumpus>
that was something I've thought of mentioning too, it does seem easier to 'just fuzz' when there's one target
< wumpus>
with separate executables it seems you need to have a specific target in mind
< cjd>
I'll write my thoughts on github, as I am not in a position where I have to work with the bitcoin codebase every day so I don't want to impose, but I would like to raise a few questions as someone who does use this method
< wumpus>
well it's good to have outside opionions on this imo
< cjd>
BTW: one type of fuzzing which could potentially be very valuable for bitcoin is difference fuzzing.. create a test function which takes input and produces output and then use some linker trickery to allow linking 2 versions of bitcoin and invoking the function from each, if the output is different between the two then you got trouble
< wumpus>
fanquake: see post; I don't think it's really a bug, we've never used a different app name for regtest
< wumpus>
(this means it shares QSettings with testnet)
< fanquake>
wumpus ah fair enough, surprised I never noticed earlier
< wumpus>
there would be a point in changing it I guess especially if you're using bitcoin-qt regtest with the functional tests, wouldn't want to run it with the testnet settings
< promag>
ty hebasto
< fanquake>
promag Could you have a look at #15000? It fixes the notification segfault on Fedora, but seems to break macOS notifications.
< fanquake>
Just want to confirm it's not a local issue of mine.
< promag>
MarcoFalke: do you update the license year range on each touched file?
< wumpus>
promag: that is the original idea behind the license years, touching the file updates the copyright to current year
< wumpus>
usually people don't bother, which isn't bad, there's a script to update all of them at the end up the year
< promag>
contrib/devtools/copyright_header.py?
< wumpus>
yes
< cjd>
It seems to me that since normally all content it considered to belong to it's creator until the copyright expires (after whatever number of years), the year written in the notice is sort of a nod to older times when people used printing presses and there was no way to get dates from git blame
< wumpus>
it's essentially redundant as the info is in git anyway, but yeah
< wumpus>
there's been many discussions about this in the past, even about removing the years from the header, but there's no strong reason to, it's convention and it doesn't harm either
< promag>
wumpus: 0.17.2 date is before 0.18?
< cjd>
there are much worse conventions than that :)
< wumpus>
cjd: it's true :)
< wumpus>
promag: I guess?
< wumpus>
promag: it's not sure of course but I would be surprised if there isn't a reason to do 0.17.2 before march/april
< bitcoin-git>
[bitcoin] harding opened pull request #15081: Doc: Update release notes for master through to 2019-01-01 (master...2019-01-monthly-release-notes-update) https://github.com/bitcoin/bitcoin/pull/15081
< fanquake>
promag, when you are testing for notifications on macOS. Are you using src/qt/bitcoin-qt, or calling make-deploy and using the App in the .dmg?
< fanquake>
Seems to make a difference for me. re hebasto's comment, I didn't get anything in the Notification center at all, not just missing popups. I'll check again.