1 | <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. |
---|
2 | <cron2> even more vacation...! |
---|
3 | <novaflash> unfortunately more like i forget about an appointment with the accountant and got a reminder via email this morning (fortunately) |
---|
4 | <novaflash> fortunately unfortunately |
---|
5 | * becm (~Thunderbi@rtr.astos.de) has joined |
---|
6 | <glcox> fyi the wiki link is https://community.openvpn.net/openvpn/wiki/Topics-2024-01-09 but today's the 10th. |
---|
7 | <cron2> ah, so we missed the meeting |
---|
8 | * becm has quit (Quit: becm) |
---|
9 | * becm1 (~Thunderbi@rtr.astos.de) has joined |
---|
10 | * becm1 is now known as becm |
---|
11 | <novaflash> glcox; lol my bad |
---|
12 | * becm has quit (Quit: becm) |
---|
13 | <novaflash> fixed |
---|
14 | <novaflash> https://community.openvpn.net/openvpn/wiki/Topics-2024-01-10 |
---|
15 | <novaflash> that was a stupid brainfart on my part yesterday when i prepared it |
---|
16 | * becm (~Thunderbi@rtr.astos.de) has joined |
---|
17 | <rob0> Accountant? Oh no! That sounds serious! |
---|
18 | <cron2> who knows what sort of role playing they will do |
---|
19 | <rob0> oh I can guess that some euros will change hands, and likely none going to novaflash |
---|
20 | <rob0> we've seen a demonstration of novaflash accounting: he put 09 when it should have been 10 |
---|
21 | <cron2> yeah, maybe that accountant can help with getting numbers right |
---|
22 | <cron2> (or "the way they are most useful") |
---|
23 | * uddr35 (~uddr35@91.214.209.137) has joined |
---|
24 | <rob0> novaflash, being absent, will want someone to run the meeting. cron2? |
---|
25 | * cron2 votes for rob0 |
---|
26 | <cron2> anyway, let's start |
---|
27 | * cron2 honks |
---|
28 | <mattock> hi |
---|
29 | <rob0> https://en.wikipedia.org/wiki/Linus_Torvalds |
---|
30 | <vpnHelper> Title: Linus Torvalds - Wikipedia (at en.wikipedia.org) |
---|
31 | <rob0> oops wrong paste |
---|
32 | <rob0> New: small security issue reported in OpenVPN GUI |
---|
33 | <uddr35> aloha |
---|
34 | <rob0> lev__, dazo, anything to report on this? |
---|
35 | <lev__> you mean with installer ? |
---|
36 | <lev__> yes, I am testing a fix |
---|
37 | <cron2> nice :-) |
---|
38 | <cron2> (strictly speaking it's not a security issue in the *GUI*. It's an installer issue, if installing into custom directories) |
---|
39 | <lev__> that issue has been for a while, and you explicitly need to install the app to another directory |
---|
40 | <rob0> (full disclosure, I am not on the security@ list.) |
---|
41 | <mattock> MSI installer? |
---|
42 | <lev__> mattock: yes |
---|
43 | <plaisthos> hey |
---|
44 | <lev__> not sure about NSIS but probably it was there too |
---|
45 | <cron2> likely |
---|
46 | <mattock> ok |
---|
47 | <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? |
---|
48 | <ordex> hi |
---|
49 | * cron2 has changed the topic to: https://community.openvpn.net/openvpn/wiki/Topics-2024-01-10 |
---|
50 | <lev__> since this is installer-only fix, we can just do I002 later if we must hurry with 2.6.9 |
---|
51 | <cron2> we have no hurry, I just try to plan when I need to do something |
---|
52 | <cron2> so, if you say 2 weeks, fine with me |
---|
53 | <cron2> so, regarding 2.6.9 - we do have one thing missing, and that's --tls-export-cert |
---|
54 | <rob0> The --tls-export-cert PR needs a little love first :) |
---|
55 | <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 |
---|
56 | <plaisthos> is that was the old implementation did? |
---|
57 | <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" |
---|
58 | <cron2> plaisthos: yes |
---|
59 | <plaisthos> because peer_cert feels like it should be only level 0 |
---|
60 | <cron2> plaisthos: this is what had me confused as well, not understanding that verify_cert_call_command() is actually called "for each verification level" |
---|
61 | <cron2> so the old code exported the cert for each level, setting $peer_cert accordingly, on all levels |
---|
62 | <cron2> ("one cert file per openvpn_run_script() call") |
---|
63 | <plaisthos> okay, terrible naming of the variable then |
---|
64 | <cron2> right |
---|
65 | <djpig> hi. sorry, was deep in NTLM protocol |
---|
66 | <rob0> well, this needs to move on. Seems safe to say 2.6.9 is not ready yet. |
---|
67 | <mattock> hi djpig! |
---|
68 | <cron2> rob0: yep, but progressing, and we aim for +2 weeks |
---|
69 | <cron2> (jan 24) |
---|
70 | <rob0> ++ |
---|
71 | <rob0> moving on, mattock needs things to do! |
---|
72 | <mattock> yes! |
---|
73 | <rob0> any opinions on TracWiki replacements? |
---|
74 | <mattock> regarding wiki alternatives which we discussed in the last meeting: I reviewed a big bunch of them |
---|
75 | <mattock> a few stood out as potential replacements given the requirements (self-hosted option, open source, etc) |
---|
76 | <mattock> wiki.js, xwiki and mediawiki |
---|
77 | <mattock> plus a bunch of other that we could also consider |
---|
78 | <mattock> almost everything seems to support LDAP auth (if we go that route) |
---|
79 | <mattock> spam protections tends to be non-existant/poor in most |
---|
80 | <mattock> many wikis seem to rely on akismet (a SaaS) service for spam protection |
---|
81 | <mattock> if we only allow trusted people to post to the wiki then that spam filter badness is a non-issue |
---|
82 | <cron2> my gut feeling says "the group of people that actually edit/post on the wiki is small, 10-ish or less" |
---|
83 | <mattock> I think that is correct |
---|
84 | <rob0> yep. Limited posting is not really a problem. |
---|
85 | <cron2> so we could go for "needs to be given permission, by asking friendly" |
---|
86 | <mattock> I would probably lean towards _testing_ wiki.js (seems very modern and modular) and xwiki (think open source confluence) |
---|
87 | <mattock> and picking one of those, if they seem fit |
---|
88 | <plaisthos> knowing confluence I am not sure "open source confluence" is a good thing %) |
---|
89 | <rob0> haha |
---|
90 | <mattock> I think Confluence is pretty ok, that is, much less worse than JIRA :joy: |
---|
91 | <cron2> we do use confluence @corp, and it has lots of nice editing features that I sorely missin trac or gitlab wiki |
---|
92 | <mattock> :) |
---|
93 | <cron2> things like "I want a table here, and see what I'm editing" is soooo annyoing in pure-markdown wikis |
---|
94 | <cron2> but I can propably live with whatever comes out |
---|
95 | <mattock> yeah, tables are a PITA |
---|
96 | <mattock> anyhow, I could set up wiki.js and xwiki, give some accounts and you could test them out yourself |
---|
97 | <cron2> +1 |
---|
98 | <mattock> neither of them should be a big deal to spin up |
---|
99 | <cron2> is there a way to export trac / import to $thingwiki? |
---|
100 | <mattock> Trac does support exporting wiki pages, but those pages probably need to be converted |
---|
101 | <mattock> with some luck there might be a markdown converter or something, but I have not checked |
---|
102 | <mattock> alternatively some crappy script could be crafted and the inevitably partially broken results could be fixed manually |
---|
103 | <mattock> anyhow, so I'll spin them up and we take it from there |
---|
104 | <uddr35> with conversion AI might help |
---|
105 | <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 |
---|
106 | <mattock> uddr35: yeah, good point, it actually might be useful here |
---|
107 | <mattock> ordex: also a good point |
---|
108 | <cron2> ordex: good point |
---|
109 | <ordex> we may end up porting only a fraction of the wiki |
---|
110 | <rob0> ordex++ I was going to suggest that as well |
---|
111 | <ordex> with OTF we have planned to onboard a copywriter, so this task may fit this role |
---|
112 | <ordex> althoough, guidance is required because *we* know what is obsolete and what not |
---|
113 | <ordex> still a strategy we coud pursue |
---|
114 | <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) |
---|
115 | <mattock> anything else on wikis? |
---|
116 | * cron2 likes how ordex says "pursue" now that moneyz have showed up |
---|
117 | <ordex> :-D |
---|
118 | <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 :) |
---|
119 | <mattock> so that I don't run out of work too badly :) |
---|
120 | <cron2> the server-side testing needs more thought, and maybe a dedicated meeting with brains & coffee |
---|
121 | <ordex> ay |
---|
122 | <cron2> for buildbot, my main grief these days is getting spammed |
---|
123 | <ordex> should we arrange a meeting for the server-side testing? |
---|
124 | <mattock> valid spam as in "build failures"? |
---|
125 | <cron2> like, d12fk pushing windows improvements to gerrit, and I'm receiving 430 mails because all non-windows platforms fail compilation now |
---|
126 | <djpig> yes |
---|
127 | <cron2> mattock: yes |
---|
128 | <mattock> ok |
---|
129 | * 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) |
---|
130 | <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 |
---|
131 | <ordex> agreed |
---|
132 | <ordex> ctrl+a, shift+del |
---|
133 | <mattock> actually sending to the submitter would discourage commits that break too much stuff |
---|
134 | <ordex> isn't possible to send an aggregated email? |
---|
135 | <cron2> but even then, 400+ mails are not "more useful" than 10 |
---|
136 | <mattock> not sure if aggregated reports are possible out of the box |
---|
137 | <plaisthos> mattock: sometimes you just overlook something |
---|
138 | <mattock> buildbot is very extensible and modular, so "anything can be done" probably |
---|
139 | <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" |
---|
140 | <mattock> plaisthos: yeah, of course |
---|
141 | <cron2> we've had both variants of "all <x>" failures |
---|
142 | <djpig> my idea was to look at https://docs.buildbot.net/latest/manual/configuration/services/failing_buildset_canceller.html |
---|
143 | <vpnHelper> Title: 2.5.18.1. FailingBuildsetCanceller — Buildbot latest documentation (at docs.buildbot.net) |
---|
144 | <djpig> bit didn't get around to that yet |
---|
145 | <cron2> plaisthos: I'm not really grumbling at you or d12fk for spamming me :-) - but trying to improve the usefulness-to-noise ratio |
---|
146 | * cron2 had his share of explosions |
---|
147 | <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 |
---|
148 | <cron2> a summary would certainly be a nice addition, but I do value the individual mails coming in quickly, like "before everything is finished" |
---|
149 | <mattock> failing_buildset_canceller looks promising, assuming we can configure it in a reasonable way |
---|
150 | <cron2> "all in one mail" would mean "wait 3 hours" |
---|
151 | <cron2> mattock: sounds good |
---|
152 | <mattock> I can do some experimentation with it |
---|
153 | <mattock> it will keep me busy for a while |
---|
154 | <ordex> cron2: got it |
---|
155 | <mattock> I can also see how possible it would be to get a summary build report |
---|
156 | <cron2> + send mails to the gerrit submitter, maybe limited to a few handful |
---|
157 | * becm has quit (Quit: becm) |
---|
158 | * becm (~Thunderbi@rtr.astos.de) has joined |
---|
159 | <mattock> do the "big explosions" typically originate from Gerrit? I recall seeing both GitPoller and GerritPoller in the latest buildbot configuration |
---|
160 | <cron2> the current flow of things is "people push new features to gerrit, gerrit triggers buildbot, things explode" |
---|
161 | <mattock> ok |
---|
162 | <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 |
---|
163 | <mattock> ok |
---|
164 | <uddr35> with gerrit there is a way to push in WIP mode which wont trigger the buildbot |
---|
165 | <mattock> would it make sense to cancel other builds if the "normal" builds (i.e. without any special configure flags) fail? |
---|
166 | <cron2> mattock: yes |
---|
167 | <cron2> "if the default config already breaks, not much use in progressing" |
---|
168 | <uddr35> @mattlock yes |
---|
169 | <mattock> cron2: ok, that could be part of the logic in cancelling the builds (or notifications) |
---|
170 | <cron2> (but this should be "configure + build", if t_client fails, go on, that could be spurious or not) |
---|
171 | <mattock> cron2: yes, makes sense |
---|
172 | <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 |
---|
173 | <ordex> in that case the pain is deserved |
---|
174 | <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 |
---|
175 | <mattock> like a first smoketest -> if it fails all is assumed broken |
---|
176 | <djpig> uddr35: the builds are useful, so WIP doesn't really help. It is more about making it not painful |
---|
177 | <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 |
---|
178 | <djpig> mattock: buildbot has no Windows builds right now |
---|
179 | <mattock> djpig: oh that's nice :) |
---|
180 | <cron2> so I don't think a "canary build" is very useful |
---|
181 | <mattock> those were a PITA anyways |
---|
182 | <djpig> Windows builds are only in Github |
---|
183 | <mattock> ok |
---|
184 | <cron2> djpig: maybe we want them back? at least mingw? |
---|
185 | <mattock> let's keep those in GitHub - managing the Windows build images was _so_ tedious and error-prone |
---|
186 | <cron2> so when you push something to gerrit that breaks *windows*, we wouldn't know today |
---|
187 | <mattock> the mingw part was not that bad - it was very reliable |
---|
188 | <ordex> yap, I think mingw would be nice |
---|
189 | <uddr35> what if we can use some labels? to run only some part which needs to be tested |
---|
190 | <uddr35> and after whole builds when the feature is ready? |
---|
191 | <cron2> uddr35: this doesn't work, because our crystal balls are too bad... |
---|
192 | <cron2> like, d12fk pushing a "windows only" change, which happened to have a "static" in it which broke all non-windows plattforms |
---|
193 | <cron2> so, having the label "windows" would have hidden that breakage |
---|
194 | <cron2> and you never know when a feature is "ready"... |
---|
195 | <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 |
---|
196 | <cron2> (but we could certainly try this, if a developer knows "this is not really ready, but I want quick feedback") |
---|
197 | <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 |
---|
198 | <uddr35> yeah, sometimes developer might want to do a quick checks on something specific |
---|
199 | <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 |
---|
200 | <cron2> maybe labels is really a good idea ("label: doc" would only run .rst sanity checks, no code...) |
---|
201 | <uddr35> @mattock yeah, great idea |
---|
202 | <mattock> ok. labels - I have no recollection about those in buildbot |
---|
203 | <mattock> djpig: is there documentation about CMake + mingw? |
---|
204 | <mattock> as in "what commands to run" etc |
---|
205 | <novaflash> you guys still going? |
---|
206 | <mattock> looks like it |
---|
207 | <cron2> I need coffee :-) |
---|
208 | <novaflash> i thought i kept the meetings going on for too long sometimes |
---|
209 | <mattock> anyhow, this is enough to keep me occupied for some time, thanks! :) |
---|
210 | <mattock> any topics _and_ time _and_ energy to go on? :) |
---|
211 | <novaflash> i feel like i could just the meeting now |
---|
212 | <novaflash> start |
---|
213 | <novaflash> oops |
---|
214 | <novaflash> hope somebody took notes lol |
---|
215 | <ordex> novaflash: we are typing it all, as you can see |
---|
216 | <novaflash> pfff |
---|
217 | <novaflash> ok copypaste and to mailing list it is haha |
---|
218 | <ordex> :D I think rob0 volunteered |
---|
219 | <djpig> mattock: https://github.com/OpenVPN/openvpn/blob/master/README.cmake.md Or just check the GHA code |
---|
220 | <novaflash> but i feel this meeting boils down to, mattock wants things to do, blah blah blah, mattock has things to do |
---|
221 | <mattock> djpig: thanks! |
---|
222 | <mattock> that part worked as intended, yes :) |
---|
223 | <novaflash> :) |
---|
224 | <mattock> the meeting has faded away probably? |
---|
225 | <rob0> ordex, voluntold! |
---|
226 | <ordex> u.u |
---|
227 | * becm has quit (Quit: becm) |
---|
228 | * becm1 (~Thunderbi@rtr.astos.de) has joined |
---|
229 | * becm1 is now known as becm |
---|
230 | <ordex> mattock: we all did |
---|
231 | <ordex> :" |
---|
232 | <mattock> yep |
---|
233 | <novaflash> you need to say that magic words; |
---|
234 | <novaflash> meeting over |
---|
235 | <novaflash> otherwise people's brains get stuck |
---|
236 | <cron2> what, meeting over? |
---|
237 | <ordex> hamsters still circling |
---|
238 | <mattock> damn, I managed to create seven tickets for myself |
---|
239 | <mattock> I need to start avoiding work soon :) |
---|
240 | <uddr35> avoiding work - that sounds like a not a human thing )) |
---|
241 | <rob0> meeting over |
---|
242 | <uddr35> gosh so many meeting already over) |
---|
243 | <uddr35> gosh so many meetings already over) |
---|
244 | <novaflash> what, meeting over? |
---|
245 | <rob0> sorry, an accountant's bill caused a 50% overage today. |
---|
246 | <ordex> meeting over! |
---|