**** BEGIN LOGGING AT Sun Dec 16 02:59:59 2018 Dec 16 07:45:05 build #1084 of ixp4xx/generic is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/ixp4xx%2Fgeneric/builds/1084 blamelist: Michael Heimpold , Rosen Penev , Deng Qingfang , Brett Mastbergen , Ben Greear Dec 16 07:45:05 , Mathias Kresin , Roman Bazalevsky , Marcin Jurkowski , Anderson Luiz Alves , Hans Dedecker , Daniel Santos , Christian Lamparter , Eneas U de Queiroz , Michael Yartys Dec 16 07:45:05 , Daniel Engberg , Hauke Mehrtens , Andre Heider Dec 16 08:15:36 Hello all Dec 16 09:03:39 hey is this a option "At this point, it might’ve complained about missing dependencies, which you should install using your distro’s package manager." ? Dec 16 09:04:42 i did build a iopsys\lede romethiny but all the stuff was super outdated ( the only thing that was updatet was the stupid iopsys html files .. lol) .. Dec 16 09:05:35 And yes, i realy want to make the wiki for iopsys EG400 ( i think i found the target name also (maybe)) Dec 16 09:22:13 ZorgxX: what are you talking about ? Dec 16 09:24:45 the builder crash many times becuse of old packes .. and i dont like to remove the patchs and add a updated link in the makefile Dec 16 09:25:07 i never done it befor now.. and .. yes it most be a better way Dec 16 09:26:23 what builder? Dec 16 09:27:35 git clone http://public.inteno.se/iopsys.git iop-cc cd iop-cc git checkout devel ./iop bootstrap ./iop setup_host ./iop feeds_update ./iop genconfig -c dg301 Dec 16 09:27:56 you should ask them Dec 16 09:29:28 its looks like a copy of openwrts builder.. was thinking of just take openwrt and put it inside and replace all the files that match ( and remove the other patches if a folder got replacet) Dec 16 09:32:05 but still .. is all the packages in your up to date if i do git clone https://github.com/openwrt/openwrt.git ? Dec 16 09:32:43 is ther no program to just "read the makefile" check database if thats last one ? Dec 16 09:33:23 in openwrt, you can update feeds like this: scripts/feeds update -a Dec 16 09:33:41 and then register them with the build system: scripts/feeds install -a Dec 16 09:33:56 nfi what iopsys does Dec 16 09:35:11 but does that update every thing in the hole builder ? Dec 16 09:35:35 they do just iop update feeds Dec 16 09:36:28 its a file name iop thats do some stuff.. but .. yea . many thing is outdated .. and i was hoping it was a simple selution to that .. Dec 16 09:38:46 that is copy in "busybox? mv -b didnt work Dec 16 09:40:44 again, you should ask them Dec 16 09:43:57 cp -u --. was is Dec 16 09:44:23 i think google is better busybox guru than iopsys thats only use outdated one Dec 16 09:46:25 is it safe to do opkg install https://downloads.openwrt.org/snapshots/targets/kirkwood/generic/packages/kernel_4.14.88-1-eb0f0ca49fb62ad22d1b45f5e15e9c12_arm_xscale.ipk Dec 16 09:49:02 * russell-- would guess not Dec 16 10:13:55 nbd: ping Dec 16 10:39:41 build #1165 of mxs/generic is complete: Failure [failed tools] Build details are at http://phase1.builds.lede-project.org/builders/mxs%2Fgeneric/builds/1165 blamelist: Michael Heimpold , Rosen Penev , Deng Qingfang , Brett Mastbergen , Ben Greear Dec 16 10:39:41 , Mathias Kresin , Roman Bazalevsky , Marcin Jurkowski , Anderson Luiz Alves , Daniel Santos , Christian Lamparter , Eneas U de Queiroz , Michael Yartys , NOGUCHI Dec 16 10:39:41 Hiroshi , Daniel Engberg , Hauke Mehrtens , Andre Heider Dec 16 10:54:31 Hauke: ^ Dec 16 10:54:55 make[3]: *** [ufb] Error 1 Dec 16 10:55:07 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=4bf5c4395b36456484c3b76d440d051f92938f96 Dec 16 10:58:34 jow: I will have a look at this Dec 16 11:08:13 thanks Dec 16 11:30:31 Hauke: what do you think about doing an 18.06.2 next week? Dec 16 11:31:06 I'm about to finish rebasing master on top of 18.06 to simplify picking fixes and backports Dec 16 11:31:26 then do a sweep over the log to see if there's anything worthwhile or missed (cve fixes and such) Dec 16 11:32:55 Yes please, something for us to update over the holidays :-) Dec 16 11:36:01 \o/ Dec 16 11:36:13 ynezz: slick patch you just sent re default gpio state. I was wondering about that when I did dts for 825-c1. In the end I left these out, luckily. Dec 16 11:37:47 jow: please include the ubifs fix Dec 16 11:43:39 russell--: got a pointer? Dec 16 11:43:47 subject / sha / ... Dec 16 11:44:40 c6a1bcac16f92afa1e41eaceafc85075d97a74cd Dec 16 11:44:53 kernel: fix ubifs loosing O_TMPFILE data after power cut Dec 16 11:45:49 thanks Dec 16 11:47:04 everything with NAND/ubifs and on 4.14.x was affected Dec 16 11:48:10 jow: I thik foing 18.06.2 would be a good idea Dec 16 11:48:31 I am already on facation and only travel on wednesday to my parents, so I have some time helping Dec 16 11:51:19 great Dec 16 11:56:39 micmac1: yeah, submitting this to linux-kernel is going to be fun, list of maintainers is pretty long Dec 16 11:57:19 :) Dec 16 12:48:52 jow: I think this failure is unrelated to this commit Dec 16 12:49:12 is this build on debian with kernel 3.16? Dec 16 12:49:46 the missing structure was introduced in kernel 3.18 and it uses the host kernel header here Dec 16 12:52:50 ok I will remove the ufb, it needs host kernel >= 3.18 Dec 16 12:57:23 Hauke: I need to check Dec 16 12:58:42 build #684 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/684 Dec 16 13:00:52 jow: I removed the tool now this part is not needed Dec 16 13:05:21 jow: should work again Dec 16 13:32:05 heh, that epic interactive rebase is still running, its already four hours or so Dec 16 13:38:09 jow: what are you doing? Dec 16 13:39:05 Hauke: wrote a script which identifies all past commits that touched patches, creates and interactive reabse plan for them, edits each commits, runs make .../refresh, identifies diffs, git commit ammends and continues rebasing Dec 16 13:39:25 ok Dec 16 13:40:32 this already identified a number of backport commits that applied okay git-wise but introduced broken or fuzzed patches Dec 16 13:43:31 problem is that the openwrt-18.06 branch lacks almost all ath79 changes and has a different kernel update history compared to master Dec 16 13:43:50 jow: what do you want to backport? Dec 16 13:44:03 so when I rebase master on top of openwrt-18.06 (to serve as source to cherry-pick fixes from later), things like mac80211 patches etc. are shifted in context Dec 16 13:44:30 Hauke: mostly cve related updates, toolchain, tools and buildroot fixes Dec 16 13:44:38 ok Dec 16 13:44:52 I might give the mac80211 from master a spin as well, but I guess we shouldn't make it part of .2 Dec 16 13:45:04 but there's some hostapd updates and fixes that should be backported Dec 16 13:45:08 like the UNKNOWN_COMMAND fix Dec 16 13:48:12 Hauke: we should come up with some sort of protocol to mark fixes for backporting to stable Dec 16 13:48:27 Hauke: like on the lkml where you simply cc stable@ Dec 16 13:48:45 yes I agree Dec 16 13:49:01 this would help me and others to identify commits which warrant backporting without having to follow master development all the time (or frequently asking people) Dec 16 14:13:12 jow: I ususally try to have a "Fixes" tag in commits for fixes referencing the commit that introduced the issue Dec 16 14:14:02 me too and some other people also Dec 16 14:18:01 KanjiMonster: ok, so for each commit in openwrt-18.06, extract the corresponding master sha by parsing "(cherry-picked from commmit ...)" [or by doing some fuzzy matching based on subject & time], then check the master log fro any commits referencing that sha in their "Fixes:" tag Dec 16 14:18:40 this works for things fixing previous broken commits, but not for things like "update iproute2 to latest minor version to fix segfault with foo bar argument" Dec 16 14:19:31 for such commits it would be great to have some kind of tag or line, e.g. "This should be backported to stable" or just "Cc: stable" or something Dec 16 14:23:09 basically anything I can git log --grep for Dec 16 14:43:42 jow: https://git.kernel.org/pub/scm/linux/kernel/git/sashal/stable-tools.git/ has a few scripts to solve some of the issues (e.g. find out if a commit is part of the branch by first checking the commit hash, then if a commit with the same subject exists) Dec 16 14:48:57 KanjiMonster: thanks! this seems to do a lot of things similar to how I was thinking to do it, probably makes sense to fork and build upon it Dec 16 14:50:02 jow: this git was my inspiration for creating our maintainer-tools git ;) Dec 16 15:13:09 xback: the build bot is unable to find the zip utils which is needed after this commit: https://git.openwrt.org/b4e17a7440cd9885a678f2a28609a38eca6dd5dc Dec 16 15:13:20 this makes the ramips target fail to build Dec 16 16:38:02 jow: can this be merged? https://github.com/openwrt/openwrt/pull/1620 . It's currently blocking a package bump in the packages feed. Dec 16 16:39:40 why the change from exec to eval ? Dec 16 16:39:48 this changes the semantics of the script Dec 16 16:40:39 that...I did not notice. Dec 16 16:41:36 the change in line 8 looks superfluous as well Dec 16 17:12:38 jow: I need some help - the elfutils patch I pushed a few days ago has broken building iproute2 https://forum.openwrt.org/t/unable-to-install-ip-full-ip-tiny/27172 I'm not sure how I missed that as I'm sure I did a build from clean. Anyway, I can revert the patch. Or maybe a better option is to cherry pick https://github.com/openwrt/openwrt/pull/1627/commits/e1b7b360b846876f8f5d8cfbfd5f9372a8eabdbd Dec 16 17:13:53 ldir: urgh, this looks hairy Dec 16 17:14:05 is ip depending on libelf as well when tc is enabled and picking it up? Dec 16 17:14:42 I have no idea - so I'm going to revert the elfutuls change and not touch anything I don't understand ever again. Dec 16 17:16:35 I had a brief look earlier today but I was somehow unable to produce a libelf.so.1 in the first place Dec 16 17:16:59 ldir: the commit you linked is fine for now as a stop-gap measure, you can simply merge it Dec 16 17:17:35 I suspect that "ip" is not actually depending but I have no proof of that Dec 16 17:18:59 Hauke: small nitpick for "[PATCH v2] base-files: Fix netdev led trigger" - you probably should check the sysfs mode file for existence before attempting to write into it Dec 16 17:19:13 I'm going to revert the elfutuls change...it's incorrect anyway as it should have had a package bump in it. Tony's changes/prs are not as independent as perhaps he things. Dec 16 17:19:28 jow: ok will do Dec 16 17:20:38 ldir: allright, I'm glad to help untangling this mess when I've finished doing my rebase stuff Dec 16 17:21:26 jow: size of package goes from 716323 to 381849. I will test your suggestions. Dec 16 17:22:45 I'm happy to mess up dnsmasq 'cos I sort of 'get it' but most others I feel (due to my ignorance) that I'm being pushed into it. Dec 16 17:23:49 ldir: its fine to apply things that appear sane and to revert them when things break Dec 16 17:23:55 don't worry too much about it Dec 16 17:24:35 ldir: you should have a look at the comits I did today ;-) Dec 16 17:27:06 well I re-opened the relevant PR with the explanation. Dec 16 17:27:08 jow: line 8 seems necessary. I reverted the change and it breaks the configure script Dec 16 17:28:32 nope Dec 16 17:28:40 wasn't line 8. it was the eval change Dec 16 17:28:54 I feel like I'm trying to help/nudge/getting asked to nudge things along but getting bitten in the process. So I'll just back off for the moment. Dec 16 17:31:14 Hauke:I switched PKG_SOURCE_URL of omcproxy to https://github.com/openwrt/omcproxy; so we can avoid to keep out of tree patches Dec 16 17:31:31 idle curiosity...why do we now get two commit emails per commit? Dec 16 17:31:44 ldir: you mean on the commits ml? Dec 16 17:31:50 yeah Dec 16 17:32:04 my fault most likely Dec 16 17:32:15 I started syncing git-01 and git-02 via gitolite Dec 16 17:32:22 this syncs all triggers as well Dec 16 17:32:27 in this case the mailhook Dec 16 17:32:42 so when you push, git-01 sends the mail, then pushes to git-02 which ... sends the mail again Dec 16 17:32:46 will fix Dec 16 17:32:48 I get one from me - and another from 'server-lede' Dec 16 17:32:53 right Dec 16 17:34:27 dedeckeh: good Dec 16 17:35:52 rmilecki: brcmfmac4366c-pcie.bin is available in linux-firmware Dec 16 17:42:19 dedeckeh: wouldn't it make sense to host it on git.openwrt.org for consistency? Dec 16 17:42:55 jow:that makes sense Dec 16 17:43:19 I'll initialize an empty project/omcproxy Dec 16 17:43:20 Is there some method to the numbering of patches in target/linux/generic/backport-4.14 Dec 16 17:43:51 ldir: yeah, iirc it follows target/linux/generic/PATCHES Dec 16 17:44:15 ok will look :-) Dec 16 17:44:31 jow:thx; I will do the transfer and the switch Dec 16 17:48:54 jow: am being asked by someone else how to produce patches for openwrt - look out for class e IP address support Dec 16 17:50:06 ldir: Dave Täht? Dec 16 17:50:32 SwedeMike: yep Dec 16 17:50:35 ldir: I've had this class-e discussion with him and a few others for a few weeks now. Dec 16 17:51:04 SwedeMike: is this something else I should be running away from? Dec 16 17:52:30 ldir: no, I think it's fine. Dec 16 17:52:38 the patches I've seen are simple enough. I was going to say 'and innocent' but I suspect that may be where the problem lies. Dec 16 17:53:23 ldir: I see no reason to remove artificial limitation that disallows configuration of addresses from class-e space Dec 16 17:53:46 err Dec 16 17:53:53 uhm, what is class-e ? Dec 16 17:54:00 I mean, I think it's fine to remove artificial limitations Dec 16 17:54:01 and where do we have limitations? Dec 16 17:54:01 I know what you're trying to say :-) Dec 16 17:54:08 jow: 240.0.0.0/4 addresses Dec 16 17:54:14 ldir: double mail should be fixed, please yell if not Dec 16 17:54:40 SwedeMike: and where is it limited? in ifconfig/ip ? Dec 16 17:54:53 http://www.taht.net/classe/ Dec 16 17:55:45 jow: it's at least limited in the places that have been identified in the patches in the link that ldir sent, might be more. Dec 16 17:56:16 jow: I helped them identify that for instance Cisco IOS XR and Juniper JUNOS allows 240.0.0.0/4 just fine. Dec 16 17:56:17 jow: so it's basically netifd & kernel ifconfig (which has gone upstream anyway) and bcp38 package needs a tweak too. Dec 16 17:57:26 but to submit those patches it's mail list for netifd, maillist/github for ifconfig (kernel backport) and github PR in openwrt/packages for bcp38 Dec 16 17:59:26 all with correct SoB of course - and just realised you need a package bump patch to bump openwrt to look at the new netifd state as well Dec 16 17:59:31 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Dec 16 18:01:56 ldir: Acked-by on netifd Dec 16 18:02:12 perhaps I should take pity and just get on and do it....after I've got rid of this blinding headache. Dec 16 18:11:24 Hauke: i know, I'm goign to test it soon Dec 16 18:13:45 [2018-12-10] [13:19:20 CET] Broadcom has released 4366c0 firmware! Dec 16 18:13:47 [2018-12-10] [13:19:27 CET] finally Dec 16 18:13:48 [2018-12-10] [13:19:32 CET] I think it took 2 years or so Dec 16 18:18:34 rmilecki: good that you already know Dec 16 18:18:48 i'll start working on that tomorrow Dec 16 18:18:54 i have some 4366b and 4366c devices Dec 16 18:20:41 rmilecki: support for it was added to the driver in feb 2016: https://git.kernel.org/linus/bc86fdb9ac02c77b9f55325f64fb70decc425962 Dec 16 18:24:21 Hauke: so my "2 years" was pretty close :) Dec 16 19:08:07 jow: would it make sense to backport https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3f7dd06fd8558685f71f01ef3cbcf844d402b71c for 18.06.2? Dec 16 19:08:40 it fixes a CVE (just like the previous 2.13 bump did as well) Dec 16 19:08:53 Borromini: already on the list Dec 16 19:09:10 I'm always a bit carefuly with dizzy commits though Dec 16 19:09:19 theres a 50-60% chance that they blow up Dec 16 19:09:21 ;) Dec 16 19:09:24 hehe Dec 16 19:09:35 he likes to bump stuff no matter what huh Dec 16 19:12:06 while I've read that it's not on the table anyways, I'd caution against pushing the 4.19 based mac80211 packages into 18.06.x, WDS and ath10k are broken with it and the ath10k --> ath10k-ct (although that one would be easy to back out) isn't completely without its own share of pitfalls either Dec 16 19:13:34 pkgadd: did you write a mail baout the wds problem to the linux wireless mailling list? Dec 16 19:13:56 *about Dec 16 19:14:16 not going to touch ath10k, its a too big can of worms Dec 16 19:14:40 Hauke: not yet, I tried to look (and test) through upstream commits as it almost looked as if it were fixed upstream, but none of the apparently relevant commits seem to fix it Dec 16 19:15:40 jow: well, the problem shows with ath10k (but not ath9k), but the actual breakage is part of the generic mac80211 stack and therefore might affect other chipsets as well http://paste.debian.net/hidden/c35d7e4b/ Dec 16 19:16:22 pkgadd: shouldn't we push a revert-patch to master then? Dec 16 19:17:08 it will definately fix WDS/ 4addr on ath10k, I've been running it since 2018-11-19, including the latest 4.19.7 based mac80211 bump Dec 16 19:17:38 can you pastebin / send / pr your local revert commits? Dec 16 19:18:03 ah nvm you did Dec 16 19:19:02 http://paste.debian.net/downloadh/c35d7e4b is the exact commit that applies as is for master, not quite sure if 999-Revert-mac80211-allow-AP_VLAN-operation-on-crypto-co.patch is the best prefix for it though, but yes, I can create a pull request as well Dec 16 19:20:14 seems to match "9xx - uncategorized other patches", but 999 might be a bit high Dec 16 19:24:08 hm, I thought the toolchain was packaged up with releases, am I mistaken? Dec 16 19:29:09 isn't WDS deprecated already? I think I remember seeing that something like a year ago Dec 16 19:29:25 Mister_X: why should it be deprecated? Dec 16 19:29:29 meh, guess I was thinking of the sdk Dec 16 19:29:41 in favor of 802.11s I'd say Dec 16 19:30:04 I can't remember exactly all the details and I'm trying to find it again Dec 16 19:32:13 https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg14457.html Dec 16 19:37:38 Mister_X: ah, but that is legacy wds Dec 16 19:37:50 when we mention "wds" here we usually mean ap_vlan / 4addr mode Dec 16 19:41:40 I thought 4 addresses were only used in WDS Dec 16 19:42:09 yes Dec 16 19:42:17 there's an old legacy wds which is very limited Dec 16 19:42:26 and a "modern wds" (4addr mode) Dec 16 19:42:48 the modern variant works like a normal ap-to-sta association and dynamically negotiates 4addr mode Dec 16 19:43:26 due to this it is free of the limitations cited in your mail Dec 16 19:43:35 it can do ht/vht, encryption etc. Dec 16 19:43:46 4addr is nice Dec 16 19:47:02 any place where I can find details on it? Dec 16 19:47:25 I'm curious how it negotiates/switches to the 4addr mode Dec 16 19:53:40 stupid question dept - I can't find any targets using k4.9 or k4.19 so how do I refresh patches ? Dec 16 19:57:53 ldir: make target/linux/refresh KERNEL_PATCHVER=4.9 (or 4.19) Dec 16 19:58:10 cheers - will try Dec 16 20:00:58 and is there any good reason to choose WDS over 802.11s when it's available? Dec 16 20:03:58 ldir: btw ar7, at91, brcm2708, ixp4xx, layerscape, and orion are still on 4.9, in addition to that brcm63xx still has 4.9 support Dec 16 20:11:27 Mister_X: don't you need routing for 802.11s ? Dec 16 20:12:08 danitool, should be taken care of Dec 16 20:12:18 as in built-in Dec 16 20:12:24 unless I'm mistaken Dec 16 20:12:36 HWMP Dec 16 20:13:07 inspired from AODV Dec 16 20:14:56 built-in driver or hardware? Dec 16 20:15:34 I guess WDS will be faster Dec 16 20:17:41 Mister_X: for a relatively simple use case with 1-3 'repeaters' in fixed locations and in range to the master AP, WDS is a simple solution that just works - and which works with the same bssid for both the WDS-clients and normal STAs Dec 16 20:19:16 it's also a nice solution if you don't want to actually repeat the signal, but just want to use an old AP (better antennas/ performance as a USB card or many PCIe cards (due to antenna placement)) as WDS-client to connect a wired-only system to the WLAN Dec 16 20:20:38 avoid to use USB wifi dongles for repeating, they're slow Dec 16 20:20:42 as hell Dec 16 20:20:52 and unreliable, yes Dec 16 20:21:08 slowness isn't that much of an issue, but long-term stability Dec 16 20:25:06 jow: https://github.com/openwrt/openwrt/pull/1640 refreshed, build- and runtime tested for the 4addr regression Dec 16 20:47:50 danitool: disagree Dec 16 20:48:02 Intel 3168 is complete garbo Dec 16 23:46:59 build #1085 of ixp4xx/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ixp4xx%2Fgeneric/builds/1085 Dec 17 01:11:52 build #1166 of mxs/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/mxs%2Fgeneric/builds/1166 Dec 17 01:51:54 build #685 of layerscape/armv8_64b is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/685 blamelist: Sebastian Kemper , Christian Lamparter , Hans Dedecker , Kevin Darbyshire-Bryant bryant.me.uk>, Stefan Lippers-Hollmann , Hauke Mehrtens Dec 17 02:19:41 build #237 of gemini/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/gemini%2Fgeneric/builds/237 **** ENDING LOGGING AT Mon Dec 17 03:00:00 2018