**** BEGIN LOGGING AT Mon Sep 24 02:59:59 2018 Sep 24 03:54:27 mangix: what guide? Sep 24 04:49:56 Hauke: ping Sep 24 04:50:04 Hauke: lets try to update mac80211 today/tomorrow Sep 24 05:12:04 yay Sep 24 07:07:06 Hauke: i jsut did a minor cleanup of the patches Sep 24 07:07:14 and folded a few Sep 24 07:07:28 and i need to check if the tx99 and unload patch are already included Sep 24 07:07:39 and then i'll push i think, thanks for the help Sep 24 07:53:36 hmm, found another buildroot quirk / design flaw / unexpected behaviour Sep 24 07:54:14 currently, we have distinct stamp files for the "configured" and "built" goals Sep 24 07:55:33 sometimes, ./configure produces bad results while still suceeding, for example the glib configure will produce a source tree that does not compile when "glib-genmarshall" is missing in the configure phase but still finish sucessfully Sep 24 07:56:02 which means that "make package/glib1/compile" will eventually fail in the build phase Sep 24 07:56:40 fixing the missing tool and running "make package/glib1/compile" will not fix the problem as the bad configure results are still cached Sep 24 07:56:55 only a manual clean helps Sep 24 07:58:21 imho we should not keep the .configured stamp when .built was not reached, at least with CONFIG_BUILDBOT=y Sep 24 08:05:54 jow: that sounds like an issue with glib's configure though, it shouldn't return success when glib-genmarshall is missing - or it should be able to compile without it Sep 24 08:08:55 I agree, yet I am not sure if its desirable to keep the configure results if the build failed [at least in a buildbot env] Sep 24 08:09:28 I do understand the negative implications for development, there you typically want to keep configure artifacts, especially when debugging or porting Sep 24 08:15:06 considering to add something like that as pre-build cleanup: https://pastebin.com/0sbnwSFn Sep 24 08:22:39 jow: looks reasonable Sep 24 08:32:49 looks legit Sep 24 08:36:39 jow: removing .configured if .built fails would be fine for me for buildbot, however i think it would be better to have .configured fail if it didn't produce proper results Sep 24 08:38:50 morning Sep 24 08:53:32 nbd: I agree, but thyt would require upstream build systems to be sane, which they often aren't Sep 24 08:55:28 nbd: since you're here - you recently added a toolchain rebuild check that relies on Git metadata to be present, if someone builds from a Github source tarball with CONFIG_BUILDBOT=y this fails Sep 24 08:55:33 well, if it's something as simple as missing glib-genmarshall, we can just add a [ -f "$(PKG_BUILD_DIR)/glib-genmarshall" ] line to Build/Configure Sep 24 08:55:47 nbd: would it be able to gracefully fallback to $topdir/version Sep 24 08:57:32 i think we should just drop those checks when not using .git Sep 24 08:57:55 fine with me Sep 24 08:57:57 if someone builds from a source tarball, it is reasonable to expect that there will be no updates Sep 24 08:58:01 so no rebuild check is necessary Sep 24 09:00:12 jow: https://pastebin.com/Ny4F6RHC Sep 24 09:00:51 yep, that looks sane Sep 24 09:00:56 please cherry-pick to 18.06 too Sep 24 09:03:22 will do Sep 24 09:08:52 done Sep 24 09:11:11 thanks! Sep 24 09:32:12 blogic: could you push updated mac80211 to your staging tree? Sep 24 09:32:16 i'd be happy to test it Sep 24 09:44:35 rmilecki: i am planning to push to master in 15 Sep 24 09:44:48 it all looks good and i had folks test it already Sep 24 09:44:56 waiting on a few test build to finish Sep 24 09:45:07 blogic: so... i'm not allowed to test it first? ;) Sep 24 09:45:25 blogic: i can start testing now if you just push it Sep 24 09:45:33 of course you are, its uploading right now Sep 24 09:45:40 done Sep 24 09:46:02 thanks, checking out Sep 24 09:46:02 https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/mac80211 Sep 24 09:46:55 nbd: btw, did you see the PR about the lacking nftables inet protocol support? Sep 24 09:47:16 nbd: somehow your partial backports of the flowoffloading api broke support for unning nftables with out patches 4.14 Sep 24 09:47:35 *running nftables with our patched 4.14 kernel Sep 24 09:48:07 yes, i've seen it, and i will review the changes in the next few days Sep 24 09:48:11 just didn't get around to it yet Sep 24 09:48:59 okay, great Sep 24 09:49:32 I hope to be able to start working on firewall4 either end of this year of jan/feb next year Sep 24 09:56:26 can someone remind me what was the workaround for that? Sep 24 09:56:30 * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-leds-gpio: Sep 24 09:56:31 * kernel (= 4.14.71-1-7de54d29a26a8b69daf83c0897a321f8) * Sep 24 09:56:37 -force-depends Sep 24 09:56:44 it's during make V=s Sep 24 09:56:58 i switched from master branch to blogic's mac80211 branch Sep 24 09:57:07 I think it required some make .../clean Sep 24 09:57:12 or rm -R something Sep 24 09:57:13 try make package/linux/clean Sep 24 10:03:34 jow: worked! thanks Sep 24 10:05:32 rmilecki: i'm off to the pool for a swim Sep 24 10:05:37 when i return i'll push to master Sep 24 10:05:49 so let me know if you run into problems Sep 24 10:05:50 blogic: sounds good, I'll post my results meanwhile Sep 24 10:05:52 have time! Sep 24 10:05:56 have fun I meant! ;) Sep 24 10:06:18 lets hope the pool is not tooo full Sep 24 10:44:18 blogic: tested on SR400ac (2 x BCM43602) works good Sep 24 10:44:22 blogic: go ahead! Sep 24 10:44:27 blogic: Hauke: thanks for your work on that Sep 24 13:18:53 openwrt/feeds/packages/lang/perl/perlmod.mk:4: ../perl/perlver.mk: No such file or directory Sep 24 13:18:56 Build-Depends: swig/host !BUILD_NLS:libiconv !BUILD_NLS:gettext Sep 24 13:19:17 newest 1806 build give me this Sep 24 13:19:59 which causes "ERROR: please fix feeds/telephony/net/freeswitch/Makefile - see logs/feeds/telephony/net/freeswitch/dump.txt for details" Sep 24 13:32:23 well WARNING: Makefile 'package/feeds/packages/keepalived/Makefile' has a dependency on 'kmod-nf-ipvs', which does not exist has been annoying me for a couple of days Sep 24 13:45:05 lidr:it seems https://github.com/openwrt/packages/pull/7008 has been accepted in feeds/packages before https://github.com/openwrt/openwrt/pull/1375 has been accepted Sep 24 13:46:45 ldir:although it was reported the PR was dependant on https://github.com/openwrt/openwrt/pull/1375 Sep 24 13:49:20 hmmm, I await my education at the conference before I merge PRs like that Sep 24 13:49:36 there is quite a backlog of openwrt PR's, many of which have zero comments Sep 24 13:50:02 so, it should be no surprise Sep 24 14:14:53 That suggests more maintainers are required. Sep 24 14:15:27 or that PRs to openwrt are eithe rblocked, or become equal to other patch sources. Sep 24 14:16:00 at the moment they're the "ok, but only occasionally when they're looked at" despite being labelled as an acceptable way of submitting patches Sep 24 14:21:47 Don't know what to suggest to that. Making it easier to submit changes is inevitably going to generate more of them, then there's the quality aspect. Sep 24 14:23:41 but there's stuff loitering in patchwork too. I have one patch assigned to me, with a couple of related commits, that I'm hoping to discuss at the conference. Sep 24 14:24:00 it's a lack of skill/experience on my part. Sep 24 14:24:29 I've just looked at https://github.com/openwrt/openwrt/pull/1391 and I can't see why this shouldn't be merged. Sep 24 14:24:43 no reason not to discuss the patch(es) here Sep 24 14:26:15 why? because the commit msg is not valid Sep 24 14:27:37 also, there is question as to whether this change is desirable at all Sep 24 14:27:44 ha good point - see I'm so out of practice in reviewing I didn't even notice that, but I certainly like the idea of the patch, and I think the implementation is ok. Sep 24 14:28:45 the files the patch uses to "hide" from uci are as plaintext as uci is Sep 24 14:29:09 and with the side effect of hiding from sysupgrade Sep 24 14:30:16 it's optional to use the files, and we AFAIK don't store ssh keys in /etc/config Sep 24 14:31:16 i just don't see a use case atm where this patch makes things better overall instead of worse Sep 24 14:32:54 but if it were up to me, i still wouldn't NAK the patch outright just because i lack the imagination to see that myself Sep 24 14:51:45 security through copying what you've done before, not security because it's secure.... Sep 24 14:54:01 both are equally insecure in this case Sep 24 14:54:49 unfortunately that doesn't help me come to a decision. Sep 24 14:59:37 (I'm on the side of this change does nothing at all, just changes the name ofr the file with the secret it in it from /etc/config/blah to /somewhereselse) Sep 24 14:59:51 and adding init script support for that seems unnecessary Sep 24 15:05:25 I've committed another PR instead Sep 24 15:07:41 i have a couple of PR's with zero comments myself Sep 24 15:11:26 Can you not put your own comments on them? ;-) Sep 24 15:11:45 the commit msgs kinda are that already Sep 24 15:15:38 you mean https://github.com/openwrt/openwrt/pull/1379 Sep 24 15:17:27 and 1359, yes Sep 24 15:18:28 I am definitely not qualified to review/commit those! Sep 24 15:18:51 an open question in both cases, though, is why wifi signal strength in both cases (ath9k and ath10k) is much stronger with the stock firmware than with openwrt Sep 24 15:32:48 DonkeyHotei: if you are capable and interested in porting tplink archer C7 v4 to ath79 I'm happy to test and comment on your pr :-) Sep 24 15:33:09 Zero_Chaos: i have a v2. i do not have a v4. Sep 24 15:33:30 mkresin, ping Sep 24 15:34:09 DonkeyHotei: I have both, so if my testing can help something, I'm offering Sep 24 15:34:31 Zero_Chaos, you concur that wifi is far superior on the v4? Sep 24 15:35:08 ntd: I honestly haven't gotta a v4 working yet. I was busy reviving my known working v2's that had corrupted flash. I can check that out though Sep 24 15:35:29 way, *way* superior in my experience Sep 24 15:35:46 Zero_Chaos: https://forum.openwrt.org/t/is-anybody-working-on-linux-4-14-for-ar71xx-platform-porting-guide-to-ath79/13013 Sep 24 15:35:59 too bad the switch LED configs is whack, that's what i'm trying to pester mkresin about Sep 24 15:36:22 ntd: in what way? my use case is ~300 people attacking the ap and the v2 seems to work and be happy about it. will the v4 help them do it more reliably? further away? what? Sep 24 15:37:35 firstly, the v2s 2.4ghz antennae are internal and the ac hw is dradft Sep 24 15:38:07 v4=external antennae are dual band, not draft hw Sep 24 15:38:14 also wave2 Sep 24 15:38:35 archer c7 is not wave2 afaik Sep 24 15:38:43 v4? Sep 24 15:38:47 any Sep 24 15:39:26 ok, haven't seen anything to explicitly say it is, but the radio model are used in wave2 products? Sep 24 15:39:44 pretty sure it's still 9880 Sep 24 15:40:14 QCA9563 Sep 24 15:40:23 that's the soc Sep 24 15:40:26 wait Sep 24 15:40:31 QCA9880-BR4A Sep 24 15:40:33 right Sep 24 15:40:50 that's the same chip as in the v2 Sep 24 15:43:21 that's according to wikidevi Sep 24 15:43:42 the model number Sep 24 15:46:42 hmm, got access to one, how to query actual wifi hw? Sep 24 15:47:03 logread and dmesg buffer have overflown Sep 24 15:52:54 ? Sep 24 15:53:17 you can maybe poke around in /sys/bus/pci? Sep 24 15:53:36 what flooded out dmesg? Sep 24 15:54:00 probably the uptime alone Sep 24 15:54:10 mhm Sep 24 15:54:23 just reboot it then :) Sep 24 15:55:54 apparently ven_0x168c dev_0x003c Sep 24 15:56:05 which suggests the same radio as v2 Sep 24 15:57:00 so apparently i was mistaken about the radio being updated. still way better performance and stability over the v2 Sep 24 15:57:46 better antennae, what? too bad they're going with non-detachable ones with the v5... Sep 24 16:00:29 DonkeyHotei, if memory serves and if i remember what jow said correctly, drivers/firmware for the v4 wifi hw was not available for 17.01 kernel version Sep 24 16:00:42 suggesting there must be some difference Sep 24 16:01:11 hence v4 support not being available until 18.06 Sep 24 16:10:09 DonkeyHotei: that was a lot of reading (that forum thread you gave me) but I think I understand it a bit better now. thanks Sep 24 16:10:40 DonkeyHotei: still not sure I want to be doing it, but I might be able to now Sep 24 16:27:00 ausjke: run feeds update two or three times Sep 24 16:27:12 ausjke: there's a kind of circular dep between freeswitch and a newer perl Sep 24 16:27:46 ausjke: that perlver error should go away after updating the packages and the telphony feed twice Sep 24 16:29:37 ldir: PR#1375 can be merged if it builds Sep 24 16:30:08 I had this lurking in my staging tree for years because I wanted to runtime test it, but I don't care enough to setup a runtime test Sep 24 16:30:46 so if it merges cleanly and is not breaking something, let's just merge it Sep 24 16:50:24 jow: indeed second feeds update it went away, thanks Sep 24 17:04:36 the 2030 is a Senao PCE3300AH 3x3:3 the 3040 appears to be a Senao IAP8350AG 4x4:4 Sep 24 17:06:07 wigyori: if you have a minute, can you check if https://github.com/openwrt/openwrt/pull/830/files is still relevant? Sep 24 17:13:46 hi, do you know in which kernel file does "reboot" occur? Sep 24 17:20:00 ok, in my case it seems arch/arm/kernel/reboot.c Sep 24 17:29:23 blogic: ping Sep 24 17:31:41 hmm, should we define an INSTALL_SBIN which installs suid binaries? Looking at https://github.com/openwrt/openwrt/pull/854/files Sep 24 17:31:56 or INSTALL_SUID Sep 24 17:45:09 jow: yep, will check Sep 24 19:20:48 blogic: Why do you have the rt2x00 changes in your mac80211 tree? Sep 24 20:41:17 if i have a target, which require checking out a git tree (like a package) and configuring/compiling it, including the built kernel image, what's the preferred way to do that? at91 had something called dfboot which did just that, but reworking that slightly for my target doesn't work - calling a "make -C bbl compile" from Image/Build doesn't build it Sep 24 20:48:03 nbd: thanks for upstreaming some of the ath9k patches Sep 24 20:48:32 jow: seems to build, so I pushed it. Sep 24 21:47:28 jow: pomg Sep 24 21:47:56 Hauke: are they notsane ? Sep 24 21:59:53 blogic: ?? Sep 24 22:02:50 Hauke: I pushed them was that no good ? Sep 24 22:03:08 i had them runinng on a test device for a couple of days .... Sep 24 22:03:39 blogic: I would suggest to remove the new rt2x00 patches and squash the other mac80211 patches together, the other rt2x00 patches can be added later Sep 24 22:03:55 Hauke: why ? Sep 24 22:04:03 dangole told me they are a-ok Sep 24 22:04:37 ok if dangole told you then I am fine **** ENDING LOGGING AT Tue Sep 25 02:59:59 2018