IrcMeetings: irclog_2024-01-10.txt

<novaflash> i unexpectedly won't be able to attend the meeting today. but the topics are up for today on the community wiki. if someone else can take notes that would be great. i don't care what format you take notes in, i can always format it afterwards and send out the summary notes later today.
<cron2> even more vacation...!
<novaflash> unfortunately more like i forget about an appointment with the accountant and got a reminder via email this morning (fortunately)
<novaflash> fortunately unfortunately
* becm (~Thunderbi@rtr.astos.de) has joined
<glcox> fyi the wiki link is https://community.openvpn.net/openvpn/wiki/Topics-2024-01-09 but today's the 10th.
<cron2> ah, so we missed the meeting
* becm has quit (Quit: becm)
* becm1 (~Thunderbi@rtr.astos.de) has joined
* becm1 is now known as becm
<novaflash> glcox; lol my bad
* becm has quit (Quit: becm)
<novaflash> fixed
<novaflash> https://community.openvpn.net/openvpn/wiki/Topics-2024-01-10
<novaflash> that was a stupid brainfart on my part yesterday when i prepared it
* becm (~Thunderbi@rtr.astos.de) has joined
<rob0> Accountant? Oh no! That sounds serious!
<cron2> who knows what sort of role playing they will do
<rob0> oh I can guess that some euros will change hands, and likely none going to novaflash
<rob0> we've seen a demonstration of novaflash accounting: he put 09 when it should have been 10
<cron2> yeah, maybe that accountant can help with getting numbers right
<cron2> (or "the way they are most useful")
* uddr35 (~uddr35@91.214.209.137) has joined
<rob0> novaflash, being absent, will want someone to run the meeting. cron2?
* cron2 votes for rob0
<cron2> anyway, let's start
* cron2 honks
<mattock> hi
<rob0> https://en.wikipedia.org/wiki/Linus_Torvalds
<vpnHelper> Title: Linus Torvalds - Wikipedia (at en.wikipedia.org)
<rob0> oops wrong paste
<rob0> New: small security issue reported in OpenVPN GUI
<uddr35> aloha
<rob0> lev__, dazo, anything to report on this?
<lev__> you mean with installer ? 
<lev__> yes, I am testing a fix
<cron2> nice :-)
<cron2> (strictly speaking it's not a security issue in the *GUI*.  It's an installer issue, if installing into custom directories)
<lev__> that issue has been for a while, and you explicitly need to install the app to another directory
<rob0> (full disclosure, I am not on the security@ list.)
<mattock> MSI installer?
<lev__> mattock: yes
<plaisthos> hey
<lev__> not sure about NSIS but probably it was there too
<cron2> likely
<mattock> ok
<cron2> so what's the timeline here?  We do have a 2.6.9 pending, but that is not "immediately urgent" - so if we can have CVE and fix next week, we can do 2.6.9 with the fix?
<ordex> hi
* cron2 has changed the topic to: https://community.openvpn.net/openvpn/wiki/Topics-2024-01-10
<lev__> since this is installer-only fix, we can just do I002 later if we must hurry with 2.6.9
<cron2> we have no hurry, I just try to plan when I need to do something
<cron2> so, if you say 2 weeks, fine with me
<cron2> so, regarding 2.6.9 - we do have one thing missing, and that's --tls-export-cert
<rob0> The --tls-export-cert PR needs a little love first :)
<cron2> the current patch in gerrit has been tested and works, but I suggest a change, namely dropping the _0, _1, _2 environment variables and always using $peer_cert
<plaisthos> is that was the old implementation did?
<cron2> and I also suggest dropping the two followup patches that add "export of multiple cert files at the same time", because it's a fairly complex change to the env stuff, and "nobody has asked for this feature yet"
<cron2> plaisthos: yes
<plaisthos> because peer_cert feels like it should be only level 0
<cron2> plaisthos: this is what had me confused as well, not understanding that verify_cert_call_command() is actually called "for each verification level"
<cron2> so the old code exported the cert for each level, setting $peer_cert accordingly, on all levels
<cron2> ("one cert file per openvpn_run_script() call")
<plaisthos> okay, terrible naming of the variable then
<cron2> right
<djpig> hi. sorry, was deep in NTLM protocol
<rob0> well, this needs to move on. Seems safe to say 2.6.9 is not ready yet.
<mattock> hi djpig!
<cron2> rob0: yep, but progressing, and we aim for +2 weeks
<cron2> (jan 24)
<rob0> ++
<rob0> moving on, mattock needs things to do!
<mattock> yes!
<rob0> any opinions on TracWiki replacements?
<mattock> regarding wiki alternatives which we discussed in the last meeting: I reviewed a big bunch of them
<mattock> a few stood out as potential replacements given the requirements (self-hosted option, open source, etc)
<mattock> wiki.js, xwiki and mediawiki
<mattock> plus a bunch of other that we could also consider
<mattock> almost everything seems to support LDAP auth (if we go that route)
<mattock> spam protections tends to be non-existant/poor in most
<mattock> many wikis seem to rely on akismet (a SaaS) service for spam protection
<mattock> if we only allow trusted people to post to the wiki then that spam filter badness is a non-issue
<cron2> my gut feeling says "the group of people that actually edit/post on the wiki is small, 10-ish or less"
<mattock> I think that is correct
<rob0> yep. Limited posting is not really a problem.
<cron2> so we could go for "needs to be given permission, by asking friendly"
<mattock> I would probably lean towards _testing_ wiki.js (seems very modern and modular) and xwiki (think open source confluence)
<mattock> and picking one of those, if they seem fit
<plaisthos> knowing confluence I am not sure "open source confluence" is a good thing %)
<rob0> haha
<mattock> I think Confluence is pretty ok, that is, much less worse than JIRA :joy:
<cron2> we do use confluence @corp, and it has lots of nice editing features that I sorely missin trac or gitlab wiki
<mattock> :)
<cron2> things like "I want a table here, and see what I'm editing" is soooo annyoing in pure-markdown wikis
<cron2> but I can propably live with whatever comes out
<mattock> yeah, tables are a PITA
<mattock> anyhow, I could set up wiki.js and xwiki, give some accounts and you could test them out yourself
<cron2> +1
<mattock> neither of them should be a big deal to spin up
<cron2> is there a way to export trac / import to $thingwiki?
<mattock> Trac does support exporting wiki pages, but those pages probably need to be converted
<mattock> with some luck there might be a markdown converter or something, but I have not checked
<mattock> alternatively some crappy script could be crafted and the inevitably partially broken results could be fixed manually
<mattock> anyhow, so I'll spin them up and we take it from there
<uddr35> with conversion AI might help
<ordex> we can also have somebody tasked with reviewing the pages and decide what to port and what not, since a lot of docs are obsolete/broken anyhow
<mattock> uddr35: yeah, good point, it actually might be useful here
<mattock> ordex: also a good point
<cron2> ordex: good point
<ordex> we may end up porting only a fraction of the wiki
<rob0> ordex++ I was going to suggest that as well
<ordex> with OTF we have planned to onboard a copywriter, so this task may fit this role
<ordex> althoough, guidance is required because *we* know what is obsolete and what not
<ordex> still a strategy we coud pursue
<mattock> ok, so spin up test instances, review current wiki content for relevant/obsolete stuff, test using AI for wiki page conversion (public anyways, so feeding to ChatGPT/Azure OpenAI is fine)
<mattock> anything else on wikis?
* cron2 likes how ordex says "pursue" now that moneyz have showed up
<ordex> :-D
<mattock> it is because of the money (i.e. weekly working quotas) that I also need some suggestions regarding server-side testing improvement and/or buildbot improvements :)
<mattock> so that I don't run out of work too badly :)
<cron2> the server-side testing needs more thought, and maybe a dedicated meeting with brains & coffee
<ordex> ay
<cron2> for buildbot, my main grief these days is getting spammed
<ordex> should we arrange a meeting for the server-side testing?
<mattock> valid spam as in "build failures"?
<cron2> like, d12fk pushing windows improvements to gerrit, and I'm receiving 430 mails because all non-windows platforms fail compilation now
<djpig> yes
<cron2> mattock: yes
<mattock> ok
* cron2 doesn't mind "a few mails", but 400+ coming in over 2-3 hours are really annoying (because it's not like "ah, failure, delete" but they keep coming)
<cron2> so we need to cut-off builds if we see "it fails on too many builds already", I think, and we should send the mails to the submitter as well
<ordex> agreed
<ordex> ctrl+a, shift+del
<mattock> actually sending to the submitter would discourage commits that break too much stuff
<ordex> isn't possible to send an aggregated email?
<cron2> but even then, 400+ mails are not "more useful" than 10
<mattock> not sure if aggregated reports are possible out of the box
<plaisthos> mattock: sometimes you just overlook something
<mattock> buildbot is very extensible and modular, so "anything can be done" probably
<cron2> I actually do like individual mails for each build, so I can skim over "ah, this is all netbsd" or "ah, this is all mbedtls, on $allunix"
<mattock> plaisthos: yeah, of course
<cron2> we've had both variants of "all <x>" failures
<djpig> my idea was to look at https://docs.buildbot.net/latest/manual/configuration/services/failing_buildset_canceller.html
<vpnHelper> Title: 2.5.18.1. FailingBuildsetCanceller — Buildbot latest documentation (at docs.buildbot.net)
<djpig> bit didn't get around to that yet
<cron2> plaisthos: I'm not really grumbling at you or d12fk for spamming me :-) - but trying to improve the usefulness-to-noise ratio
* cron2 had his share of explosions
<ordex> cron2: if you get an email with a list of failures, I think it'd be as useful as reading the subjects of all the individual emails
<cron2> a summary would certainly be a nice addition, but I do value the individual mails coming in quickly, like "before everything is finished"
<mattock> failing_buildset_canceller looks promising, assuming we can configure it in a reasonable way
<cron2> "all in one mail" would mean "wait 3 hours"
<cron2> mattock: sounds good
<mattock> I can do some experimentation with it
<mattock> it will keep me busy for a while
<ordex> cron2: got it
<mattock> I can also see how possible it would be to get a summary build report
<cron2> + send mails to the gerrit submitter, maybe limited to a few handful
* becm has quit (Quit: becm)
* becm (~Thunderbi@rtr.astos.de) has joined
<mattock> do the "big explosions" typically originate from Gerrit? I recall seeing both GitPoller and GerritPoller in the latest buildbot configuration
<cron2> the current flow of things is "people push new features to gerrit, gerrit triggers buildbot, things explode"
<mattock> ok
<cron2> I do push to the "mattock" repo directly, but usually at this point the code will not break "everything" but maybe just one or two builds
<mattock> ok
<uddr35> with gerrit there is a way to push in WIP mode which wont trigger the buildbot
<mattock> would it make sense to cancel other builds if the "normal" builds (i.e. without any special configure flags) fail?
<cron2> mattock: yes
<cron2> "if the default config already breaks, not much use in progressing"
<uddr35> @mattlock yes
<mattock> cron2: ok, that could be part of the logic in cancelling the builds (or notifications)
<cron2> (but this should be "configure + build", if t_client fails, go on, that could be spurious or not)
<mattock> cron2: yes, makes sense
<cron2> so we might have explosions where the code compile but 400 "make check" break due to SIGSEGV'ing t_lpback ("been there...") - but that is not as likely
<ordex> in that case the pain is deserved
<mattock> is there a clear split between "unix-type OS" and "Windows" here? if yes, perhaps a "tripwire build" on "some Linux/BSD" should pass or else we cancel everything else
<mattock> like a first smoketest -> if it fails all is assumed broken
<djpig> uddr35: the builds are useful, so WIP doesn't really help. It is more about making it not painful
<cron2> mattock: ah, well, we have a myriard of linux builders these days, so "one linux fails" could mean "all linuxes fail", but maybe it's just that particular distro
<djpig> mattock: buildbot has no Windows builds right now
<mattock> djpig: oh that's nice :)
<cron2> so I don't think a "canary build" is very useful
<mattock> those were a PITA anyways
<djpig> Windows builds are only in Github
<mattock> ok
<cron2> djpig: maybe we want them back?  at least mingw?
<mattock> let's keep those in GitHub - managing the Windows build images was _so_ tedious and error-prone
<cron2> so when you push something to gerrit that breaks *windows*, we wouldn't know today
<mattock> the mingw part was not that bad - it was very reliable
<ordex> yap, I think mingw would be nice
<uddr35> what if we can use some labels? to run only some part which needs to be tested
<uddr35> and after whole builds when the feature is ready?
<cron2> uddr35: this doesn't work, because our crystal balls are too bad...
<cron2> like, d12fk pushing a "windows only" change, which happened to have a "static" in it which broke all non-windows plattforms
<cron2> so, having the label "windows" would have hidden that breakage
<cron2> and you never know when a feature is "ready"...
<mattock> buildbot setup we have now is easy to reproduce with different configurations (I did it about five times yesterday myself), so if we want, we can have a separate buildbot instance for Gerrit that does not have all the builders in the world
<cron2> (but we could certainly try this, if a developer knows "this is not really ready, but I want quick feedback")
<cron2> mattock: actually we do want all the builders in the world before I merge something and *then* it all breaks :-) - but a slightly more efficient handling of "all" might be good
<uddr35> yeah, sometimes developer might want to do a quick checks on something specific
<djpig> yeah, no problem with adding mingw builds in buildbot. Now that the mingw build is pretty trivial with CMake this should be no problem
<cron2> maybe labels is really a good idea ("label: doc" would only run .rst sanity checks, no code...)
<uddr35> @mattock yeah, great idea
<mattock> ok. labels - I have no recollection about those in buildbot
<mattock> djpig: is there documentation about CMake + mingw?
<mattock> as in "what commands to run" etc
<novaflash> you guys still going?
<mattock> looks like it
<cron2> I need coffee :-)
<novaflash> i thought i kept the meetings going on for too long sometimes
<mattock> anyhow, this is enough to keep me occupied for some time, thanks! :)
<mattock> any topics _and_ time _and_ energy to go on? :)
<novaflash> i feel like i could just the meeting now
<novaflash> start
<novaflash> oops
<novaflash> hope somebody took notes lol
<ordex> novaflash: we are typing it all, as you can see
<novaflash> pfff
<novaflash> ok copypaste and to mailing list it is haha
<ordex> :D I think rob0 volunteered
<djpig> mattock: https://github.com/OpenVPN/openvpn/blob/master/README.cmake.md Or just check the GHA code
<novaflash> but i feel this meeting boils down to, mattock wants things to do, blah blah blah, mattock has things to do
<mattock> djpig: thanks!
<mattock> that part worked as intended, yes :)
<novaflash> :)
<mattock> the meeting has faded away probably?
<rob0> ordex, voluntold!
<ordex> u.u
* becm has quit (Quit: becm)
* becm1 (~Thunderbi@rtr.astos.de) has joined
* becm1 is now known as becm
<ordex> mattock: we all did
<ordex> :"
<mattock> yep
<novaflash> you need to say that magic words;
<novaflash> meeting over
<novaflash> otherwise people's brains get stuck
<cron2> what, meeting over?
<ordex> hamsters still circling
<mattock> damn, I managed to create seven tickets for myself
<mattock> I need to start avoiding work soon :)
<uddr35> avoiding work - that sounds like a not a human thing ))
<rob0> meeting over
<uddr35> gosh so many meeting already over)
<uddr35> gosh so many meetings already over)
<novaflash> what, meeting over?
<rob0> sorry, an accountant's bill caused a 50% overage today.
<ordex> meeting over!