I2P dev meeting, June 1, 2021 @ 20:00 UTC
Quick recap
- Present:
eyedeekay, zzz, zlatinb, psi
Full IRC Logg
(04:01:11 PM) eyedeekay: Hi everyone, welcome to the Tuesday, June 1 Community meeting
(04:01:25 PM) eyedeekay: 1) Hi
(04:01:25 PM) eyedeekay: 2) 300 logged community meetings
(04:01:25 PM) eyedeekay: 3) 0.9.51
(04:01:25 PM) eyedeekay: 4) go-i2p
(04:01:25 PM) eyedeekay: 5) reproducible build status
(04:01:25 PM) eyedeekay: 6) update channels report / Mac bundle report
(04:01:25 PM) eyedeekay: 7) Next release number, deferred item from April 6 meeting
(04:01:25 PM) eyedeekay: 8) 0.9.50 status / remaining release items
(04:01:42 PM) eyedeekay: 1) hi
(04:01:50 PM) eyedeekay: Hi everybody
(04:02:08 PM) zzz: hi
(04:02:10 PM) zlatinb: hi
(04:02:31 PM) eyedeekay: Hi zzz, hi zlatinb.
(04:02:31 PM) eyedeekay: Anybody else with us today?
(04:03:00 PM) eyedeekay: OK 2) 300 logged community meetings
(04:03:45 PM) eyedeekay: Congratulations everybody, the first meeting we have recorded on the web site was 19 years ago, nearly 20 now, and now we're 300 meeting later
(04:04:18 PM) eyedeekay: Thanks to all I2P contributors in the past as well as in the present
(04:04:54 PM) zzz: yes
(04:05:16 PM) zzz: any eepsites from back then still work
(04:05:44 PM) zzz: and some bugs from back then are still to be found and fixed! I fixed a bug from 2004 today
(04:06:58 PM) eyedeekay: I saw that over in #ls2 earlier, especial thanks to zzz who has been the heart and soul of this project for longer than most of us have even been around :)
(04:07:20 PM) zzz: can't do it alone, never could
(04:08:11 PM) zzz: but that's all the time you get for reminiscing, let's get on with the work
(04:08:24 PM) eyedeekay: Again thanks and congratulations to everybody, on to 3) 0.9.51
(04:09:34 PM) eyedeekay: We're about 2 weeks into this release, for my part I'm working on my X-I2P-Location feature in the default site and thinking about options for integrating a browser profile with a main installer at the moment
(04:09:59 PM) eyedeekay: What is everyone else working on for this release at this time?
(04:10:41 PM) zzz: I'd like to remind everyone to update the website roadmap with your plans for the next release. There's not a lot there right now
(04:11:05 PM) eyedeekay: Ack, thanks for reminding us, I will do mine this evening after the meeting
(04:11:27 PM) zlatinb: I will be starting the Mac-specific side of the Mac bundle updater, unless we decide to split the work otherwise. I'm happy to work on the i2p.i2p side as well, will discuss more in point 6)
(04:11:32 PM) zzz: the #ls2 team is continuing to work on proposal 157 (new tunnel build messages), it's going slower than planned. Not clear right now how much will get into the next release
(04:12:09 PM) zzz: the proposal is still incomplete, so until we do that, we can't finish the code
(04:12:42 PM) zzz: SSU2 is still not started. We had hoped to have it done this year... that seems unlikely at this point. We could use some more help
(04:12:56 PM) zzz: EOT
(04:14:15 PM) eyedeekay: Thanks zzz, zlatinb. I'll do what I can to contribute as my understanding grows. Speaking of that, 4) go-i2p
(04:15:41 PM) eyedeekay: I've written a cursory proposal for go-i2p in the proposal branch on gitlab.
(04:15:41 PM) eyedeekay: Besides that, I've nearly completed migrating the common structures from the old distro off of using byte-slice representation to using objects(structs) for representation, and re-written the tests to accomodate this change
(04:16:07 PM) eyedeekay: That means I'm at the point where I'm writing new code instead of just updating what's there, which is pretty exciting
(04:16:29 PM) eyedeekay: No transport yet, but that will be the next thing on the roadmap
(04:16:35 PM) eyedeekay: EOT
(04:16:41 PM) zzz: are you still over in a separate branch and if so why haven't you merged back?
(04:17:39 PM) eyedeekay: I've got ~4 tests to finish up before I do
(04:18:30 PM) eyedeekay: Once all the existing tests pass again or I can be sure they are redundant I'll merge it back
(04:18:34 PM) zzz: ok. and where are we with the full-go vs. go wrapper around i2pd? If the latter is really only 2 hours of work, as orignal claimed, shouldn't that be the next step?
(04:18:55 PM) zzz: as a proof of concept, or MVP, or to judge demand from go projects
(04:19:22 PM) zzz: then you could later just swap it out with the go router via the same API
(04:20:53 PM) eyedeekay: I've got it started but I'm having some issues figuring out exactly how to create the C wrapper for api.h, probably just because the process is new to me
(04:22:34 PM) zzz: ok. I still don't understand if the i2pd wrapper is a) an alternative to be evaluated; b) something definitely to be done first but we're doing both; c) low-priority/TBD
(04:22:53 PM) zzz: or d) we've rejected it
(04:24:04 PM) eyedeekay: IMO it should be b), because I should learn how to write a C wrapper for C++ code, and because the ability to easily embed i2pd in anything that SWIG supports would be very useful to have in general
(04:25:18 PM) zzz: ok you have an estimated date for that?
(04:27:52 PM) eyedeekay: Orignal's right, it's 2 hours of work for someone who knows how to do it already. The hard part to guess is how long I have to read examples to know what I'm doing. The 15th seems safe.
(04:28:14 PM) zzz: thanks, EOT
(04:28:40 PM) eyedeekay: OK that's everything I have for it too
(04:28:41 PM) eyedeekay: 5) reproducible build status
(04:28:57 PM) eyedeekay: zlatinb this one is yours
(04:29:21 PM) zlatinb: So, there's something that is reproducible on Mac and Linux with English locale and JDK 11 and sort of works
(04:29:44 PM) zlatinb: I know how to fix it for all Locales and to build on Windows too, there are a few small tweaks necessary for that
(04:30:31 PM) zlatinb: Despite it's PoC status I think we should have a web page with instructions for others interested in trying it out
(04:31:04 PM) zlatinb: as it uses the gradle build system it doesn't add to the release load and I'm happy to own it
(04:31:35 PM) zlatinb: that's about it
(04:31:38 PM) zzz: I said this on my forum already but I think it's important. We already have reproducible builds for Debian/Ubuntu. This is for gradle, which is not a supported build product now
(04:32:13 PM) zzz: I question the value of it, and the ability to support it when we're lacking all the repro. build infrastructure of debian
(04:33:05 PM) zzz: and announcements that 'i2p is now reproducible' is misleading/wrong. we need to be very clear about what it is
(04:35:01 PM) zzz: I don't think our testing is sufficient to claim reproucibility, and we don't publish our tool versions anyway.
(04:35:34 PM) zzz: eot
(04:37:23 PM) zlatinb: The only tool that matters is the JDK, and that is published to be 11. I am very skeptical that our Debian/Ubuntu builds are truly reproducible, and doubt that anyone will be able to reproduce the .deb packages on their own. Just because it passes the build bot doesn't mean it's reproducible, but that's another point.
(04:37:55 PM) zlatinb: There is value added to certain class of users even from an incomplete PoC that "strives" towards reproducibility or however we want to word it.
(04:38:38 PM) zlatinb: If nothing else it shows that we're aware that there is demand and are making effort (albeight low priority) to address that demand
(04:38:43 PM) zzz: the build bot has a lot of tests in it, more than we're testing, including changing username, PWD, locale, time, timezone
(04:39:02 PM) psi: doesn't debian have a bunch of hooks and shims that normalize timestamps and directories?
(04:39:08 PM) zlatinb: but it's clearly not changing the timestamps of the checked out code, otherwise it would break right away
(04:39:14 PM) psi: (for deterministic builds, also hi)
(04:39:25 PM) zzz: there may be 'demand' but not clear it's enough to justify the effort
(04:40:01 PM) zzz: yes psi, that's the build infrastructure we rely on for our reproducible debian builds
(04:40:08 PM) eyedeekay: I can confirm that zlatinb and I did not compare notes on what tools we were using, other than that we were on the same JDK, we certainly didn't compare individual libraries
(04:40:21 PM) zlatinb: the effort falls on me, as I said I'm happy to own it, and most of the work is already done
(04:40:31 PM) zzz: we have an answer now, 'use debian'
(04:40:53 PM) zlatinb: no, the answer is "use the debian toolchain and build environment to build your .deb"
(04:41:09 PM) zzz: I'm not convinced your testing is thorough enough to claim 'mostly done'
(04:41:55 PM) zlatinb: There are no known issues remaining, and the unknown ones we'll bump into as more and more people use it
(04:42:00 PM) zzz: and I'm not convinced we need another release product solely for those demanding non-debian reproducibility
(04:43:06 PM) zzz: I don't think we want to rely on users to discover reproducibility issues. we need some testing harness or build bot to confirm it given various permutations listed above and others
(04:43:13 PM) zlatinb: it doesn't need to be a release-quality product, I keep saying it is work-in-progress and will remain so for the foreseeable future.
(04:44:00 PM) psi: is the purpose an end user ready package or is it to appase the intellecuals?
(04:44:01 PM) zzz: in that case, no objections
(04:44:30 PM) zlatinb: clearly to appease the intellectuals, 100%
(04:45:22 PM) psi: gotcha, just catching up
(04:46:15 PM) zlatinb: what's wrong with having the users help find reproducibility issues?
(04:47:14 PM) zzz: 1) because most users won't actualy try to reproduce; but 2) if it's not an official release-quality product, nevermind
(04:47:34 PM) eyedeekay: Moving right along to 6) update channels report / Mac bundle report
(04:48:14 PM) eyedeekay: Unless we need to keep going on 5)?
(04:48:37 PM) zzz: I'm done with 5)
(04:48:51 PM) eyedeekay: OK, 6 then
(04:49:24 PM) eyedeekay: zlatinb this is also your topic
(04:50:20 PM) zlatinb: not much to report since the last meeting on the Mac bundle side of things; I've been dogfooding it a bit
(04:51:15 PM) zlatinb: I will probably have time this month to look into update channels properly. At least the part that will live in the mac-jpackage repo
(04:51:30 PM) zlatinb: can also look into the changes required to i2p.i2p unless someone else wants to have a stab at those?
(04:51:33 PM) zlatinb: eot
(04:52:07 PM) zzz: I'm happy to do the other side, let's coordinate this week
(04:52:30 PM) zlatinb: ok sounds good
(04:52:52 PM) zlatinb: that's all from me on 6)
(04:52:56 PM) zzz: I believe there's a few choices we have discussed but haven't fully decided on, but shouldn't be hard
(04:52:57 PM) zzz: eot
(04:53:08 PM) eyedeekay: 7) Next release number, deferred item from April 6 meeting
(04:53:57 PM) eyedeekay: 1.0.0? 9.51.0? There were several choices in the thread
(04:54:26 PM) zzz: yes. 2 months ago, I presented 0.9.50 vs. 1.0.0
(04:54:44 PM) zzz: since then, I noted that bitcoin core is going from 0.22 to 23.0
(04:54:54 PM) zzz: if a number is just a number, it can be anything
(04:55:18 PM) zzz: 0.9.51, 1.0.0, 2.0, 9.51, 10.0. whatever we want
(04:55:54 PM) zzz: if "1.0.0" brings up too much anxiety or implicit promise of perfection, we can avoid that by jumping right over it
(04:56:15 PM) zzz: or, we can just keep doing 0.9.x forever, or until some particular goal we haven't agreed to yet.
(04:56:18 PM) zzz: EOT. thoughts?
(04:56:55 PM) eyedeekay: I think a number is a number as long as the one we choose is on top when standard tools sort it, and in light of that, 9.51 has some appeal.
(04:57:52 PM) zlatinb: If we had a roadmap for installers I would put a nice round 1.0.0 after those are finished, but we don't have such a roadmap, so I'd rather avoid 1.0.0 altogether. Other than that 0.9.51 or 9.51 are the same to me.
(04:58:27 PM) zzz: don't necessarily need consensus today either, we have two more meetings before the next release
(04:59:04 PM) zzz: could always do a reddit poll although that may be counterproductive
(05:01:40 PM) zzz: let's discuss again next month eyedeekay
(05:01:41 PM) zzz: eot
(05:02:15 PM) eyedeekay: I do agree with zlatinb, if we were to use "1.0.0" as PR to seek new users, improving the installers would probably make such an effort more successful. If we wanted to preserve the opportunity to do do a 1.0.0 when that is done then we'd need to do 0.9.51, eot
(05:02:28 PM) eyedeekay: 8) 0.9.50 status / remaining release items
(05:03:16 PM) eyedeekay: zzz added this, but there's at least two of these I should probably answer for, GPlay and F-Droid
(05:04:27 PM) eyedeekay: There was a bit of a mess with GPlay during release time, I had to migrate us to an Android app bundle which requires me to generate a key and upload it to Google so that they could confirm I was the one uploading the app
(05:05:16 PM) eyedeekay: I failed at this process the first time which required me to contact google support, which caused a delay in the Android releases
(05:05:47 PM) eyedeekay: For reasons related to the release process, this also delayed F-Droid builds.
(05:06:33 PM) eyedeekay: From now on, F-Droid will be an apk, and Google Play will be an .aab, and the release process for one will not depend on the other. EOT.
(05:06:46 PM) eyedeekay: Anything to add zzz?
(05:07:20 PM) zzz: debian is the big issue. anybody heard from mhatta? he completely missed .49, now we're waiting on 50
(05:09:01 PM) eyedeekay: Not in quite a while unfortunately, I can reach out again
(05:09:08 PM) zzz: as far as net status, about 35-45% of net updated, about 25% have rekeyed, very smooth, no major complaints
(05:09:08 PM) zzz: please keep this item on the agenda for next month, since we're not done yet
(05:09:08 PM) zzz: eot
(05:09:34 PM) eyedeekay: Will do
(05:09:47 PM) eyedeekay: Anything else for 8?
(05:10:00 PM) eyedeekay: Or in general? timeout 1m
(05:11:26 PM) eyedeekay: All right then, thanks for coming everybody, next meeting will be July 6