Logs

<fluffypony> Hi all
<fluffypony> I'm on my phone
<ArticMine> Hi all
<tooquick_4u> hello
<DaveyJones> NoodleDoodle, TheKoziTwo,
<DaveyJones> anyone else?
<pigeons> hola
<DaveyJones> luigi1112, listening or cruising ;)
<DaveyJones> jwinterm
<fluffypony> lol
<fluffypony> hyc and moneromooo are around afaik
<tewinget> fluffypony: if you wanna just give a list of things to cover, one of us can conduct the meeting. (assuming you don't wanna have to type a shitload on your phone)
<fluffypony> Well I think let's start with 0MQ, tewinget
<fluffypony> Then you can talk and I don't have to
<fluffypony> :-P
<tewinget> well, I wanted to have more news, but I'm having to do a full distro upgrade to get a newer boost on this craptop, and the internet is slow as balls...so I don't really have much in the way of updates. Soon™. Need to merge RingCT stuff into my zmq branch, then make the new RingCT-related RPC calls (as well as updating any others as needed), then should be golden for basic implementation.
<tewinget> will try to get most of that done today or tomorrow.
<fluffypony> This is daemon only right now right?
<tewinget> daemon RPC, and a lib to use it that libwallet will call into.
<fluffypony> ok - and then next thing after daemon is buttoned up is a wallet 0MQ endpoint right?
<tewinget> but yes, for right now I'm working on the daemon's RPC. Once that's in a good spot I can move onto wallet RPC. Oh, and I think since the last dev meeting I redid the formatting of the RPC commands to get JSON-RPC 2.0 compliant.
<fluffypony> Ok so tewinget let me ask about the backwards-compatible stub
<fluffypony> Coz obviously we still need a stub for those that insist on touching the daemon using old RPC
<fluffypony> Is that just a matter of refactoring it out of the daemon?
<tewinget> well...so *my* plan was to leave the old RPC in place until we decide "yea, that's for sure deprecated and gonna be removed now"
<fluffypony> That's fine - I meant as a later exercise
<fluffypony> Just trying to gauge the amount of effort it's going to take
<tewinget> hmm, well, a wrapper around the old RPC to hook into the new wouldn't be too hard...
<tewinget> just tedious
<fluffypony> I know it's tedious
<fluffypony> What if we made it generic
<fluffypony> Like it translated the RPC call directly
<fluffypony> If it fails pass the error back
<fluffypony> Oh wait that won't work
<fluffypony> The 0MQ calls are different
<tewinget> not hugely different, but different in some cases, yes. with good reason...
<fluffypony> Ok so tedious because it requires everything implemented as a 0MQ client, got it
<fluffypony> As a practical matter
<fluffypony> We need to consider something like cppnetlib for TLS and auth
<tewinget> I'm trying to make switching costs as low as possible, but I can't make it nonzero.
<fluffypony> And implement that as a matter of some urgency, since the entire net_skeleton thing was a colossal waste of time
<fluffypony> Ok tks tewinget - anything else from your side?
<tewinget> yea, I might make TLS and auth a priority ahead of wallet RPC (since it will need auth anyway)
<tewinget> other than that, not really.
<tewinget> carry on.
<moneromooo> "I can't make it nonzero" <-- excellent!
<fluffypony> Hokay
<fluffypony> LOL
<fluffypony> Nice catch
<hyc> lol
<fluffypony> breaking: Monero contributor works for free!
<hyc> just tuning in, was teaking my ARM code
<tewinget> god dammit.
<fluffypony> Instant delivery!
<tewinget> well, moneromooo, I can't
<tewinget> because it has to use ZERO MQ
<fluffypony> Hah hah
<tewinget> #SavedIt
<hyc> :P
<fluffypony> #dadjokes
<fluffypony> At any rate
<fluffypony> I'd like to introduce pigeons
<fluffypony> He's recently started doing some stuff with me
<fluffypony> and he's kindly going to help us redo our sysops / devops
<fluffypony> For all projects, including Kovri
<hyc> nice
<pigeons> Hi guys. :)
<moneromooo> Hi
<hyc> hey there
<fluffypony> pigeons: tell us a bit about yourself or whatever
<fluffypony> "Long walks on the beach" and all that
<hyc> I guess the population explosion kinda demanded more ops
<moneromooo> I see what a sysop is, but not a devop.
<pigeons> I like pina coladas and getting lost in te rain. Ive been syadmin type stuff forever.
<ArticMine> Hi pigeons
<fluffypony> moneromooo: devops is like CI and build boxes and that
<pigeons> devops is the new term for brogrammers who use docker and jenkins CI etc
<moneromooo> Oh nice :)
<fluffypony> Hah hah
<hyc> I think a devop is a developer with rootpw on all production machines. sysaop's worst nightmare :P
<fluffypony> Devops-as-a-Service
<fluffypony> lol
<pigeons> but yeah im gonna try and get buildbot ci going the system chromium and some others use
<pigeons> get builds and tests for arm, windows, mac, freebsd, linux 32 64
<fluffypony> Also the immediate aim is to be able to push nightlies to the site
<hyc> nice
<iDunk> #1047 did this
<iDunk> oops
<i2p-relay> {-guzzi} hi pigeons
<fluffypony> So the broader community can test without waiting for fluffypony to build
<pigeons> eventually look at gitian style reproducible builds
<hyc> ARM is gonna be 3 distinct builds, ARMv6, ARMv7, ARMv8
<hyc> rapidly proliferating...
<pigeons> ok cool
<fluffypony> hyc: I think we'll have to drop ARMv6 for performance concerns
<fluffypony> If not now then soon
<hyc> ok, fair enough
<fluffypony> Also on that note
<hyc> yeah, the perf/watt just isn't there on ARMv6
<fluffypony> Am I correct in saying that QEMU is about the only way we're going to get arm7/8 build boxes?
<fluffypony> Or does anyone know of hosted native arm boxes?
<hyc> there's an ARM VPS provider out there
<pigeons> yeah what are they called again, there is one
<tewinget> someone recommended one to me just the other day, oddly enough...can't remember the name.
<fluffypony> lol
<bitjedi> awww. i still use my pi zero nodes
<bitjedi> which are arm v6
<fluffypony> bitjedi: they'll choke on RingCT
<iDunk> scaleway.com ?
<hyc> scaleways?
<hyc> yeah
<bitjedi> are u sure it's cpu and not io?
<fluffypony> Awesome
<fluffypony> Isn't scaleways native and not virtualised?
<fluffypony> I seem to vaguely recall
<tewinget> I think it was Scaleway
<hyc> hm, they claim bare metal, yeah
<pigeons> theres one ovhi or somone in scandanavia
<fluffypony> Ok
<fluffypony> Also the implication is that anyone relying on the Mac / 32-bit test boxes should expect an impending change
<fluffypony> I think anonimal primarily uses them
<fluffypony> Also we'll hopefully be able to provide broader access to test hardware in future
<i2p-relay> {-anonimal} * has yet to use 32-bit boxes
<fluffypony> Ok then FreeBSD
<fluffypony> Has anyone tried the WIP boost 1.60 port on BSD?
<hyc> haven't touched BSD in years
<i2p-relay> {-anonimal} Last I checked, build failed hard on freebsd for monero.
<i2p-relay> {-anonimal} Works with kovri.
<fluffypony> xmj is our resident BSD expert and even he hasn't touched boost 1.60
<fluffypony> If anyone wants to volunteer to play with that great
<fluffypony> We also need to start thinking about packaging
<fluffypony> lol relevant PR is relevant
<fluffypony> hyc how do you guys handle packaging for like Debian / Ubuntu?
<hyc> eh, OpenLDAP Project is source-code only, distros do their own packaging
<fluffypony> Coz my concern with farming it out is that we end up with old versions on old distros
<i2p-relay> {-anonimal} fluffypony: I was planning to work with the monero bsd build (only freebsd though) once we get kovri releases going
<hyc> yes, that's a pervasive problem with distros
<fluffypony> Tks anonimal - I'll also fiddle
<fluffypony> When I have time, so never :-P
<fluffypony> Ok next thing
<fluffypony> moneromooo: want to talk about the rct serialisation changes?
<fluffypony> And the impact on testnet
<moneromooo> It's finished. It's on github ready to merge. And it will need reorganizing on testnet, yes.
<moneromooo> So, I guess someone with hash power will have to pop N blocks till before v4, and mine.
<moneromooo> After a few daysm it'll reorg for everyone :)
<moneromooo> And we'll get to test deep reogs.
<hyc> so anyone mining testnet right now should stop
<moneromooo> Unless you want to test stuff.
<iDunk> i exported the raw blockchain up to 800499. that's before v3, right?
<tewinget> well that's not entirely necessary >**_>**
<moneromooo> Yes.
<iDunk> and v4 is... ?
<iDunk> 802000 or so iirc ?
<moneromooo> 801220
<jjiia> XMR up or down
<iDunk> ah, k
<fluffypony> I think my miner is off atm
<fluffypony> it had that hiccup and I never fixed it coz stuff
<moneromooo> rct soon!
<fluffypony> ok so moneromooo
<ArticMine> It had to be done
<MalMen> are you guys forking the testnet ?
<fluffypony> when it loads the blockchain on the new code
<MalMen> im gonnad do a testnet classic
<fluffypony> it should freak out
<i2p-relay> {-anonimal} Is this the meeting where we can discusses CI for CD?
<fluffypony> and rollback?
<fluffypony> anonimal: CD? like compact discs?
<i2p-relay> {-anonimal} Laser-only releases
<moneromooo> It'll probably moan a bit, but not overly.
<fluffypony> :-P
<fluffypony> ok but what I mean is
<fluffypony> when we load a blockchain off disk we don't re-verify
<MalMen> the dev meeting is still going on or to late ?
<fluffypony> so will we have to manually pop blocks?
<dEBRUYNE> still going on MalMen
<moneromooo> Yes.
<fluffypony> ok so I'll merge tomorrow afternoon, gives us a day for review
<moneromooo> Just the miner. Others will just reorg when the miner passes the old chain's diff.
<moneromooo> (hopefully)
<fluffypony> and then I'll do some block-popping tomorrow night
<fluffypony> and hopefully deep reorgs
<moneromooo> luigi1112: btw, you'll want to read the latest get_transaction_hash and comment. It's still 3 parts.
<fluffypony> ok
<fluffypony> then the next thing is our hard fork date and the next release
<fluffypony> we're planning on finalising final bits and releasing 0.10 shortly
<fluffypony> but obviously RingCT (ie. v4 blocks) is not ready for even a final inclusion in this code freeze
<fluffypony> given that we're still making changes
<fluffypony> so I'd like some input from contributors and those present as to how to handle the v4 fork, since we have a couple of options
<fluffypony> either:
<fluffypony> 1. we leave v4 till March 2016
<iDunk> 2017
<fluffypony> tks 2017
<fluffypony> 2. we change the "complain about a fork" date to like end-of-November, with an aim to forking to v4 end of December
<fluffypony> so coded freeze beginning of December
<fluffypony> (this would make RCT transactions potentially available on mainnet from Jan 1)
<fluffypony> but obviously there's the risk of breakage
<hyc> maybe December is too soon, how about January?
<fluffypony> so if we had to do Jan, then when do we do v5?
<fluffypony> March is too close to Jan for v5, imho
<ArticMine> fluffypony My preference is 2, but my biggest concern is the amount of time left for finalization of development and testing
<dEBRUYNE> We don't necessarily have to decide the exact dates now, but I think option 2 would be best
<fluffypony> ok so what if we did 2, but then pushed the v5 fork to September next year
<hyc> if we have v4 in January then June/July would be OK
<fluffypony> that way RCT is available on mainnet early on, but if anything breaks we have 9 months to fix it
<fluffypony> hyc: I don't want to go too far away from our schedule
<hyc> ok
<dEBRUYNE> <hyc> if we have v4 in January then June/July would be OK <= Fine with that too
<DaveyJones> sounds reasonable to me
<dEBRUYNE> Like I said, we can always decide on the exact dates later
<fluffypony> like this is major enough to warrant a change, but we should aim for a singular change
<hyc> so march/september is the cadence we're aiming for?
<ArticMine> Yes I like the idea of advancing V4 fork but keeping the v5 fork on schedule
<tewinget> I agree, singular deviation from the schedule is preferable.
<hyc> ok
<fluffypony> hyc: yep
<dEBRUYNE> fluffypony: most people will use Ring CT transactions anyway
<fluffypony> so we bring v4 a bit forward, and leave v5 as scheduled
<lurker> yes
<fluffypony> dEBRUYNE: we can always make it the non-default, like we did with transfer_new
<hyc> sounds good
<dEBRUYNE> yeah agree
<ArticMine> agree
<fluffypony> ok so we'll move the freak-out to early December, and actual fork block height will be decided at that code freeze
<fluffypony> but likely late Dec / early Jan or so
<fluffypony> and v5 stays for September 2017
<fluffypony> consensus: reached!
<DaveyJones> \o/
<fluffypony> (it's so easy when you're tiny and only like 5 people have to agree, lol)
<fluffypony> I think that's about it from my side, there's something else but I completely can't remember
<fluffypony> is there anything else that anyone wants to bring up?
<ferretinjapan> I dunno multisig for bitcoin was a bitch...
<hyc> current freeze, release date?
<tewinget> since Ilya's not here...
<i2p-relay> {-anonimal} I moved kovri logo decision agenda to the beginning of kovri meeting in 10'ish minutes so we can catch everyone before they leave
<ferretinjapan> that only had 8 guys
<fluffypony> ferretinjapan: lol
<lurker> a quick update on multisig preferably
<moneromooo> Do you want to wait for the fee change before binaries ?
<fluffypony> lurker: https://shnoe.wordpress.com/2016/03/22/ring-multisignature/
<fluffypony> it's whitepaper-only right now
<kintaji> fluffpony - the GUI wallet. Languages and regional variations.
<fluffypony> oh
<Kermit_> Hi guys can I ask about public wallet build release dates
<fluffypony> yes moneromooo thanks for reminding me
<fluffypony> tag->release->binaries will be in the coming week, hopefully
<fluffypony> there are two things still remaining
<fluffypony> 1. fee changes (lower min-fee, bind it to the inverse of the block median as suggested by ArticMine)
<fluffypony> 2. ideally, if anyone is up for it, we seriously need our DNSSEC check expanded to actually check from the root cert down, at the moment it's relying on the DNS server to send back a "secure" flag, which is breaking it on lots of routers
<MalMen> tewinget can you point me to the list of 0qm commands that you have already?
<fluffypony> and we rely on DNSSEC for MoneroSeeds and MoneroPulse
<MalMen> I have some sugestion
<ArticMine> moneromooo is coding the fee changes
<fluffypony> there's some time pressure on that, but it's not a huge piece of work, so if anyone is up for it then that would be appreciated
<fluffypony> if not it'll have to hold off till the next release
<moneromooo> Yes, I started looking at it this afternoon. Not a simple change, since it'll require a new RPC, and access to median block size calc in misc places.
<fluffypony> ok
<dEBRUYNE> fluffypony: would it be feasible to provide trezor binaries?
<fluffypony> dEBRUYNE: I haven't actually looked at it properly, and NoodleDoodle isn't around to give his opinion
<dEBRUYNE> I see, he's still working on the Ring CT bit, so probably better to wait until that is finished to provide them
<fluffypony> kintaji: re: languages / variants, I think we'll hold off on that a bit as there are large parts of the GUI that are non-functional right now
<fluffypony> Kermit_: do you mean the GUI wallet, or the next tagged release?
<Kermit_> Yes gui
<kintaji> fluffypony - Okay. Just to say there are some oddities with the current flag page. Can expand at a later time.
<fluffypony> Kermit_: not certain yet - I'll look at building beta binaries in the next week or so
<Kermit_> Thanks
<fluffypony> kintaji: yeah maybe best thing to do is drop it out the wizard initially
<fluffypony> and add it back in later on
<tewinget> MalMen: have a look at https://www.github.com/tewinget/bitmonero/tree/zmq-dev, file src/rpc/daemon_messages.h. I need to do a bit of write-up, but that's a good place to start.
<kintaji> fluffypony - yep. sounds like a good idea.
<fluffypony> ok anything else or can we start the Kovri meeting?
<hyc> any other volunteers to test ARMv8 builds?
<fluffypony> oooh I will hyc
<pero> yea i can
<hyc> cool, I'll have atarball ready later tonight
<MalMen> tewinget you are writing your rcp calls with up letters right ?
<pero> fluffy i have centos 64bit on my rpi3 fyi
<fluffypony> hyc: is an R8 ARM processor an armv8?
<fluffypony> coz if so then I have a bunch of C.H.I.Ps lying around that I can test on
<hyc> I don't know what R8 is. what box is that?
<tewinget> MalMen: the class names are CamelCase, but the methods (currently) are "word_word_word". No reason that can't change, of course.
<MalMen> ahhhh, nice
<fluffypony> AllWinner R8
<MalMen> I was in mind that you where using WordWordWord
<hyc> ok I see it
<MalMen> would sugest wordWordWord
<fluffypony> "Allwinner R8 is SoC designed based on A13 featuring one core Cortex-A8 ARM CPU with Cedar Engine VPU and Mali 400 GPU"
<hyc> nope . Cortex-A8 is ARMv7
<fluffypony> ah ok
<fluffypony> well that sucks
<fluffypony> hi meeting-bot!
<tewinget> MalMen: the method names (as in, the method field in the RPC call on the wire) are "word_word_word" to conform with the previous RPC, but I have no particular attachment to that format.
<MalMen> well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better

19 KiB Raw Blame History

Logs

19 KiB

Raw Blame History