**** BEGIN LOGGING AT Tue Jan 14 03:00:09 2020 Jan 14 07:19:25 rmilecki: can you give me your Reviewed-by for https://patchwork.ozlabs.org/patch/1217561/ (fstools: Add support to read-only MTD partitions (eg. recovery images)) and related kernel part https://github.com/openwrt/openwrt/pull/2535 (sent upstream as well), thanks! Jan 14 07:42:55 hmm... https://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=64f4eb79fe2977320660f8940bc908fa4def807b Jan 14 07:43:08 I have the feeling that this is not going to work and that it breaks DNS Jan 14 07:43:21 at least I see no code somewhere that actually creates the required directory Jan 14 07:44:01 ah, it happens in /etc/init.d/boot/ Jan 14 07:44:31 I'm running r11956-35ba9304c6, while I only noticed it passing by (updating my externally backed up configs), DNS is working Jan 14 07:44:43 yeah I overlooked a related commit Jan 14 07:45:06 still it feels not ideal to make netifd use a default that will not work when netifd is used on its own Jan 14 07:46:19 yep Jan 14 08:05:12 oh cute... an automake error Jan 14 08:05:16 haven't seen those in ages Jan 14 08:09:28 and I wonder whats up with ncurses... it keeps rebuilding every time here Jan 14 08:20:20 any idea why this doesn't work https://lxr.openwrt.org/ident?i=sprintf ? Jan 14 08:21:21 s/Not used/Shouldn't be used/ ? :-) Jan 14 08:21:46 lxr only indexes functions which are declared by the source code it scans Jan 14 08:21:56 ahh, makes sense Jan 14 08:22:02 sprintf is externally provided by musl Jan 14 08:22:13 I could add it to lxr... Jan 14 08:22:24 not sure how much sense it makes though Jan 14 08:22:33 I was just wondering Jan 14 08:22:53 I'll somehow bend ctags or such Jan 14 08:23:21 hm, just stumbled over this again Jan 14 08:23:31 ip/tc etc. depend on libcap when it is available Jan 14 08:23:39 libcap however is part of the external feeds Jan 14 08:35:47 build #83 of ramips/rt305x is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt305x/builds/83 blamelist: Petr ?tetiar Jan 14 08:35:55 build #238 of omap/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/238 blamelist: Petr ?tetiar , Florian Eckert , Hauke Mehrtens Jan 14 08:40:17 git is farting :) Jan 14 08:46:54 I honestly have no idea how to solve these intermittent Git timeouts Jan 14 08:47:09 I suppose the instance needs some resource increase Jan 14 08:48:23 maybe add some monitoring and see what is happening on the system when this issues occur? Jan 14 08:51:05 I tried... it seems to correlate with high load which is not tied to any specific process Jan 14 08:51:15 so likely caused by disk io bottlenecks Jan 14 08:54:06 ok, I'll try to finish "BPF Performance Tools" and look at it, unless someone else beats me to it Jan 14 09:45:00 morning Jan 14 09:45:44 is anyone else seeing recursive dependency warnings about vpnbypass or is it just me ? Jan 14 09:47:30 yes http://buildbot.openwrt.org/master/images/builders/bcm53xx%2Fgeneric/builds/209/steps/defconfig/logs/stdio Jan 14 09:48:05 yes = it's not just you, other fellow bots see it as well Jan 14 09:51:15 *yawn* Jan 14 09:51:46 it's almost lunch! Jan 14 09:52:19 been awake for a while Jan 14 09:52:37 i pulled chunkeys tree and started bumping targets to v5.4 Jan 14 09:52:58 weeeee Jan 14 09:54:22 the 4.14 targets or the 4.19 targets? Jan 14 09:54:48 good point :) Jan 14 09:55:07 is that a real or an implying question ? Jan 14 09:56:31 I don't understand the question.... a personal preference is that I'd like to see the end of 4.14 (for purely selfish reasons) Jan 14 09:58:22 the purely selfish reason is that the out of tree cake module can be got rid of :-) Jan 14 09:59:39 well, the list of targets still stuck at 4.14 is long, puting aside the minor targets probably nobody uses/cares about, but what about ramips (there is 4.19 PR pending on GH) and mediatek? are we going to drop them? :] Jan 14 10:00:12 ynezz: i am bumping ramips to 5.4 right now Jan 14 10:00:14 layerscape bump to 4.19 probably needs just poking at NXP, I can handle that Jan 14 10:00:17 what GH pr do you mean ? Jan 14 10:00:27 ynezz: already pinged NXP Jan 14 10:00:35 ah, so we're skipping 4.19? Jan 14 10:00:36 they will provide 5.4 int the comiing weeks Jan 14 10:00:41 same as MTK Jan 14 10:00:47 ok, nice Jan 14 10:01:04 ipq40xx is already building a tree for bumpage on the server Jan 14 10:01:15 and i poked qca about some register info so we can upstream more patches Jan 14 10:01:31 cool Jan 14 10:01:41 which ramips PR did you mean ? Jan 14 10:01:56 https://github.com/openwrt/openwrt/pull/2385/ Jan 14 10:03:42 neheb PR Jan 14 10:03:53 dengqf6's Jan 14 10:04:01 the problem is its too much Jan 14 10:04:13 bump what you have, get it stable then start switching drivers around Jan 14 10:04:34 and i would vote to drop nand/sdhci down stream, upstream works or there is no support till it works Jan 14 10:05:06 well, that's fine with me Jan 14 10:06:28 the thing is, that I gave it a go while merging the ipq80xx 4.19 support, but it didn't booted on my ubnt-erx (mt7621) and I wasn't in a mood to deep into that deeper and fix it Jan 14 10:08:18 blogic: oh, we can start bumping to 5.4 ? great Jan 14 10:08:37 wigyori: i was not aware of anything telling me not to do so Jan 14 10:09:00 wigyori: https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=summary using this as baseline right now Jan 14 10:09:36 so what about the kernel for next release, is it 4.19 or 5.4 ? Jan 14 10:09:58 I mean, are we really going to skip release with 4.19? Jan 14 10:10:09 dunno Jan 14 10:10:13 blogic: sweet, tanks Jan 14 10:10:16 thanks, even Jan 14 10:10:19 4.19 is eol 12/2020 Jan 14 10:10:38 so if we push a release say june then we have 6 months till its eol Jan 14 10:10:55 while 5.4 is eol 12/2022 and people are considering to make it super lts Jan 14 10:11:12 sounds like a nobrainer to me Jan 14 10:11:21 aka ciao 4.19 ;) Jan 14 10:14:12 to be fair, the v4.19 EOL date will be pushed further, at least until mid 2022 Jan 14 10:14:15 well, it's fine with me as well, hopefully it wont demotivate the others developers/users who put some effort into making 4.19 working Jan 14 10:15:00 (Debian 10 buster is based on 4.19, so they'll have to keep maintaining it - and Ben Hutchings has done that officially within the LTS framework for pervious Debian kernels as well) Jan 14 10:19:16 BTW that 4.19 for next release was mentioned several times by Hauke, here for example http://lists.infradead.org/pipermail/openwrt-devel/2018-November/014526.html Jan 14 10:19:30 The next release after 19.01 would be planned for the summer or fall Jan 14 10:19:30 2019, this release will be based on kernel 4.19, all targets have to be Jan 14 10:19:30 upgrade to kernel 4.19 by then. This release will probably not contain Jan 14 10:19:34 ar71xx any more, but only ath79 for these boards. Jan 14 10:20:21 so perhaps we can conclude, that 19.01 has slipped by a year, so that's why we're skipping 4.19 in favor of 5.4? Jan 14 10:21:22 but something has to be "announced" officialy, that the plans has changed, to avoid confusion, clanish behaviour :) Jan 14 10:23:54 just my two cents, I'm inside the clan, but sometimes still confused Jan 14 10:25:41 I agree with the reasoning and I think most users/developers will understand the reason. There is always a risk involved when working with moving targets, even if it was semi oficially announced that 4.19 would be the next kernel Jan 14 10:33:06 as +1, there would be a lot more stuff to backport into 4.19 if that'd be the base of trunk for some time and the next release Jan 14 10:42:53 ynezz: well the arguments are clear I guess. a) 19.07 slipped by several months, delaying the gneral schedule Jan 14 10:43:07 b) 4.19 will be EOL soon after 20.x is relased Jan 14 10:43:37 c) 5.4 is going to be the next extended LTS kernel and vendors are likely going to base their next years efforts on that Jan 14 10:43:38 and I think motivation is higher to work on newer LTS kernel rather than older? Jan 14 10:43:45 d) we'd be able to get rid of most backports Jan 14 10:44:03 or many at least Jan 14 10:44:15 new device support becomes simpler as well Jan 14 10:44:36 the question is: do you think it is realistic to aim for end of march / end of april as a branch date? Jan 14 10:45:22 it might be slightly over ambiguous, but it would probably be good to avoid another ~12 months release gap Jan 14 10:45:27 build #83 of zynq/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/zynq%2Fgeneric/builds/83 Jan 14 10:46:16 jow: theoretically stabilizing a number of targets on 5.4 is overly optimistic to schedule for april Jan 14 10:46:31 s/ambiguous/ambitious/ ;) Jan 14 10:47:04 well then lets do a march v4.19 branch and bump v5.4 in the background so we can aim for late autmn Jan 14 10:47:25 okay, I mean we could release 20.x in whatever state master happens to be then, but it'll be burnt, low quality release with little developer backing I guess Jan 14 10:47:31 so the question is whether it wil lbe worth it Jan 14 10:47:45 just skip the 4.19, don't waste resources on that Jan 14 10:47:51 ynezz: yep Jan 14 10:48:01 go to 5.4, bite the bullet and aim for a 9 month cycle Jan 14 10:48:02 staying closer to upstream should be prefered Jan 14 10:48:05 then 6 month after Jan 14 10:48:15 slowly get closer and that wont happen if we lag behind a lot Jan 14 10:48:25 ynezz: we can drop lots of patches for sure Jan 14 10:49:40 and it seems like the meeting is going to happen in the autumn as well, so we can branch it in the autumn as well Jan 14 10:49:59 or at least thats what I read between the lines :) Jan 14 10:50:02 okay, I think we should summarize this discussion here and put it on the developer list Jan 14 10:50:09 maybe conclude it with a vote Jan 14 10:50:16 I can do that tonight Jan 14 10:50:32 pls dont vote on technical directions :) Jan 14 10:50:51 people doing the work or willing the work should decide, thats my view Jan 14 10:51:05 but I can't prevent you from doing that :) Jan 14 10:51:15 Absolutely. Fine with me Jan 14 10:51:41 still I'd like to reassure that there's a consensus Jan 14 10:51:54 lets put a mail on -adm then Jan 14 10:52:08 right, that email is necessary, thanks for taking care of that Jan 14 10:52:23 that additional vote is not needed, but fine with me Jan 14 10:52:54 maybe delay the vote by 3 days? Jan 14 10:53:04 we can vote for the switch to 5.4 + new logo/colors Jan 14 10:53:46 I already have the final 4 variants, going to ask for feedback/voting on forum with a poll open for 3 days Jan 14 10:54:10 and maybe add the openwrt-announce@ list to that vote as well Jan 14 10:54:14 3 in 1, time saved Jan 14 10:54:21 what do you think? Jan 14 10:54:38 makes sense Jan 14 11:08:42 jow: can you pls close that previous logo topic? Jan 14 11:09:38 the refresh one? Jan 14 11:13:26 yes, I'm creating new one now Jan 14 11:13:37 cant close it by myself Jan 14 11:13:47 (or don't know how to) Jan 14 11:13:56 ah okay, can you give me the link of the new one? Jan 14 11:14:19 then I'll close and tell people to follow up there Jan 14 11:21:26 https://forum.openwrt.org/t/help-pre-select-new-openwrt-project-logo-in-the-poll/52674 Jan 14 11:22:29 thanks Jan 14 11:22:31 closed Jan 14 13:39:04 Makefile:531: *** target pattern contains no '%'. Stop. Jan 14 13:39:11 anyone seen this before ? Jan 14 13:39:58 yes Jan 14 13:40:04 enlighten me Jan 14 13:40:06 and it can basically mean anything Jan 14 13:40:19 I'd start looking for superfluous tabs Jan 14 13:40:53 do you have a diff? That would make it easier to figure out Jan 14 13:41:05 trunk ipq40xx Jan 14 13:41:17 vanilla? Jan 14 13:42:03 chunkeys tree Jan 14 13:42:08 let me revert a recent patch Jan 14 13:46:18 jow: Can you remove this directory from snapshots server: Jan 14 13:46:20 https://downloads.openwrt.org/snapshots/targets/mediatek/32/ Jan 14 13:46:39 it's 15 years old and has been renamed Jan 14 13:46:46 15->1.5 Jan 14 13:46:50 :D Jan 14 13:46:52 will do Jan 14 13:47:18 not urgent, just got aware of it Jan 14 13:48:57 done Jan 14 13:49:08 than Jan 14 13:49:14 thanks Jan 14 14:09:26 does anybody know if chunkeey is present here also? Jan 14 14:28:52 xback: he used to be, in the evenings, during weekend usually Jan 14 14:29:07 ynezz: any idea what is nickname is? Jan 14 14:29:41 lach1xxx some number or such Jan 14 14:29:58 ynezz: thnx Jan 14 14:30:11 what is it with people and different nicknames ¯\_(ツ)_/¯ Jan 14 14:31:25 lach1012 Jan 14 14:34:06 stintel: possibly influence from Reservoir Dogs, you know Mr. Blue & co. :p Jan 14 14:34:59 Who gave you that regdomain unlocker? Mr. Blue! Jan 14 15:23:19 fyi, 5.4 bumped to 5.4.11 in my staging Jan 14 15:25:37 xback: let me have a look Jan 14 15:25:47 xback: i bumped ath79, ramips and ipq40xx today Jan 14 15:25:58 about to start doing full builds to see what else breaks Jan 14 15:26:37 blogic: I also added some patches from chunkeey fixing some symbol stuff etc Jan 14 15:26:47 so my staging should be the latest reference at this moment Jan 14 15:29:23 xback: i will converge in that case Jan 14 15:29:36 xback: if i send you patches can you merge them ? Jan 14 15:29:43 so that we have everything in a single tree Jan 14 15:29:51 stuff si only compile tested right now Jan 14 15:29:56 blogic: for sure :-) Jan 14 15:30:27 as soon as a few targets work cleanly as expected, I would merge the work Jan 14 15:31:31 but that will take a few weeks more Jan 14 15:31:42 yup Jan 14 15:33:26 blogic: if you have patches, just put them in your tree and ping me. I'll do the merge and rebasing then to my staging Jan 14 15:34:36 great Jan 14 15:36:52 xback: you also did ath79 Jan 14 15:37:00 i'll drop mine and see if you did all the fixes i did Jan 14 15:37:57 blogic: that ath79 patchset is from blocktrron Jan 14 15:38:30 ok Jan 14 16:21:56 blogic: the ath79 patchset is completely untested Jan 14 16:22:18 I only made the patches apply, the color of the fireball still has to be examined Jan 14 16:23:11 * ldir wow, that was a bit of an outage - my internet borked for 4 hours Jan 14 16:31:00 ping jow - if you have a few minutes Jan 14 16:37:44 it's about trying to move forward on https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=shortlog;h=refs/heads/dropcake Jan 14 16:58:09 ldir: ah ... I totally paged that topic out of my head Jan 14 16:59:02 however as I see it you're basically swapping one kmod for another and the netlink api should be finalized, so it should'nt cause issues Jan 14 17:17:23 i love cake Jan 14 17:23:47 jow: apols for delay - yes I think getting to 'in kernel cake' with necessary backports of functionality from later kernel versions should they arise is a good idea(tm) Where it fell over is with the PROVIDES stuff for k4.14 - I created a 'cake out of tree' mod for that but found a flaw in the provides/dependency handling that you came up with a 'tweak' for Jan 14 17:24:37 I've had that tweak in my tree for a while.... but I don't know what it really does, so writing a proper commit description is a challenge :-) Jan 14 17:25:26 the OOT cake package (not quite in final form) is https://github.com/ldir-EDB0/packages/commit/22cb9666c216d6de8222ad7a22b2a92e9070dcb6 Jan 14 17:30:15 ldir: yeah I vaguely recall. The hack cannot be committed as-is, it was a very bad stop-gap measure to prevent package-metadata.pl from emitting wrong dependencies Jan 14 17:31:38 the problem goes away if we simply wait for k4.14 to fall out of the tree. Jan 14 17:33:20 but we don't even need the package for k4.19 or indeed k5.4. and it bugged me that https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=9f2b6de204aff8f42bee0cdbd0fddebff401cd6b is even a thing :-) Jan 14 17:41:13 I'd opt for the "wait for 4.14 to fall out of tree" option Jan 14 17:43:42 * ldir sits on hands Jan 14 18:12:20 ynezz: what to do with 469ba33? This triggers full image write on sysupgrade, wiping out partition table on devices using sd card or hdd to boot. Jan 14 18:29:34 ynezz: thanks for taking the initiative on the logo redesign :) Jan 14 19:10:52 tmn505: and 61c57af618e264e9ed3ebd795eb923cbf32797c8 ? Jan 14 19:14:31 I wanted to make it even smaller, but then it wouldn't use f2fs Jan 14 19:15:37 so this a minimum now, hopefully providing usable images with overlays for everybody Jan 14 19:16:38 the reason is described in d03ef97c1b57b2b5588115d3b7c7355399874aa3 Jan 14 19:24:57 so perhaps adding some guard/notice in 18.06/19.07 sysupgrade code now would make sense Jan 14 19:26:20 I still don't get it how could it overwrite the partition table, if the images previously were 256MB big Jan 14 19:26:22 yeah, I understand the reason for both, but if user added additional partition(s), those won't be there after sysupgrade and how many users read issues on release notes? Jan 14 19:27:13 now it's 104MB Jan 14 19:28:06 the sysupgrade saves the partition table on upgrade and compares it with the one from the image, differs? then it's wiped Jan 14 19:28:20 ah, ok, makes sense Jan 14 19:30:41 not difficult to rescue the data, since the rootfs is smaller, but if user doesn't know about it? Jan 14 19:31:10 sure, I agree, something has to be done Jan 14 19:33:06 I'm thinking about narrowing this change to virtual targets, would that be good? Jan 14 19:34:07 there seems to be question "Partition layout has changed. Full image will be written." before the write Jan 14 19:34:19 *yawn* Jan 14 19:34:22 so maybe it should be more explicit? Jan 14 19:34:37 or do this only if --force is enabled? Jan 14 19:34:37 my newly established owrt tuesday worked and yielded 14 hrs Jan 14 19:34:55 nice :) Jan 14 19:34:55 this was the 2nd week i did so, lets hope it'll work out for weeks to come Jan 14 19:35:11 ynezz: yeah, been off-sync too long Jan 14 19:35:42 I will be doing owrt exclusive tuesdays and if that works do a 2 hr patchwork round every odd day in the morning Jan 14 19:35:58 I bought a new laptop just for this, located in a different room than my office Jan 14 19:36:01 :-D Jan 14 19:36:53 ynezz: that would be difficult to do, I mean usin somethin other than dd. Jan 14 19:37:30 o_O why different room than office? Jan 14 19:38:24 stintel: my office distrcats me with work Jan 14 19:38:31 took me 9 months to realize Jan 14 19:38:49 so now I have a laptop in the living room that has no work related crap on it Jan 14 19:39:03 not even skype, slack, webex, jabber ... Jan 14 19:39:11 we call it workgap Jan 14 19:39:26 workgap for working :-) Jan 14 19:39:36 * ldir looks forward to fixup wednesday :-) and runs away... very quickly :-) Jan 14 19:39:51 ldir: wednesdays i go swimming Jan 14 19:40:12 I am very autistic about my swimming and workout slots Jan 14 19:40:15 it was a far too cheeky joke Jan 14 19:40:24 ldir: *kiss* Jan 14 19:40:52 ldir: what is broken today? Jan 14 19:40:55 this new laptop id beefy Jan 14 19:41:13 its a i5 like my old but it compiles owrt much faster Jan 14 19:41:27 cant wait till next week when i get 2 i7 servers Jan 14 19:41:32 ynezz: nothing that I know of Jan 14 19:41:39 it'll change my life Jan 14 19:41:45 + the fact that tomorrow is the day Jan 14 19:41:48 THE DAY Jan 14 19:41:59 the day? Jan 14 19:42:02 when i go from 7/1 to 250/100 uplink Jan 14 19:42:13 hehehe Jan 14 19:42:16 faaaaaaaaaaaaaaaast Jan 14 19:42:18 then you can be distracted with porn :D Jan 14 19:42:24 yeah had this before Jan 14 19:42:39 I was in the compsi lab at uni in 95 downlowding c&c maps Jan 14 19:42:49 at crappy kbit rates Jan 14 19:42:57 and boom the inet went offline for 10 minutes Jan 14 19:43:07 came back up and suddenly it was mbit rates Jan 14 19:43:28 that was the day when the cross atlantic cable went online Jan 14 19:43:45 I was on the 2nd most northen hub of super janet at the time Jan 14 19:44:05 I will have the same dopamine rush tomorrow Jan 14 19:44:45 rare these moment Jan 14 19:45:06 perfect for workout wednesday, just remember to switch arms every now and then 😂 Jan 14 19:45:06 ***k me .. when did 4.19.96 sneak out?!!! Jan 14 19:45:32 stintel: I mainly do own body weight training Jan 14 19:45:53 i use weights like 10% of the time Jan 14 19:46:03 * tmn505 imagines new blogic tuesdays merging-spree with accompaniment of Quake killing sounds... Godlike Jan 14 19:46:18 tmn505: not really Jan 14 19:46:38 tmn505: to me this is still dudes doing what they enjoy, never understood the hype ;) Jan 14 19:47:06 If owrt works for my family&friends wifi all is cool Jan 14 19:47:27 ldir: last night according to my mails Jan 14 19:47:44 right, off to watch john wick 3 :-D Jan 14 19:47:46 I went from 80/20 down to 0/0 today for 4 hours (exchange PSU fault taking out town and a few surrounding villages) so enjoy your 250/100 ! Jan 14 19:48:22 sometimes One just needs to kill something, even if it's a bug Jan 14 19:56:05 Borromini: lets see how the "official" voting goes :] Jan 14 19:57:57 ynezz: hehe Jan 14 19:58:12 nonetheless, it's nice you took the initiative Jan 14 20:15:43 Borromini: it was worth just for the comments/feedback, this one is my favorite so far "Nice, but ... all emphasis is on the wireless, not on the routing." Jan 14 20:19:44 =) Jan 14 20:34:45 ldir: Just today. It looks like a security fix: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.96&id=dd4f3b3508f65fe37975db223365216316da3998 Jan 14 20:36:18 mamarley: thx Jan 14 20:36:20 ldir: And regarding the internet speeds, check out https://www.speedtest.net/result/8941637901. O.o Jan 14 20:36:26 mamarley: yes but I think problems in i915 are not so relevant for OpenWrt Jan 14 20:37:05 Hehe.. while I obviously like owrt in many APs I manage every which where, solely doing wireless would kinda kill all the separate routers I manage in another subset of every which where =) Jan 14 20:37:13 Hauke: I know; I was just guessing at the likely reason for the kernel release because of the surprise that it had been released. Jan 14 20:39:12 As a busy person, may I ask what poll and does it have any relevance or influence by me as owrt user that compiles own stuff? Jan 14 20:39:23 :p Jan 14 20:39:42 I think it is about a new logo for the project. Jan 14 20:40:34 mamarley: hmm, that link capacity would be good for off-site backups Jan 14 20:51:52 blogic: jow: ynezz: If we go with kernel 4.19 we should branch off in march, if we go with kernel 5.4 we probably need till Mai or June to branch off Jan 14 20:52:40 xback: could please you prepare your generic kernel 5.4 stuff to get it to the mailling list and into master, it would be really nice to have it in master and not depend on some staging trees Jan 14 21:10:22 Hauke: FYI jow is going to draft an email about this 4.19->5.4 change, including a vote (3in1 voting actually, 1. 4.19->5.4, 2. new logo/colors, 3. openwrt-announce@) Jan 14 21:11:27 so we're now waiting till the voting about the logo is finished on forum to send it out (Friday, 12:00) Jan 14 21:11:30 Hauke: personal pref, lets skip the bullet, go for a 9 month cycle and be bleeding then try to approximate to 6 month after. Jan 14 21:12:03 imho getting close to upstream carries more weight than customer satisfaction Jan 14 21:12:20 ynezz: thx for the effort Jan 14 21:33:51 ynezz: thanks for the information Jan 14 21:37:14 Hauke: i think meeting is feb is blown Jan 14 21:37:22 proposal ? Jan 14 21:42:17 there was another date in March Jan 15 00:53:52 jow: any comment on https://github.com/openwrt/packages/pull/11002 ? **** ENDING LOGGING AT Wed Jan 15 02:59:57 2020