**** BEGIN LOGGING AT Tue Sep 15 02:59:57 2020
**** BEGIN LOGGING AT Tue Sep 15 03:25:22 2020
Sep 15 05:05:21 <gch981213> mrkiko: I just tried a build with default config for gbpc1 and mt76 isn't selected. As for SD card, could you double check if kmod-sdhci-mt7620 is included?
Sep 15 05:10:33 <rmilecki> morning
Sep 15 05:12:37 <rmilecki> jow: i decided to use "list" method after all due to its simplicity - can you take a look at https://patchwork.ozlabs.org/project/openwrt/patch/20200914163107.27739-1-zajec5@gmail.com/ [PATCH luci] luci-base: use actual JSON-RPC for verifying ubus RPC URL
Sep 15 05:17:01 <russell--> hexa-: what is your overlay filesystem?
**** BEGIN LOGGING AT Tue Sep 15 05:48:42 2020
Sep 15 06:01:48 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ath97.html has been updated. (99.2% images and 99.7% packages reproducible in our current test framework.)
**** BEGIN LOGGING AT Tue Sep 15 06:39:34 2020
**** BEGIN LOGGING AT Tue Sep 15 06:55:17 2020
Sep 15 07:08:55 <aparcar[m]> zorun: ping
Sep 15 07:12:40 <zorun> aparcar[m]: pong, but only for 5 minutes
Sep 15 07:15:07 <aparcar[m]> do you think the opkg patch I sent is very insecure?
Sep 15 07:15:16 <aparcar[m]> else I'd send a regular patch
Sep 15 07:17:19 <aparcar[m]> And I don't really understand you commeting regarding SIGNATURE_CHECK or the usage of SIGNED_PACKAGES - sorry
Sep 15 07:19:44 <zorun> "file:packages" seems overly specific
Sep 15 07:20:53 <zorun> it boils down to "why do you need to depend on SIGNED_PACKAGES"
Sep 15 07:21:18 <zorun> the obvious answer is "you need signed package lists" but this is not actually th ecase
Sep 15 07:22:41 <aparcar[m]> should we just always trust local feeds?
Sep 15 07:22:57 <aparcar[m]> that's maybe dangerous if you mirror stuff externally e.g. via rsync
Sep 15 07:24:00 <zorun> no idea, sorry
Sep 15 07:24:19 <aparcar[m]> but fair, we should use SIG_CHK instead SGND_PKGS, as already done in package/system/opkg/Makefile
Sep 15 07:24:24 <jow> rmilecki: approach looks good. But can you use session/list instead? Also remove "params: undefined" and maybe inline the options object
Sep 15 07:25:04 <Tusker> aparcar[m]: maybe it should be like ssh keys... for local feeds, so it prompts when there is a missing signature, and generates one if it isn't found, etc
Sep 15 07:25:14 <aparcar[m]> jow: opinion on the opkg patch? Should the file:packages repo be trusted by default or a special variable added?
Sep 15 07:26:18 <Tusker> so, interactive it prompts, non-interactive, then need to add the signature into config to allow it through ?
Sep 15 07:26:25 <aparcar[m]> Tusker: not sure if prompts should be added to the IB...
Sep 15 07:26:58 <Tusker> k, maybe not
Sep 15 07:31:29 <jow> "the opkg patch" ?
Sep 15 07:32:28 <aparcar[m]> jow: nevermind I though you maybe saw it already on the ML https://lists.infradead.org/pipermail/openwrt-devel/2020-September/031403.html
Sep 15 07:32:55 <jow> that patch is a no-go
Sep 15 07:33:49 <aparcar[m]> jow: I figured it's "very poor". So I'm asking if you have an idea
Sep 15 07:34:35 <jow> it probably should become a per-source attribute in the configuration
Sep 15 07:36:00 <rmilecki> nbd: can you check https://patchwork.ozlabs.org/project/openwrt/patch/20200727181444.28780-1-zajec5@gmail.com/ please? [PATCH uhttpd rfc] client: really close connection on timeout
Sep 15 07:40:33 <aparcar[m]> the easiest I could think of would be src/trusted and src/gz/trusted. The extra stuff seems unused, just like the handling of dist and dist/gz in general. Should that maybe get some cleanup?
Sep 15 07:40:48 <aparcar[m]> I've never seen OpenWrt use this debian-style
Sep 15 07:42:33 <rmilecki> jow: since you want "call" method, I'll have to replace "params: undefined" with arguments instead of totally dropping it
Sep 15 07:43:04 <rmilecki> I'm ok with that, it;ll just make request slightly more complex (few more lines)
Sep 15 07:43:08 <rmilecki> working on that
Sep 15 07:43:26 <aparcar[m]> with extra stuff I mean insertion of $url/$extra/$file, as used in debian
Sep 15 07:43:44 <rmilecki> params:  ["00000000000000000000000000000000", "session", "list", {}]
Sep 15 07:44:17 <jow> rmilecki: ah okay, fine then.
Sep 15 07:44:52 <rmilecki> rmilecki: "fine" as "stick to list" or "use session list"? ;)
Sep 15 07:46:00 <jow> rmilecki: I'd prefer session/list because it is guaranteed to be available since it is an rpcd builtin
Sep 15 07:46:09 <rmilecki> got it
Sep 15 07:46:39 <rmilecki> well "list" is also built-in I believe ;)
Sep 15 07:47:38 <rmilecki> OK, I have "session" "list" with reply "{jsonrpc: "2.0", id: "init", error: {code: -32002, message: "Access denied"}}" - that is HTTP code 200, so all good
Sep 15 07:48:13 <jow> rmilecki: an even better candidate would be session/access
Sep 15 07:48:33 <rmilecki> with no arguments?
Sep 15 07:48:41 <aparcar[m]> jow: zorun would you be okay with a patch adding "src/trusted" to opkg which skips signature checks? This is then added per default to the local packages feed.
Sep 15 07:49:02 <jow> session access '{ "scope": "ubus", "object": "session", "function": "access" }'
Sep 15 07:49:10 <jow> that should succeed even for the null session
Sep 15 07:49:40 <jow> succeed as in HTTP 200 and UBUS_STATUS_OK
Sep 15 07:50:45 <rmilecki> please remind me, how is that better from a simple "list" request? ;)
Sep 15 07:50:51 <rmilecki> list as listing ubus objects
Sep 15 07:51:24 <jow> list request is fine too
Sep 15 07:52:03 <rmilecki> jow: that's what I put in my patch in the first place ;) https://patchwork.ozlabs.org/project/openwrt/patch/20200914163107.27739-1-zajec5@gmail.com/
**** BEGIN LOGGING AT Tue Sep 15 07:54:01 2020
Sep 15 07:54:44 <rmilecki> jow: can I inline options, and push with your Acked?
Sep 15 07:54:50 <jow> yep
Sep 15 07:54:59 <rmilecki> thank you for all help
Sep 15 08:26:07 <svanheule[m]> greearb: ping
Sep 15 08:27:52 <svanheule[m]> greearb: I've been testing stintel's patches for ath10k-ct 5.8 and got two FW crashes (qca9880, wave-1) https://gist.github.com/svanheule/711d0d8182ce126a43ba58da8d29faff
Sep 15 08:29:05 <stintel> these patches: https://patchwork.ozlabs.org/project/openwrt/list/?series=199172
Sep 15 08:30:14 <dansan> That's weird.  Was there a problem with the infradead mailing list?  For some reason, I was unsubscribed at some point after June 20th 9:30PM GMT
Sep 15 08:31:00 <rsalvaterra> svanheule[m]: I see those sporadically. I guess it's just the QCA9880 firmware doing its thing. :/
Sep 15 08:32:11 <rsalvaterra> (On current master, that is.)
Sep 15 08:32:41 <svanheule[m]> rsalvaterra: weird, I don't remember seeing them before. But maybe I just wasn't paying enough attention to the logs (no clear issues with the connected devices)
Sep 15 08:33:22 <svanheule[m]> "current master" might explain why I don't remember them
Sep 15 08:33:49 <rsalvaterra> Yeah, the driver usually recovers in a couple of seconds, so it can go by unnoticed.
Sep 15 08:34:33 <rsalvaterra> svanheule[m]: I also don't remember seeing these crashes on 19.07.
Sep 15 08:34:39 <stintel> dansan: yes
Sep 15 08:35:48 <stintel> dansan: http://lists.openwrt.org/pipermail/openwrt-devel/2020-June/029781.html
Sep 15 08:36:21 <dansan> stintel: Thank you! :)  That's very helpful to know.  I'm probably on too many mailing lists
Sep 15 08:36:32 <stintel> welcome :)
Sep 15 08:37:00 <dansan> Good to know I haven't made some enemy out there somewhere who's pranking me, lol!
**** BEGIN LOGGING AT Tue Sep 15 08:43:12 2020
Sep 15 08:46:54 <rmilecki> @all: i'm planning to push https://patchwork.ozlabs.org/project/openwrt/patch/20200914151523.4757-1-zajec5@gmail.com/ today [PATCH V3 uhttpd] ubus: add new RESTful API
Sep 15 08:47:20 <rmilecki> if you use LuCI, you may want to test it at least
Sep 15 08:56:45 <karlp> :+1:
Sep 15 08:56:55 <karlp> fingers crossed, it all looks like good stuff :)
Sep 15 08:59:17 <rmilecki> thanks
Sep 15 08:59:23 <jow> rmilecki: btw, event subscription auth is still pending, right?
Sep 15 08:59:29 <rmilecki> jow: correct
Sep 15 08:59:34 <rmilecki> i think i'll start working on that right now
Sep 15 09:03:33 <aparcar[m]> jow: can we get rid of the packages/ folder of ImageBuilders by adding a feed like added to snapshots? (src/gz openwrt_kmods https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/kmods/5.4.52-1-414b18aa0d8abc3a21dbf831bc990cd6/)
Sep 15 09:04:13 <aparcar[m]> Only kernel.ipk and libc seem missing, where at least kernel.ipk is a dummy package
Sep 15 09:04:29 <aparcar[m]> this way we could skip any modification of opkg
Sep 15 09:09:17 <Tusker> anyone here have experience with nand ?  uboot reads ff ff ff ff at offset 5f20000, but when I boot into openwrt, it reads the values that I wrote to that offset.   If I write to that offset in uboot, it reads fine in both uboot and openwrt.  any idea why this is the case?  something wrong with sector size vs page size etc ?
Sep 15 09:30:53 <rmilecki> Tusker: maybe OpenWrt doesn't write to OOB correctly / at all?
Sep 15 09:31:31 <rmilecki> Tusker: try dumping that block including OOB after writing with OpenWRt and after writing with uboot
Sep 15 09:32:50 <karlp> hang on, if you write to it in uboot, it reads fine in both uboot and openwrt? when do you get fffff?
Sep 15 09:33:05 <karlp> is that perhaps just uboot hasn't initialized things before it does the first write?
Sep 15 09:33:19 <Tusker> if I write in openwrt, it reads fine in openwrt, but fails to read in uboot
Sep 15 09:33:29 <Tusker> if I write in uboot, it reads fine in uboot and reads fine in openwrt
Sep 15 09:35:39 <Tusker> all data and OOB reads as ff, for the case of writing from openwrt
Sep 15 09:37:26 <Tusker> if I write in uboot, the data looks perfect, and OOB has a mixture of mostly ff, but scattering of 69 a6 9a, 9a 99 a5, 33 ff c3, 3c c0 33
Sep 15 09:59:00 <Tusker> hmmm.... seems nandwrite -p resolves it, mtd write maybe needs to have the file itself padded ?
**** BEGIN LOGGING AT Tue Sep 15 10:02:26 2020
Sep 15 10:10:39 <Tusker> will investigate it more tomorrow... need to go now
Sep 15 10:10:43 <Tusker> thanks for the pointers
**** BEGIN LOGGING AT Tue Sep 15 10:16:04 2020
Sep 15 10:22:25 <mrkiko> Hello guys!! I sent here a message yestarday, so sorry for repeating myself. Just wondering if anyone of you got problems in having MMC/SD working in a mt7621 board (GB-PC1 in my case), and how to fix that; snapshot build, no mmc module enabled by default. I also noticed GB-PC1 builds with mt76-core which brings in unneeded code and a wpad instance running uselessly, since there is no wi-fi on this
Sep 15 10:22:31 <mrkiko> device.
Sep 15 10:24:00 <jow> aparcar[m]: the libc and kernel packages are intentionally withheld from the package repositories
Sep 15 10:25:27 <gch981213> mrkiko: I tried a build 5 hours ago with default config for gbpc1 and mt76 isn't selected. As for SD card, could you double check if kmod-sdhci-mt7620 is included?
Sep 15 10:25:37 <aparcar[m]> jow: but couldn't they be added to the kmods/ folders and the kmods index?
Sep 15 10:26:37 <mrkiko> gch981213: it's not... I noticed it wasn't included and I didn't include it either since I tough it was mt7620
Sep 15 10:26:44 <gch981213> mrkiko: I'm guessing you probably used an old config and device packages aren't selected
Sep 15 10:26:46 <aparcar[m]> other approach is to add both libc and kernel to the cache folder and install those two files directly, without an index. kmods are remotely installed
Sep 15 10:27:29 <mrkiko> gch981213: I did select my r6220 first, then changed my mind and selected gb-pc1, maybe this influenced?
Sep 15 10:28:39 <mrkiko> gch981213: and, on a totally differnet topic: I remembed you spoke about some netgear devices like the r6220 execuging some sercomm code before loading the kernel or something like that. Where can the that code found? Is in the the u-boot or somewhere else? And what does this code do?
Sep 15 10:29:34 <mrkiko> btw, even ahci wasn't selected
Sep 15 10:29:40 <mrkiko> so probably oyu'rte right
Sep 15 10:30:15 <gch981213> mrkiko: If you saved the config before changing device in menu, packages for the new device won't be selected.
Sep 15 10:31:00 <mrkiko> gch981213: thanks, I'll take care to not do this anymore
Sep 15 10:31:33 <aparcar[m]> jow: okay correction: only add kernel and libc to packages/ folder and disable the index creation + remove the file:packages repository entry. kmods are now downloaded from remote.
Sep 15 10:31:34 <gch981213> mrkiko: I don't remember about those r6220 stuff. Sorry.
Sep 15 10:32:02 <aparcar[m]> I just tested it and seem to work fine. I'm off for now, will send some patches tomorrow
Sep 15 10:32:54 <mrkiko> gch981213: well, don't remember either if it was specific to r6220 or not, thank you very very much!
Sep 15 10:41:04 <mrkiko> don't even remember if it was you telling this or blocktrron ; thank you guys for your help in any case. without your help the ramips 5.4 transition would have been harder...
Sep 15 10:41:10 <mrkiko> for me
**** BEGIN LOGGING AT Tue Sep 15 10:43:03 2020
**** BEGIN LOGGING AT Tue Sep 15 12:27:52 2020
Sep 15 12:55:34 <Zoxc> What do NIC and switch interfaces look like for ARM SoCs?
Sep 15 12:58:10 <mrkiko> for me
Sep 15 12:58:14 <mrkiko> oops, sorry
Sep 15 12:59:06 <hexa-> russell--: f2fs
Sep 15 13:13:21 <greearb> svanheule[m], that is same as bug 123, some buffer memory corruption in the rx logic, and not sure how to make progress on it.
Sep 15 13:15:12 <eduardas> hello, anyone here have experience using libmodbus with RS-485 on embedded Linux?
Sep 15 13:18:19 <mrkiko> to make nand backups, should one use nanddump or cat ? Or both?
Sep 15 13:46:16 <karlp> eduardas: do you have any particular question or concern? it "just works" just like on regular linux...
Sep 15 13:48:37 <eduardas> karlp: yes, I have specific questions. I find that when using modbus_rtu_set_custom_rts, the RTS duration is dependent on usleep function and that gives much too long RTS duration
Sep 15 13:49:08 <eduardas> karlp: I link to ligpiod to implement my callback for modbus_rtu_set_custom_rts
Sep 15 13:49:50 <karlp> I highly recommend not using custom userspace gpios for rts if you're being serious.
Sep 15 13:50:10 <karlp> you're ~always going to have a bad time as soon as you use a device from another vendor that has different timing windows than what you tested with.
Sep 15 13:50:12 <eduardas> karlp: I would have liked to use native RS-485 UART driver functionality (I run on i.MX6UL SoC), but driver gives gaps between bytes periodically when rts-gpios is enabled in devicetree
Sep 15 13:50:37 <karlp> gaps of how long?
Sep 15 13:50:44 <karlp> longer than t3.5?
Sep 15 13:50:45 <eduardas> karlp: I believe this is actually a mainline kernel driver problem, honestly
Sep 15 13:50:49 <karlp> if so, fix that driver
Sep 15 13:51:08 <karlp> you'll have _far_ more happiness with that than with trying to speed up user space delays on gpio toggling
Sep 15 13:51:45 <karlp> what I've done before is to just hardcode the gpios into the serial driver, before rts-gpios features were available.
Sep 15 13:51:45 <eduardas> karlp: I do not have that option since I do this for my dayjob and I was asked for a quick workaround
Sep 15 13:52:00 <karlp> it's almost guaranteed to be the quicker turnaround still.
Sep 15 13:52:12 <eduardas> karlp: I was never given the opportunity to learn driver development as such
Sep 15 13:52:28 <karlp> seriously, how are you possibly going to sleep predictably in user space around the kernel serial layer?
Sep 15 13:53:14 <karlp> are you getting the driver enable held on for too long after the transmission has finished?
Sep 15 13:53:32 <karlp> how constrained is your environment, can you get the other devices to delay before replying?
Sep 15 13:53:34 <eduardas> karlp: if it is really so bad, why does libmodbus even bother implementing a custom callback for RTS?
Sep 15 13:53:48 <karlp> eduardas: because some people insisted on it, and it sort of owrks for some people
Sep 15 13:53:55 <karlp> but it's never going to make you happy long term.
Sep 15 13:54:57 <eduardas> karlp: I am aware of that. But I really do not have many options if I can not fix the driver myself.
Sep 15 14:00:13 <karlp> it's one of the most common bug reports/issues on libmodbus is it not doing what people hoped it would do.
Sep 15 14:02:39 <eduardas> karlp1: just wondering: libmodbus is the most popular FOSS Modbus RTU implementation on Linux?
Sep 15 14:03:05 <eduardas> karlp1: because it seemed to me that way when I needed to justify using it
Sep 15 14:03:40 <karlp1> sorry, got lost there. https://paste.jvnv.net/view/3LYMM
Sep 15 14:03:54 <karlp1> eduardas: there's not really many others that I'm aware of.
Sep 15 14:04:09 <karlp1> there's two python modules, but they require python
Sep 15 14:04:30 <karlp1> I've heard anecdotally that the differences between them is mostly in how they handle (or not) RTU timing.
Sep 15 14:04:45 <eduardas> karlp1: thank you for posting that paste
Sep 15 14:05:39 <karlp1> are you _sure_ you're getting interbyte delays on the imx uart _only_ when adding rts-gpios?
Sep 15 14:05:55 <karlp1> it would seem unrelated, or at least, should be.
Sep 15 14:06:08 <eduardas> karlp1: pretty sure, I will post logic analyzer output.. a moment
Sep 15 14:07:15 <eduardas> karlp1: https://imgur.com/kCoyOAH
Sep 15 14:07:41 <eduardas> karlp1: I just echo a bunch of As to /dev/ttymxc4
Sep 15 14:08:04 <eduardas> and the gaps are not present when not using rts-gpios in dts
Sep 15 14:10:47 <karlp1> are those individual bytes?
Sep 15 14:11:16 <karlp1> or is that "a few bytes, big gap, a few more bytes, big gap, few more bytes" ?
Sep 15 14:12:27 <eduardas> karlp1: it is as you've just described
Sep 15 14:12:29 <karlp1> if you're doing the same methodolgy for testing with and without rts gpios and getting that clear an issue, I'd be very much looking at what the rts-gpios handling for your uart is actually doing.
Sep 15 14:12:56 <karlp1> if you're using a ~close to upstream kernel and write nicely, you might be able to get help on it as well.
Sep 15 14:13:12 <karlp1> but this isn't really anything to do with openwrt
Sep 15 14:13:19 <eduardas> karlp1: I am using upstream 5.8.5 with custom dts
Sep 15 14:13:37 <eduardas> karlp1: but I am not sure to whom exactly I can complain
Sep 15 14:13:48 <karlp1> should be pretty easy to get linux-serial to help you then,
Sep 15 14:14:38 <karlp1> have you tried other modes from https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt ?
Sep 15 14:14:40 <eduardas> karlp1: that is a mailing list. There is no dedicted freenode channel for this as far as I understand
Sep 15 14:15:04 <karlp1> yes, you will need to write a nice clear email to them.
Sep 15 14:15:11 <eduardas> karlp1: also I wanted to find someone with i.MX6 hardware using rts-gpios with mainline to verify this
Sep 15 14:15:23 <karlp1> that mailing list is th ebest place for that.
Sep 15 14:15:29 <eduardas> karlp1: just to do a sanity check
Sep 15 14:15:37 <karlp1> openwrt doesn't actually run mainline
Sep 15 14:15:51 <karlp1> so you're not really looking in the right place, you just got lucky
Sep 15 14:16:07 <karlp1> I'd try uart-has-rtscts and use the cts line instead, see if that still gives you the delays
Sep 15 14:16:51 <eduardas> karlp1: I googled some cases where people were using libmodbus on openwrt, so that is why I thought asking
Sep 15 14:17:11 <eduardas> karlp1: also asked on yocto and other channels
Sep 15 14:18:14 <eduardas> karlp1: I though that it's the best I can do quickly since I'm not subscribed to any mailing lists at the moment
Sep 15 14:20:22 <eduardas> karlp1: and just to answer your question: yes, I'm aware of those settings and I've played around with them
Sep 15 14:21:01 <mrkiko> svanheule[m]: congrats for your device additions; fine soldering scares me a little bit :D
Sep 15 14:21:57 <svanheule[m]> mrkiko: thanks!
Sep 15 14:22:18 <svanheule[m]> mrkiko: wait till you see what I'm doing to TP-Link's OC200
Sep 15 14:22:22 <stintel> :P
Sep 15 14:22:32 <stintel> I will have a go at that too, soon
Sep 15 14:22:43 <svanheule[m]> mrkiko: https://tweakers.net/fotoalbum/image/xjUZySIf8gGjbbbOIZqMtlhq.jpg
Sep 15 14:22:56 <svanheule[m]> the bottom pins  are your everyday 2.54mm header
Sep 15 14:23:00 <eduardas> karlp1: thank you for your advice. I think this is very useful.
Sep 15 14:24:00 <karlp1> I'd very carefully confirm that the inserted delays are _only_ from rts-gpios as my number one step, and if so, take that to linux-serial.  if the hardware isn't fixed yet, and you don't get delays with uart-has-rtscs, I'd use that, and just move on with life.
Sep 15 14:25:23 <mrkiko> svanheule[m]: no recovery for those devices in general unfortunately ...
**** BEGIN LOGGING AT Tue Sep 15 14:48:44 2020
Sep 15 16:05:43 <pavlix> Hello. I cannot get gdb running on build host due to the requirement for NCURSESW6_5.1.20000708
Sep 15 16:06:11 <pavlix> The distro ncurses is  relatively new ncurses 6 version.
Sep 15 16:06:27 <pavlix> Is there a way to get OpenWRT build its own ncurses and use it?
Sep 15 16:51:48 <Borromini> svanheule[m]: is there a tp-link firesale you took advantage of? :D
Sep 15 16:53:50 <stintel> Borromini: it was shipped to him by another Stijn
Sep 15 16:54:40 <svanheule[m]> Borromini: It's not what it looks like! I'm not a TP-Link fanboy :P
Sep 15 16:54:46 <Borromini> stintel: oh you sent it to him? :D
Sep 15 16:54:51 <Borromini> funny coincidence :P
Sep 15 16:54:59 <Borromini> svanheule[m]: i was getting worried.
Sep 15 16:55:00 <stintel> (after said other Stijn bricked his first OC200 and failed to get UART on the 2nd :P)
Sep 15 16:55:14 <Borromini> :P
Sep 15 16:55:27 <svanheule[m]> anyone else named Stijn wants to send me hardware? ;-)
Sep 15 16:55:50 <stintel> I have 2 colleagues also called Stijn, I can ask them :P
Sep 15 16:56:09 <Borromini> haha while we're at it
Sep 15 16:56:19 <Borromini> i have this funny thing. i ordered custom M&M's
Sep 15 16:56:30 <Borromini> you know, from Mars
Sep 15 16:57:03 <Borromini> but it seems just today (when i want to see where the delivery is at, track & trace) their google hosted domain seems to suffer from an expired certificate >_>
Sep 15 16:57:06 <Borromini> mymmseu.com
Sep 15 16:57:12 <Borromini> is this working for you guys?
Sep 15 16:57:20 <Borromini> i get 'has expired'
Sep 15 16:57:28 <svanheule[m]> me too
Sep 15 16:57:47 <svanheule[m]> they get your personal info, and then they vanish?
Sep 15 16:58:06 <stintel> at least they didn't get your nudes :)
Sep 15 16:58:49 <Borromini> worse :(
Sep 15 16:58:53 <Borromini> they got my credit card :D
Sep 15 16:59:16 <Borromini> weird. mms.com/be-nl/ shows the expired certificate message but then does show the site
Sep 15 17:37:05 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.1% images and 99.7% packages reproducible in our current test framework.)
Sep 15 19:04:22 <philipp64|work> got a question about GRE tunnels for anyone who wants to answer…. I understand that they need (a) fixed endpoints (“local” and “remote”), (b) a device name (of course), and (c) a route pointing to what network(s) are reachable via this tunnel… why does it also need an interior address to the tunnel, usually as a /30? What does that address ever get used for?