**** BEGIN LOGGING AT Mon Jun 17 02:59:58 2019 Jun 17 04:56:17 Hauke: I don't have strong opinion on KERNEL_TESTING_PATCHVER, but I think, that it's very likely, that we're going to add it back soon or later, so if we keep it, we can simply just change the number instead of re-adding of complete variable Jun 17 04:58:57 Hauke: regarding the 4.19 bump, if it compiles, ship it :) but really, people were being told forever, don't bump the version, we'll do it once we branch off Jun 17 05:03:13 Hauke: I didn't wanted to just blindly bump the version, so we've actually build tested it again (some targets even runtested) with stintel and I'm afraid, that if we don't bump the kernel version soon enough, we're simply going to miss some testing time Jun 17 05:05:51 and AFAIK there is no such thing as `target maintainer` anymore, so I'm going to send this 4.19 bump patches to the mailing list in order to get some feedback Jun 17 06:51:46 tmn505_: Hauke: regarding your mvebu 4.19 sfp comment, those patches seems like forward port of 4.14 patches currently available in the tree Jun 17 06:53:44 but I've to agree, that they look quite strange as they're from rmk and still not in the upstream :) Jun 17 06:55:14 I believe, that there's some good enough obscure reason behind all of them Jun 17 06:56:19 morning Jun 17 07:26:17 hey guys. i have flashed two ath79 devices (WNDR3700) with 19.07 HEAD and they both started bootlooping. Jun 17 07:26:47 one with the hardened copy for MIPS enabled, another with that patch reverted - doesn't seem to make a difference there, same behaviour Jun 17 07:27:31 haven't seen any bug reports on flyspray about it yet, wanted to give a heads up before other people might start trying it (luckily the WNDR3700 has a pretty foolproof recovery) Jun 17 07:28:23 Borromini: can you please try https://lore.kernel.org/linux-mips/MWHPR2201MB127770B15273D2B1BC3B3F40C1E80@MWHPR2201MB1277.namprd22.prod.outlook.com/T/#m03b2f62618494645d58d31dc4aca92d124cc3cbc ? Jun 17 07:29:15 Borromini: I've registered at least two FS bug reports related to this Jun 17 07:29:28 ynezz: i have replied to one yes, FS 2297? :) Jun 17 07:29:47 the hardened copy for mips broke my dir-860l, reverting it made it work again Jun 17 07:30:31 i think i saw the other one as well Jun 17 07:30:40 indeed I feel your pain, but it would be better to find the root cause for this issues and fix them Jun 17 07:31:14 if we can't do that before the 19.07, then we've to revert that kernel config symbol Jun 17 07:31:43 yeah, i understand Jun 17 07:32:02 we all know the road to new stable is sometimes bumpy :) Jun 17 07:33:24 i will undo my revert and try that patch, thanks Jun 17 07:33:28 (and report back) Jun 17 07:33:33 great, thanks Jun 17 07:45:28 jow: FYI, I've just pushed ar71xx source-only change, could you please handle the remaining part on the buildbot(s) ? Jun 17 07:45:53 jow: while at it, could you please add urngd repo on git.openwrt.org ? Jun 17 07:49:27 blogic: morning! :) Jun 17 07:50:22 ynezz: just to be sure, that patch would go into e.g. target/linux/ath79/patches-4.14/ right? Jun 17 07:51:44 nope, I would put it into target/linux/generic/backports Jun 17 07:52:25 oh Jun 17 07:52:30 thanks :) Jun 17 07:53:01 if you're cooking patch/PR, then please add it for 4.19 as well Jun 17 07:54:06 if i were, what numbering should it get in backports? 900-? Jun 17 07:55:52 oh 921 Jun 17 07:56:08 there's a 920-MIPS-fix-bounds-check-virt-addr-valid.patch already. Jun 17 07:56:26 o_O nevermind me that's the patch i just dropped in there >_> >_> Jun 17 08:00:11 git bisecting two months of 1.5 year old tree is harder than you'd think :\ Jun 17 08:03:34 :D Jun 17 08:04:47 well, one usually deserve this entertaining experience in order to remember, that staying close to upstream has its benefits :) Jun 17 08:04:51 with OpenWrt it is. due to the toolchain changes mostly :) Jun 17 08:05:14 ynezz: ack for bumping sunxi to 4.19 Jun 17 08:06:50 great, thanks! Jun 17 08:40:12 aha, well, this is illuminating: commit e2b35f91b38f668976cc8a8e08843cf853d9be71 Jun 17 08:57:30 Would it be possible to look at this pull request https://github.com/openwrt/openwrt/pull/1937 and this one https://github.com/openwrt/openwrt/pull/2092 ? The first one is necessary for adding Meson support. Jun 17 09:05:36 Pepe: seems like people want this Python3 badly, but nobody has ever bothered to respond with 'Tested-by:' so far :) Jun 17 09:06:10 anyway, I'm going to clean it up and send it to the mailing list for review and then push it Jun 17 09:09:17 possibly leaving layerscape in borken state Jun 17 09:21:52 ynezz: could you also cherry pick the mikrotik detection patch to 19.07 ? thnx Jun 17 09:24:45 xback: I'll do it, just leaving some window for testing on master Jun 17 09:45:25 xback: BTW, FS#2321 looks like some regression introduced between 4.14.123 and 4.14.125 related to the HW offloading support, I don't have mt7621 yet so I'm not able to reproduce it Jun 17 09:46:16 Hi is there a initial change log for openwrt 19 yet? Jun 17 09:46:51 xback: and the provided stack trace seems quite short/unusable for any further debugging Jun 17 09:47:02 ynezz: https://bugs.openwrt.org/index.php?string=offload&project=2&do=index&type%5B%5D=&sev%5B%5D=&pri%5B%5D=&due%5B%5D=&reported%5B%5D=&cat%5B%5D=&status%5B%5D=open&percent%5B%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Jun 17 09:48:03 Tapper: "Improved version compared to 18.06" ;-) Jun 17 09:48:50 xback: so you're suggesting, that it's just some random crash, not related to 4.14.123 -> 4.14.125 kernel bumps? Jun 17 09:49:13 I'm guessing the crash is older than those bumps Jun 17 09:49:44 he specificaly states, that it doesn't crash for him on 4.14.123 Jun 17 09:53:20 I hope were are looking at the same #2321 ? https://bugs.openwrt.org/index.php?do=details&task_id=2321 Jun 17 09:53:39 yes Jun 17 09:53:43 ynezz: yeah lol Jun 17 09:54:05 he is pointing to crashlog from 4.14.63 Jun 17 09:54:35 xback: nope The correct link is: https://gist.github.com/SirToffski/41aa69bf4baca463bb04b9c1f746fad3 Jun 17 09:54:58 he has added wrong link in the description (I guess it's impossible to change it afterwards) Jun 17 09:57:53 aah :) the comment section was just ouside my screen view Jun 17 09:58:09 checking the commits between 4.14.123 & 4.14.125 .. Jun 17 09:58:48 anyway, seeing that dev_get_by_index_rcu in the stack trace, it might as well suggest, that he was just lucky on his 4.14.123 and he wasn't able to reproduce it Jun 17 10:01:16 Tapper: you're a bit too quick i think :P Jun 17 10:01:28 xback: and I wouldn't spend much time on this, we can simply remove that patch/hack in 19.07 Jun 17 10:01:59 Borromini Yeah Jun 17 10:03:07 Borromini What can I say I am a optimist! hah Jun 17 10:03:18 hehehe Jun 17 10:03:44 i'm already running 19.07 on an apu2, my dir-860l, an nbg6617 and multiple UniFi AP AC Pros Jun 17 10:04:12 both my WNDR3700s choked on 19.07 though so going to test with a patch ynezz linked me to Jun 17 10:04:55 Hopefully it should not take long for 19.x to be ready because master is really stable for me on my wrt3200acm wrt1900 c7v2 and a wdn750 Jun 17 10:06:14 are the WNDR3700s on ath79? Jun 17 10:08:49 yeah Jun 17 10:09:04 if master is stable and you're pining for 19.07, why not switch already? Jun 17 10:09:11 i assume you're building yourself Jun 17 10:09:42 Borromini yeah mate building from sorce. Jun 17 10:10:16 I am not pinning for 19.x mate was asked about it on twitter Jun 17 10:10:22 oh Jun 17 10:10:32 early days. Jun 17 10:10:39 I will stick with trunk I like to live on the edge. Jun 17 10:11:02 * Tapper Grins Jun 17 10:11:39 as long as your missus can live with it eh ;) Jun 17 10:12:12 i just switched friends over and i spent hours trying to 'fix' their vlan config only to find out ipq40xx apparently doesn't really care what about what you tell it to do Jun 17 10:15:37 jow: ping Jun 17 10:17:56 Borromini: QinQ is broken on ipq40xx ? Jun 17 10:18:44 Who fancies a laugh at my expense? Jun 17 10:18:56 blogic: sorry no idea what QinQ is Jun 17 10:19:15 Borromini: double vlan tagging Jun 17 10:19:38 It's essentially literally vlan inside vlan Jun 17 10:19:55 ..blogic beat me to it :) Jun 17 10:20:06 we have a patch to fix that i think Jun 17 10:20:53 blogic: would be neat if i could test, however this was 'just' splitting up the switch into two vlans of two LAN ports each Jun 17 10:20:57 Borromini: apparently its not in the tree, i'll dig it out Jun 17 10:21:00 so no overlap Jun 17 10:21:17 does that qualify as QinQ as well? Jun 17 10:21:31 Borromini: you need to also fiddle with the dts file for that i think Jun 17 10:21:58 yeah jeff said something similar on the forum Jun 17 10:22:54 Borromini: no, many vlans on interface is not QinQ :) Jun 17 10:23:12 https://forum.openwrt.org/t/nb6617-wan-connectivity-loss-when-vlans-are-added/38907 < what i'm seeing Jun 17 10:23:13 Borromini: Qinq is eth0.1.2 Jun 17 10:23:30 oh Jun 17 10:23:30 so you run vlan 1 ontop of eth0 and then vlan 2 inside vlan 1 Jun 17 10:23:37 no. not using that Jun 17 10:23:49 https://en.wikipedia.org/wiki/IEEE_802.1Q - double tagging Jun 17 10:23:49 QinQ is basically another set on vlan tagging after first vlan... for various reasons Jun 17 10:23:57 so if your switch uses vlan 1 for the lan ports you can make it spew out vlan 2 once the outer tag is strupped Jun 17 10:24:07 what would be the use case for that? Jun 17 10:24:37 oh ISPs Jun 17 10:25:05 Hello, i have a little problem with the partition boardconfig of a Tp-link w8970 Jun 17 10:25:12 Hello, i have a little problem with the partition boardconfig of a Tp-link w8970 Jun 17 10:25:21 what i'm seeing basically is, once i split off half of the LAN ports into a second vlan (which seems to work; device still boots), the WAN interface (eth1) loses all connectivity Jun 17 10:25:30 Wiki has example already, but for example ISP could more easily do their stuff across, say, country, and client can keep their nationwide vlanning still Jun 17 10:25:46 The module ath9k won't load and give me error -22 Jun 17 10:25:50 i didn't even think that could be related, but apparently ipq40xx has all kinds of funkiness on the switch front >_> >_> Jun 17 10:26:39 Anyone can give me a hint? PS: if i execute the script for extracting the firmware, it's succefully extracted Jun 17 10:26:58 For home users qinq is rarely a thing, but the larger the network needing to provide and cater, suddenly qinq can make sense Jun 17 10:28:21 And qinq is still as lightweight as possible, no need for other tunneling methods etc Jun 17 10:29:23 :) Jun 17 10:29:50 * ldir sends a kind of funkiness https://www.youtube.com/watch?v=8bztE5IbQOo Jun 17 10:31:48 ynezz: i just flashed my wndr3700 with hauke's patch applied. there seems to be some progress: it doesn't bootloop anymore. it just hangs somewhere during boot though =) Jun 17 10:32:06 i am a complete moron when it comes to serial so that's all i can give you. Jun 17 10:32:25 at least there's some progress :) Jun 17 10:32:42 :) Jun 17 10:33:56 if you need me to test other possible fixes, just let me know. the weird thing is the ath79 images for the UniFI AP AC Pros I maintain seem to work just fine. Jun 17 10:34:37 wndr3700 is v5, ramips, right? Jun 17 10:34:47 mt7621 soc Jun 17 10:34:56 no wndr3700 v1 is ath79 Jun 17 10:35:02 ah Jun 17 10:35:24 my dir-860l is mt7621; until i reverted the hardened mips copy patch, that choked on master/19.07 too Jun 17 10:36:05 oh, wndr3700v1 is ar7161, I don't have anything with this here Jun 17 10:36:48 next step might be testing the same on your dir-860l Jun 17 10:37:20 yes Jun 17 10:37:27 but that won't be today Jun 17 10:37:34 that's my main AP, so... Jun 17 10:37:36 erm router Jun 17 10:37:38 :) Jun 17 10:37:46 everything goes poof here then Jun 17 10:40:16 ynezz: If you are searching router with mt7621, what about Xiaomi Mir3G? Jun 17 10:40:39 indeed, I've ordered r3g and xf-r Jun 17 10:40:54 or how is that labeled :) Jun 17 10:41:30 er-x Jun 17 10:41:42 almost correct Jun 17 11:05:29 god i hate networkmanager >_> Jun 17 11:06:36 * xback hmz .. I recall someone recently complaining about this kernel err: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.51&id=028b3d8d549e276ffa34835aeb2c2a18c98e7ca3 Jun 17 11:13:35 xback: me ? Jun 17 11:13:59 14|13:40:14< stintel> bah. [220085.859305] unregister_netdevice: waiting for wan to become free. Usage count = 1 Jun 17 11:14:29 but that was on x86/64 w/ 4.19.48 kernel and flow offload disabled Jun 17 11:15:02 nft_flow_offload module is loaded though Jun 17 11:20:24 stintel: thanks for the trigger Jun 17 11:20:32 couldn't remember the context :) Jun 17 11:22:23 np Jun 17 11:22:57 good to know, I'll try building new images for my routers later today Jun 17 11:24:00 wah, i hate this error :D Jun 17 11:44:28 bad news: new kernel bumps pushed to my staging .. Jun 17 11:49:43 :P Jun 17 12:10:22 quick, modify some patches in master so they don't apply anymore :P Jun 17 12:10:47 KanjiMonster: lol - now that's cruel! :-) Jun 17 12:16:08 xback: 78ee6b1a40 needs to be re-introduced 'cos upstream incorrectly backported it, so we dropped it, then upstream reverted the backport so we need our local patch again Jun 17 12:19:41 and it should really go into 19.07. oh bu**er this has got complicated already. Jun 17 12:19:58 ldir: thanks for the info! Jun 17 12:21:04 upstream did the revert in 125. I can't remember when they incorrectly did the backport. Jun 17 12:21:31 they as in AI? :) Jun 17 12:22:09 I'm guessing your kernel bumps will be picked into 19.07? Jun 17 12:22:31 ynezz: ok, *it* Jun 17 12:22:47 ldir: found it .. they backported it after reviewing this one: https://lore.kernel.org/netfilter-devel/5E006285-FB1F-4948-87BE-BD1B8D0321E2@darbyshire-bryant.me.uk/ Jun 17 12:24:15 no one has taken me up on the offer of a damn good laugh at my expense. Jun 17 12:24:35 kidding :-) Jun 17 12:24:56 ldir: yes, got bumps for all 3 branches Jun 17 12:25:03 ok - *another* good laugh at my expense :-) Jun 17 12:25:55 * blogic hand ldir a trout Jun 17 12:25:59 *hands Jun 17 12:26:05 fat finger day for me Jun 17 12:28:40 close enough https://lore.kernel.org/netdev/20190617100327.24796-1-ldir@darbyshire-bryant.me.uk/ Jun 17 12:35:20 wtf is libupm Jun 17 12:35:34 it appears to kill our phase2 builders Jun 17 12:35:46 apparently it takes longer than an our to build it Jun 17 12:35:50 *hour Jun 17 12:36:08 me hides Jun 17 12:36:27 ah, some iot crapfest Jun 17 12:36:27 its that intel IoT crap Jun 17 12:36:33 fest Jun 17 12:36:34 set it to source-only Jun 17 12:36:46 ldir: laughs on me Jun 17 12:37:02 can't easily do that Jun 17 12:37:05 instant karma is quick these days :-) Jun 17 12:37:09 jow: i'll set it and stuff that depends on it to source-only Jun 17 12:37:26 jow: how not ? Jun 17 12:37:41 iirc there's no "source only" flag for packages Jun 17 12:37:48 but an hour is long, used to take 10 minutes Jun 17 12:37:49 just @BROKEN Jun 17 12:37:55 then break it Jun 17 12:38:07 i ported it for the linkit smart thingy Jun 17 12:41:05 I think its unrelated Jun 17 12:41:10 libupm itself was touched months ago Jun 17 12:42:43 but right now its spending excessive amounts of time compiling various lsm9ds0PYTHON_wrap.cxx.o files Jun 17 12:43:11 maybe some pip carnage Jun 17 12:43:27 like its trying to access some $could$hipster$crap that is offline Jun 17 12:43:34 i vote for BROKEN Jun 17 12:44:40 what about implementing source only for packages? Jun 17 12:48:40 added an "scripts/feeds uninstall libupm" for now to stabilize things Jun 17 13:03:47 blogic: who is the mantainer of the ath9k boardconfig extract script? Jun 17 13:08:39 stintel: what would source only mean, like just deliver sources as if cloned via git? Jun 17 13:09:16 not build by buildbots, not producing binary packages/images Jun 17 13:10:11 ynezz: source-only applied Jun 17 13:10:22 aparcar[m]: like for example https://git.openwrt.org/016d1eb1f9c1 Jun 17 13:10:50 jow: nice, thanks, another milestone towards 20.1 achieved :) Jun 17 13:11:09 DuDu371: There isn't such a thing, I think. Jun 17 13:12:10 ynezz: repo created as well. Please use "ssh git@git.openwrt.org desc project/urngd Whatever foo" to set a meaningful description Jun 17 13:14:10 gch981213: Thx, do you know ho can help me instead Jun 17 13:20:23 jow: thanks, done Jun 17 13:22:08 Hauke: what is this %z format type? A type suitable for (s)size_t ? Jun 17 13:24:16 jow: blogic: technically there is; "DEFAULT:=n" will prevent the package from being enabled by ALL_ Jun 17 13:25:01 (not sure if this helps when building with sdk) Jun 17 13:27:02 yepp, also works for SDK Jun 17 13:32:21 ynezz nice commit! I'll comment it under my removal PR to lower the hate :) Jun 17 13:32:45 done already :p Jun 17 13:33:01 didn't noticed decrease of the hate, though Jun 17 13:59:43 ynezz: the hate is strong with this particular one Jun 17 14:00:12 jow: %zu %zd %zx are C99 additions for printing size_t Jun 17 14:00:45 aparcar[m]: which PR is this? Jun 17 14:01:35 The one which number one must not speak of Jun 17 14:01:39 blogic: ping Jun 17 14:04:03 I'm looking at some really old stuff, apparently broken around the time when OpenWrt switched to procd... we have something called Image Config Options with (CONFIG_)TARGET_INIT_ENV which seems no longer working or at least I'm just blind trying to find out what should use its value Jun 17 14:05:17 am I right thinking that procd should add that custom env vars? Jun 17 14:06:07 before migration to procd it was done like this: Jun 17 14:06:09 exec env - PATH=$pi_init_path $pi_init_env $pi_init_cmd Jun 17 14:06:21 inside 99_10_run_init Jun 17 14:08:10 package/base-files/files/etc/preinit -> for pi_source_file in /lib/preinit/*; do ? Jun 17 14:08:39 echo 'pi_init_env=$(if $(CONFIG_TARGET_INIT_ENV),$(CONFIG_TARGET_INIT_ENV),"")' >>$(1)/lib/preinit/00_preinit.conf Jun 17 14:08:44 Wow, does that ath10k antenna gain change from 3 dBi to 6 dBi make as big a difference as I think it does? Jun 17 14:08:58 Quazil: yes, double Jun 17 14:09:06 ... Jun 17 14:09:19 in some cases ;) Jun 17 14:09:52 It's actually 1.6x :P Jun 17 14:10:15 ynezz: yes and then what? the pi_init_env var isn't used AFAIK Jun 17 14:11:10 for powers calculations, a 3dB increase or decrease represents a doubling or halving of the power. Jun 17 14:11:25 ynezz: it looks like support for some of the configs got accidentally dropped Jun 17 14:11:42 for voltage calculations, 6dB represents a doubling/halving Jun 17 14:13:14 ynezz: pi_init_cmd (TARGET_INIT_CMD) is the second one Jun 17 14:13:40 so a 20dBm (ie dB related to 1 milliwatt - a watt is a measure of power) represents 0.1W. Jun 17 14:14:31 pepe2k: yep, looks like that Jun 17 14:14:38 23dBm corresponds to (fractionally under) 0.2W (0.1995262315) which is a doubling near as dammit. Jun 17 14:16:00 ynezz: ok, thanks, lets fix or drop it Jun 17 14:26:51 pepe2k: drop it, that preinit mechnism is overcomplicated anyway imho Jun 17 14:28:21 jow: actually part of that is (or should be) used later, in regular init Jun 17 14:29:51 failsafe related options are working but they are used inside preinit by scripts Jun 17 14:30:31 pepe2k: yeah but I'm all for removing any options which are broken right now Jun 17 14:31:56 jow: ack, will send patch later Jun 17 14:54:12 Seems like OpenWrt is now on the official LXD servers Jun 17 14:54:38 cool Jun 17 14:54:53 Offered as an image Jun 17 15:01:04 Aka here https://us.images.linuxcontainers.org/ Jun 17 15:23:41 I'm wondering how to handle the Python3 switch Jun 17 15:24:11 so far it seems like anything using scons will fail to build, as the scons scripts are written for Python2 Jun 17 15:24:47 and layerscape is using a lot of Python2 code in their platform tooling Jun 17 15:26:14 ynezz: You kinda need to be able to install both and then set the scripts the need python 2 explicitly to #!/usr/bin/python2 Jun 17 15:27:12 ynezz: let's replace scons with mesons ;) Jun 17 15:27:43 Quazil: nope, don't want to support both version, it's a road to craziness Jun 17 15:28:42 not that python2 would suddenly stop working, but AFAIK all the support for it is nearing the end... Jun 17 15:29:17 https://pythonclock.org/ Jun 17 15:31:50 well, I'm not asking if we should do it, but rather if it would be ok to do it with 1 broken target and 3 broken packages Jun 17 15:32:25 that broken target is layerscape with package/firmware/layerscape/ls-rcw broken and it needs to be fixed upstream Jun 17 15:32:48 I've tried to convert it to python3, but it's above my head, it's actually pretty crazy Jun 17 15:33:49 and those broken packages in the packages feeds are iotivity, smartsnmpd and gpsd which are using scons, but doesn't build with Python3 anymore Jun 17 15:33:58 not that bad score I would say Jun 17 15:34:56 Will meson be integrated to the buildroot? I remember some was pushing things Jun 17 15:35:28 it's likely, once there's python3 Jun 17 15:36:11 All right Jun 17 15:40:02 ynezz: have you tried poking the layerscape people to make them fix their packages with python3? Jun 17 15:40:47 KanjiMonster: https://github.com/openwrt/openwrt/pull/1937#issuecomment-487829011 Jun 17 15:41:35 going to poke them again Jun 17 15:47:27 Is there a `make` target that just packages the existing kernel/rootfs and doesn't rebuild everything? Jun 17 15:48:14 I'm using `make target/linux/install` Jun 17 15:48:54 jow: is there something like getver.sh but for the actual release? Like it checks the tag or something Jun 17 15:51:41 or could getver.sh be extended to show the release as well Jun 17 16:16:31 jeffsf: ping Jun 17 16:17:58 pong Jun 17 17:19:26 jow: the last update to libupm was really done by nxhack on github Jun 17 17:19:54 mangix: yeah seen it. anyhow something made it suddenly take a loooong time to build Jun 17 17:20:10 apparently it builds node.js, python 2 and python 3 bindings Jun 17 17:20:35 maybe something was unbroken recently, causing it to take 3+ hours Jun 17 17:24:53 is this on a specific platform? Jun 17 17:26:05 I know node and dependent packages fail on ARMv5 platforms Jun 17 17:26:47 on all as far as I can see Jun 17 17:28:14 BLK_CGROUP_IOLATENCY for Linux 4.19 is patched somewhere on a staging tree, yes? Jun 17 17:29:27 jow: fbthrift fails on the buildbots in some weird way. Buildbots don't build the host packages for some reason. Actually the way the host libraries are handled is a bit special Jun 17 17:29:35 Definitely needs review Jun 17 17:30:43 mangix: sounds like it implies new prereqs Jun 17 17:33:03 I mean these two lines: https://github.com/openwrt/packages/blob/master/libs/fbthrift/Makefile#L32 . Usually these are listed in PKG_BUILD_DEPENDS Jun 17 17:34:16 yeah, looks very weird and wrong Jun 17 17:34:36 why not just PKG_BUILD_DEPENDS := boost/host or whatever Jun 17 17:34:59 It's already there. But boost is modular Jun 17 17:35:50 well the host build shouldn't be Jun 17 17:36:48 right, the commit that added this tried to match what Boost the target package was doing Jun 17 17:38:39 I also do not understand this line: https://github.com/openwrt/packages/blob/master/libs/fbthrift/Makefile#L18 . Why is HOST_BUILD_PREFIX normally set to _HOSTPKG? Jun 17 17:39:17 I have no idea Jun 17 17:39:28 too much black magic for my taste Jun 17 17:41:01 This sets it: https://github.com/openwrt/openwrt/blob/master/include/host-build.mk#L30 . I don't understand the if condition Jun 17 17:41:37 packages are supposed to use _HOSTPKG, non-packages (tools/*) not Jun 17 17:41:52 fbthrift violates this requirement Jun 17 17:42:50 That's bizarre since boost/host gets installed to _HOST not _HOSTPKG Jun 17 17:43:03 then something is wrong about it Jun 17 17:44:30 hmmm I'm not seeing anything that specifies _HOST in the Boost Makefile Jun 17 17:44:52 line 382 is the problem Jun 17 17:45:04 https://github.com/openwrt/packages/blob/master/libs/boost/Makefile#L382 Jun 17 17:49:15 hmmm OK. I will think about this. Jun 17 17:50:58 I know that net/kea was depending on boost/host before this commit, but boost/host probably was only running this line: https://github.com/openwrt/packages/blob/master/libs/boost/Makefile#L379 Jun 17 17:51:46 in any case boost should stage in _HOSTPKG, not _HOST Jun 17 17:52:28 reasoning: multiple targets (e.g. x86, ath79, ...) may share the same buildroot and the same tools Jun 17 17:52:45 Each target however may have differently configured host builds of its respective packages Jun 17 17:53:08 so you can have an x86 boost/host and a differently configured ath79 boost/host Jun 17 17:55:10 Right. As for those host dependencies, I think I will hardcode them. Jun 17 18:00:22 ynezz: I would leave the KERNEL_TESTING_PATCHVER fetaure, but remove it from the target when the normal kernel and the testing kernel version are the same Jun 17 18:00:51 it would be nice if someone would try if it boots before we change the kernel to 4.19 Jun 17 18:01:29 we do not have to change all of them at the same time to 4.19, if you think a target is ok just change it Jun 17 18:01:53 I will have a look at sunxi tomorrow, Jun 17 18:02:37 ynezz: with target maintainer I mean someone who had the hardware and knows a little about ti Jun 17 18:02:39 *it Jun 17 18:20:53 jow: yes %z is for size_t Jun 17 18:21:06 I think this is veen in posix Jun 17 18:21:38 %z is only problematic on Windows when MinGQ has STRICT_ANSI set Jun 17 18:21:44 *MinGW Jun 17 18:23:18 even microsoft supports %z now in revent VS versions Jun 17 18:23:47 right, it's not really a problem Jun 17 18:24:35 Hauke: I've got Ack from wigyori for sunxi already Jun 17 18:25:39 Hauke: I'm wondering what's the point of adding support for 4.19 at the first place and then do another round of testing in order to enable it Jun 17 18:28:22 ynezz: it could broke after some time Jun 17 18:31:48 ok, fine with me, so I'll update only those I've run tested myself, got Tested-by or Acked-by Jun 17 18:32:22 do I need to run test also every subtarget? Jun 17 18:32:41 no testing the main target should be sufficent Jun 17 18:59:35 no one tell xback that 4.14.127 4.19.52 are out.. with CVEs too. Jun 17 19:01:22 nice optimization, he can skip one bump Jun 17 19:02:05 jeffsf_: yes https://git.openwrt.org/9083c0e70a7b Jun 17 19:02:32 Thanks ynezz Jun 17 19:06:52 tmn505_: can I have your 'Tested-by' for the mvebu and tegra 4.19 bumps? Jun 17 19:44:42 gch981213: have you submitted the netif_receive_skb_list patch? Jun 17 19:55:37 Any tricks for passing a space-containing string in a target image declaration to `param_get`? Jun 17 19:55:46 blah='one two' gets split and results in blah='one Jun 17 20:00:18 NM, there it is: include/toplevel.mk:space:= $(empty) $(empty) Jun 17 20:03:13 Bah, not quite -- another day... Jun 17 22:15:24 great. new kernels addressing 3 CVEs \o/ Jun 17 22:15:58 xback: you might want to wait with pushing your staging tree kernel bumps :/ Jun 18 01:06:31 Are there any "written" restrictions on characters for board naming, other than underscore and comma are "special"? Jun 18 01:06:58 In particular, is it safe to assume that ampersand & doesn't appear in a "valid" board name? **** ENDING LOGGING AT Tue Jun 18 02:59:57 2019