**** BEGIN LOGGING AT Tue Aug 13 02:59:56 2019 Aug 13 06:53:08 aparcar[m]: commit message makes no sense to me, I don't understand whats the problem Aug 13 06:57:23 aparcar[m]: I mean, manifest file is common for a complete ath79 target, it's not being generated for every device Aug 13 07:51:40 nbd: thanks for looking at that old EAP patch Aug 13 08:02:28 ynezz: are you sure? Make info shows often different packages per profile, did that changed on ath79? Aug 13 08:07:43 I'm just not aware about such functionality Aug 13 08:07:56 that's why the commit message makes no sense to me, that's all about it Aug 13 08:08:19 I've just looked at manifests in http://downloads.openwrt.org/snapshots/targets/ Aug 13 08:11:53 ynezz: https://paste2.org/cxZjA6Ch Aug 13 08:13:06 ok, good, but my feedback is "fix the commit message" :) Aug 13 08:14:30 "while generating per device manifest files using following command 'foo meh' I'm currently getting this weird named manifest files...so this should be fixed with this patch" Aug 13 08:14:33 ynezz: 🙂 sure will do, could you point me in a direction what doesn't make sense to you? Aug 13 08:14:56 as you can see, I'm not able to reproduce/see the problem, so it works for me (tm) Aug 13 08:14:56 negative rtt, not bad, thanks Aug 13 08:25:07 ynezz: https://github.com/openwrt/openwrt/pull/2322 does this work for you? Aug 13 08:27:07 so this 'make image' is related to SDK? Aug 13 08:29:31 ynezz: no, did I write SDK anywhere Aug 13 08:29:31 ? Aug 13 08:34:35 aparcar[m]: you also didn't write ImageBuilder, but 'make image' only works in IB Aug 13 08:35:46 ok, SDK/IB are same things for me :p Aug 13 08:40:58 Um, okay I'll explictily write ImageBuilder sorry Aug 13 08:44:41 ynezz: they aren't :) Aug 13 08:45:00 I mean, external headaches :) Aug 13 08:45:50 they shouldn't be external ones though, because right now the SDK is our primary means of package production Aug 13 08:48:35 I mean, in order to verify if some changes doesn't break something in SDK/IB, one needs to build SDK/IB, unpack and verify which are not trivial steps in term of time Aug 13 08:49:12 right, but just because its hard does not mean that we can ignore it Aug 13 08:49:38 when buildroot things are touched, SDK and IB must be verified to function correctly afterwards Aug 13 08:50:40 which does not mean that I want to imply that they're getting ignored Aug 13 08:51:01 I know its tedious, but necessary unfortunately Aug 13 08:51:09 indeed, that's life Aug 13 08:55:33 ynezz: I'm working on various CI things, hopefully some sunny day this work falls of your shoulders Aug 13 08:55:47 aparcar[m]: PROFILE_SANITIZED is used in rootfs.tar.gz as well, does it mean, that there's same problem? Aug 13 08:56:07 I'll try it straight away Aug 13 08:56:10 aparcar[m]: nah, the reduced complexity will free resources to introduce new complexity Aug 13 08:56:17 speaking of testing, has anyone ever thought about packaging test suites ("make check" like) that could be used to verify on-target operation? Aug 13 08:56:36 in the end we'll debug both the buildroot, sdk, ibs and the ci setup containers :) Aug 13 08:57:08 jow: you mentioned to have build containerized, are there some further inforation? Aug 13 08:57:23 russell--: well, in many cases this requires self-hosting capabilities (on-target toolchains) which are not there atm Aug 13 08:58:01 russell--: and achieving that is a very long way. FOr libraries etc. one could start packaging shipped example application, but thats up to the individual maintainers Aug 13 08:58:13 jow: well, changes won't get merged unless there is green light from CI, which would be a big help already Aug 13 08:58:26 jow: btw I talked some time ago with lynxis about having repo.openwrt.org for package hosting and put that on a round robin mirror dns, would that make sense to you? Aug 13 08:58:36 aparcar[m]: yeah its done more or less. 18.06, 19.07 and master run off a dockerized build cluster atm Aug 13 08:58:57 aparcar[m]: I'm no fired of round robin dns Aug 13 08:59:05 *friend Aug 13 08:59:07 * russell-- was thinking about it for the "patch" changes, but honestly hadn't looked into what was needed on target Aug 13 09:00:35 round robin dns in conjunction with inconsistent repositories is a recipe for desaster Aug 13 09:01:09 it also only works if all mirrors are equally well connected Aug 13 09:01:23 jow: makes sense, is there another way? Aug 13 09:01:26 for exmaple it does not make sense to round robin balance an eu request ot a singapore mirror Aug 13 09:01:46 I've been evaluating mirrorbits Aug 13 09:02:08 but didn't have time for it so far Aug 13 09:03:09 lynxismentioned that media.ccc got a good cdn (for lage files), maybe to ask them for advise? Aug 13 09:05:22 ynezz: why didn't you want to add the 19.07 key here? https://github.com/openwrt/packages/pull/9659 Aug 13 09:05:23 apart from that, if you're okay I'd build and upload your 1.0.4 image Aug 13 09:06:32 it's simple, you're just bikdeshedding :) Aug 13 09:06:42 jow: so how is the build process? buildroot builds IB/SDK, both then create packages and images? Aug 13 09:07:09 ynezz: bikeshedding regarding the CI push? Aug 13 09:07:19 no, the keys, the time package etc. Aug 13 09:07:41 that PR is about something completely different Aug 13 09:08:32 fixing build breakage due to missing python3 and making the build error messages more human readable Aug 13 09:10:03 ynezz: okay sorry then, I'll build your container straig away, you can then adapt it in the image: thing Aug 13 09:10:12 ok, thanks! Aug 13 09:11:33 aparcar[m]: now that I understand the issue in your PR#2322 I think, that you're fixing it in a wrong place Aug 13 09:14:34 how would you do it? Aug 13 09:15:34 at the proper place, when that DEVICE_ is added to that PROFILE varibale, probably somewhere in the imagebuilder? Aug 13 09:18:29 looking at .config I see this line Aug 13 09:18:29 CONFIG_TARGET_ath79_generic_DEVICE_8dev_carambola2=y Aug 13 09:18:30 so maybe thats it? Aug 13 09:19:08 ynezz: https://hub.docker.com/r/openwrtorg/packages-cci/tags here you go Aug 13 09:25:26 aparcar[m]: the buildbots? phase1 uses full sources to build images (with multi-device and per-device-rootfs), non-shared packages and IB/SDK; phase2 uses SDK to build shared packages Aug 13 09:30:05 aparcar[m]: I've no clue about IB, but I doubt, that PROFILE gets filled from .config Aug 13 09:30:44 aparcar[m]: https://github.com/openwrt/packages/pull/9659/commits/d8dbe7e72758941d42fe83fa51d6140743059581 seems to work Aug 13 09:36:53 Do I have the honor to merge this bikeshedding free PR? Aug 13 09:42:12 ynezz: - Aug 13 09:43:51 well, you should be really careful, there is one NAK with +1 Aug 13 09:45:03 ynezz: you revertet it didn't you? Using 3 cores until an error occurs, fine for me Aug 13 09:45:10 I have another bike-shed remark Aug 13 09:45:12 which one are you talking about? Aug 13 09:45:23 PR#9659 Aug 13 09:45:28 instead of exit 1, you should propagate the original error code Aug 13 09:45:28 jow: no ynezz doesn't like biek shedding Aug 13 09:45:31 9659? Aug 13 09:45:42 karlp: yes Aug 13 09:46:07 something like make "package/$PKG/compile" -j3 V=s || { rc=$?; ...; exit $rc } Aug 13 09:46:10 jow: well, this is on topic, good point Aug 13 09:46:31 :) Aug 13 09:48:18 well, it could be considered bike shedding, if one considers, that the original exit code could be found just few hundred lines above in that make -j3 failure :p Aug 13 09:48:59 where does 3 come from? is that a circleci thing? Aug 13 09:49:48 yep Aug 13 09:49:58 it's already hardcoded in that file Aug 13 09:50:30 I see where are you heading (was wondering about it myself as well), but please stop :) Aug 13 09:54:07 jow: should be fixed Aug 13 09:54:17 https://github.com/openwrt/packages/pull/9659/commits/b14adeb3a9eaf866cc2786c5d7c876157ced6c6b Aug 13 10:00:40 ynezz: I'm off to sleep, midnight here, I'm sure you have packages commit access as well right? Aug 13 10:01:53 Circleci gives you two cores on a free plan, as it's a container nproc would show 32 or something similar Aug 13 10:03:50 ok, makes sense, good night! Aug 13 10:13:14 that matrix is really weird :) Aug 13 10:26:08 speaking of incomprehensible errors, what's actually gone wrong here? https://circleci.com/gh/openwrt/packages/4622?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-checks-link Aug 13 10:28:04 karlp: you miss some of the prerequisites from host make V=s ought to tell way more Aug 13 10:28:37 so that's a bug in the ci setup of the packages prs? Aug 13 10:28:47 (to not be in V=s already?) Aug 13 10:29:34 karlp: hmm... I didn't even realise you were on some kind of "enviroment" there... just looked commands =) Aug 13 10:49:03 karlp: I see a > /dev/null in the commands, so whatever error/complaint there was was probably output to stdout Aug 13 12:58:04 karlp: tried to fix it, but can't get it to print anything to stderr :| Aug 13 13:08:04 can't it be related to 200f2666fb1c8d9d128824dc5586e0e66386971f ? Aug 13 13:11:31 I bet it is :) Missing python3 Aug 13 13:12:45 dunno, I tried fixing printing collected error messages to stderr instead of stdout Aug 13 13:15:08 CI Docker images don't have Python3 support yet, that's why the prereq-build step is failing Aug 13 13:16:00 I wonder why this step needs to be silenced Aug 13 13:19:06 if it's producing too much output, maybe adding additional `make prereq` would fix it Aug 13 13:32:36 karlp: https://github.com/openwrt/packages/pull/9659/commits/ce87522c780ee178e83a8685105780466b56cbf5 Aug 13 13:35:34 now it's `Error opening terminal: unknown.` https://circleci.com/gh/openwrt/packages/4628 Aug 13 13:39:48 that's .... still gotta be outside scope of the package itself yet right? (I'm not entirely convinced of the changes to how that package builds, which is why I was looking at it) Aug 13 13:41:39 yes, it's CI problem Aug 13 13:45:36 is that something in the prereq checking for a terminal? Aug 13 13:47:20 it's due to menuconfig Aug 13 13:47:34 prereq depends on .config Aug 13 13:48:58 wasnt' there a make defconfig first? Aug 13 13:49:34 yes Aug 13 13:49:41 but it depends on prereq Aug 13 14:14:33 here is the problem visible https://circleci.com/gh/openwrt/packages/4636 Aug 13 14:50:54 ynezz: I'm going to revert the source-only flag on ath79 now in 18.06. Any objections? Aug 13 14:51:02 ynezz: running into a python2/3 issue in wireless-regdb on 19.07: https://bpaste.net/show/aEhU Aug 13 14:51:11 People appear to want it now instead of waiting for the next release Aug 13 14:51:23 my guess is that you fixed in a few days ago on master in b6bae4a2c9f11f7e55319c2b4c709396ce649688 Aug 13 14:51:31 but then it needs a backport :) Aug 13 14:51:50 ynezz: sorry s/18.06/17.09/ Aug 13 14:52:04 *19.07 ... sigh Aug 13 14:53:14 :) Aug 13 14:53:37 sure, it's fine with me Aug 13 14:58:43 ynezz: jow: btw, what do you think of https://pastebin.com/EGEmcM0C (semi-related, as one could use it to e.g. keep some devices of ath79 unbuild by default) Aug 13 15:00:06 KanjiMonster: I'm perlblind, sorry :) Aug 13 15:01:50 KanjiMonster: I like it Aug 13 15:01:58 please push it Aug 13 15:02:18 whats the situation in ar71xx vs. ath79 - are devices ported to ath79 dropped in ar71xx? Aug 13 15:02:31 no Aug 13 15:03:19 meh Aug 13 15:03:32 it would be fine to find someone willing to actually support ath79 in 19.07 Aug 13 15:04:14 I mean, providing images is just the easy part, providing support is different Aug 13 15:04:19 so what do we prefer? Disable ar71xx ones which are available in ath79 or disable ath79 ones present in ar71xx? (keep only new ath79 stuff) Aug 13 15:04:31 Should they? AFAIK unless things start to woe extraordinaly hard and next 10 years, then mine suggestion is that jsut leave the ar71xx as is and continue developing the ath79, so when it is deemed good enough, drop ar71xx completely(?) Aug 13 15:05:01 Again, as you know, I'm no core developer, but sne workflow is allways fun thing =) Aug 13 15:05:09 sane* Aug 13 15:05:49 ..there is strong and weak points in every method, in diffirnet areas Aug 13 15:08:58 ath79/19.07 is stuck on 4.14, ath79/master is 4.19, it might soon move more closely to the upstream ag71xx driver, so the differencies between master and 19.07 wouldn't be negligible Aug 13 15:09:37 so it's going to be really another PITA for support (reproducing bugs, backporting fixes etc.) Aug 13 15:11:58 Well, if ar71xx is planned to be dropped "yesterday" then do we really need to have "clean" but laborous method to drop device support one by one? or just forget whole branch when ath79 is deemed mature anough Aug 13 15:12:39 that was the plan Aug 13 15:13:24 have only ath79 in 20.y Aug 13 15:15:18 sorry, dirty environment I guess Aug 13 15:16:49 Ofcourse, you as openwrt devs do just as you like to, that's only fair and only sane deal, but suggestions from side is always cool ;) Aug 13 15:16:59 says the suggestor ;D Aug 13 15:17:03 jow: I think, that you're just going to receive another kind of complains, like that device X was more stable with ar71xx then with ath79, so what are you doing? :p Aug 13 15:17:23 well A complain you will get no matter what you do Aug 13 15:17:32 can't please everyone Aug 13 15:18:42 sure, but the thing is, that nobody has stepped up and said, ok, I'll try to do my best and I'll actually support ath79 in 19.07 Aug 13 15:19:24 I think, that ar71xx has a good support from xback & co Aug 13 15:20:50 ynezz: speaking of stability of ath79...... if you want to have ath79 in 19.07, then cab you backport the missing watchdog into ar9330.dtsi? :) Aug 13 15:21:21 (iff we're going there) Aug 13 15:22:18 karlp: maybe you should reread the backlog :) Aug 13 15:22:34 or I should fix my english Aug 13 15:23:01 anyway, there was some discussion in the past, and someone has suggested to provide the images for ath79 in 19.07, but mark them as beta Aug 13 15:23:48 either in Release notes or by naming the download folder as ath79-beta Aug 13 15:23:56 well, known missing watchdog is somethign I'd consider worth adding, not just "haha it's only beta" Aug 13 15:25:24 I've marked ath79 as source only in 19.07, I've stopped caring about that target afterwards Aug 13 15:26:11 karlp: can you prepare a backport patch? Aug 13 15:26:24 ynezz: no problem, I'll track it then. Aug 13 15:26:52 jow: sure, just going try it cherry picked as is, make sure the ar7130-wdt it references is in the 4.14 kernel Aug 13 15:28:07 (seems to be in all the dtsi though so preliminary beliefe is shoudl be fine) Aug 13 15:28:18 ynezz: are you doing ramips? Aug 13 15:28:47 what do you mean exactly? Aug 13 15:28:59 ynezz:sorry, seems you already merged it to 1907 anyway :) thank you! Aug 13 15:29:05 a question in #openwrt came up whether it is preferred to cover all oem flash partitions in dts or whether to just cover the ones needed by openwrt and mark the rest as "reserved" or something Aug 13 15:29:18 not sure what the current preferred approach is Aug 13 15:30:00 from my point of view it should be all, read-only Aug 13 15:31:23 current dts looks so as well - thanks! Aug 13 15:34:05 KanjiMonster: DonkeyHotei: m4t: Re the broken sysupgrade on ath79 for devices with RedBoot bootloader. Can You look at this report https://bugs.openwrt.org/index.php?do=details&task_id=2428, unfortunately fixing this is outside of my skill set. Aug 13 16:51:56 hexa-: how did you fix your regdb issue? Aug 13 16:53:48 ugh. it seems the musl update broke way too many packages Aug 13 17:02:41 mangix: no problem, just update all the packages too ;) Aug 13 17:05:57 specifically looking at this: https://downloads.openwrt.org/snapshots/faillogs/mips64_octeonplus/packages/ Aug 13 17:06:06 glib2 breakage broke everything Aug 13 17:07:33 ynezz: are you okay with your acked-by on the source-only revert? Aug 13 17:07:49 ynezz: I do not want to make it appear as if I'm somehow overruling others Aug 13 17:08:34 huh, local compile succeeded Aug 13 17:08:43 i think i need to rebuild my toolchain Aug 13 17:09:25 mangix: undefined ref to major/minor, looks a bit as if it was built without -D_BSD_SOURCE Aug 13 17:09:46 not quite. it's because of a missing header Aug 13 17:10:15 sys/types.h include missing? Aug 13 17:10:22 https://github.com/openwrt/openwrt/commit/79596f782e2c8daa1ebb8e480b6373c8142714c6 Aug 13 17:10:35 major/minor is not included in sys/types anymore Aug 13 17:10:57 hm, unfortunate Aug 13 17:11:36 man 3 major instructs developers to use #define _BSD_SOURCE + sys/types.h, so the majority of GNU programs will probably exactly do that Aug 13 17:12:33 hmmm? My man page does not say this Aug 13 17:13:01 It says this under notes: The BSDs expose the definitions for these macros via . glibc also exposes definitions for these macros from that header file if suit‐ able feature test macros are defined, but this is deprecated since glibc 2.25 and will be removed in the future. Aug 13 17:13:08 ah indeed, I was checking linux.die.net, the local man page refers to sysmacros.h as well Aug 13 17:14:21 already at gcc/final. these new ryzen parts are really fast at compiling openwrt I must say. Aug 13 17:15:03 bloody bank did something wrong when I requested to increase my payment limits on my card, so I'm unable to order my Ryzen build :( Aug 13 17:17:46 stintel: have you seen the gcc benchmark with the new ryzen parts? Aug 13 17:19:12 mangix: I have not. seriously considering getting a 3900x Aug 13 17:19:36 but then again, if I need to wait because fixing this card issue will take several days, if they do it correctly this time Aug 13 17:19:40 might as well wait for the 3950x Aug 13 17:19:58 and hopefully some more compatible ECC RAM, preferably 4x32GB Aug 13 17:21:31 stintel: https://www.gamersnexus.net/images/media/2019/CPUs/r5-3600/games/gcc-compile.png Aug 13 17:23:41 geez Aug 13 17:24:46 apparently, it's all because of high amounts of L3 cache Aug 13 17:25:53 3900X clocks in at 7.1 Aug 13 17:34:21 karlp: delete everything, fresh checkout Aug 13 17:35:39 great.... Aug 13 17:36:09 had you switched from master to 1907? that's what I did... Aug 13 17:38:55 huh. I can't replicate that build failure locally Aug 13 17:39:17 looking at the code, it looks correct Aug 13 17:51:37 the wireless regdb? the error is very much what you get running py3 on py2 code. Aug 13 17:57:38 huh. the mips64 buildbot seems totally broken Aug 13 17:58:04 minor/major are not found in there Aug 13 18:09:19 hmm. is eth0 still not working on ath79 for SoC: Atheros AR7240 rev 2? this was a problem back in march. Aug 13 18:16:42 ynezz: what is this for? https://github.com/openwrt/packages/pull/9659/files#diff-1d37e48f9ceff6d8030570cd36286a61R97 Aug 13 18:20:32 I wish I didnt experience the race condition but alas I do :/ Aug 13 18:20:56 anything over 20 threads seems to encounter it, even with logging enabled Aug 13 18:24:37 mangix: did you use the downloadable SDK to replicate it? Because that is what the buildbots do Aug 13 19:19:21 jow: no Aug 13 19:20:18 i looked at the code of several of the failing packages. they include both sys/type and sys/sysmacros Aug 13 20:15:41 jow: pushed Aug 13 20:31:23 jow: do you know who manages the server openwrt got from prpl? Aug 13 20:58:53 aparcar[m]: we got servers from prpl? Aug 13 20:59:06 at least funding afaik Aug 13 20:59:16 jow: ack, revert that source-only please Aug 13 21:01:15 > [17:29] a question in #openwrt came up whether it is preferred to cover all oem flash partitions in dts or whether to just cover the ones needed by openwrt and mark the rest as "reserved" or something Aug 13 21:01:17 jow: DTS should describe device in general, not just for OpenWrt needs, so more accurate paritions = better Aug 13 21:01:31 jow: in theory we should be able to use the same DTS files for bootloaders Aug 13 21:01:45 jow: and bootloaders may need access more partitions than OpenWrt Aug 13 21:02:26 vendors should also use DTS files (ideally, I know...) so that's another argument for putting all partitions in .dts Aug 13 21:04:15 aparcar[m]: as far as I am informed, the process is still ongoing and apparently the money transfer process is complicated Aug 13 21:04:42 jow: thanks for the update Aug 13 21:04:45 that is step 1, step 2 would be actually renting machines and working out contract details Aug 13 21:04:57 right now there is neither money nor machines Aug 13 21:05:11 and I do not expect this to change within the next 4-8 weeks Aug 13 21:05:30 blogic may chime in if this is not correct Aug 13 21:06:32 can't we tell purple what we like to have and they just buy it giving us ssh access? Aug 13 21:07:29 that would not be optimal as it would force us to rebuild the entire infrastructure when funding runs out Aug 13 21:07:46 instead of merely securing follow up financing Aug 13 21:07:56 *funding Aug 13 21:08:25 but thats just my personal opinion, you need to ask blogic about the details Aug 13 21:09:05 is the current build apprach discribed somehwere? Aug 13 21:09:19 https://git.openwrt.org/?p=buildbot.git;a=summary Aug 13 21:09:38 the docker subdirectory contains a complete setup Aug 13 21:10:41 will have a look thanks Aug 13 21:12:13 the current x86/64 imagebuilder prints an error when running make info, ideas? https://paste2.org/YXICaBXt Aug 13 21:13:08 probably some shell expression failing Aug 13 21:14:54 [ "$($(p)_SUPPORTED_DEVICES)" ] && echo ' SupportedDevices: $($(p)_SUPPORTED_DEVICES)'; Aug 13 21:15:03 this will fail when $($(p)_SUPPORTED_DEVICES) is empty Aug 13 21:15:20 expr && cmd will cause a non-zero exit when expr is not true Aug 13 21:15:26 which in turn will cause make to abort Aug 13 21:15:42 you always need to use the forstm expr && cmd || true Aug 13 21:15:50 *form Aug 13 21:16:01 or ! expr || cmd Aug 13 21:18:20 https://pastebin.com/FiUVLTx4 Aug 13 21:18:24 this will likely fix it Aug 13 21:21:37 sure it does Aug 13 21:21:48 should I create or will you? Aug 13 21:44:10 jow: anyway here it is https://github.com/openwrt/openwrt/pull/2323 Aug 13 23:40:27 started a new testing run with erx and bullet-m5 evaluating the prevalence of https://bugs.openwrt.org/index.php?do=details&task_id=296 Aug 14 02:29:11 russell--: That might be yet another hardware bug on ar7240. Aug 14 02:30:50 russell--: BTW this commit has no effect at all. speed is only used when there's no phy mask defined: https://git.openwrt.org/f8f6fa11c0410b3486494443739220244d2e9962 **** ENDING LOGGING AT Wed Aug 14 02:59:56 2019