**** BEGIN LOGGING AT Fri Oct 11 03:00:00 2019 Oct 11 07:00:53 aparcar[m]: karlp: I think, that the documentation about that JSON config option is good enough, I don't see a reason to produce those files by default if you don't plan to consume them Oct 11 07:04:35 karlp: you're always welcome to be part of review process (as everyone else), that feature was lingering on GitHub since July https://github.com/openwrt/openwrt/pull/2192 Oct 11 07:07:27 and I'm looking forward to have something like this https://sudhanshu16.github.io/openwrt-firmware-selector/ officially as part of openwrt.org Oct 11 07:52:45 nbd: don't upgrade to Catalina, well unless you solve https://pastebin.com/Ra7qH4T8 :-) Oct 11 08:32:19 ldir: try make -C scripts/config clean Oct 11 08:35:41 nbd: Pretty sure I've tried that - the 'conf' that's failing is the one in build/target_foo/linux/scripts/kconfig/conf - not the conf openwrt uses for make menuconfig Oct 11 08:38:14 oh Oct 11 08:38:17 just done a make dirclean so waiting for the gcc initial build to finish before I try your incantation Oct 11 08:38:43 no need to try that Oct 11 08:38:46 dirclean cleans everything Oct 11 08:39:55 I've had occasion where dirclean didn't clean in scripts/config - so it's worth a try Oct 11 08:46:37 as I suspected, didn't help. Oct 11 09:39:33 ynezz: the "documentation" is a rewording of the config option name. It should say where the files go, what's in them, maybe a sample, or at the very list a link to the web docs that outline it. It's pointless saying, "CONFIG_JSON_BUILD_DATA" and then "stores build data in json" Oct 11 09:50:55 good, happy to merge your improvement :) Oct 11 09:54:18 not a chance. I don't _have_ that documentation. Oct 11 09:54:27 consider it late review feedback. Oct 11 09:56:27 as I said, it's fine with me, so I don't plan to improve it Oct 11 10:00:40 ldir: seems like this is in kernel? are you able to reproduce it out of the tree, directly in upstream kernel? Oct 11 10:00:53 maybe it was already fixed and we just need to backport that fix? Oct 11 10:06:21 ynezz: to be fair I do not understand the exact nature of this option either Oct 11 10:06:30 and I do not feel like reading python to figure out what it does Oct 11 10:06:42 for example it is still entirely unclear to me where these files end up Oct 11 10:06:56 are they put in a subdirectory? next to the firmware images? Oct 11 10:07:10 why not one large manifest file instead of many small ones? Oct 11 10:07:28 and the fact that it still does not work on an unmodified buildbot does not inspire confidence either Oct 11 10:07:40 it likely relies on implicit dependencies in buildroot or something+ Oct 11 10:17:35 ynezz: you mean build the kernel directly in macos ? Oct 11 10:17:46 ldir: yep Oct 11 10:18:56 I seem to enter dependency hell Oct 11 10:20:13 So I'm either going to go the VM route (urgh) or the container route. The former I understand, the latter I have no clue. Oct 11 10:20:54 or just wait till Felix 'upgrades' and figures it out. Oct 11 10:21:33 just run Linux ;) Oct 11 10:22:17 perhaps after next macOS version bump :p Oct 11 10:23:04 stintel: no. Oct 11 10:23:49 jow: help text - 97.3% of them could be improved I would say, python failures - well, software :) Oct 11 10:24:10 I'm interested about the outcome as well Oct 11 10:24:27 (about those python failures) Oct 11 10:27:59 jow: manifest files - this is really not my cup of the tea, but I think, that if we're going to merge just the stuff which is 100% correct and perfect, then the progress is going to be very slow Oct 11 10:28:12 there is enough time to rework this stuff till the next release Oct 11 10:28:26 or rather "enough time" :) Oct 11 10:28:44 other help being bad/missing is no excuse for current/new help being bad/missing. Oct 11 10:29:35 and from my experience, there is no discussion about anything unless the code hits the Git repository Oct 11 10:33:12 ynezz: do *you* know where those files end up and how they're organized? Oct 11 10:33:33 iirc I asked this in the PR already but I can't remember the reponse Oct 11 10:34:01 ynezz:ok, so, we're havinga d iscussion, late is always worse than ebfore, but just because it's late doesn't mean it doesn't matter does it? Oct 11 10:35:37 jow: I don't know, all I'm just saying is, that I find this feauture useful and I would probably merge it as it is as well Oct 11 10:36:17 jow: then you perhaps need to make that comment as blocking (starting the review) so it's not accidentaly merged until your remarks are cleared Oct 11 10:36:47 I'm not in anyway asking for it to be reverted, just that while it's still fresh and people _might_ know some details about it, can we improve the help? Oct 11 10:38:20 jow: it's quite easy to cheat on GitHub, marking review comments as resolved by just clicking on them, one has to start review in order to make them hard stop comments Oct 11 10:40:16 karlp: then it will get refactored, help text outdated, and we're here back again :) Oct 11 10:40:31 but in this case I believe, that aparcar[m] is hearing this feedback and will improve it Oct 11 10:41:08 I also wonder why each JSON file contains the target information Oct 11 10:41:19 this should be the same for all files within a directory Oct 11 10:41:31 same as version number and commit Oct 11 10:41:40 well, I would just reopen the PR and asked for improvements Oct 11 10:49:59 on the other actual topic, releases :) shouldn't we just build rc0/rc1 right after it's branched? Oct 11 10:52:28 and make version .1 after 30 days of rc0/rc1 or something like that Oct 11 10:52:51 ynezz: well the problem is that branching happened a few months too early, luci was in a really bad shape for example Oct 11 10:53:15 since most developers do not care about it and I am the only one doing it, its lagging far behind Oct 11 10:53:43 which would've menat that rc0 would've shipped with a completely different ui featureset compared to rc1 or final Oct 11 10:53:51 so it wouldnt've been an rc Oct 11 10:57:24 tough one :) Oct 11 10:58:15 Does not help that I care and can't develop (: Oct 11 10:59:07 So very much appreciate the jows hard work! Oct 11 10:59:55 ynezz: in principle I agree with whats been discussed previously though. Simply have an automatic schedule Oct 11 11:00:33 from my point of view I would simply do 19.07 even with broken UI (or provide images without luci at all this time) and make 19.09 (or 20.01) with luci again Oct 11 11:00:53 sounds like a recipe for the perfect chaos Oct 11 11:01:16 if you want recent untested shit without ui you can simply use the snasphots Oct 11 11:01:27 or start producing release images with and without luci Oct 11 11:02:04 if we go by that logic to simply omit everything we don Oct 11 11:02:05 chaos would make some people aware, that there are missing resources in some places Oct 11 11:02:20 't like to fix, we'll soon run out of features Oct 11 11:06:37 and without release we'll run out of users :) Oct 11 11:07:48 well in my world a delayed relese is better than a shitty one, or one whith wildly oscillating feature sets Oct 11 11:08:28 also releases for the sake of releases, without any maintenance plans afterwards are just glorified archive snapshots Oct 11 11:08:51 you can do that right now. Rsync the current snapshot repo and declare it the october 11 release 2019. Oct 11 11:10:45 I think, that we really need to solve that development tooling (GitLab Vs GitHub Vs Something) so it's clear in one place what needs to be done to get the release done so other interested developers could help make that happen Oct 11 11:10:57 anyhow back on topic - as I already wrote to the list, I think I'll need two to three months more Oct 11 11:11:31 sorry, two or three weeks Oct 11 11:11:40 if life isn't getting i nthe way Oct 11 11:12:47 thanks, lets see if someone is actually going to offer some help Oct 11 11:15:23 Hauke: jow: can't we just bump hostapd (and stuff around) in 19.07 to the master one? Oct 11 11:16:48 I can help backport/build/run test this stuff if you tell me all the components/packages which need to be bumped/backported Oct 11 11:17:25 which should help with 2) and 4) in your email Oct 11 11:17:40 iwinfo, hostapd, uhttpd, rpcd Oct 11 11:17:48 cgi-io in the feeds Oct 11 11:21:39 ok, will work on iwinfo/uhttpd/rpcd/cgi-io and wait with hostapd for Hauke Oct 11 11:32:09 some recursive dependency http://paste.ubuntu.com/p/x7YNgSSxSf/ Oct 11 11:33:55 jow: that cgi-io dependency is just planned as I don't have it enabled in config from https://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/ath79/generic/config.buildinfo Oct 11 11:43:43 its required by luci master Oct 11 12:36:29 eh, can someone entertain me why pkg version bump is necessary in such changes? https://github.com/openwrt/packages/commit/bbb1ea7345f367ed675dcfe40e36ac32ddf8a2e1#diff-0d09514b80d20dae320752b8f2bf3789 Oct 11 12:36:57 making backports PITA Oct 11 12:43:17 it changes the opkg files, because they contain it? Oct 11 12:59:17 so I need to upgrade just because of this cosmetic changes? Oct 11 13:38:31 ynezz: you've branched at the wrong point in time ;-) Oct 11 13:39:16 * ldir goes back to catching up with 2 months of invoicing Oct 11 13:44:23 ldir: my customers need to catch up with paying Oct 11 13:45:12 blogic: yeah well they don't even think about doing that if you don't invoice them in the first place Oct 11 14:03:15 jow: cgi-io backports PR prepared, iwinfo backports pushed, uhttpd and rpcd don't seems to have any pending backports Oct 11 14:04:08 ynezz: looks good Oct 11 14:04:12 i'd hit the green button Oct 11 14:04:15 !? Oct 11 14:07:34 thanks, will rebase the backport PR Oct 11 14:17:21 it builds, ship it! Oct 11 14:31:03 jow: Hauke: here are hostpad backports from master to 19.07 https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=shortlog;h=refs/heads/upstream/19.07/hostapd-backports just compiled tested now Oct 11 14:46:01 Can someone tell me why in /toolchain/kernel-headers/Makefile the KMAKE line has CFLAGS="$(TARGET_CFLAGS)" when the binaries that result in linux/scripts/kconfig/ end up running on the host system? Oct 11 14:46:43 not that changing it to $(HOST_CFLAGS actually solves the problem, but it raised the question :-) Oct 11 14:51:17 * ldir goes to walk the dog Oct 11 16:04:20 * ldir woofs Oct 11 17:32:33 ynezz: you forgot to update the mirror hash for libnl-tiny Oct 11 18:26:47 ynezz: the hostapd version in 19.07 should support WPA3 already, but I am fine with backporting it from master Oct 11 18:27:32 we should think about dropping the mesh DFS patches we have in hostapd, I think they cause memory leaks and I am not sure I forward ported them correctly Oct 11 18:27:51 hmm, I would make a patch and ask daniel golle for advice Oct 11 18:28:14 The security problems in hostapd from 19.07 should all be fixed Oct 11 18:28:22 but using 2.9 should make maintaiance easier Oct 11 18:29:15 jow: the WPA3 vurnabilies in hostapd should be fixed Oct 11 18:29:35 everything listed here is backported: https://w1.fi/security/ Oct 11 19:43:47 jow: ynezz I'll create a follow up PR, please don't revert it. Files are stored next to the image, starting with the same IMAGE_PREFIX as the images. Regarding target and version, I thought it is the cleanest to have a single file containing all the image related information instead of guessing from the path. But I can remove it for now. Oct 11 19:43:47 Problem is currently that the make prepare step removes all json files which I did not account when I tetsed the script locally, I'll fix that Oct 11 20:47:25 mangix: indeed, thanks! Oct 11 21:22:36 ynezz: thanks for the docker cleanup **** ENDING LOGGING AT Sat Oct 12 02:59:57 2019