monero-project / meta Goto Github PK

https://build.getmonero.org/builders/kovri-all-ubuntu-arm7/builds/103/steps/benchmark/logs/stdio
https://build.getmonero.org/builders/kovri-all-debian-arm8/builds/99/steps/benchmark/logs/stdio

The build "fails" because of benchmarks timing out on ARM boxes. IMHO, 28 minutes is more than enough time to run benchmarks so I'm wondering if the problem is kovri-side. @danrmiller says that the machines may be to blame though, so info needed.

I had said I would do a cryptopp benchmark test and see if there are compiler flags that can resolve the situation. Ticketing for housekeeping while I look into that.

From monero-project/kovri#540:

HTTP client tunnel output to file will also ease sharing of whitelisted addresses for server tunnels

Instead of a file, we can implement on check.kovri.i2p to provide a header response for HTTP client tunnels without persistent keys, similar to what stats.i2p/cgi-bin/mydest is doing (see tunnels config documentation for details).

This is trivial to implement with PHP. Ticketing for housekeeping.

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Resolve PR's for monero-forum and monero-site and meta
4. Code + issue discussion / Q & A
5. Any additional meeting items
6. Confirm next meeting date/time

Notes:

• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

I'll move the private things like api tokens and builder passwords out of the main file, refactor a few things, and then make a PR to this "meta" repo so we can manage that here.

This has been an idea for a long time now and I'm wondering if anything is in the works. Referencing #9.

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev

Time

Use the timezone converter or the image below.

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. A discussion of PR 1816, & perhaps a more general discussion of C++ templating etc.
4. A Series of Unfortunate Events: the v0.10.2.x release failures, massive regressions, and serious issues. How do we do better in future?
5. Code + ticket discussion / Q & A
6. Any additional meeting items
7. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev will be relayed to each other through the duration of the meeting, even though there won't be a Kovri meeting following the Monero one.
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

The Irc2P network (IRC on I2P) currently consists of 3 server operators: irc.dg.i2p, irc.postman.i2p, and irc.echelon.i2p. While they are trusted within the I2P community and have the long record with the java I2P project, the issue of IRC centralization and the potential for abuse (e.g., anti-Kovri sentiment leading to removal of #kovri/#kovri-dev) still exists purely by design.

I can provide assistance/details to anyone who is interested. Your contribution will make waves with Kovri and the I2P community.

Other builds wait in the queue during the upload step when (I'm assuming) resources are available for the next build. When the upload step is reached, is it possible to queue that [the step] instead of entire builds?

For the static builds on the website: monerod uses libunbound which in turn uses OpenSSL statically. kovri uses cpp-netlib which in turn uses OpenSSL statically (now that the static builds are ready).

This is a problem for the website binaries in terms of keeping up with critical OpenSSL updates. We should somehow decide who takes care of what, and how, and preferably the process would be as automated as possible.

This idea was originally going to be only for kovri until just now when I noticed the capacity of monerod's libunbound usage.

I'll cross-post this into monero's repo since there are far more eyes there than here (though I'll close the issue there if someone thinks it should stay here). Maybe someone will want to jump at the opportunity and pickup the slack?

[main] make 4968 fork: child -1 - forked process 6800 died unexpectedly, retry 0, exit code 0xC0000142, errno 11
https://build.getmonero.org/builders/kovri-all-win64/builds/210/steps/compile/logs/stdio

Windows binaries needs to be built without avx cpu flags to be supported on older machines.

• static libboost build with -mno-avx and same toolchain as qt5 prebuilt mingw binaries. Inspiration here: https://forum.getmonero.org/5/support/2510/building-monero-v0-9-2-on-win32
  Qt 5 mingw install: http://download.qt.io/official_releases/qt/5.6/5.6.2/qt-opensource-windows-x86-mingw492-5.6.2.exe
• libwallet built with same toolchain
• monero-core build

Other platforms can be built with official instructions found in Readme.

As mentioned in monero-project/kovri#530 and monero-project/kovri#159 we could write descriptions of requisites/internals for developing Monero/GUI/Kovri and put into publishable form. From there we could post through various mediums. We could also create a request for particular research via the MRL. The sky's the limit.

If something like this is already in place, I don't know where it is nor if it is formal. I've spoken with @fluffypony and various things are in the works so I'd consider this issue to be a general purpose proposal.

For kovri and monero, I'm currently managing both but we easily have this automated (maybe weekly or daily). monero-core can be thrown into the mix too.

@danrmiller we can talk details in private.

Location:

• Freenode | OFTC | Irc2P | Slack
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Code + ticket discussion / Q & A
4. Any additional meeting items
5. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev will be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Monero HackerOne Bounty https://www.reddit.com/r/Monero/comments/5zmywx/monero_bounty_for_hackerone/
4. Code + ticket discussion / Q & A
5. Any additional meeting items
6. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev should be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

Upon every RDP disconnect, all my windows/running programs are closed. This makes run-time testing or building impossible unless I keep an RDP client session open 24x7.

I'm using xfreedrp with /u: /p: and /v: options.

3.8 or higher if possible.

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Preparation for 96boards.org OpenHours showcase for Kovri / Monero
4. Status of Monero HackerOne umbrella and bounty
5. Code + ticket discussion / Q & A
6. Any additional meeting items
7. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev should be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

@danrmiller we're good to go now.

Effects the ability to confirm new static build fix for BSD. Build log here.

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. More preparation for 96boards.org OpenHours showcase for Kovri / Monero (@fluffypony @danrmiller location status, @anonimal "de-anon consideration" status)
4. Status (again) of Monero HackerOne umbrella and bounty. hackerone.com/monero is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
5. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
6. Code + ticket discussion / Q & A
7. Any additional meeting items
8. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev should be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

@danrmiller knows the details. This includes min req for boost, a current openssl, and vastly increased swap space (probably 2gig min). cmake and gcc-4.9 have already been installed.

Time and location:

• 17:00 (UTC)
• IRC: Freenode | OFTC | Irc2P | Slack
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Status of nightly releases / alpha release
4. Code + ticket discussion / Q & A
5. Any additional meeting items
6. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev will be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Code + ticket discussion / Q & A
4. Any additional meeting items
5. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev should be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

We'll very soon have benchmarks running within the utility binary. This means no more kovri-benchmarks. I personally don't have a need to run benchmarks on every build either (but that's just me) so if we remove them all-together from the build then I'm fine with that. Otherwise we'll have to run them from kovri-util.

Moving here from monero-project/kovri#105.

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev

Time

Use the timezone converter or the image below.

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Discussion of fireice-uk's proposal (as started in #1828
4. Remote nodes (ie. a discussion of #605
5. Code + ticket discussion / Q & A
6. Any additional meeting items
7. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev will be relayed to each other through the duration of the meeting, even though there won't be a Kovri meeting following the Monero one.
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

As I've discussed with Robert Wolff, @danrmiller and @fluffypony: a two-episode live-stream demo showcase, both 30-40 minutes long, of both Kovri and Monero. https://www.96boards.org/openhours.

• The call is hosted by Robert Wolff and includes Linaro and 96Boards engineers (most of the time) and community
• They'll need commitment from us 2-4 weeks advanced notice prior to the episode
• They're booked until April

We'll continue talking internally, ticketing for housekeeping.

Poor machines 😢 (I noticed that this wasn't addressed in monero-project/kovri#452).

This includes markdown and things unrelated to compiling. I believe @danrmiller said this was a WIP. Ticketing for housekeeping.

This has been long in the works. If there was a resolution, I've seemed to have missed it!

Referencing monero-project/kovri#27 and monero-project/kovri#225

The Monero Core Team does not have time to lable the Issues (especially in monero-core Repo).

This increases workload for everybody and with rising complexity, neees to be changed in my view. Labeling and Filteing Issues is a powerfull tool which will help support planing and at the same time increases transparency.

The idea has been coming up during discussions on how to enable certain people to label issues, but withiout giving them full repo access. since github does not support selective permissioning, the idea of a labeling bot came up.

the bot could ideally be controlled via IRC or similar.

Time and location:

• 17:00 (UTC)
• IRC: Freenode | OFTC | Irc2P | Slack
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Status of alpha release preparations
4. Code + ticket discussion / Q & A
5. Any additional meeting items
6. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev will be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

Despite ~3GiB unallocated memory, buildslave is not releasing ~80% of swap while idle(?) (not currently building anything according to top). As a result, attempting to build kovri with gcc for testing results in OOM.

I can use clang for now, but can we still up the swap (or find another solution)?

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev
  • #kovri-dev

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Code + ticket discussion / Q & A
4. Any additional meeting items
5. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev should be relayed to each other through the duration of the meeting
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

Something I'd actually like to host (and may in the future) but my plate is currently full (as is everyone else's these days).

There are benefits for monero/kovri in running a reseed server (some of which I'll be happy to elaborate on) and I'd recommend reading this. Also, AFAICT, we don't need to use java I2P to host a reseed server because our netdb layout + RI's are that of java I2P's - so the process of netdb scraping shouldn't be an issue (I would need to review more before anything goes online).

Ticketing here in case anyone else is interested. I highly recommend anyone to get involved with this issue or with hosting a reseed server. If hosted by a monero community member, ideally I would work with them to have access to the server for kovri development purposes and to help with maintenance if needed.

Introduced with monero-project/kovri#568

I believe that @fluffypony mentioned at some point something along these lines - but I'd like to see for certain where we stand and what the plan was exactly (I do like the idea very much 👍).

Referencing monero-project/kovri#46 and monero-project/kovri#90.

https://build.getmonero.org/builders/kovri-all-debian-arm8/builds/116/steps/compile/logs/stdio

[100%] Linking CXX executable ../../kovri
/usr/bin/ld: /home/buildbot/slave/kovri-static-debian-arm8/build/deps/cpp-netlib/build/libs/network/src/libcppnetlib-client-connections.a(client.cpp.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `_ZTVSt8bad_cast@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/buildbot/slave/kovri-static-debian-arm8/build/deps/cpp-netlib/build/libs/network/src/libcppnetlib-client-connections.a(client.cpp.o)(.text._ZN5boost16exception_detail10clone_implINS0_19error_info_injectorISt8bad_castEEEC1ERKS4_[_ZN5boost16exception_detail10clone_implINS0_19error_info_injectorISt8bad_castEEEC1ERKS4_]+0x14): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZTVSt8bad_cast@@GLIBCXX_3.4'
/usr/bin/ld: final link failed: Bad value

Effects monero-project/kovri#438: OSX 10.10, Ubuntu i686, ARMv7, FreeBSD (#3).

The idea is to use makeself on a per-platform basis (currently, we'll need to use msys2 on windows) though this does not substitute real packaging (and windows users will eventually not be be expected to have msys2 installed).

Once cloned, we'd run something like this with buildbot:

./makeself.sh ~/kovri-install ~/kovri-install.sh "Kovri Static Nightly Installer" ./install.sh  # preferably, the title will be appended with git revision hash

Where ~/kovri-install has all contents of kovri/pkg, the binary kovri/build/kovri, and custom install.sh (will PR). Currently, that looks something like this:

$ ls -lha
total 96M
drwxr-xr-x  4 4.0K Jan  1 16:36 client
drwxr-xr-x  2 4.0K Jan  1 16:36 config
-rwxr-xr-x  1 1.3K Jan  2 00:19 install.sh
-rwxr-xr-x  1 96M Jan  1 15:41 kovri

Once complete, kovri-install.sh will be a single self-installable executable that can easily be distributed.

Note: I'll have to adjust the kovri Makefile to build static with coverage (I should probably open a separate issue for that). PR is on the way for the install script.

I don't have privs so maybe we can pick a designated port or just give me firewall privs? I've left the firewall pop-up open on both instances for review.

Effects monero-project/kovri#431, build log here. A fix is currently in-progress, ticketing for housekeeping.

Location:

• Freenode | OFTC | Irc2P | Slack
  • #monero-dev

Time

Use the timezone converter or the image below.

Proposed meeting items:

1. Greetings
2. Brief review of what's been completed since the previous meeting
3. Code + ticket discussion / Q & A
4. GetMonero.org redesign discussion
5. Any additional meeting items
6. Confirm next meeting date/time

Notes:

• #kovri-dev and #monero-dev will be relayed to each other through the duration of the meeting.
• Meeting log will be posted to https://getmonero.org/blog/tags/dev%20diaries

Effects monero-project/kovri#431, build logs here and here. A fix is currently in-progress, ticketing for housekeeping.

Post json coverage data with the kovri repo token to coveralls as a buildstep in the kovri build factories on buildbot.

Is this possible? If this is implemented, then monero-project/kovri#513 shows otherwise. I think the filter works for .md/.asc/.conf files though. Can anyone confirm?

I setup a HackerOne account for kovri when we first started monero-project/kovri#225 but monero and monero's GUI does not have an account. Ideally, we would have a completed vulnerability response process and we would also raise FFS funds for a bug bounty pool.

We've had several kovri meetings about this in the past. I can fill in details if needed.

All-purpose Monero box, also for PR's and nightlies.