**** BEGIN LOGGING AT Sat Apr 06 02:59:57 2019
Apr 06 09:10:50 <dansan> Anybody care for a big, fat, full OpenJDK8 on their little board? :)
Apr 06 09:11:58 <dansan> It's amazing what will run on a little mt7620 with 256M of ram
Apr 06 09:12:03 <dansan> (mt7620a)
Apr 06 09:15:00 <SwedeMike> dansan: well considering we could run a full Linux OS plus IRC client for several users with 4MB RAM in the 90ties, it's not that surprising :P
Apr 06 09:15:13 <dansan> lol! good point
Apr 06 09:15:25 <dansan> I guess I'm kinda trying to rag on java
Apr 06 09:16:16 <dansan> I had originally run a debian mipsel chroot to get a recent java and it was SO slow because I was loading in a separate glibc and all
Apr 06 09:16:36 <dansan> but I finally got OpenJDK to build for mipsel against musl and it's much faster
Apr 06 09:17:03 <dansan> Also the default (unless you get all ninja, bar fight with it) is that OpenJDK thinks it should build with -O3
Apr 06 09:32:44 <dansan> what causes this? configure: loading site script /home/daniel/proj/embedded/openwrt/gse/include/site/mipsel
Apr 06 10:24:04 <dansan> HAH! It's a conflict because OpenJDK sets TOPDIR and that conflicts with OpenWRT's TOPDIR
Apr 06 12:18:09 <movi> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=1d4d156a7ce67988f922c470f622f6dd2a5c161b this should make traffic accounting work with offload, right?
Apr 06 14:23:34 <abenz> I noticed when using a usb thumb drive (flash), cpu usage is very high, as opposed to using a usb drive (mechanical)
Apr 06 14:23:41 <abenz> both ext4
Apr 06 14:25:34 <abenz> would this be due to controller/cache perhaps
Apr 06 14:26:33 <olmari> good or shit usb-drive? suprisingly diffirent
Apr 06 14:34:27 <abenz> usb drive is buffalo ministation (powered only through router, no external power). USB thumb is a sandisk cruzer
Apr 06 14:34:55 <olmari> neither does sound particularly bad
Apr 06 14:35:03 <olmari> does not... even..
Apr 06 14:35:24 <olmari> umm... long day... won't fix and fail 3rd time xD
Apr 06 15:49:01 <Hauke> jow: could you please add the new target target/linux/tegra/ to the build bots
Apr 06 15:55:00 <DonkeyHotei> Hauke: thoughts on putting https://pastebin.com/9qAp0NcG in master?
Apr 06 15:56:07 <Hauke> DonkeyHotei: I do not know how this is from the legal point of view
Apr 06 15:56:25 <DonkeyHotei> license files are included
Apr 06 16:48:41 <KanjiMonster> DonkeyHotei: does the licence allow distribution by third parties?
Apr 06 16:50:08 <DonkeyHotei> the license header is as follows
Apr 06 16:50:11 <DonkeyHotei> All firmware files are copyrighted by Lantiq Deutschland GmbH.
Apr 06 16:50:11 <DonkeyHotei> The files have been extracted from header files found in Lantiq BSPs.
Apr 06 16:50:11 <DonkeyHotei> If not stated otherwise all files are licensed under GPL.
Apr 06 16:50:57 <DonkeyHotei> this of course makes no sense, but that is how they are being distributed
Apr 06 16:52:56 <KanjiMonster> this is from the licence file in the lantiq BSP / vendor BSPs?
Apr 06 16:54:32 <DonkeyHotei> in the most recent gpl tarball for the dm200
Apr 06 16:55:06 <DonkeyHotei> the copyright is as follows
Apr 06 16:55:21 <DonkeyHotei> # (C) Copyright 2007 - 2012
Apr 06 16:55:21 <DonkeyHotei> # Lantiq Deutschland GmbH
Apr 06 16:55:21 <DonkeyHotei> # (C) Copyright 2012
Apr 06 16:55:21 <DonkeyHotei> # Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Apr 06 16:56:05 <DonkeyHotei> under a standard fsf license header
Apr 06 16:56:15 <DonkeyHotei> gpl2+
Apr 06 16:58:18 <DonkeyHotei> first google result for that name is an lkml message cc'd to both you and him in 2017
Apr 06 17:03:10 <KanjiMonster> DonkeyHotei: is this the phy fw?
Apr 06 17:03:21 <DonkeyHotei> the gphy fw, yes
Apr 06 17:04:03 <DonkeyHotei> i have renamed the files to match what the mainline kernel expects and put the result on pastebin including license files for the moment
Apr 06 17:04:27 <DonkeyHotei> a total of 8 files in .7z.base64
Apr 06 17:06:00 <KanjiMonster> assuming it's the ltq_fw_PHY-IP-1.6.tar.gz, the licence file in there ( https://pastebin.com/8qbBV9Gc ) vorbids redistribution
Apr 06 17:06:09 <KanjiMonster> *forbids
Apr 06 17:06:45 <DonkeyHotei> i do not know the version number, but the a2x files look newer than what is in owrt
Apr 06 17:09:17 <DonkeyHotei> the a1x files appear to be the same
Apr 06 17:09:50 <DonkeyHotei> x300 files are also there
Apr 06 17:43:32 <KanjiMonster> DonkeyHotei: it's the source archive for the gphy firmwares, found in the dl directory of the netgear sources
Apr 06 17:47:03 <KanjiMonster> technically netgear is already violating the licence, as it only allows distribution with the hardware, not separately
Apr 06 17:47:52 <DonkeyHotei> not sure those are the same files as ./DM200-V1.0.0.61_gpl_src/git_home/linux.git/firmware/lantiq/ but it's easy to check
Apr 06 17:52:51 <DonkeyHotei> the files that are different from the ones in owrt are in ltq_fw_PHY-IP-1.6.tar.gz, but the files that are the same are not
Apr 06 17:53:19 <DonkeyHotei> seems netgear decided to mix and match in their image
Apr 06 17:57:08 <DonkeyHotei> the change.log mentions hardware errata as being the only difference between what the netgear image uses and what owrt uses
Apr 06 17:57:28 <DonkeyHotei> sad
Apr 06 17:57:51 <DonkeyHotei> oh well
Apr 06 17:59:46 <DonkeyHotei> well, hardware errata plus EEE
Apr 06 18:03:36 <DonkeyHotei> but the rev numbers do not match
Apr 06 18:10:00 <mangix> KanjiMonster: ping
Apr 06 18:16:43 <jow> Hauke: done!
Apr 06 18:22:30 <aparcar[m]> I ucert signed firmware images enabled by default for 19.03?
Apr 06 18:22:31 <aparcar[m]> Aka will it be preinstalled?
Apr 06 18:22:56 <jow> lach1012: ping
Apr 06 18:23:14 <lach1012> jow: pong!
Apr 06 18:23:53 <lach1012> ah I see
Apr 06 18:24:03 <jow> lach1012: your firmware-utils commit breaks on some older builders due to a default C standard mode forbidding inline variable declarations  for (int i = ...)
Apr 06 18:24:13 <lach1012> yes
Apr 06 18:24:21 <DonkeyHotei> nec-enc, that is
Apr 06 18:25:04 <lach1012> C99 Designated Initializers
Apr 06 18:25:14 <lach1012> no
Apr 06 18:25:41 <jow> its probably enough to just add -std=gnu99 like for some of the other applets
Apr 06 18:26:30 <lach1012> jow: by the way wasn't there a feed of the phase1 builder?
Apr 06 18:26:42 <DonkeyHotei> it's in #openwrt-devel-build
Apr 06 18:27:01 <lach1012> thank you
Apr 06 18:27:18 <jow> lach1012: https://phase1.builds.openwrt.org/one_line_per_build
Apr 06 18:28:21 <lach1012> jow, gnu99 vs c99 any preference?
Apr 06 18:28:37 <lach1012> oh ok
Apr 06 18:28:44 <lach1012> file has gnu extensions
Apr 06 18:28:46 <jow> lach1012: not really, I'd probably settle for whatever is most used in firmware-utils/Makefile
Apr 06 18:28:58 <jow> and yeah if it uses GNUisms then gnu99
Apr 06 18:30:02 <lach1012> how gets "Reported-by" ?
Apr 06 18:30:12 <aparcar[m]> jow thoughts regarding ucert?
Apr 06 18:30:19 <jow> can you rephrase the question? :)
Apr 06 18:30:30 <aparcar[m]> jow me?
Apr 06 18:30:35 <jow> aparcar[m]: no, lach1012
Apr 06 18:30:44 <jow> aparcar[m]: I don't think signed images will be the default
Apr 06 18:30:46 <aparcar[m]> ack
Apr 06 18:30:55 <aparcar[m]> aparcar bueno, thanks
Apr 06 18:31:07 <lach1012> *who
Apr 06 18:31:22 <jow> lach1012: "Spotted by buildbot" :)
Apr 06 18:32:00 <lach1012> :)
Apr 06 18:32:47 <jow> aparcar[m]: I think before start relying on ucert by default it requires some more exposure, some documentation and at least one or two more developers being familiar with it
Apr 06 18:33:22 <jow> once it is mature I am all for using it, GPG is just far too tedious
Apr 06 18:33:40 <jow> on the other hand there's that saying that one should never do his own crypto
Apr 06 18:36:25 <aparcar[m]> jow very true :) I'm just curious cuz the upgrade server will rely on ucert + firmware metadata in images. Me and Dango are still looking for ways to make things more secure, ucert seems like the first step
Apr 06 18:42:00 <lach1012> jow: pushed
Apr 06 18:44:45 <jow> thanks!
Apr 06 18:44:51 <DonkeyHotei> lach1012: PR 1379 updated, too
Apr 06 18:55:42 <mangix> lach1012: probably would have been better to fix the error so that it's compatible with all standards. mkresin did so in one of the firmware-utils a while bach
Apr 06 18:55:45 <mangix> *back
Apr 06 18:56:17 <lach1012> mangix: there's no perfect fix
Apr 06 18:57:11 <mangix> hmm? just put the declaration above the for loop
Apr 06 18:57:46 <lach1012> well, have you tried compiling stuff with c89?
Apr 06 18:58:08 <mangix> eh no, I use the GNU variants
Apr 06 18:58:13 <lach1012> or what's the "lowest" standard there is?
Apr 06 18:58:26 <mangix> ie, gnu89
Apr 06 18:58:58 <mangix> the kernel uses this, making it good enough for me
Apr 06 18:59:00 <lach1012> isn't there a ansi or k&r
Apr 06 18:59:43 <DonkeyHotei> iirc c89 and c99 are both ansi revisions
Apr 06 19:00:00 <lach1012> ah, it was -ansi
Apr 06 19:00:04 <DonkeyHotei> first ansi draft came out in 1987
Apr 06 19:00:36 <mangix> gcc manual says -ansi is equivalent to std=c90
Apr 06 19:01:06 <lach1012> mangix, it seems this changed over the years
Apr 06 19:01:17 <lach1012> https://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Standards.html#Standards says c89
Apr 06 19:01:30 <lach1012> " To select this standard in GCC, use one of the options -ansi, -std=c89 or -std=iso9899:1990; to"
Apr 06 19:03:02 <mangix> In any case, gcc by default selects gnu**. Compatibility with that should be good enough
Apr 06 19:03:42 <lach1012> mangix, do you know what the kernel will use when it gets clang support?
Apr 06 19:03:50 <mangix> same
Apr 06 19:04:02 <mangix> clang by default uses the gnu variants too
Apr 06 19:05:31 <lach1012> k
Apr 06 19:07:22 <lach1012> mangix, did you know that the kernel tools also go for gnu99
Apr 06 19:09:19 <DonkeyHotei> if the question of the SoC compatible string can be put to rest, i can make a final push to resolve the merge conflict right now
Apr 06 19:09:44 <lach1012> the qca9557 / qca9558?
Apr 06 19:09:47 <DonkeyHotei> yes
Apr 06 19:10:11 <mangix> lach1012: looks lazy. that is, there is no requirement unlike the kernel tree itself. I still maintain that it's easy to add gnu89 compatibility.
Apr 06 19:11:06 <mangix> also seems like most tools ommit an std= line
Apr 06 19:11:21 <lach1012> mangix: some have it though like the usbip util
Apr 06 19:11:39 <lach1012> so, even they can't manage to go with one version
Apr 06 19:11:44 <lach1012> wonder why
Apr 06 19:12:45 <lach1012> DonkeyHotei, is it just the "#include "qca9557.dtsi"" define that bugs you?
Apr 06 19:13:05 <DonkeyHotei> the compatible string
Apr 06 19:13:16 <lach1012> oh
Apr 06 19:14:43 <DonkeyHotei> some of the other qca9558_*.dts have "qca,qca9557" so that was what i initially had
Apr 06 19:14:45 <lach1012> hm, your current version qca,qca9558 looks fine to me
Apr 06 19:14:57 <DonkeyHotei> ok
Apr 06 19:15:51 <DonkeyHotei> pushed
Apr 06 19:17:21 <lach1012> DonkeyHotei: ".git/rebase-apply/patch:22: new blank line at EOF.
Apr 06 19:17:21 <lach1012> "
Apr 06 19:17:45 <lach1012> well, git fixed it so all good
Apr 06 19:18:05 <mangix> lach1012: no particular experience with usbip. I still maintain it's that way because there's no requirement.
Apr 06 19:18:59 <mangix> gch981213: out of curiosity, did you test your ag71xx switch driver rework speedwise? I think one of your patches reduced iperf speed. Not sure which.
Apr 06 19:19:06 <lach1012> mangix: finally found the commit that set gnu89 : 51b97e354ba9fce1890cf38ecc754aa49677fc89
Apr 06 19:19:26 <lach1012> Ah it was because of "gcc5 changed the default standard to c11"
Apr 06 19:19:55 <lach1012> they even say: "End result: we may be able to move up to a newer stdc model eventually"
Apr 06 19:20:04 <mangix> erm the commit message is incorrect
Apr 06 19:20:08 <mangix> it's gnu11 not c11
Apr 06 19:20:42 <jow> it probably makes sense to globally fix it to gnu99, then fix any code breaking due to that
Apr 06 19:23:44 <mangix> jow: kernel size may increase with a change to std=gnu99 as 99 changes inlining behavior.
Apr 06 19:24:33 <jwh> mangix: usbip is broken atm btw
Apr 06 19:24:55 <jow> mangix: I mean for firmware-utils
Apr 06 19:26:13 <jow> jwh: usbip is fubar since eudev was replaced with libudev-fbsd in the feed
Apr 06 19:26:23 <jwh> ye
Apr 06 19:26:41 <jwh> there is something else as well though
Apr 06 19:26:55 <jwh> I can't remember now, but I had to patch it (same on other distros)
Apr 06 19:27:10 <jwh> iirc it was vhci in the kernel changed but utils haven't been updated
Apr 06 19:27:17 <jwh> doesn't look like its really maintained
Apr 06 19:47:16 <mangix> jow: libudev-fbsd is not active either: https://github.com/jiixyj/libudev-fbsd/issues/2
Apr 06 21:51:24 <mangix> cotequeiroz: I noticed OpenSSL is using -fPIC unconditionally. Can we switch to using $(FPIC)?
Apr 07 01:15:16 <gch981213> mangix: Never done that. It's setting up the same VLAN with a different switch driver after all and I doubt if this can cause a speed regression.
Apr 07 02:01:41 <mangix> gch981213: hmmm. i remember the iperf performance regression came after one of your patchsets
Apr 07 02:03:10 <mangix> hmmm must have been this one then: https://github.com/openwrt/openwrt/pull/1735/commits
**** ENDING LOGGING AT Sun Apr 07 02:59:57 2019