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