**** BEGIN LOGGING AT Mon Sep 14 02:59:57 2020
**** BEGIN LOGGING AT Mon Sep 14 03:09:52 2020
Sep 14 05:17:30 <rmilecki> jow: i see one reason why LuCI uses fallback for me
Sep 14 05:18:01 <rmilecki> jow: probeRPCBaseURL() seems to depend on uhttpd ubus replying 400 for GET requests
Sep 14 05:18:56 <rmilecki> my patch breaks that by adding support for GET requests and replying to them only with 200, 404 and 500 codes
Sep 14 05:32:51 <owrt-snap-builds> build #546 of cns3xxx/generic is complete: Failure [failed checkarch]  Build details are at http://buildbot.openwrt.org/master/images/builders/cns3xxx%2Fgeneric/builds/546  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>
**** BEGIN LOGGING AT Mon Sep 14 05:36:02 2020
**** BEGIN LOGGING AT Mon Sep 14 05:38:52 2020
Sep 14 06:59:35 <jow> rmilecki: that might be the case, yes
Sep 14 07:00:08 <jow> rmilecki: maybe you can add some "|| res.code = 200" condition or similar.
Sep 14 07:28:53 <aparcar[m]> jow: could you please send me a makefile for utpl?
Sep 14 07:31:35 <jow> aparcar[m]: this is what I use: https://gist.github.com/jow-/d6d82ec44d5af56072e67ad82321a1f2
Sep 14 07:31:45 <jow> together with CONFIG_SRC_TREE_OVERRIDE + git-src
Sep 14 07:32:04 <aparcar[m]> all right thanks!
Sep 14 07:36:03 <aparcar[m]> jow: may I ask why ISC and not MIT?
Sep 14 08:25:41 <jow> aparcar[m]: ISC is simpler, I like simple and short licenses
Sep 14 08:41:55 <stintel> heh I don't get this. excess flood is freenode terminating the connection, why don't they bloody gline a client / IP after this happens 10 times in an hour
Sep 14 08:42:17 <stintel> s/free/fail/
Sep 14 08:43:08 <rmilecki> jow: Linux developers on the other hand want MIT instead of ISC
Sep 14 08:46:04 <rmilecki> see https://www.spinics.net/lists/linux-xfs/msg17623.html and https://www.spinics.net/lists/linux-xfs/msg17627.html
Sep 14 08:46:24 <rmilecki> ("want" may be too strong)
Sep 14 08:46:34 <jow> rmilecki: I don't plan to develop Kernel code though :)
Sep 14 08:47:15 <stintel> what's wrong with GPLv3
Sep 14 08:47:16 * stintel hides
Sep 14 08:47:28 <jow> sorry, I do software, not politics
Sep 14 08:48:37 <rmilecki> stintel: Linus likes GPLv2 for the freedom it gives AFAIR
Sep 14 08:49:43 <rmilecki> $ git log --oneline --author="Jo-Philipp" | wc -l
Sep 14 08:49:44 <rmilecki> 1
Sep 14 08:50:07 <rmilecki> oh, I thought you did some kernel development
Sep 14 08:50:31 <jow> no I leave that to the people who know what they're doing :)
Sep 14 08:50:32 <rmilecki> ALSA quick doesn't count ;)
Sep 14 08:50:40 <stintel> git shortlog --summary --author=Jo-Phillip ;)
Sep 14 08:51:18 <rmilecki> jow: oh, you surely wouldn't manage to get any kernel commit right :D
Sep 14 08:51:20 <stintel> minus the typo
Sep 14 08:51:39 <olmari> I kinda loke GPLv2, too, it is clear what it wants.. v3 adds unneccesary things in it... but then again I'm just hobbyist coder anyway =)
Sep 14 08:51:47 <olmari> like*
Sep 14 08:51:51 <rmilecki> jow: one of the best OpenWrt hacker ;)
Sep 14 09:12:14 <rmilecki> jow: what about sending OPTIONS to /ubus and checking for 200?
Sep 14 09:12:37 <rmilecki> OPTIONS seems to be mostly used by CORS but it doesn't seem to be requirement
Sep 14 09:19:06 <jow> I thin kthe best test would be sending an actual ubus rquest and checking for a valid reply, not trying to interpret failure states
Sep 14 09:20:24 <rmilecki> jow: but still as part of the probeRPCBaseURL() ?
Sep 14 09:24:16 <rmilecki> jow: should I try calling some existing ubus method? and treat any response 200 as succeess (even if that 200 is JSON-RPC reply with error code)?
Sep 14 09:24:47 <rmilecki> or should I try calling "foo" (literally) ubut object method "bar" (literally)?
**** BEGIN LOGGING AT Mon Sep 14 09:54:18 2020
**** BEGIN LOGGING AT Mon Sep 14 09:59:59 2020
Sep 14 11:46:59 <stintel> https://nvidianews.nvidia.com/news/nvidia-to-acquire-arm-for-40-billion-creating-worlds-premier-computing-company-for-the-age-of-ai
Sep 14 11:47:01 <stintel> oh dear :(
Sep 14 11:48:59 <jow> rmilecki: calling session/access with object: session and method: access might make sense
Sep 14 11:49:23 <karlp> stintel: what are your fears?
Sep 14 11:49:31 <rmilecki> jow: like that
Sep 14 11:51:58 <jow> karlp: that router enclosures will now come with glowing green ornaments :P
Sep 14 12:00:31 <rmilecki> jow: can you check this line? https://git.openwrt.org/?p=project/luci.git;a=blob;f=modules/luci-base/htdocs/luci-static/resources/rpc.js;h=7bfc913367a529b3ccb29dfc47be78c961ab0b1a;hb=HEAD#l37
Sep 14 12:01:06 <jow> rmilecki: its a cosmetical / convience feature
Sep 14 12:01:06 <rmilecki> jow: for rpcBaseURL being "/ubus/" above results in e.g. "/ubus//luci.getFeatures" (double slash)
Sep 14 12:01:33 <rmilecki> it's cosmetical as grouping requests hides URL detail anywa
Sep 14 12:01:39 <rmilecki> but looks like a minor typo still?
Sep 14 12:02:19 * rmilecki missied it's 14:00, running for a dinner
Sep 14 12:03:39 <jow> rmilecki: yeas, seems so
Sep 14 12:18:48 <stintel> karlp: license price increase and blobs :P
Sep 14 12:42:16 <rmilecki> jow: i believe i found some weird behaviour with unmodified uhttpd and luci, see https://pastebin.com/fCj7Kdb8
Sep 14 12:43:03 <rmilecki> it seems uhttpd replies twice to the first JSON-RPC?
Sep 14 12:43:42 <rmilecki> and then LuCI handler treates duplicated features reply as a reply to the "file" "list" JSON-RPC request
Sep 14 12:44:11 <rmilecki> maybe one of my recent changes broke that :|
Sep 14 12:44:24 <rmilecki> maybe I dropped some code cleaning a buffer
Sep 14 12:45:14 <rmilecki> candidate: https://git.openwrt.org/?p=project/uhttpd.git;a=commitdiff;h=628341fae41230627ff4055b248698bb6ed007a8 ("ubus: use local "blob_buf" in uh_ubus_handle_request_object()")
Sep 14 12:45:20 <rmilecki> i'll try to debug and fix that, just a heads up
Sep 14 12:49:17 <stintel> karlp: not to mention this US trade war blacklist crap. if ARM becomes US owned HiSilicon is for sure dead. and who knows how many companies will follow
**** BEGIN LOGGING AT Mon Sep 14 12:51:40 2020
**** BEGIN LOGGING AT Mon Sep 14 13:05:47 2020
Sep 14 14:36:39 <hexa-> mwarning: deeplink would be benefitial to yafs
Sep 14 14:36:42 <hexa-> deeplinking*
Sep 14 14:36:49 <hexa-> beneficial
Sep 14 14:37:32 <hexa-> i'll create an issue
Sep 14 15:51:44 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (54.5% images and 100.0% packages reproducible in our current test framework.)
**** BEGIN LOGGING AT Mon Sep 14 16:56:54 2020
Sep 14 17:39:06 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
**** BEGIN LOGGING AT Mon Sep 14 17:45:37 2020
Sep 14 18:23:42 <Hauke> stintel: this could be good for RISC-V
Sep 14 18:25:43 <Hauke> the bigger problem is that nVidia is a competitor to some of the ARM customers
Sep 14 18:27:08 <Hauke> there are not so many alternatives to ARM in these days
Sep 14 19:55:36 <mrkiko> Hello nice guys!! Two notes on my recent openwrt snapshot build with GB-PC1: 1) mt76-core is brought in uselessly, bringing in wpad as well, running with no purpose on the system. 2) the SD card doesn't work anymore. Any recommendations for that? It doesn't show. Maybe i should enable the mmc kernel module manually??
Sep 14 19:56:18 <mrkiko> The mt76-core issue isn't as important, even tough occupying resource uselessly isn't great. The SD card thing would be more important to me.
Sep 14 19:56:44 <mrkiko> And so any hint would be welcome... gch9812136
Sep 14 20:00:24 <mrkiko> BTW - github issues disabled on the openwrt ?
Sep 14 20:00:30 <mrkiko> git repo? No more PRs?
Sep 14 20:02:11 <stintel> mrkiko: PRs are a different tab, issues -> https://bugs.openwrt.org
Sep 14 20:03:18 <mrkiko> stintel: oh, sorry, I am looking at this from CLI with the "ghi" tool
Sep 14 20:03:33 <stintel> np :)
**** BEGIN LOGGING AT Mon Sep 14 20:30:32 2020
Sep 14 20:33:54 <Tapper> Hi people now we are rolling out the firmware selector I think it would be a good thing to start including LUCI in snapshots.
Sep 14 20:34:34 <Tapper> If any one installs a snapshot there will not be left with a webinterface.
Sep 14 20:34:42 <Tapper> without*
Sep 14 20:43:40 <mrkiko> Tapper: oh no, please ...
**** BEGIN LOGGING AT Mon Sep 14 20:57:21 2020
Sep 14 21:09:07 <Tapper> mrkiko If you want a custem build would not you build it on your computer insted of downloading a snapshot?
Sep 14 21:15:06 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
Sep 14 23:05:55 <aparcar[m]> zorun: thanks for your review
**** BEGIN LOGGING AT Mon Sep 14 23:12:46 2020
Sep 15 00:48:55 <lmore377> would it be rude to re-request a review from the 3 people that have looked at my pr? https://github.com/openwrt/openwrt/pull/3115
Sep 15 00:51:43 <pkgadd> imho a gentle ping wouldn't be a problem
Sep 15 00:52:41 <pkgadd> if only that or a similarly priced ipq8065 device would be available on this side of the pond :(
Sep 15 00:59:56 <lmore377> pkgadd: just keep an eye out on sites like ebay. im not sure how shipping would be but i always see people posting this router on there (probably not knowing that they'll be charged by the isp)
Sep 15 01:21:32 <pkgadd> lmore377: shipping and duties kill it (more than the the device price itself, 30-50 USD for shipping and duties alone)
**** BEGIN LOGGING AT Tue Sep 15 01:43:13 2020
Sep 15 01:45:09 <hexa-> what would be way to make sure the overlay is synced to disk before rebooting? calling `sync` apparently does not work for that and when I reboot too fast the changes to the overlay are just gone
**** BEGIN LOGGING AT Tue Sep 15 02:01:11 2020
**** ENDING LOGGING AT Tue Sep 15 02:59:57 2020