**** BEGIN LOGGING AT Thu Jul 11 03:01:20 2019
**** BEGIN LOGGING AT Thu Jul 11 03:40:59 2019
Jul 11 07:06:14 <jow> philipp64: make kernel_menuconfig and trace the dependencies through the search/help dialog (use slash to search for the symbol, then follow its depends and prereqs)
Jul 11 07:19:12 <m_splinter> Hi all, how can I close an image if I've made a small change to the rootfs, without running the default rule for make?
Jul 11 07:28:37 <Rene__> Someone using mediatek mt7628 with v5.2 kernel?
Jul 11 08:02:30 <gch981213> jow: ping - Have you received my ssh public key?
Jul 11 08:52:46 <ldir> custom dns servers - should we be able to specify a custom port as well ?
Jul 11 08:53:45 <ldir> is fiddling with the dns over https proxy and cannot work out how to get dnsmasq to look at 127.0.0.1:5053 for dns servers
Jul 11 08:56:23 <kristrev> I think that already works. If I remember correctly from my own tests, then the server UCI option maps directly to dnsmasq's --server option and supports the same syntax
Jul 11 08:56:29 <kristrev> But I have only tested with remote servers
Jul 11 08:58:31 <gweentea> 127.0.0.1#5053
Jul 11 09:01:35 <ldir> hmmm, doesn't work for me.  I must be doing something wrong.
Jul 11 09:14:35 <ldir> OK, fallen into a few traps.
Jul 11 09:16:12 <ldir> So the first is that under luci - interfaces 'use custom DNS servers' does not support adding a port reference, e.g. 127.0.0.1#5053 or 127.0.0.1:5053
Jul 11 09:17:04 <ldir> This has to be done under DHCP and DNS - dns forwardings "127.0.0.1#5053"
Jul 11 09:17:35 <ldir> The next trap is to disable dnssec validation on dnsmasq.
Jul 11 09:28:52 <ldir> aahhhh ok, resolv.conf doesn't accept port numbers.
Jul 11 09:31:11 <ds_shadof> server=127.0.0.1#5453 to /etc/dnsmasq.conf
Jul 11 09:33:17 <romany> does WPA3 work on current HEAD?
Jul 11 09:37:05 <slh64> yes
Jul 11 09:38:07 <romany> which client did you use to test?
Jul 11 09:38:49 <romany> linux with recent wpa_supplicant?
Jul 11 09:42:56 <slh64> yes, Debian/ unstable, wpa_supplicant 2.8
Jul 11 09:44:16 <slh64> you need to use a passphrase, not a hex key (that misunderstanding kept me busy for months)
Jul 11 09:59:02 <romany> ok, thanks
Jul 11 10:02:48 <ssn> Hi
Jul 11 10:04:44 <ssn> What needs to be done to get this merged?
Jul 11 10:04:46 <ssn> https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg47226.html
Jul 11 11:07:55 <karlp> sideways related, is there any reason why mtd-mac-increment is unsigned? it could be -1 just as easily right?
Jul 11 11:12:31 <rmilecki> ssn: that looks good to me I think [PATCH] ath79: add support for gl-ar750
Jul 11 11:13:55 <ssn> I'd love to see it merged
Jul 11 11:14:38 <Neighbor11111117> I've noticed that boards have separate SoCs and wireless chips. I always assumed the wireless chip is integrated into the SoC. Is this not the case? If so how is the wireless chip typically connected to the SoC? E.g. https://openwrt.org/toh/netgear/r7000
Jul 11 11:14:52 <rmilecki> anyone with objections for that https://patchwork.ozlabs.org/patch/1122661/ [PATCH] ath79: add support for gl-ar750
Jul 11 11:14:55 <rmilecki> ?
Jul 11 11:15:28 <rmilecki> Neighbor11111117: most wireless chipsets are out of SoC and connected using some bus, usually PCIe
Jul 11 11:15:59 <rmilecki> Neighbor11111117: i guess you may try to call wireless chipset a SoC if it's a FullMAC device with a real CPU
Jul 11 11:16:09 <rmilecki> Neighbor11111117: i wouldn't call that SoC personally
Jul 11 11:16:53 <rmilecki> Neighbor11111117: BCM4360 is SoftMAC chipset, so real CPU on it
Jul 11 11:16:55 <Neighbor11111117> Ok that makes sense. So you need the datasheet for the SoC and the wireless chipsets as well then
Jul 11 11:17:20 <rmilecki> yes, they are completely different
Jul 11 11:17:30 <Neighbor11111117> ok brilliant thanks for the info
Jul 11 11:17:39 <rmilecki> Neighbor11111117: SoC has a CPU, memory controller, flash controller, PCIe controller, USB conroller, etc.
Jul 11 11:17:43 <Neighbor11111117> so the BCM4360 has a CPU in it. Are you able to program it?
Jul 11 11:18:06 <rmilecki> sorry, my bad
Jul 11 11:18:14 <rmilecki> fixes: BCM4360 is SoftMAC chipset, so NO real CPU on it
Jul 11 11:18:38 <rmilecki> there is only some small CPU executing a microcode, that is closer to a state machine
Jul 11 11:18:46 <Neighbor11111117> ok awesome
Jul 11 11:18:59 <Neighbor11111117> how do you know all of this? Do you have the datasheet?
Jul 11 11:19:11 <rmilecki> i don't
Jul 11 11:19:26 <Neighbor11111117> If you have a fullmac chipset are you able to program it? And if so do you ave any example routers that have this
Jul 11 11:19:32 <rmilecki> this page lists FullMAC chipsets: https://wireless.wiki.kernel.org/en/users/drivers/brcm80211
Jul 11 11:20:04 <Neighbor11111117> very cool
Jul 11 11:20:43 <rmilecki> Neighbor11111117: yes, if you deal with Broadcom FullMAC wireless device, you upload a firmware to it every time, you could in theory write your own one, that does your own calculations (whatever) instead of handling wireless core + traffic
Jul 11 11:21:06 <rmilecki> so you can try mining bitcoins on your wireless card ;)
Jul 11 11:21:16 <Neighbor11111117> that is super frakin cool
Jul 11 11:21:23 <Neighbor11111117> have you ever done anything interesting like that yourself?
Jul 11 11:21:29 <rmilecki> no
Jul 11 11:21:54 <rmilecki> i think I saw FullMAC firmwares using TRX format, so it should be not that hard to build one
Jul 11 11:22:13 <rmilecki> you still need to get a kernel that will run on that wireless card's CPU though
Jul 11 11:22:28 <rmilecki> for some FullMAC firmwares Broadcom was using ThreadX
Jul 11 11:22:41 <rmilecki> not sure what do they use in more recent ones
Jul 11 11:23:08 <Neighbor11111117> super interesting indeed
Jul 11 11:23:30 <Neighbor11111117> thanks for that info rmilecki
Jul 11 11:24:38 <KanjiMonster> rmilecki: according to the core ids, 4360 has an 32-bit arm cpu -> https://askubuntu.com/questions/736600/id-0x4360-rev-0x03-and-package-0x01-analog-12-type-11-ac-revision-1
Jul 11 11:26:02 <KanjiMonster> I wouldn't wonder if e.g. 43602 is just a 4360 with (more) ram to run a full firmware
Jul 11 11:26:33 <KanjiMonster> *wouldn't be surprised
Jul 11 11:26:38 <rmilecki> yes, most likely
Jul 11 11:29:16 <KanjiMonster> I also assume you still could use the modern fmac (pcie) devices as smac, by not loading a firmware and programming it directly - if you had documentation for that ;)
Jul 11 11:30:09 <rmilecki> KanjiMonster: well, you scan cores on it from host system
Jul 11 11:30:21 <rmilecki> KanjiMonster: so maybe accessing all wireless core details it also possible
Jul 11 11:30:30 <rmilecki> interesting :)
Jul 11 11:32:16 <KanjiMonster> you could probably build the chip so the registers aren't accessible from the host side, but that would likely require a full redesign of it, and I assume broadcom to be too lazy for that ;)
Jul 11 11:32:56 <KanjiMonster> still might be that interrupt routing won't properly work anymore to host side or so
Jul 11 11:33:25 <karlp> or just not even connected on boards,
Jul 11 11:33:52 <KanjiMonster> interrupt routing would be SoC internal, nothing exposed on the outside of the chip
Jul 11 11:35:01 <KanjiMonster> my guess is that the broadcom chips supported fmac and smac modes since ages; fmac when used as usb (or sdio) dongle, smac when pcie or embedded
Jul 11 11:40:45 <ssn> [PATCH] ath79: add support for gl-ar750
Jul 11 11:40:48 <ssn> merge please
Jul 11 12:47:47 <jow> gch981213: I'll take care of it now. What is your preferred nickname?
Jul 11 12:56:07 <jow> gch981213: nvm, I added your key now. The internal username is "981213"
Jul 11 13:35:30 <rmilecki> jow: would you care to check https://github.com/openwrt/packages/pull/8157 ?
Jul 11 13:35:44 <rmilecki> it seems that developer changed design of that PoE manamgenet since your last review
Jul 11 13:36:15 <blocktrron> jow: while you are at it - did you receive my email?
Jul 11 13:36:37 <karlp> given that it's just a gpio togglign thing, can we not call it PoE anything?
Jul 11 13:41:55 <gch981213> jow: Thanks a lot!
Jul 11 13:50:07 <rmilecki> karlp: yeah
Jul 11 13:50:24 <rmilecki> karlp: make it something generic (that can handle more than GPIO) and call it PoE
Jul 11 13:50:36 <rmilecki> karlp: or make is manage GPIOs and call it GPIO-whatever
Jul 11 13:50:37 <karlp> or the other way, and just have it be a gpio control daemon
Jul 11 13:50:43 <karlp> indeed. it's stuck int he middle at the moment.
Jul 11 13:50:52 <karlp> I've commented to taht effect ont he PR
Jul 11 13:52:36 <rmilecki> thanks karlp
Jul 11 15:03:15 <rmilecki> gch981213: did you discuss that "ramips: dts: drop memory nodes" with any upstream maintainers?
Jul 11 15:03:25 <rmilecki> gch981213: or is there similar work that was accepted?
Jul 11 15:03:55 <rmilecki> gch981213: i was talking long time ago (at summit in Berlin maybe?) with some big upstream maintainer
Jul 11 15:04:05 <rmilecki> I *think* he didn't like removing such info from .dts
Jul 11 15:05:45 <gch981213> rmilecki: Oops... Half a year ago I did the same thing for ath79 target.
Jul 11 15:06:04 <rmilecki> gch981213: i don't know if that's good or not
Jul 11 15:06:09 <rmilecki> i'd like to hear upstream maintainers opinion
Jul 11 15:06:19 <rmilecki> so we don't end up dropping info that IS needed after all
Jul 11 15:07:46 <rmilecki> i just pushed my small cleanup sysupgrade change, @everyone ping me if sth got broken [PATCH] base-files: move stage2 upgrade to separated file
Jul 11 15:12:23 <gch981213> rmilecki: I'll send a mail to device tree list tomorrow.
Jul 11 15:13:33 <jow> blocktrron: can you give me some pointer? subject / sender / timestamp? PM if you like
Jul 11 15:14:51 <blocktrron> jow: Subject was "SSH pubkey for Git server" 10.07.2019
Jul 11 15:15:23 <jow> blocktrron: your irc handle shall become the nickname as well?
Jul 11 15:15:36 <blocktrron> yes :)
Jul 11 15:17:42 <jow> blocktrron: done
Jul 11 15:17:56 <blocktrron> thanks
Jul 11 15:18:10 <jow> gch981213: blocktrron: can you please give me your bugs.openwrt.org and openwrt.org wiki handles as well? Also Github in case you're not part of the org there already
Jul 11 15:19:28 <blocktrron> jow: bugs.openwrt.org was done yesterday by petr. openwrt wiki matches my irc handle.
Jul 11 15:19:40 <blocktrron> Github org was also done by ynezz
Jul 11 15:21:56 <jow> okay, you're wiki admin as well now
Jul 11 15:22:07 <jow> allows to edit protected pages like the frontpage
Jul 11 15:30:17 <rmilecki> jow: me and karlp raised some questions/doubts about that https://github.com/openwrt/packages/pull/8157 that you just merged
Jul 11 15:30:29 <rmilecki> i'd prefer to see that cleared up before merging it
Jul 11 15:30:56 <jow> rmilecki: oh - I thought you wanted me to merge it
Jul 11 15:31:09 <rmilecki> no, rather review it ;)
Jul 11 15:31:13 <jow> shall I revert it? I mean I don't care about it at all
Jul 11 15:31:23 <rmilecki> jow: can you look at that code?
Jul 11 15:31:24 <jow> I have no use case, suitable hardware or interest
Jul 11 15:31:27 <rmilecki> i think it's pretty bad designed
Jul 11 15:31:37 <jow> what about it?
Jul 11 15:32:11 <rmilecki> it pretends to be for PoE management but doesn't define any nice way of mapping PoE hw management into a friendly interface
Jul 11 15:32:18 <rmilecki> right now it seems to be rather GPIO management
Jul 11 15:32:22 <gch981213> jow: It's also 981213.
Jul 11 15:33:05 <rmilecki> karlp: we got a small misunderstanding with jow and we got https://github.com/openwrt/packages/pull/8157 merged, while i'm still not happy about that design
Jul 11 15:33:10 <rmilecki> karlp: should we revert that?
Jul 11 15:33:17 <rmilecki> karlp: i think jow is OK with reverting
Jul 11 15:33:23 <rmilecki> and I'd rather see that better designed
Jul 11 15:33:57 <jow> I reverted it
Jul 11 15:34:20 <jow> rmilecki: so - the things that involve rpcd look okay to me. I have no opinion on the overall design
Jul 11 15:34:33 <rmilecki> jow: ok, thanks
Jul 11 15:34:34 * gch981213 screwed up his first push :(
Jul 11 15:35:01 <rmilecki> gch981213: what's wrong there?
Jul 11 15:38:06 <gch981213> rmilecki: I didn't change all board name cases for MQmaker WiTi and have pushed a fix for it.
Jul 11 15:38:58 <rmilecki> gch981213: you fixed that and you even used Fixes tag, noone is going to mind :)
Jul 11 15:39:17 <jow> rmilecki: just seen your commit about moving stage2
Jul 11 15:39:34 <rmilecki> jow: sth wrong about it?
Jul 11 15:39:44 <rmilecki> [17:07] <rmilecki> i just pushed my small cleanup sysupgrade change, @everyone ping me if sth got broken [PATCH] base-files: move stage2 upgrade to separated file
Jul 11 15:39:45 <rmilecki> ;)
Jul 11 15:39:51 <jow> rmilecki: for scripts which are executable but aren't supposed to be run by the user directly, I usually prefer /usr/libexec
Jul 11 15:40:07 <jow> but I guess its just bikeshedding, so probably not important enough to be changed
Jul 11 15:40:47 <rmilecki> well, one nice thing it keeping that in a common sysupgrade directory /lib/upgrade/
Jul 11 15:40:59 <jow> yeah, was thinking the same
Jul 11 15:41:00 <rmilecki> but I don't mind /usr/libexec/ if you think it's significently better
Jul 11 15:41:07 <KevinDB> green
Jul 11 15:41:12 <jow> blue!
Jul 11 15:41:31 <KevinDB> how about red
Jul 11 15:41:31 <stintel> transparent?
Jul 11 15:41:38 <KevinDB> sneaky!
Jul 11 15:41:48 <jow> rmilecki: nvm ;)
Jul 11 15:42:08 * KevinDB looks for the transparent bit
Jul 11 15:42:30 <rmilecki> about about seven red lines in blue & transparnet ink? ;) https://www.youtube.com/watch?v=BKorP55Aqvg
Jul 11 15:42:36 <rmilecki> *what about
Jul 11 15:59:04 <rmilecki> jow: i'm looking at https://github.com/openwrt/openwrt/pull/2188 that adds liblua5.3.so.0.0.0 (and symlinks liblua5.3.so.0.0 + liblua5.3.so.0 + liblua5.3.so) - do those names look good to you?
Jul 11 15:59:21 <rmilecki> jow: it seems to matches Debian mostly, see: https://pastebin.com/wfar2VCg
Jul 11 15:59:57 <rmilecki> *to match
Jul 11 16:01:58 <rmilecki> jow: i suppose you want to match Debian, so I think it looks good, but I just want to make sure
Jul 11 16:16:45 <jow> rmilecki: ABI_VERSION should be 5.3
Jul 11 16:16:58 <jow> at least I think so
Jul 11 16:17:10 <rmilecki> jow: i think that for lua 5.1 we have 5.1.5 too
Jul 11 16:17:26 <jow> ok
Jul 11 16:17:31 <rmilecki> ABI_VERSION:=5.1.5
Jul 11 16:17:40 <rmilecki> that's from package/utils/lua/Makefile
Jul 11 16:18:03 <jow> https://abi-laboratory.pro/index.php?view=timeline&l=lua
Jul 11 16:18:16 <jow> seems that point versions are compatible
Jul 11 16:18:22 <jow> so it should be 5.3 after all
Jul 11 16:18:49 <jow> 5.1.5 for 5.1 was a mistake actually
Jul 11 16:18:55 <rmilecki> ok
Jul 11 16:19:04 <rmilecki> any other comments?
Jul 11 16:19:05 <jow> but doesn't matter much as 5.1.5 is the last 5.1 anyway
Jul 11 16:19:33 <jow> whats the SONAME of liblua5.3.so* ?
Jul 11 16:20:16 <jow> I suppose there isn't one
Jul 11 16:20:49 <jow> no further comments, looks fine to me (without compile testing)
Jul 11 16:21:10 <rmilecki> > objdump -p ./staging_dir/target-mipsel_74kc_musl/usr/lib/liblua5.3.so.0.0.0 | grep SONAME
Jul 11 16:21:11 <rmilecki>   SONAME               liblua5.3.so.0.0.0
Jul 11 16:21:52 <jow> ok
Jul 11 16:33:48 <karlp> heh, in 1806 at least, the slovak translation dosn't have a .lmo file to install.
Jul 11 16:33:57 <karlp> wsa like, "wat, why is it installed but not in the dropdown?!"
Jul 11 16:40:32 <rmilecki> can someone please CLOSE https://github.com/openwrt/openwrt/pull/2188 ?
Jul 11 16:41:38 <gch981213> rmilecki: done.
Jul 11 16:41:43 <rmilecki> thx
Jul 11 16:41:46 <karlp> so, you can ocmmit to master, you can comment on github, but you're not in the group for the master repo?
Jul 11 16:41:59 <rmilecki> it seems so ;)
Jul 11 16:42:58 <karlp> you should ask for that instead .)
Jul 11 16:43:30 <rmilecki> jow: are you openwrt project admin at github?
Jul 11 16:43:40 <gch981213> rmilecki: Fixed that for you :D
Jul 11 16:43:41 <rmilecki> can you allow me to close merge requests?
Jul 11 16:43:44 <rmilecki> oh, nice
Jul 11 16:43:52 <karlp> there youg o :)
Jul 11 17:56:17 <Borromini> hi guys
Jul 11 17:56:28 <Borromini> blocktrron: congrats on the 'promotion' :^)
Jul 11 18:01:35 <Borromini> hauke: anything specific you need testing with for the 19.07 mac80211 update?
Jul 11 19:15:41 <_abc_> Is there a ls-lR.txt somewhere documenting all the files in the directories at https://downloads.openwrt.org/snapshots/targets/ somewhere?
Jul 11 19:20:38 <_abc_> in https://openwrt.org/toh/tp-link/tl-wr841nd v14 appears listed, with mention snapshot, but I can't find a corresponding file in snapshots
Jul 11 19:25:20 <MY_R> _abc_, https://downloads.openwrt.org/snapshots/targets/ramips/mt76x8/
Jul 11 19:26:36 <_abc_> I found it yes, the coin dropped later when I saw it's hw is like v13
Jul 11 19:27:04 <_abc_> MY_R: still, a ls-lR.txt would be nice? /me makes large puppy eyes.
Jul 11 19:27:08 <_abc_> thanks.
Jul 11 19:28:53 <MY_R> :)
Jul 11 19:48:40 <blogic> *yawn*
Jul 11 19:48:48 <_abc_> So I don't get it, to add ehci + uhci usb support to a device which does not have it, one edits the dte and then recompiles or is the edit only to influence the package assembly scripts?
Jul 11 19:59:24 <Borromini> kernel picks up the dts from what i know
Jul 11 19:59:42 <_abc_> But only if one compiles it, no?
Jul 11 20:00:03 <_abc_> Im trying to figure out if I need to rebuild or not to tinker with usb on a barely supported router.
Jul 11 20:00:29 <jeffsf> Depending on the device is how the kernel gets the DTB. Generally, you'll need to rebuild the image
Jul 11 20:01:30 <jeffsf> Without the kernel knowing that the device exists and what drivers would be appropriate, it won't attach a driver.
Jul 11 20:13:23 <_abc_> Doesn't modprobe put it in?
Jul 11 20:13:29 <_abc_> I see what you mean.
Jul 11 20:15:12 <_abc_> eg refer to this, USB mod on tl-wr841n v13, in LEDE times, shows changes to DTS involving ehci and uchi hooks only. Would these be in a normal snapshot build? Where would one look for these things to avoid adding them twice? https://forum.openwrt.org/t/wr841n-v13-usb-mod/9098
Jul 11 20:15:30 <_abc_> I understand the new way is DTB not DTS
Jul 11 20:15:58 <jeffsf> DTB: binary output of compiling a DTS (source)
Jul 11 20:16:05 <_abc_> ah
Jul 11 20:16:52 <Borromini> :)
Jul 11 20:17:01 <jeffsf> Kernel deals with DTB, most mere mortals can't read a DTB, not to mention write them, so we deal with DTS
Jul 11 20:17:23 <Borromini> _abc_: your hardware has usb support but the openwrt image is missing it?
Jul 11 20:17:26 <Borromini> or did you mod it
Jul 11 20:17:33 <_abc_> I should sit and read up on these things from a to z until I know them by heart.
Jul 11 20:18:05 <_abc_> Borromini: mod, in future, I need to get the router 1st
Jul 11 20:19:23 <Borromini> k
Jul 11 20:19:43 <Borromini> what's your interest in buying one and modding it when you could buy a similar device with usb support ootb
Jul 11 20:19:46 <Borromini> if i may ask?
Jul 11 20:19:51 <Borromini> or is this a mere tinkering project
Jul 11 21:16:59 <someoner> I'm trying to understand the docu here: https://bcm-v4.sipsolutions.net/Backplane/index.html#BAS0
Jul 11 21:17:00 <someoner> This register controls which backplane address is currently mapped into the mapped memory. Each core uses 0x1000 bytes (4K) for registers, so when setting the mapped core, take the Core Index multiplied by 0x1000 (the size of the core registers) and add that to the base value of 0x18000000. Note that mapping may not succeed on the first attempt, so
Jul 11 21:17:00 <someoner>  the proper method of mapping is to write the register, then read back the value until it is actually set to the desired value (max 10 times). To find which core is mapped, read this register and do the above calculation in reverse.
Jul 11 21:17:48 <someoner> How does this mapping work? Where do I have to write what?
Jul 11 21:23:27 <someoner> So there are cores with various functionality connected by the ssb bus. So do I need to do something to get access to the registers of this core?
Jul 11 21:38:25 <Hauke> someoner: I think on the SoCs (BRCM47xx) all cores are mapped at the same time, this mapping is only used on the PCI(e) devices
Jul 11 22:46:14 <Tapper> Hi people if there is any thing you would like for me to put out on the OpenWrt twitter let me know.
Jul 11 22:46:47 <Tapper> EG I just posted this. https://github.com/openwrt/openwrt/commit/14e0e4f138e35c3e2a15cc3a836c939547ee053b
Jul 11 22:47:37 <hellsenberg> openwrt twitter?
Jul 11 22:47:37 <Tapper> So any new routers, packages or forum posts that mite be intresting let me know
Jul 11 22:48:10 <Tapper> yeah https://twitter.com/openwrth?lang=en
Jul 11 22:49:01 <hellsenberg> i see
Jul 11 22:49:10 <hellsenberg> didn't know openwrt had a twitter
Jul 11 22:49:38 <pkgadd> jeffsf: extrapolating from more current Linksys devices (e.g. ea6350 v1, I would assume Linksys to omit the h/w revision for v1 - but on the other hand, the ~2009 vintage wrt610n v1 spells it out as v1)
Jul 11 22:50:11 <Tapper> They didn't  then I made one. :)
Jul 11 22:50:16 <jeffsf> Dunno -- I posted on the forums for anyone with early WRT54GS units around to comment on the label
Jul 11 22:50:48 <jeffsf> I don't know where mine are, but I think there's at least one frequent poster there that has a few still around.
Jul 11 22:51:58 <Tapper> hellsenberg give us a follow if you like.
Jul 11 22:52:25 <hellsenberg> Tapper: "us"?
Jul 11 22:53:11 <hellsenberg> oh, just found tapper82
Jul 11 22:53:11 <Tapper> OK me :) But I am repping for OpenWrt
Jul 11 22:53:30 <Tapper> Unofficially!
Jul 11 22:53:38 <hellsenberg> I noticed that
Jul 11 22:54:48 <Tapper> Yes tapper82 is me, I don't post anything from the OpenWrt that is not about the project.
Jul 11 22:55:05 <Tapper> Thanks for the follow
Jul 11 22:55:53 <Tapper> If there is everry a post that people don't like pleas let me know I would hate to bring any shame on to OpenWrt.
Jul 11 23:02:02 <Tapper> I am not doing bad as OpenWrt-h up to 103 followers now!
Jul 11 23:56:21 <mirko> .s 0
Jul 11 23:56:27 <mirko> oops
Jul 11 23:56:57 <jeffsf> I wonder if the KGB will complain the day ar71xx isn't being built anymore
Jul 11 23:59:22 <hellsenberg> o_O
Jul 12 00:06:38 <blogic>   lynxis ping
Jul 12 00:06:43 <blogic> lynxis: ping
Jul 12 00:07:05 <blogic> lynxis: if you got a sec for me tomorrow i'd appreciate it
**** ENDING LOGGING AT Fri Jul 12 02:59:57 2019