**** BEGIN LOGGING AT Sun Jan 05 02:59:58 2020
Jan 05 07:03:10 <owrt-snap-builds> build #178 of ramips/mt7621 is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7621/builds/178  blamelist: Maksym Medvedev <redrathnure@gmail.com>, Daniel Golle <daniel@makrotopia.org>, Hauke Mehrtens <hauke@hauke-m.de>
Jan 05 08:26:14 <owrt-snap-builds> build #192 of x86/64 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2F64/builds/192
Jan 05 08:44:31 <owrt-snap-builds> build #206 of gemini/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/gemini%2Fgeneric/builds/206  blamelist: Maksym Medvedev <redrathnure@gmail.com>, Daniel Golle <daniel@makrotopia.org>, Hauke Mehrtens <hauke@hauke-m.de>
Jan 05 08:45:24 <owrt-snap-builds> build #207 of imx6/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/imx6%2Fgeneric/builds/207  blamelist: Maksym Medvedev <redrathnure@gmail.com>, Daniel Golle <daniel@makrotopia.org>, Hauke Mehrtens <hauke@hauke-m.de>
Jan 05 10:57:49 <ynezz> mangix: it works fine, I build my staging tree for some time with that Docker image https://gitlab.com/ynezz/openwrt/-/jobs/388895606
Jan 05 10:58:28 <ynezz> mangix: jenkins is using the same image on buildbots, so it has to work :)
Jan 05 11:01:10 <ynezz> mangix: .gitlab-ci.yml example https://gitlab.com/ynezz/openwrt/commit/f0c4d73a9c36a54a36af019bd3b3e5aeb1bffcf4 which uses the same image and build steps (almost) as buildbots
Jan 05 11:03:47 <ynezz> free gitlab runners are quite slow, so you would probably need to increase the default 2h build timeout, but adding private gitlab runner on some beefy box is quite easy
Jan 05 11:12:40 <ynezz> Hauke: The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte ('\0')).
Jan 05 11:13:19 <ynezz> Hauke: so I really don't see why I need to do that `sizeof(buf) - r - 1`, can you please elaborate?
Jan 05 11:14:21 <ynezz> we control the prefix used in snprintf, so there's enough space for vsnprintf and it should never overflow and the string should be always NULL termintaed
Jan 05 11:15:51 <ynezz> and as my math sucks, I've actually run tested this vjson_error function outside with various inputs
Jan 05 11:16:14 <ynezz> with valgrind and sanitizers
Jan 05 11:16:31 <ynezz> so I'm quite confident, that its 99.9% correct
Jan 05 11:36:09 <Hauke> mkresin: sysupgrade from 18.06 to 19.07 does not work for me on the xiaomi_mir3g without -F because this change is not in 18.06: https://git.openwrt.org/35f70774b88b77f46c100fbe383e718de3c8ef73
Jan 05 11:48:33 <Hauke> ynezz: sorry I probably mixed this up with something else, snprintf() and vsnprintf() are always null terminated
Jan 05 11:50:26 <Hauke> ynezz: the code looks ok and you can add my acked-by
Jan 05 11:52:21 <ynezz> Hauke: thanks, but I've already pushed it, now adding the Daniel jail fix and going to test it
Jan 05 11:52:37 <ynezz> BTW did you found the solution for that initramfs+jail issue?
Jan 05 11:52:44 <Hauke> no
Jan 05 11:52:58 <Hauke> but I haven't investigated further
Jan 05 11:59:29 <PaulFertser> Yes, it's strncpy that's not always null-terminating.
Jan 05 12:13:25 <mkresin> Hauke: wasn't the image metadata only enabled for 19.07+. if so, we cant rely on the metadata
Jan 05 12:14:01 <mkresin> Hauke: the question is rather why the nand_do_platform_check fails for an 19.07 image
Jan 05 12:15:07 <Hauke> mkresin: the identify takes the first 4 bytes of the tar file
Jan 05 12:15:12 <Hauke> which is sysu
Jan 05 12:15:44 <Hauke> it should look at the rootfs insude the tar
Jan 05 12:15:46 <Hauke> *inside
Jan 05 12:16:37 <mkresin> Hauke: I'm quite sure it works different. nand_do_platform_check checks for sysupgrade-$board_name/CONTROL
Jan 05 12:16:56 <mkresin> could it be that the boardname was changed without taking care of compat
Jan 05 12:17:54 <Hauke> I am getting "Invalid sysupgrade file." and "Image check 'platform_check_image' failed."
Jan 05 12:18:03 <Hauke> from nand_do_platform_check()
Jan 05 12:18:26 <Hauke> becasue file_type is set to "unknown 73797375"
Jan 05 12:21:08 <Hauke> mkresin: the board was renamed from mir3g to xiaomi_mir3g
Jan 05 12:21:15 <mkresin> yeah, but the filetype is only checked because $control_length" = 0
Jan 05 12:21:40 <mkresin> Hauke: yeah, compat is missing. we need to add something like https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/lantiq/image/vr9.mk;h=cd43c61e6ef71573750727f07d3e6fe485866922;hb=HEAD#l165
Jan 05 12:21:40 <Hauke> yes and this is 0 because "tar: sysupgrade-mir3g/CONTROL: not found in archive"
Jan 05 12:22:41 <Hauke> it should also search for the other compat paths and not only for the one
Jan 05 12:23:24 <mkresin> and that feature was most likely added after 18.06
Jan 05 12:24:52 <mkresin> there is no other way than using BOARD_NAME with the former used name. we always will have a version which expects a fixed name
Jan 05 12:26:01 <Hauke> ok
Jan 05 13:45:00 <zorun> this is the same issue I had on another board, ubnt-erx https://bugs.openwrt.org/index.php?do=details&task_id=2430
Jan 05 13:45:35 <zorun> if there is a way to fix that, I'm interested
Jan 05 13:47:33 <ynezz> zorun: but upgrade from 18.06 to 19.07 works for ubnt-erx
Jan 05 13:48:18 <ynezz> it's 18.06 to master which doesnt work
Jan 05 13:48:30 <zorun> ynezz: you're right, the board name changed happened after 19.07
Jan 05 13:49:02 <zorun> ah, now I understand what you meant in the ticket: 19.07 has compat code to accept the new name?
Jan 05 13:49:14 <ynezz> didnt looked deeper
Jan 05 13:50:05 <ynezz> if 18.06->19.07 sysupgrade wouldnt work without -F I would care
Jan 05 13:56:52 <Hauke> ynezz: 18.06->19.07 sysupgrade does not work without -F
Jan 05 13:57:09 <Hauke> 19.07 to master works
Jan 05 13:57:59 <zorun> Hauke: yes, sorry, on the er-x it's a bit different, it's 18.06 -> master that fails
Jan 05 13:58:36 <zorun> 18.06 -> 19.07 works (there was no board name change), and according to ynezz 19.07 -> master works (probably because of compat)
Jan 05 13:58:44 <zorun> the underlying issue is the same though
Jan 05 13:58:53 <zorun> but it's less of an issue
Jan 05 13:59:52 <Hauke> zorun: yes the change which was done between 19.07 and amster for ubnt-erx was done between 18.06 and 19.07 for xiaomi_mir3g
Jan 05 14:11:57 <ynezz> Hauke: so what about the libubox/ubus/procd bumps in 19.07? I'm in favor of just cherry-picking of the stuff from current master
Jan 05 14:14:51 <Hauke> ynezz: ok fine with me
Jan 05 14:15:06 <ynezz> = Acked-by? :)
Jan 05 14:16:45 <ynezz> and I just found following reminder https://github.com/openwrt/openwrt/pull/2340#issuecomment-561317688 for 19.07
Jan 05 14:17:00 <ynezz> too many open tabs...
Jan 05 14:19:14 <Hauke> yes
Jan 05 14:22:33 <owrt-snap-builds> build #249 of brcm63xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/brcm63xx%2Fgeneric/builds/249
Jan 05 14:27:16 <Hauke> the omnia fix looks ok, but I am not an expert in this area
Jan 05 14:40:14 <Hauke> mangix: the build bot uses the SDK to build libcxx, have you checked that it builds with the SDK or if it misses some files?
Jan 05 14:45:24 <jow> Hauke: I think we should test extroot with usb drives before we release
Jan 05 14:45:27 <owrt-1907-builds> build #96 of mvebu/cortexa72 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/96  blamelist: Florian Fainelli <f.fainelli@gmail.com>
Jan 05 14:45:37 <jow> there's been a few reports that might hint at an fstools regression
Jan 05 14:57:56 <Hauke> jow: I never used extroot
Jan 05 14:58:05 <Hauke> who is familiar with it and wants to use it?
Jan 05 14:58:17 <jow> giving it a try on a mir3g atm
Jan 05 14:58:34 <jow> if will give you feedback in a few mins
Jan 05 15:01:56 <Hauke> jow: thanks
Jan 05 15:06:06 <jow> Hauke: yep, its broken
Jan 05 15:08:22 <Hauke> jow: do you have time to fix it?
Jan 05 15:08:29 <PaulFertser> extroot is essential feature afaict
Jan 05 15:11:24 <jow> Hauke: I'll try to bisect it at least
Jan 05 15:26:32 <owrt-1907-builds> build #96 of mpc85xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fgeneric/builds/96
Jan 05 15:54:37 <olmari> For x86-64, should I look to compile git 19.07 or try master? 🙂 Or other way round, how is things (webui maybe specifically) on master ATM?
Jan 05 15:57:07 <olmari> I guess same goes for tplink wdr4900 and archer C7 v2, webui not as important there, but genreal status between git 1907 and master :)
Jan 05 16:01:39 <jow> Hauke: fb0700f0fdfc4bec220203d31df87be2b4ccc467 ("block: support hierarchical mount/umount") broke it
Jan 05 16:02:14 <jow> olmari: 19.07 and master webuis should be on the same state more or less. Master has a few more backend optimizations
Jan 05 16:06:51 <olmari> jow: Thank you for the insight, I'll do master then for the x86 at the least :)
Jan 05 16:13:23 <jow> Hauke: I mailed yousong
Jan 05 16:31:07 <jow> Hauke: it seems I found a minimal invasive fix
Jan 05 16:41:50 <PaulFertser> Hm, openwrt.org doesn't have a DNSSEC record.
Jan 05 16:43:37 <olmari> PaulFertser: indeed it doesnot
Jan 05 16:44:08 <Hauke> jow: nice
Jan 05 16:54:01 <user747> quit
Jan 05 17:32:19 <Hauke> ynezz: was the link in package/uledd added intentional?
Jan 05 17:37:00 <ynezz> nope
Jan 05 17:41:49 <jow> Hauke: fixes pushed. Let's hope I didn't introduce new regressions
Jan 05 17:42:54 <Hauke> jow: thanks
Jan 05 17:43:23 <Hauke> based on all these big changes I am unsure if we should tag the final tomorrow or better do an rc3 and do final next weekend
Jan 05 17:43:36 <jow> which big changes?
Jan 05 17:43:50 <jow> I didn't really track openwrt for the last two to three weeks or so
Jan 05 17:44:02 <jow> in LuCI I almost exclusively pushed fixes to 19.07
Jan 05 17:44:05 <Hauke> jow: the procd, libubox and ubus updates
Jan 05 17:44:06 <PaulFertser> libubox/etc fixes
Jan 05 17:44:37 <jow> Hauke: hm, I'd lean towards releasing final
Jan 05 17:44:43 <Hauke> ok
Jan 05 17:44:52 <Hauke> I anyway plan to to a .1 in 3 to 4 weeks
Jan 05 17:44:57 <jow> fine with me
Jan 05 17:45:25 <jow> let's also draft up our envisioned roadmap for the upcoming year sometime this week
Jan 05 17:45:33 <jow> tuesday would work for me
Jan 05 17:45:50 <Hauke> yes
Jan 05 17:47:57 <jow> s/upcoming/this/
Jan 05 17:48:05 <jow> I'm really lagging behind :P
Jan 05 17:50:14 <Hauke> jow: did you wrote something down?
Jan 05 17:50:45 <jow> not yet, but will do so tomorrow or tuesday
Jan 05 17:51:14 <Hauke> ok
Jan 05 17:55:26 <ynezz> Hauke: fixed, thanks
Jan 05 17:56:48 <Hauke> ynezz: thanks
Jan 05 20:00:39 <Hauke> I am seeing this is the log of my production router: [522413.117215] do_page_fault(): sending SIGSEGV to dnsmasq for invalid read access from 2a001450
Jan 05 20:00:59 <Hauke> this happended multiple times some days ago
Jan 05 20:02:12 <russell--> Hauke: i've seen that here on a wdr3600 for months
Jan 05 20:02:14 <Hauke> https://pastebin.com/BTv2v8C1
Jan 05 20:15:50 <russell--> http://sprunge.us/DKjdEf
Jan 05 20:18:16 <ynezz> meh, "Filesystem too small for a journal" with openwrt-19.07-snapshot-r10854-a5653ec87e-x86-64-combined-squashfs.img.gz
Jan 05 20:18:51 <ynezz> I've forget to backport the bunch of the fixes
Jan 05 20:20:34 <ynezz> but since this is probably only related to QEMU and overlay, I'll rather skip them
Jan 05 20:31:13 <mangix> Hauke: the commit message for the libcxx change was slightly wrong. It does indeed copy extra files as a result of adding those extra paths. I have not tried compiling with the SDK
Jan 05 20:31:31 <mangix> I've only tried with a Debian buster host and a Fedora one
Jan 05 20:32:37 <mangix> ynezz: https://gist.github.com/neheb/9cec313cc7c8949d712f7a0e3df48637 . No idea why it's failing.
Jan 05 20:32:59 <mangix> maybe some SELinux policy
Jan 05 20:38:26 <ynezz> mangix: why just dont use the prebuilt image?
Jan 05 20:38:53 <mangix> link?
Jan 05 20:39:31 <ynezz> docker run --rm -it openwrtorg/buildslave /bin/bash
Jan 05 20:40:50 <ynezz> "The push refers to repository [docker.io/openwrtorg/buildslave]" and "denied: requested access to the resource is denied" is correct
Jan 05 20:41:13 <ynezz> you don't have API key/access to that docker.io repo
Jan 05 20:42:58 <ynezz> one openwrtorg/buildmaster is orchestrating the openwrtorg/buildslave(s) which are actually doing the work
Jan 05 20:44:58 <mangix> hrm I seem to be misunderstanding something. I'll deal with this later.
Jan 05 20:47:08 <owrt-snap-builds> build #227 of x86/generic is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/227  blamelist: Tokunori Ikegami <ikegami.t@gmail.com>, Rosen Penev <rosenp@gmail.com>, Bj?rn Mork <bjorn@mork.no>, Petr ?tetiar <ynezz@true.cz>, Christian Lamparter <chunkeey@gmail.com>, Andrea
Jan 05 20:47:09 <owrt-snap-builds> Dalla Costa <andrea@dallacosta.me>, Christoph Krapp <achterin@googlemail.com>, Matt Merhar <mattmerhar@protonmail.com>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Jack Chen <redchenjs@live.com>, Andreas B?hler <dev@aboehler.at>, Josef Schlehofer <pepe.schlehofer@gmail.com>, Jo-Philipp Wich <jo@mein.io>, Hauke Mehrtens <hauke@hauke-m.de>, Mason Clarke
Jan 05 20:47:09 <owrt-snap-builds> <mclarke2355@gmail.com>
Jan 05 20:48:57 <ynezz> fatal: unable to access 'https://git.openwrt.org/project/ustream-ssl.git/': The requested URL returned error: 504
Jan 05 20:49:11 <ynezz> is that build failure
Jan 05 21:44:59 <Hauke> ynezz: I saw these build problem already multiple times today
Jan 05 21:58:39 <Hauke> russell--: for me it is crashing in blockdata_write()
Jan 05 22:09:58 <Hauke> ldir: dnsmasq is sometimes crashing for me in blockdata_write() it looks like next is pointing to some wrong value
Jan 05 22:11:33 <Hauke> it happens in a row like 3 times in 1 second and then some days nothing
Jan 05 22:11:49 <Hauke> I assume that it is triggered by some DNS entry
Jan 05 22:11:53 <Hauke> this does not look good
Jan 05 22:21:49 <Hauke> this looks promising: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=e710c34469af4378c2db6fa0b0be88313adcb68f
Jan 05 22:23:58 <Hauke> does someone know how to trigger: "A negative SRV entry is possible and has no data, obviously."
Jan 05 22:42:13 <PaulFertser> Hm, I thought calling "dig SRV jabber.org" twice should do that as it's not NXDOMAIN, empty, and stored in cache but apparently that's not the thing, as my dnsmasq is not crashing.
Jan 05 22:43:42 <PaulFertser> Hauke: probably it might on your machine, unlikely but worth a try.
Jan 05 22:44:21 <PaulFertser> SRV records are most often used by SIP and XMPP (Jabber), probably you're running some IP telephony software to trigger that?
Jan 05 22:48:15 <Hauke> PaulFertser: I need one with a negative SRV entry
Jan 05 22:52:38 <PaulFertser> Hauke: I understand, and I thought such a query would lead to adding one to the cache. As "negative" is a dnsmasq-specific flag it uses to mark certain results. Probably on of your SIP applications performs a suitable query.
Jan 05 22:54:37 <Hauke> I do not know what I did when I saw this problem I saw it the last time 18 days ago
Jan 05 23:08:07 <PaulFertser> Hauke: with this command I really get "jabber.org                                                              VF   N     619" in the dnsmasq cache where "N" stands for "Negative" and "V" stands for SRV.
Jan 05 23:10:48 <Hauke> I get:
Jan 05 23:10:50 <Hauke> jabber.org.900INSOAns1.xmpp.org. hostmaster.xmpp.org. 2018032602 1800 900 604800 900
Jan 05 23:11:20 <Hauke> and in the second call nothing
Jan 05 23:12:09 <PaulFertser> Hauke: yes, and this puts a negative srv record inside dnsmasq cache, that's why the second time you get nothing.
Jan 05 23:13:09 <Hauke> PaulFertser: ah thanks
Jan 05 23:13:10 <PaulFertser> Hauke: I enabled log-query and sent SIGUSR1 to see all the cache in the syslog, and I checked the sources to see what letters in the dump mean what.
Jan 05 23:15:33 <Hauke> so we probably need that patch, but it is not the problem we looked for ;-)
Jan 05 23:17:08 <PaulFertser> It seems so.
Jan 05 23:19:16 <Hauke> I will go to sleep now
Jan 05 23:19:33 <Hauke> PaulFertser: if you find something then send me a mesage on irc
Jan 05 23:20:51 <PaulFertser> Hauke: Sure. Good night, sleep well.
Jan 05 23:28:00 <PaulFertser> The fixed code is executed apparently only for TCP queries. So adding +tcp at the end of dig command line makes a different but doesn't crash it here.
Jan 05 23:29:10 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Jan 05 23:35:44 <PaulFertser> Hauke: worth retrying with +tcp added at the end. For me the entry is not added to the cache (so the next reply is also a "full" one) but dnsmsq doesn't crash.
**** ENDING LOGGING AT Mon Jan 06 02:59:57 2020