**** BEGIN LOGGING AT Mon Mar 02 02:59:57 2020
Mar 02 04:44:47 <owrt-1806-builds> build #70 of lantiq/falcon is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/lantiq%2Ffalcon/builds/70
Mar 02 06:18:31 <blogic> aloha
Mar 02 06:20:00 <Redfoxmoon> moin
Mar 02 06:22:48 <owrt-snap-builds> build #224 of ramips/mt7620 is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/224  blamelist: David Bauer <mail@david-bauer.net>, Jeffery To <jeffery.to@gmail.com>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Stijn Tintel <stijn@linux-ipv6.be>, Michael T Farnworth
Mar 02 06:22:48 <owrt-snap-builds> <michael@turf.org>, Rosen Penev <rosenp@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Tim Harvey <tharvey@gateworks.com>
Mar 02 06:55:42 <owrt-snap-builds> build #225 of mpc85xx/p2020 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp2020/builds/225  blamelist: David Bauer <mail@david-bauer.net>, Jeffery To <jeffery.to@gmail.com>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Stijn Tintel <stijn@linux-ipv6.be>, Michael T Farnworth
Mar 02 06:55:43 <owrt-snap-builds> <michael@turf.org>, Rosen Penev <rosenp@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Tim Harvey <tharvey@gateworks.com>
Mar 02 07:31:47 <ynezz> boo openwrt-ramips-mt7620-netgear_ex2700-squashfs-factory.bin is too big
Mar 02 07:33:23 <jow> 19.07.2 and 18.06.8 are done building, we can announce them throughout the day
Mar 02 07:51:07 <blogic> jow: thanks
Mar 02 08:00:37 <owrt-snap-builds> build #235 of sunxi/cortexa7 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa7/builds/235
Mar 02 08:27:06 <aparcar[m]> how can I make a script run by makefile stop the make process if it fails? || exit 1 does not do anything
Mar 02 08:27:11 <aparcar[m]> blogic: aloha
Mar 02 08:27:43 <blogic> aparcar[m]: hi
Mar 02 08:28:18 <blogic> https://stackoverflow.com/questions/16315089/how-to-get-exit-status-of-a-shell-command-used-in-gnu-makefile
Mar 02 08:28:21 <aparcar[m]> you fogot about the udrone stuff :(
Mar 02 08:28:22 <blogic> first hit on google
Mar 02 08:28:28 <blogic> no i did not
Mar 02 08:28:30 <blogic> I am just busy
Mar 02 08:28:40 <blogic> its on my list for today
Mar 02 08:29:04 <aparcar[m]> yey
Mar 02 08:29:30 <aparcar[m]> regarding the makefile, I already tried the || exit thing, do I need to do any fancy @ + - combo?
Mar 02 08:31:25 <blogic> did you escaoe the $$ stuff ?
Mar 02 08:33:07 <aparcar[m]> blogic: I'm trying to stop makefile if this fails here https://github.com/openwrt/openwrt/blob/master/include/image.mk#L595
Mar 02 08:34:08 <aparcar[m]> ynezz: please join the fun
Mar 02 08:34:30 <blogic> oh the makefile based image building code
Mar 02 08:34:57 <blogic> too early in the mornnig to look aty accidents
Mar 02 08:35:40 <aparcar[m]> accidents as in pairing makefile with python scripts?
Mar 02 08:36:00 <blogic> as in the whole code
Mar 02 08:36:16 <blogic> ;)
Mar 02 08:37:31 <aparcar[m]> -.-
Mar 02 09:07:51 <owrt-snap-builds> build #251 of mpc85xx/p1020 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/251  blamelist: David Bauer <mail@david-bauer.net>, Jeffery To <jeffery.to@gmail.com>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Stijn Tintel <stijn@linux-ipv6.be>, Michael T Farnworth
Mar 02 09:07:51 <owrt-snap-builds> <michael@turf.org>, Rosen Penev <rosenp@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Tim Harvey <tharvey@gateworks.com>
Mar 02 09:09:34 <stintel> oooh did we merge 5.4?
Mar 02 09:12:56 <stintel> neat
Mar 02 09:30:06 <mangix> stintel: totally broken for ath79 :D
Mar 02 09:47:31 <ldir> 5.4 isn't default (yet) it's testing, for presumably, testing
Mar 02 09:49:19 <jow> aparcar[m]: the image build code is run protected, you cannot break out of that with shell errors
Mar 02 09:49:45 <aparcar[m]> jow: thank you thats good to know!
Mar 02 09:49:50 <jow> you could try capturing the output using $(shell ...) and then conditionally die using $(error ...)
Mar 02 09:50:15 <jow> $(if $(shell foo --blah),$(error Meh))
Mar 02 09:50:52 * ldir lols at error Meh
Mar 02 09:50:55 <jow> will die when the invoked command produces any output
Mar 02 09:52:02 <aparcar[m]> jow: what would you suggest for the json info file creation script? If it fails, should more happen than just an error message?
Mar 02 09:52:36 <jow> I'd war and continue
Mar 02 09:52:38 <jow> *warn
Mar 02 09:55:27 <aparcar[m]> ack
Mar 02 10:22:43 <jow> ldir: thanks for the conntrack graph update, didn't know that collectd records percentages
Mar 02 10:23:30 <ldir> collectd is a continuing mystery :-)
Mar 02 10:37:23 <ldir> jow: I'm probably about to cause some pain https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=277e5c038be8c1cd9eff065f31516e0ecf45ce08
Mar 02 10:37:43 <ynezz> jow: aparcar[m]: I find it quite weird, that if I select some config option, like that JSON output = I want that, then I'm just getting some warning/python exception in the build log if something fails
Mar 02 10:38:18 <ldir> But I think what I'm proposing is 'technically correct'/neater
Mar 02 10:39:47 <ynezz> jow: aparcar[m]: everything needed should be in place, so if the code fails, it fails for some reason and that reason should be fixed, not just skipped over
Mar 02 10:42:41 <ldir> ynezz: is there a way that I can make that macos runner useful for you?
Mar 02 10:43:02 <ynezz> ldir: s/you/for the project/, yes :)
Mar 02 10:43:16 <ldir> good - how?
Mar 02 10:43:44 <ynezz> ldir: setup weekly rebuild of all targets on macos
Mar 02 10:44:40 <ynezz> ldir: gitlab can schedule pipelines
Mar 02 10:44:42 <ldir> ok, let me re-word the question.  Is there a way I can open that runner up to the project ?
Mar 02 10:45:20 <ynezz> there is no CI in the repo
Mar 02 10:48:43 <aparcar[m]> ynezz: Fair point. I'm a bit shy changing buildroot behaviour for the JSON files. From my understanding the script does not fail if copying the image itsel fails neither.
Mar 02 10:49:36 <ldir> I see the words but don't really understand.  Let's take this private and continue in small steps for me :-)
Mar 02 10:50:22 <ynezz> ldir: in order to be able to use your runner, we would need to attach it under openwrt group on gitlab.com
Mar 02 10:50:41 <ynezz> ldir: but it would do nothing, as there is no .gitlab-ci.yml currently in the tree
Mar 02 10:51:32 <ldir> right, the gitlab-ci.yml are currently done as commits in our local forks.
Mar 02 10:52:25 <ynezz> exactly, so as interim solution ldir/openwrt is good enough
Mar 02 10:53:07 <ynezz> although that would probably mean two branches, two different .gitlab-ci.yml configs
Mar 02 10:53:26 <ldir> but that assumes I push to the gitlab repo instance on a reasonable basis.
Mar 02 10:53:35 <ynezz> it can be automated
Mar 02 10:54:16 <ldir> ok, is it worth doing the 'attach to openwrt' anyway, so it's ready?
Mar 02 10:55:26 <ynezz> thats official project, so I don't want to decide that solely here, as we'll be accussed of clanism etc. :)
Mar 02 10:56:05 <ynezz> some folks could argue, that it was decided to have self-hosted GitLab instance, but we're continuing with GitLab.com or what not
Mar 02 10:56:28 <ldir> LOL - ok, let's not stir the pot too much :-)
Mar 02 10:56:34 <ynezz> but ldir/openwrt is just fine, it's not official, you can do whatever you want there
Mar 02 10:57:09 <ynezz> for me it's important the result, weekly feedback green/red
Mar 02 10:57:50 <ynezz> and since you got it working already, I don't see a point to wait another few months to use the results "officialy"
Mar 02 10:59:13 <ldir> lol - I wish it was quicker.. hour to build the toolchain, hour to build the 'phase 1' images.  But it's better than it sat there doing nothing
Mar 02 11:00:33 <ynezz> well, thats quite different topic
Mar 02 11:00:50 <ynezz> it would mean using your macmini as buildslave for the buildbot setup
Mar 02 11:01:04 * ldir goes to find caffeine
Mar 02 11:01:18 <ynezz> IIRC this would need some tweaks, since it would produce unusable SDKs
Mar 02 11:01:41 <ynezz> or rather SDKs usable only on darwin host
Mar 02 11:02:02 <ynezz> (or something like that)
Mar 02 11:02:32 <ldir> yeah I think stintel found that out the hard way when he set up an arm based buildbot :-)
Mar 02 11:02:53 <stintel> s/arm/power8/
Mar 02 11:03:26 <ldir> stintel: forgive me, my memory is suffering multiple bit errors these days ;-)
Mar 02 11:03:33 <stintel> builds everything I use just fine, but the buildbot setup doesn't support !x86_64
Mar 02 11:04:06 <stintel> as my toolchain was packed as SDK with x86_64 in the name but containing ppc64 instead
Mar 02 11:04:17 <ynezz> I'm just using that part of CI to build my staging tree, so I don't build other feeds, SDK or IB every time
Mar 02 11:04:25 <stintel> and package build was also not possibe as it uses the SDK tarbals
Mar 02 11:12:21 <aparcar[m]> ynezz: thanks for your multi tasking 🙂 regarding the ignored message, do you want me to remove the IGNORE?
Mar 02 11:13:01 <ynezz> aparcar[m]: sorry, you've asked me why it's working that way, I didn't suggested anything :)
Mar 02 11:13:31 <aparcar[m]> ynezz: yea I was suspecting that answer when you did not mention anything in the mail...
Mar 02 11:13:58 <aparcar[m]> And how did you change the INPUT_DIR to work with imx6?
Mar 02 11:15:27 <aparcar[m]> ynezz: sorry nevremind the question. I see that the missunderstanding is clearly on my side
Mar 02 11:27:27 <aparcar[m]> ynezz: I gotta sleep, late here, more mails incomming soon
Mar 02 11:29:29 <ynezz> aparcar[m]: nite
Mar 02 11:30:13 <ynezz> BTW I've the fix for the `build #251 of mpc85xx/p1020` failure in the works, just waiting for 3 builds to finish
Mar 02 11:30:21 <aparcar[m]> ynezz: fml so it"s again a matter of having the subtarget or not... INPUT_DIR=$(BUILD_DIR)/linux-$(BOARD)$(if $(SUBTARGET),_$(SUBTARGET))/tmp
Mar 02 11:30:48 <aparcar[m]> can't we just unify this for every target one and for all and get rid of the corner cases :(
Mar 02 11:31:18 <aparcar[m]> my script looks at imx6_generic because this is how KDIR is defined
Mar 02 11:32:52 <ynezz> aparcar[m]: whatever, I'm not going to merge stuff which doesn't pass my tests/review
Mar 02 11:33:13 <ynezz> or should I merge it with "currently broken on x86 and imx6"
Mar 02 11:34:46 <ynezz> so yes, there are two options, remove the corner cases OR handle the corner cases
Mar 02 11:34:55 <ynezz> ;)
Mar 02 11:35:34 <ynezz> question is how/when are we going to find out about the corner cases if the errors are silenced
Mar 02 11:36:19 <aparcar[m]> I'm not asking for that. But I don't want to pass your tests by a workaround. So rather add generic as subtarget to imx6
Mar 02 11:37:21 <aparcar[m]> And x86 needs to be reworked which is a bit above me current league....
Mar 02 11:38:10 <aparcar[m]> Do you accept generic as sub target for imx6? Then I create a PR tomorrow
Mar 02 11:39:43 <aparcar[m]> And we should add a parameter to unignore if that doesn't already exists. I don't want json files created if the image itself failed. If you want to exit on failed image creation I'll delete the IGNORE tag
Mar 02 11:40:52 <xback> fyi, i'll hold off bumping the kernel for 2 .. 3 days as I'm seeing 5.4 pulls staged
Mar 02 11:52:05 <jow> aparcar[m]: chef.libremesh.org is down?
Mar 02 11:52:29 <jow> was looking at https://github.com/openwrt/luci/issues/3677 and wanted to translate the existing attended sysupgrade
Mar 02 11:52:38 <jow> but it appears you changed the api too?
Mar 02 11:56:34 <aparcar[m]> jow: thanks for looking into that! The update checks changed as they've been badly over engineered. I hoped with a versions.json (see devel) this could be solved. For requesting actual image requests the API is nearly the same, it's now oriented at the created json info files.
Mar 02 11:57:21 <jow> well I have no desire to actually build a new client, I was hoping that I can simply transcribe the existing client
Mar 02 11:57:44 <jow> but without a working server to test against this is futile
Mar 02 11:58:30 <aparcar[m]> Yes. Can you give me 2 days so I finish the backend and update the current LuCI app?
Mar 02 11:58:38 <jow> sure
Mar 02 11:58:55 <aparcar[m]> Good, I'll update you once I'm done
Mar 02 12:36:31 <karlp> jow: any ideas what causes this? https://imgur.com/a/pYGxisd system->system isn't my own code, and I can't reproduce it.  browser was chrome, language was autodetected as german,
Mar 02 12:37:10 <karlp> my own local installation running the same code works in chrome/chromiuim/ff/ie/edge on linux/windows, so at a bit of a loss
Mar 02 12:37:23 <jow> karlp: no idea. Possible race condition maybe
Mar 02 12:37:58 <karlp> yay.  reloads had no impact.  some pages worked, some were jsut persistently stuck dead with that error.
Mar 02 12:38:00 <jow> or a stale browser cache
Mar 02 12:38:08 <jow> or a bad extension
Mar 02 12:38:20 <karlp> fun times :)
Mar 02 12:39:00 <karlp> tried to get them to use IE, but ie obviously had "different" network settings to chrome, as it wouldn't even connect, just said the site was unavailable.
Mar 02 12:41:11 <ynezz> rmilecki: ping :)
Mar 02 12:42:16 <jow> karlp: in any case the error happens because a loaded class throws a runtime error
Mar 02 12:42:33 <jow> karlp: do you have access to the machine?
Mar 02 12:42:45 <karlp> not any more, was on a remote call setting things up.
Mar 02 12:42:51 <karlp> and I can't reproduce it at all.
Mar 02 12:43:44 <karlp> I wasns't expecting a failure on one of the core luci pages as well, my own page being busted wouldn't be out of line.
Mar 02 12:45:27 <jow> karlp: which theme was in use?
Mar 02 12:45:45 <karlp> our own, based on the bootstrap theme.
Mar 02 12:46:00 <karlp> I'd tried to resync it with upstream as much as possible from scratch when we moved to 19.07
Mar 02 12:46:28 <karlp> and many pages were fine, and the pages were getting translations that were avialable.
Mar 02 12:48:24 <jow> default /etc/config7system or customizations?
Mar 02 12:49:12 <karlp> a couple of extra keys, option rme_blah stuff, but no extra sections
Mar 02 12:49:30 <jow> ntpd builtin?
Mar 02 12:49:47 <karlp> yeah, and enable_server 1 too.
Mar 02 12:53:15 <karlp> selecting a different theme would be on that same page too
Mar 02 12:59:40 <ynezz> rmilecki: I've just proposed revert of this patch https://patchwork.ozlabs.org/patch/1247614/
Mar 02 13:25:21 <ynezz> pkgadd: did you tested the 5.4 for ipq806x already?
Mar 02 13:31:55 <rmilecki> ynezz: i came back from week holidays, i'll check those reports today
Mar 02 13:32:02 <rmilecki> ynezz: thanks for assigning that bug to me
Mar 02 13:32:25 <ynezz> nice, welcome back, hope you've enjoyed the holidays! :)
Mar 02 13:32:44 <ynezz> AFAIK didn't assigned that bug to you
Mar 02 13:32:48 <rmilecki> i had a nice hiking time in polish mountains, thanks :)
Mar 02 13:32:59 <ynezz> so covid-19 free? :p
Mar 02 13:33:04 <rmilecki> :D
Mar 02 13:33:33 <rmilecki> russell--: any chance you would find a moment to write a patch for calculating & printing absolue addresses?
Mar 02 13:34:46 <rmilecki> ynezz: ah, I saw the last notification e-mail with your commant, it was actually Yousong who assigned it to me
Mar 02 13:34:52 <rmilecki> anyway, i'll look at it later
Mar 02 13:42:45 <ynezz> ok, thanks
Mar 02 14:02:13 <russell--> unsurprisingly, packages feed's iptables-addons breaks with kernel 5.4
Mar 02 14:04:21 <russell--> rmilecki: regrettably, not in the near future
Mar 02 14:56:17 <mirko> blogic: re mtdsplit - i'm on a target with an emmc and want to access the overlay from a different system (rescue mode). any pointer by any chance?
Mar 02 15:08:08 <blogic> mirko: ok
Mar 02 15:08:15 <blogic> look at the sqsh header
Mar 02 15:08:24 <blogic> grab the len and pad it to 1k
Mar 02 15:19:19 <mirko> blogic: ack, thanks
Mar 02 15:19:32 <blogic> mirko: worste case look at how the kernel does the splitting
Mar 02 18:03:46 <owrt-snap-builds> build #296 of pistachio/generic is complete: Failure [failed tools]  Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/296  blamelist: Petr ?tetiar <ynezz@true.cz>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Mar 02 18:12:14 <ynezz> Makefile:30: recipe for target '/builder/shared-workdir/build/build_dir/host/gengetopt-2.23/.configured' failed -> "configure: error: invalid value of canonical build" pretty clear error, right?
Mar 02 18:12:26 <ynezz> that the pistachio breakage
Mar 02 18:13:36 <pkgadd> ynezz: I haven't tested kernel v5.4 for ipq806x, but I can do that tonight/ within the next couple of hours
Mar 02 18:20:46 <ldir> ynezz: err, no, that error is not clear at all.
Mar 02 18:34:24 <ldir> ynezz: I wonder if this is related to my getopt/gnugetopt location tweak.  I guess the error would be builtbot machine related and not target.
Mar 02 18:34:51 <ldir> other targets appear to be building ok.
Mar 02 19:15:06 <ynezz> ldir: based on the set of commits in that build, I guess, that it is somehow related to your change in connection to the buildbot machine/setup
Mar 02 19:15:53 <ynezz> ldir: that "pretty clear error" was rather my (probably failed) joke attempt
Mar 02 19:35:41 <ynezz> pkgadd: I've already prepared it https://gitlab.com/ynezz/openwrt/-/commit/763a72a6fbbace050b260a7847d7ae321cd6319c, 4.19 built fine, 5.4 should finish soon, so waiting for your green light now
Mar 02 19:48:18 <ynezz> pkgadd: https://gitlab.com/ynezz/openwrt/-/jobs/456539627 if you want prebuilt images
Mar 02 19:49:16 <pkgadd> ynezz: my build just finished, but I seem to have problems with kernel 5.4 on ipq8065/ nbg6817, there seems to be something wrong with ethernet or switch need to take a closer look (and respond to the PR)
Mar 02 19:49:39 <pkgadd> wireless is working though, so it boots up
Mar 02 19:49:41 <ynezz> ok then
Mar 02 19:50:49 <pkgadd> dmesg: http://paste.debian.net/hidden/b920c7a1/
Mar 02 19:52:25 <ynezz> dwc3 11000000.dwc3: Failed to get clk 'ref': -2
Mar 02 20:07:20 <pkgadd> I also get that with the (working) kernel 4.19, [    4.070400] dwc3 11000000.dwc3: Failed to get clk 'ref': -2
Mar 02 20:07:42 <ynezz> ah, ok
Mar 02 20:08:15 <ynezz> I just went through the qcom-ipq8065-nbg6817.dts 5.4 changes and didn't spotted anything obvious
Mar 02 20:09:31 <pkgadd> yeah, I'm also looking for differences. weird behaviour
Mar 02 20:10:13 <ynezz> both gmacs seems to be initialized in your dmesg
Mar 02 20:10:36 <ynezz> strange, maybe it's some config issue?
Mar 02 20:11:17 <ynezz> it can even sense link on eth0
Mar 02 20:14:39 <pkgadd> the problem is, if I drop the config, I loose WLAN access - so no further debugging possible (just push-buttopn tftp recovery). my switch config is a bit complex
Mar 02 20:18:59 <ynezz> as we're not enabling the 5.4 anyway, I'll probably remove that premature tested-by of yours and push it, hannu confirmed, that it works for him already and I believe, that Ansuel is going to iron out the remaining glitches soon
Mar 02 20:24:20 <ynezz> ipq8065, R7800 works, another user nmrh reports working r7500v2
Mar 02 20:44:30 <pkgadd> o.k., same results with your binaries
Mar 02 20:48:36 <ynezz> bummer
Mar 02 20:57:04 <aparcar[m]> ynezz: what do you think is less a work around? Adding "generic" as default subtarget to all targets or add a line like the following:
Mar 02 20:57:04 <aparcar[m]> -  KERNEL_BUILD_DIR ?= $(BUILD_DIR)/linux-$(BOARD)$(if $(SUBTARGET),_$(SUBTARGET))
Mar 02 20:57:04 <aparcar[m]> +  KERNEL_BUILD_DIR ?= $(BUILD_DIR)/linux-$(BOARD)_$(if $(SUBTARGET),$(SUBTARGET),generic)
Mar 02 21:05:20 <KanjiMonster> aparcar[m]: why do you need to change the kernel_build_dir?
Mar 02 21:12:10 <aparcar[m]> KanjiMonster: wired corner case for one of my patches. While formulating an answer I realized there might be a simpler solution keeping everything else as (heterogenous as) before
Mar 02 21:14:12 <KanjiMonster> but in general my vote is always the one-line-change if the alternative is forcing subtargets on all targets
Mar 02 21:15:49 <aparcar[m]> KanjiMonster: may I ask why? Most targets got subtargets and even if not there are multiple workarounds in the build system to make it act as the subtarget would be "generic". Does it add any complexity at any point?
Mar 02 21:23:50 <KanjiMonster> aparcar[m]: IMHO it bloats the code, especially if the same boilerplate code is added to every target. The less meaningless code a target needs to implement, the better
Mar 02 21:37:00 <ynezz> +1
Mar 02 21:38:57 <aparcar[m]> what about adding SUBTARGET?=generic somewhere in the build system? This way no extra boilerplate is needed and we don't bloat the build system with corner cases :)
Mar 02 21:40:22 <aparcar[m]> ynezz: regarding the .IGNORE problem, seems we have to implement a more advanced filter https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
Mar 02 21:40:37 <aparcar[m]> I think the same is already doen for packages
Mar 02 21:46:10 <ynezz> why?
Mar 02 21:47:09 <ynezz> $$(_TARGET): $(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2))$$(GZ_SUFFIX) your-json-foo-target
Mar 02 22:33:18 <rmilecki> ynezz: i did some progress with my memory drain debugging & got someone interested in ASUS & found problem with ASUS .trx images
Mar 02 22:33:51 <rmilecki> ynezz: i''ll look at partitioning problem tomorrow morning, right after sending e-mail regarding memory drain
Mar 02 22:34:03 <rmilecki> that e-mail should take me 30-60 minutes to write
Mar 02 22:34:06 <rmilecki> goodnight!
Mar 02 22:51:18 <ynezz> rmilecki: ok, nite
Mar 02 22:51:34 <ynezz> mangix: https://bugs.openwrt.org/index.php?do=details&task_id=2873 (Replacing pkg-config with pkgconf breaks kmod packages (and possibly more))
Mar 02 22:51:37 <ynezz> :)
Mar 03 01:38:08 <owrt-snap-builds> build #226 of mpc85xx/p2020 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp2020/builds/226
Mar 03 02:06:40 <owrt-snap-builds> build #225 of ramips/mt7620 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/225
**** ENDING LOGGING AT Tue Mar 03 02:59:59 2020