**** BEGIN LOGGING AT Mon Jan 07 02:59:56 2019
Jan 07 03:34:56 <biangbiangmian> ahoy, where can i read more about what the line: compatible = "denx,uimage"; in the device tree firmware partition section supposed to be fixing?
Jan 07 03:57:32 <DonkeyHotei> damn, i was typing an answer to his question
Jan 07 04:02:38 <pkgadd> I almost hit enter, just seconds after he left - 4 minutes attention span isn't ideal on irc
Jan 07 04:07:49 <DonkeyHotei> and i was just asked how i knew about it on github the other day, too
Jan 07 06:28:23 <jow> KanjiMonster: the 1043nd image downloads look "legit" it is a number of different ips fetching it with wget over and over, often in the same instant
Jan 07 06:29:16 <jow> I agree that the volume is insane though, looks like some auto-update going crazy
Jan 07 06:40:46 <jow> its also all random spanish dialup IPs
Jan 07 08:04:21 <xback> Mornin' all
Jan 07 08:37:45 <rmilecki> morning
Jan 07 08:37:54 <rmilecki> will someone dare to look at http://phase1.builds.lede-project.org/builders/ramips%2Fmt76x8 ?
Jan 07 08:38:05 <rmilecki> oh, blogic is offline
Jan 07 08:38:11 <rmilecki> i wanted to ping blogic and jow ;)
Jan 07 08:38:28 <rmilecki> that subtarget fails with
Jan 07 08:38:29 <rmilecki> sh: 1: zip: not found
Jan 07 08:40:35 <rmilecki> that is caused by netgear_r6120 image which uses:
Jan 07 08:40:37 <rmilecki> IMAGE/factory.img := $$(IMAGE/default) | mksercommfw
Jan 07 08:41:48 <rmilecki> looking at tools/firmware-utils/src/mksercommfw.c it seems it tries to system("zip .........");
Jan 07 08:43:54 <rmilecki> that code for r6120 seems to be there for half a year since 5543d63fc84e ("ramips: add support for Netgear R6120")
Jan 07 09:01:37 <xback> rmilecki: I have spend a large amount of time on the sercom thing
Jan 07 09:02:00 <xback> this is the only target which required the host build system to have the "zip" tool installed
Jan 07 09:03:42 <xback> rmilecki: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b4e17a7440cd9885a678f2a28609a38eca6dd5dc
Jan 07 09:04:20 <rmilecki> i see, but what do we do about it?
Jan 07 09:04:34 <rmilecki> do we install "zip" as tool on our own?
Jan 07 09:04:40 <rmilecki> or do we require buildbots to provide it?
Jan 07 09:04:42 <rmilecki> jow: ?
Jan 07 09:04:47 <xback> well, Jow suggested that zip should be added to prereq
Jan 07 09:05:19 <xback> it'sa bit stupid .. for a single target which I could not even this if this sercomm thing actually works ..
Jan 07 09:05:55 <xback> I rewrote the app as it was full of out-of-bound and stack overflow issues .. but couldn't actually test it if that zip image even works
Jan 07 09:07:03 <xback> iirc, an issue was that some buildbots are not controllable by jow .. so it was not possible to install zip tool on them
Jan 07 09:39:39 <jow> rmilecki: we should add a zip host util
Jan 07 09:40:44 <rmilecki> jow: like tools/zip/ ?
Jan 07 09:41:41 <jow> yes
Jan 07 09:44:40 <karlp> is this that sercomm thing that someone wrote in C and declared it to be superior to the "unmtained" shell scripts and python?  what a surprise it was full of classic C bugs....
Jan 07 09:47:14 <jow> rmilecki: a host build of info-zip 3.0 should be straight forward, thankfully its a rather simple build
Jan 07 09:47:34 <jow> upstream @ ftp://ftp.info-zip.org/pub/infozip/src/zip30.tgz
Jan 07 09:47:55 <jow> build:  make -f unix/Makefile clean
Jan 07 09:48:02 <jow> sorry,  make -f unix/Makefile zip
Jan 07 09:48:33 <jow> resulting "zip" executable will reside in $(PKG_BUILD_DIR)
Jan 07 09:49:16 <rmilecki> nice :)
Jan 07 09:51:12 <jow> and I'd add it to tools/Makefile using  tools-$(CONFIG_TARGET_ramips_mt76x8) += zip
Jan 07 09:51:27 <jow> this way it won't bother the other targets, even if the overhead is low
Jan 07 10:32:05 <KanjiMonster> jow: rmilecki: xback: what about the zlib we already build by default? can't we use that?
Jan 07 10:33:08 <rmilecki> sounds better than system("zip")
Jan 07 10:41:05 <jow> iirc a zip archive involves a bit more than just a zlib stream
Jan 07 10:41:17 <jow> header and member structs and such
Jan 07 10:43:22 <karlp> so you need the hardware itself to check what you can convince it to accept...
Jan 07 10:43:40 <KanjiMonster> tools/wrt350nv2-builder/src/ioapi.c seems to contain code for handling zip files, so maybe make this code shared
Jan 07 10:43:53 <KanjiMonster> (using zlib)
Jan 07 10:50:19 <xback> yes, it needs to be tested for sure (even the binary being generated today)
Jan 07 11:18:44 <KanjiMonster> can zip files be made reproducable? if yes, that would be a way to test/ensure switching to zlib will still generate correct images
Jan 07 11:46:48 <jow> finally got around to update my lxr setup, it was still pointing to the old nbd.name git
Jan 07 11:47:00 <jow> it also has a proper domain name now; http://lxr.openwrt.org/
Jan 07 12:00:59 * ynezz bookmarks
Jan 07 16:26:46 <jwh> hey I'm back with more inane questions :D
Jan 07 16:27:25 <jwh> given that using an external kernel tree doesn't generate a .config, is there some shortcut that wil dump out what it would have generated were it a normal build, without going through the build and copying it?
Jan 07 16:35:45 <ynezz> I'm not sure if I understand your question, but `scripts/kconfig.pl + /target/linux/generic/config-4.14 /target/linux/imx6/config-4.14 > .config` should be probably a good start
Jan 07 16:36:33 <ynezz> complete steps are in include/kernel-defaults.mk look at Kernel/Configure/Default
Jan 07 16:39:43 <rmilecki> jow: i still can't search for some identifiers
Jan 07 16:39:48 <rmilecki> e.g. https://lxr.openwrt.org/ident?i=uci_ptr
Jan 07 16:40:00 <rmilecki> is there sth wrong with OpenWrt code that lxr doesn't like about?
Jan 07 16:40:33 <jwh> ynezz: that makes sense really, thanks
Jan 07 16:40:59 <rmilecki> https://lxr.openwrt.org/source/uci/uci.h maybe it's because of the extern "C" {
Jan 07 16:43:07 <ArthurML1> rmilecki: sorry to bother, but any update on those logs I sent a while ago? do you think I can flash openwrt, and not brick it?
Jan 07 16:43:29 <rmilecki> ArthurML1: oh, sorry, I forgot, try giving me one more day
Jan 07 16:53:25 <jow> rmilecki: yep, extern "C" seems to be the culprit
Jan 07 16:53:47 <rmilecki> should I report it to the LXR team?
Jan 07 16:53:49 <jow> genxref reduces the entire header to `extern "C" {}`
Jan 07 16:54:10 <jow> well, there is LXR2 now which suffers from a severe case of 2nd system syndrome
Jan 07 16:54:17 <jow> will hack up the instlal here
Jan 07 16:54:25 <rmilecki> ok, tanks
Jan 07 16:54:59 <ynezz> I wondering if elixir from bootlin is any better
Jan 07 16:55:07 <ynezz> s/I/I'm/
Jan 07 16:55:42 <ArthurML1> rmilecki: okok, no prob
Jan 07 17:03:10 <owrt-snap-builds> build #1126 of zynq/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/zynq%2Fgeneric/builds/1126
Jan 07 17:05:40 <jow> rmilecki: seems to work now
Jan 07 17:40:42 <mkresin> jow: rmilecki: KanjiMonster: I'm working on the missing zip issue. in fact, I managed to finish the code yesterday. but my SSD decided to die exactly at the moment I commited my changes to my local clone.
Jan 07 17:42:17 <KanjiMonster> mkresin: cool. also thanks for affirming my phobia of using SSDs for user data. ;)
Jan 07 17:42:19 <mkresin> we should add tools/zip, get rid of the zip call in mksercomfw and use a zip build recipe. mksercomfw expects a zipped binary and only need to add the sercom header
Jan 07 17:45:33 <mkresin> we should be able to create a reproducible zip file by not using the extended header fields (contains guid, uid .. on *nix). had already code in place to pass a custom date for the file date of the compressed files
Jan 07 17:50:50 <owrt-snap-builds> build #723 of layerscape/armv8_64b is complete: Failure [failed images]  Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/723  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Koen Vandeputte <koen.vandeputte@ncentric.com>, Hans Dedecker <dedeckeh@gmail.com>, HsiuWen Yen <y.hsiuwen@gmail.com>, John Crispin
Jan 07 17:50:50 <owrt-snap-builds> <john@phrozen.org>
Jan 07 17:57:43 <Monkeh> KanjiMonster: SSDs are fine, just always keep backups :)
Jan 07 18:00:32 <KanjiMonster> Monkeh: I don't like how SSDs tend to fail AFAICT (go from working to completely broken without no warning signs)
Jan 07 18:00:44 <KanjiMonster> *without any
Jan 07 18:01:53 <Monkeh> Eh, I've had many HDDs do the same
Jan 07 18:06:38 <SwedeMike> I've had more SSDs do that compared to HDDs
Jan 07 19:01:05 <mangix> well, there is recourse with hdds
Jan 07 20:25:23 <KanjiMonster> oh, we got 5.0
Jan 07 20:43:59 <Borromini> KanjiMonster: yeah, i thought i was still sleepy
Jan 07 20:44:15 <Borromini> but linus did pretty much the same with 3.19 -> 4.0
Jan 07 20:44:26 <Borromini> i kinda liked 2.6.23 and whatnot though :D
Jan 07 20:44:35 <Borromini> those major increments feel so big
Jan 07 20:44:52 <mangix> well
Jan 07 20:44:57 <mangix> 5.0 comes with freesync
Jan 07 20:45:04 <mangix> that's major for amd gpu users
Jan 07 20:45:21 <mangix> legacy i/o schedulers probably got nuked too
Jan 07 20:45:42 <Borromini> but does that warrant a major number bump?
Jan 07 20:45:54 <Borromini> many new kernels have big updates
Jan 07 20:46:27 <mangix> meh. it's subjective.
Jan 07 20:47:57 <Borromini> q.e.d. ;)
Jan 07 20:47:58 <stintel> he learned to count to 20 now :)
Jan 07 20:48:13 <KanjiMonster> so you mean we'll get 5.21, then 6.0? ;)
Jan 07 20:48:15 <stintel> and 5.22 will become 6.0 :P
Jan 07 20:48:15 <mangix> reminds me of my pull request here to get rid of deadline
Jan 07 20:48:21 <mangix> this time, upstream did it
Jan 07 20:48:36 <stintel> KanjiMonster: ;-)
Jan 07 20:48:48 <Borromini> hehe
Jan 08 00:08:51 <lynxis> evening
Jan 08 00:24:25 <owrt-snap-builds> build #263 of gemini/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/gemini%2Fgeneric/builds/263
**** ENDING LOGGING AT Tue Jan 08 02:59:57 2019