**** BEGIN LOGGING AT Tue Jan 22 02:59:56 2019
Jan 22 03:06:46 <owrt-snap-builds> build #1181 of ramips/rt3883 is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Frt3883/builds/1181
Jan 22 05:58:23 * russell-- has an espressobin on r8984-6ba58b7b02 where eth0 (wan) seems to go away after a while, shows up, can't ping anything
Jan 22 06:41:50 <television> hello
Jan 22 06:42:53 <jow> morning
Jan 22 06:43:50 <jow> ynezz: since you last commented on the topic - any reason to not merge https://github.com/openwrt/openwrt/pull/1493 ?
Jan 22 06:45:44 <russell--> ah, local routing nonsense was responsible
Jan 22 07:00:25 <jow> sigh, walking through the open github prs is painful
**** BEGIN LOGGING AT Tue Jan 22 07:44:58 2019
Jan 22 07:47:15 <mangix> hmm? why is that?
Jan 22 07:52:16 <jow> it takes ages, and every pr I look at has issues in one form or another
Jan 22 07:55:08 <ynezz> jow: I've commented on PR#1000 which was ar71xx predecesor of ath79 PR#1493, and from my point of view it looks like "just" flash access improvement only for some cases (like certain flashsize, >= 16M ?), but could probably cause regressions as it wasn't tested properly on all SoCs it touches yet
Jan 22 07:55:45 <jow> ynezz: so we reject it? Too much risk, too little gains?
Jan 22 07:56:09 <jow> I think we should start to close PRs we do not want to take instead of having them linger forever
Jan 22 07:56:19 <ynezz> no, I wouldn't reject it, just needs more time to do testing
Jan 22 07:56:41 <jow> well, do we have the time and resources to do that testing before the entire target becomes obsolete?
Jan 22 07:56:52 <ynezz> well, there are more important things to fix/improve in ath79 :)
Jan 22 07:57:05 <jow> thats what I was getting at
Jan 22 07:57:23 <ynezz> I'll take care of that PR, I'll message you when it's tested and ready for merge
Jan 22 07:57:50 <jow> no hurry, didn't want to single you out on that one, it just happened to be one of these "meh" PRs I've skimmed over
Jan 22 07:57:53 <ynezz> there was some time spent on it already, so it would be waste to just reject it, and some devs are interested in such improvements
Jan 22 08:03:13 <ynezz> regarding GitHub, it seems like it has the lowest barrier for potential contributors, so from this point of view it's good for the project I think
Jan 22 08:04:23 <jow> well not questioning github per-se (this time), I just have the feeling that noone dares to close/reject PRs that have no chance to get merged
Jan 22 08:04:27 <ynezz> but I understand, that it needs a lot of time to get through the discussion to the point where one can realize if it's ready for merge or not
Jan 22 08:06:54 <dedeckeh> jow:I've PR1585 in my staging tree but I still need to run test it
Jan 22 08:09:47 <jow> mangix: I think your aria2 openssl patch might have been faulty
Jan 22 08:09:57 <mangix> elaborate
Jan 22 08:09:59 <jow> mangix: a user reports https://forum.openwrt.org/t/aria2-error-ssl-ctx-new-failed/29667
Jan 22 08:10:13 <jow> mangix: openssl errstr 140A90A1 => error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
Jan 22 08:10:37 <jow> mangix: this commonly happens when a SSL_library_init(); call is missing
Jan 22 08:11:03 <mangix> that....is weird
Jan 22 08:11:14 <mangix> there was a discussion about it actually
Jan 22 08:11:42 <mangix> both me and the maintainer couldn't figure out the reason for the patch
Jan 22 08:12:12 <mangix> https://github.com/openwrt/packages/pull/7891
Jan 22 08:12:20 <jow> I don't have enough context to know where the "OPENSSL_101_API" define comes from
Jan 22 08:12:36 <jow> but openssl 1.0.2 also still needs SSL_library_init()
Jan 22 08:12:44 <mangix> yes it does
Jan 22 08:13:12 <mangix> one possibility is that the header where OPENSSL_101_API is not included
Jan 22 08:13:20 <mangix> but then wouldn't GCC throw an error?
Jan 22 08:13:47 <jow> nope
Jan 22 08:14:22 <jow> echo -e '#if !DOESNOTEXIST\n#warning foo\n#endif' | gcc -x c -E -
Jan 22 08:14:25 <jow> throws no error
Jan 22 08:14:48 <mangix> that would explain everything then
Jan 22 08:14:54 <jow> that define name is confusing though
Jan 22 08:15:14 <jow> OPENSSL_101_API is true if OPENSSL_VERSION_NUMBER >= 0x1010000fL
Jan 22 08:15:28 <jow> thats not openssl 1.0.1 api but openssl 1.1 api
Jan 22 08:15:56 <mangix> yeah it just takes it from the version number without the ending 0s
Jan 22 08:16:09 <mangix> OPENSSL_API_VERSION is the same way
Jan 22 08:16:19 <jow> the define should be called OPENSSL_1_1_API
Jan 22 08:16:22 <jow> imho
Jan 22 08:17:55 <jow> anyhow, after this PR, aria2 will call deprecated SSL_library_init() when openssl version >= 1.1.0 which looks inverted
Jan 22 08:18:11 <jow> and will not call it for openssl < 1.1.0
Jan 22 08:18:22 <jow> while it actually is required with these versions
Jan 22 08:23:23 <mangix> yeah the original patch was almost correct
Jan 22 08:25:03 <blogic> hi
Jan 22 08:25:30 <mangix> hello
Jan 22 08:28:13 <jow> howdy blogic
Jan 22 08:43:53 <mangix> jow: https://github.com/openwrt/packages/pull/8011
Jan 22 09:19:39 <owrt-snap-builds> build #1217 of at91/legacy is complete: Failure [failed images]  Build details are at http://phase1.builds.lede-project.org/builders/at91%2Flegacy/builds/1217  blamelist: Milan Krstic <milan.krstic@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Jeffery To <jeffery.to@gmail.com>, Michal Hrusecky <Michal@Hrusecky.net>, Peter Wagner <tripolar@gmx.at>,
Jan 22 09:19:39 <owrt-snap-builds> Matthias Badaire <mbadaire@gmail.com>, Carsten Wolff <carsten@wolffcarsten.de>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Jo-Philipp Wich <jo@mein.io>
Jan 22 09:40:36 <jow> bam, build fail. Why do I always fall into dizzy's PR traps...
Jan 22 09:44:44 <blogic> jow: not learned the lesson yet ?
Jan 22 09:44:46 <blogic> :-)
Jan 22 09:44:55 <television> lol
Jan 22 09:47:29 <KanjiMonster> the at91 build seems to fail because of a race in the image build code
Jan 22 09:49:33 <jow> KanjiMonster: I was refering to something else
Jan 22 09:49:44 <jow> libreadline/host fails to build for me now since the 8.0 bump
Jan 22 09:49:49 <KanjiMonster> ah
Jan 22 09:49:52 <jow> -fPIC woes
Jan 22 11:50:33 <ynezz> Hauke: do you've an idea where should CONFIG_USB_ROLE_SWITCH kernel config go, generic or the platform one? context https://github.com/openwrt/openwrt/pull/1694#issuecomment-455857434
Jan 22 12:26:03 <xback> ldir: fyi musl bump to 1.1.21 pushed to my staging
Jan 22 12:29:05 <ldir> xback: thank you Sir
Jan 22 12:39:53 <karlp> heh, if you thought the openssl deprecated patches were a sea, I'm now starting to see people doing driveby fixes for 2038 time_t "problems"
Jan 22 12:54:39 <jow> xback: ping
Jan 22 12:55:32 <xback> jow: pong
Jan 22 12:57:29 <jow> xback: f3b80c36bb01fa7cf4181828d78da8a66f46c31d ("ar71xx: fix sysupgrade generation for some targets") removed the "os-image" and "file-system" entries for various entries, yet the .first_sysupgrade_partition and .last_sysupgrade_partition members still mention them, how does it work?
Jan 22 12:57:42 <jow> is the tplink mtd splitter still providing these partitions at runtime?
Jan 22 13:00:46 <jow> or are these struct members completely unused now? If so, we should probably drop them
Jan 22 13:03:09 <xback> jow: checking for the details to properly answer this .. but the changes were tested by various users
Jan 22 13:05:16 <jow> xback: yeah, I figured that it works... just want to know why :D
Jan 22 13:07:16 <dwmw2_gone> hm, is there a way to ensure that a service is *disabled* after sysupgrade?
Jan 22 13:07:36 <dwmw2_gone> I can make sure one's enabled by including the S99foobar symlink in the keep.d files.
Jan 22 13:07:50 <dwmw2_gone> can't see how to make sure it's disabled though.
Jan 22 13:10:03 <KanjiMonster> dwmw2_gone: the only solution currently is to have a dis- or enabled uci option for the service
Jan 22 13:14:01 <dwmw2_gone> in fact I do want it to run, but it can't run before a certain interface comes up
Jan 22 13:14:53 <dwmw2_gone> it's bind (named) and it binds(2) to a specific address. An address that doesn't exist on the system at boot. And which it can't bind(2) to later because it's already dropped privs and is no longer root.
Jan 22 13:15:14 <dwmw2_gone> dnsmasq seems to have the same problem, in fact. Running as user 'dnsmasq', if I later run 'ifup lan' it can't re-bind to that address, and stops serving DHCP
Jan 22 13:18:03 <jow> mkresin: ping
Jan 22 13:23:15 <xback> jow: seesm to be due to this part:  https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=tools/firmware-utils/src/tplink-safeloader.c;h=74ea6976348d5051ebaf18fc3e5fef5ebf3205cf;hb=HEAD#l1615
Jan 22 13:23:24 <xback> line 1615
Jan 22 13:26:29 <xback> splits the fw again based on firmware-image input as input to the builder  (if I'm reading this correctly)
Jan 22 13:27:40 <jow> xback: ah ok
Jan 22 13:27:48 <jow> makes sense
Jan 22 13:28:11 <xback> it allows easy swapping between fixed an dynamic partitions
Jan 22 13:28:22 <xback> by only changing the partition overview in the structs
Jan 22 13:30:13 <jow> we should remove the member assignment for the dynamic case though and do it inside that if (firmware) { ... } block though
Jan 22 13:31:18 <mkresin> jow: pong
Jan 22 13:32:07 <jow> mkresin: do we require tftp install instructions for device support commits?
Jan 22 13:32:26 <jow> or is an instruction like "upload generated factory image via vendor web ui" enough?
Jan 22 13:33:50 <mkresin> jow: if the later works it is fine. if you need to exploit some web ui bugs to upload owrt, a more reliable method should be mentioned in the commit message
Jan 22 13:34:19 <jow> thanks
Jan 22 13:34:30 <xback> jow: agreed
Jan 22 14:16:06 <owrt-snap-builds> build #1202 of x86/legacy is complete: Failure [failed targetupload]  Build details are at http://phase1.builds.lede-project.org/builders/x86%2Flegacy/builds/1202  blamelist: Milan Krstic <milan.krstic@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Jeffery To <jeffery.to@gmail.com>, Michal Hrusecky <Michal@Hrusecky.net>, Peter Wagner
Jan 22 14:16:06 <owrt-snap-builds> <tripolar@gmx.at>, Matthias Badaire <mbadaire@gmail.com>, Carsten Wolff <carsten@wolffcarsten.de>, Kuang Rufan <master@a1983.com.cn>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Jo-Philipp Wich <jo@mein.io>, Andy Walsh <andy.walsh44+github@gmail.com>
Jan 22 14:17:08 <owrt-snap-builds> build #395 of ipq40xx/generic is complete: Failure [failed kmodupload]  Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/395  blamelist: Milan Krstic <milan.krstic@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Jeffery To <jeffery.to@gmail.com>, Michal Hrusecky <Michal@Hrusecky.net>, Peter Wagner
Jan 22 14:17:08 <owrt-snap-builds> <tripolar@gmx.at>, Matthias Badaire <mbadaire@gmail.com>, Carsten Wolff <carsten@wolffcarsten.de>, Kuang Rufan <master@a1983.com.cn>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Jo-Philipp Wich <jo@mein.io>, Andy Walsh <andy.walsh44+github@gmail.com>
Jan 22 15:03:24 <ldir> dwmw2_gone: does setting "option nonwildcard '1'" aka --binddynamic in dnsmasq-speak help?
Jan 22 15:15:53 <dwmw2_gone> ldir: it's already doing that.
Jan 22 15:16:24 <ldir> dammit
Jan 22 15:17:56 <dwmw2_gone> other than that though, yay. I finally have my house updated to 18.06 :)
Jan 22 15:18:20 <dwmw2_gone> and seamlessly surviving sysupgrades, even the wndr3800 which has to have domoticz on a USB stick because it won't fit in the internal flash
Jan 22 15:18:39 <dwmw2_gone> so there's a symlink farm, all listed in /lib/update/keep.d/domoticz :)
Jan 22 15:19:02 <dwmw2_gone> I did try to put domoticz on the lantiq box with more flash and RAM, but that falls over if you actually try to use its USB port.
Jan 22 15:20:17 <jow> mkresin: canyou take a brief look at the last two commits in my staging tree?
Jan 22 15:34:07 <mkresin> jow: I would suggest a few changes: drop default-state = "off" from the leds. a recent commit has done it treewide
Jan 22 15:34:47 <mkresin> jow: heartbeat trigger looks unusual. is it even enabled/included/compiled anywhere
Jan 22 15:35:57 <mkresin> jow: KERNEL_INITRAMFS can be dropped. it defaults to the kernel build recipe anyway
Jan 22 15:39:26 <gch981213> jow: Regarding that Archer C2 commit: The image building code is exactly the same as Device/tplink-safeloader-uimage defined in common-tp-link.mk.
Jan 22 15:47:12 <jow> I wonder how the other archer build recipes can work without setting TPLINK_HWID
Jan 22 15:47:38 <jow> that variable seems to be used by "tplink-v1-header"
Jan 22 15:47:52 <jow> but its not set everywhere and I cannot find a generic or fallback declaration for it
Jan 22 15:49:38 <jow> mkresin: so for the system led you want `default-state = "on";` ?
Jan 22 15:50:18 <owrt-snap-builds> build #293 of at91/sama5d2 is complete: Failure [failed targetupload]  Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/293  blamelist: Milan Krstic <milan.krstic@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Jeffery To <jeffery.to@gmail.com>, Michal Hrusecky <Michal@Hrusecky.net>, Peter Wagner
Jan 22 15:50:18 <owrt-snap-builds> <tripolar@gmx.at>, Matthias Badaire <mbadaire@gmail.com>, Carsten Wolff <carsten@wolffcarsten.de>, Kuang Rufan <master@a1983.com.cn>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Jo-Philipp Wich <jo@mein.io>, Andy Walsh <andy.walsh44+github@gmail.com>
Jan 22 15:52:01 <ynezz> jow: no, just drop that `default-state = "off";` line as it's default, see https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=0d23fd2ab29a66f5d03187db4fac3e396b4f3b62
Jan 22 15:52:25 <jow> ynezz: I mean "jow: heartbeat trigger looks unusual. is it even enabled/included/compiled anywhere"
Jan 22 15:52:33 <jow> the system led uses heartbeat
Jan 22 15:52:42 <ynezz> ah, sorry
Jan 22 15:52:55 <jow> the other Archer xyz dts files use default-state on
Jan 22 15:53:03 <jow> for the system led
Jan 22 15:54:30 <ynezz> I would say yes, "on" as the heartbeat would clash with diag.sh signal states
Jan 22 15:54:42 <jow> okay, updated the commit in my staging tree
Jan 22 15:54:51 <jow> also incorporated gch981213's feedback
Jan 22 15:56:05 <mkresin> jow: default on for the system led is fine
Jan 22 15:57:11 <jow> https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=eee7647fe2898537a9793dcb265d45e21c71ab49
Jan 22 15:57:16 <mkresin> jow: wouldn'T be surprised if TPLINK_HWID is a copy/paste. but would need to check to be sure
Jan 22 15:57:59 <jow> I still not understand how tplink-v1-header (tplink-safeloader-uimage) works without it being defined
Jan 22 16:00:22 <gch981213> jow: tplink-safeloader uses that but tplink-safeloader-uimage doesn't
Jan 22 16:00:48 <jow> ah right
Jan 22 16:00:51 <jow> facepalm
Jan 22 16:02:48 <jow> seems SUPPORTED_DEVICES is lacking too, yet
Jan 22 16:05:59 <gch981213> jow: There is a auto-generated one in https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/image/Makefile;h=734f27e689c9d76abedad8c89f22a24006ba86ae;hb=HEAD#l63
Jan 22 16:07:03 <gch981213> Additional SUPPORTED_DEVICES in ath79 are for sysupgrade compatibility from ar71xx
Jan 22 16:07:53 <jow> ok, so not relevant for a new device
Jan 22 16:09:06 <jow> mkresin: TPLINK_HWID dropped as well
Jan 22 16:16:19 <Slimey> morning
Jan 22 17:59:18 <owrt-snap-builds> build #278 of gemini/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/gemini%2Fgeneric/builds/278
Jan 22 19:00:50 <owrt-snap-builds> build #100 of ath79/tiny is complete: Failure [failed targetupload]  Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Ftiny/builds/100  blamelist: Milan Krstic <milan.krstic@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Jeffery To <jeffery.to@gmail.com>, Michal Hrusecky <Michal@Hrusecky.net>, Carsten Wolff
Jan 22 19:00:50 <owrt-snap-builds> <carsten@wolffcarsten.de>, Matthias Badaire <mbadaire@gmail.com>, Kuang Rufan <master@a1983.com.cn>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Jo-Philipp Wich <jo@mein.io>, Andy Walsh <andy.walsh44+github@gmail.com>
Jan 22 20:25:57 <owrt-snap-builds> build #1218 of at91/legacy is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/at91%2Flegacy/builds/1218
Jan 22 20:49:28 <Borromini> i scoured throughc
Jan 22 20:49:35 * Borromini apologises
Jan 22 21:22:20 <jwh> hm, any safeloader magicians around?
Jan 22 21:22:52 <jwh> specifically, tools/firmware-utils/src/tplink-safeloader.c
Jan 22 21:25:24 * Monkeh shudders
Jan 22 21:25:48 <jwh> :D
Jan 22 21:26:02 <Monkeh> Go on, ask some questions. :P
Jan 22 21:26:05 <jwh> I'm trying to figure out what this model wants
Jan 22 21:26:22 <jwh> I'm missing a crucial bit I think
Jan 22 21:28:12 <jwh> for added fun, cu is busted on alpine
Jan 22 21:28:32 <jwh> musl is great and everything but still just doesn't work half the iem
Jan 22 21:28:33 <jwh> time*
Jan 22 21:28:39 <jwh> lol
Jan 22 21:28:53 <Monkeh> I think it's more a case of it doens't have the full complement of glibc bugs..
Jan 22 21:29:10 <jwh> well heres a good one
Jan 22 21:29:19 <jwh> iodine builds and runs successfully but silently fails
Jan 22 21:29:39 <jwh> anyway, safeloader!
Jan 22 21:31:13 <Monkeh> *crickets*
Jan 22 21:31:44 <jwh> ikr
Jan 22 21:31:46 <jwh> :(
Jan 22 21:31:53 <Monkeh> I said ask questions!
Jan 22 21:34:07 <jwh> have to know what to ask :D
Jan 22 21:34:25 <Monkeh> Well, then, elaborate, etc
Jan 22 21:34:29 <Monkeh> Help me help you
Jan 22 21:34:29 <jwh> thats why I asked for a wizard who already knows how it works
Jan 22 21:34:45 <Monkeh> I've spent more time in that code than I ever wanted to
Jan 22 21:35:06 <jwh> ok, first one - model name and support list
Jan 22 21:35:14 <jwh> how do you determine the corect strings?
Jan 22 21:36:19 <jwh> I think I've got that wrong for a start
Jan 22 21:36:49 <Monkeh> Take them from the stock firmware
Jan 22 21:37:23 <jwh> as in, the firmware filename, or mash the model number and stuff together?
Jan 22 21:37:45 <Monkeh> From the header off an upgrade image, usually - that's what you're going to generate anyway.
Jan 22 21:37:52 <jwh> ah hm
Jan 22 21:38:34 <jwh> I extracted it, some of its there, wheres the header?
Jan 22 21:39:21 <Monkeh> It's plain text at the start of the image
Jan 22 21:39:29 <jwh> ohhh
Jan 22 21:39:39 <Monkeh> Just use strings
Jan 22 21:40:28 <Slimey> you may see it on the console also if you have it connected when it boots the oem firmware
Jan 22 21:42:47 <Slimey> bin_filename=QCA9984/hw.1/athwlan.bin swap_filename=/lib/firmware/QCA9984/hw.1/athwlan.codeswap.bin
Jan 22 21:42:47 <Slimey> ol_transfer_bin_file: Downloading firmware file: QCA9984/hw.1/athwlan.bin
Jan 22 21:46:03 <jwh> ah this is more fun, its not ath
Jan 22 21:46:12 <jwh> I was hoping for the ath model but its the cns3xxx one
Jan 22 21:46:37 <jwh> stock is vxworks also, just to make it even better
Jan 22 21:47:17 <jwh> no glaring holes in it to gain any sort of shell either except the tplink one which is barely a cli
Jan 22 21:47:47 <jwh> Monkeh: hm, nothing at the start really, except a few bytes in there is just 'er6020' - not in the same format as their other devices
Jan 22 21:48:06 <Monkeh> Are you sure it's even safeloader?
Jan 22 21:48:48 <jwh> yes, thats it shows on bootup
Jan 22 21:48:56 <jwh> its quite clearly uboot, the assholes
Jan 22 21:49:44 <jwh> theres no way to even boot a tftp image, so whatever I possibly get to flash needs to not nuke the bootloader too
Jan 22 21:50:09 <jwh> kSAFE-LOADER
Jan 22 21:50:09 <jwh> er6020
Jan 22 21:50:11 <jwh> sadface
Jan 22 21:50:13 <Monkeh> v1 or v2?
Jan 22 21:50:16 <jwh> v1
Jan 22 21:50:30 <jwh> v2 is ipq, which would probably be easier
Jan 22 21:52:20 <Monkeh> Yes, v1 is safeloader, and the header starts at 0x1014 in the image - there's no support list in these, apparently.
Jan 22 21:52:40 <jwh> yeah thats was my next question
Jan 22 21:52:52 <Monkeh> This may not be exactly the same format as other devices.
Jan 22 21:52:58 <jwh> sigh
Jan 22 21:53:39 <jwh> so the question, how different is it
Jan 22 21:57:20 <Monkeh> Being Cavium I want nothing to do with this device. :P
Jan 22 21:57:51 <jwh> hey, nothing wrong with cavium
Jan 22 21:57:58 <jwh> at least they open source their sdk
Jan 22 21:58:26 <Monkeh> Yes, but it's a whole other ecosystem
Jan 22 21:58:46 <Monkeh> Which means many pitfalls and trying to work out how that bootloader likes things.
Jan 22 21:59:00 <jwh> well, thats a tplink thing rather than cavium
Jan 22 21:59:17 <jwh> they could have just had s standard looking u-boot, but no
Jan 22 21:59:23 <jwh> had to hide all the useful stuff
Jan 22 21:59:30 <jwh> its *even* worse than mediatek
Jan 22 21:59:45 <jwh> at least you can do stuff with their horrible uboot
Jan 22 22:00:20 <jwh> hm, I'm guessing the webui does the same checks - wonder if there ssomething in there
Jan 22 22:10:46 <jwh> document.getElementById("chwinfo").innerHTML = CHWINFO.replace("(UN)","");, wat
Jan 22 22:13:41 <jwh> lol, doesn't even have the correct model in the title
Jan 22 22:21:56 <jwh> ebay or whatever it is I guess
Jan 22 22:22:04 <jwh> not particularly useful software, shame
Jan 22 22:35:39 <jwh> xback: ping :D
Jan 22 22:41:29 <Hauke> ynezz: I think it should go to generic
Jan 22 22:45:41 <jwh> its about time the EU actually did something useful and banned the sale of devices with things like locked bootloaders
Jan 22 22:47:37 <Monkeh> But FCC.
Jan 22 22:48:25 <jwh> the FCC/ETSI already made region specific devices a thing, so they can just deliver the EU versions with sensible bootloaders
Jan 22 22:48:36 <jwh> do what they want in the US
Jan 22 22:48:56 <jwh> not like consumers there have any expectations
Jan 22 22:49:05 <Monkeh> Not like we do here, really
Jan 22 22:49:46 <jwh> well, in a similar vein mobile operators are required to remove network locks - similar should really apply to all devices
Jan 22 22:50:58 <Monkeh> Eh, it's debatable if that's quite the same thing.
Jan 22 22:51:29 <jwh> well, it about not fucking the consumer
Jan 22 22:51:31 <jwh> same applies
Jan 22 22:55:17 <Hauke> the EU and the FCC are working together on the router lockdown
Jan 22 22:55:55 <Hauke> there is the rumor that the EU started with this and the FCC just followed
Jan 22 22:56:03 <jwh> that would not surprise me
Jan 22 22:56:28 <jwh> EU are definitely the more malevolent of the two
Jan 22 22:57:15 <Monkeh> I wouldn't be so sure of that with Trump's chosen man in charge
Jan 22 22:57:17 <jwh> totally not the kind of people to do things that suit them on a whim
Jan 22 22:57:18 <jwh> owait
Jan 22 22:58:09 <jwh> nevermind, sooner it all comes crashing down the better
Jan 23 01:36:20 <television> hi
Jan 23 01:37:38 <DonkeyHotei> hello
**** ENDING LOGGING AT Wed Jan 23 02:59:57 2019