**** BEGIN LOGGING AT Tue Feb 12 02:59:59 2019 Feb 12 03:45:05 gch981213: ah i see. it's not that simple then. a quick grep of ath79 shows 10, 25, and 104 MHz **** BEGIN LOGGING AT Tue Feb 12 04:22:33 2019 **** BEGIN LOGGING AT Tue Feb 12 05:13:21 2019 **** BEGIN LOGGING AT Tue Feb 12 06:36:21 2019 Feb 12 09:04:37 jow: ping Feb 12 09:04:59 jow: unping Feb 12 09:07:31 * ldir solves his identity crisis Feb 12 09:07:40 jow: ping Feb 12 09:21:46 ynezz: it's a Ubiquiti Rocket M5 --> https://www.ui.com/airmax/rocketm/ Feb 12 09:21:54 ldir: pong Feb 12 09:24:10 xback: hi. Does your mega kernel bump box also do full builds 'buildbot' style? I'm pondering merging pr/1626 & 1627 that are otherwise hanging around for ages, being kept up to date but not going anywhere. Feb 12 09:26:49 xback: I've a branch in my staging tree (forkoen) that's basically master & those pr's merged. Failing that I just merge it, and be damned :-) Feb 12 09:28:52 ldir: I only do full builds these days (all kmods) for targets which I'm able to also test. Feb 12 09:29:09 if you can provide me the exact targets you want to test. I'm happy to do full builds on all of them Feb 12 09:29:09 ldir: /me is vaguely aware of the iproute2 PR you pointed me at, hasn't read it closely, doesn't have strong feelings about it beyond keeping things as-small-as-practical is good Feb 12 09:32:05 xback: well anything you currently build for would be great - I don't have a specific target/s in mind, just a little bit more compile testing before merge to try and avoid buildbot induced surprises. Feb 12 09:32:52 russell--: excellent thank you - I think the 'small as practical' intent is maintained. Feb 12 09:34:25 ldir: ok. i'll use the branch and will compile for a whole series of targets Feb 12 09:35:16 xback: that's fantastic - thank you - my mini macbook just doesn't have the compute power Feb 12 09:44:00 hiho, can someone maybe explain to me what the deal with /lib/upgrade/keep.d is and why some packages .upgrade files there? I seem to get automatic files there for my packages, without doing anything, yet one package has not all conffiles section defined files in it there? Feb 12 09:50:10 example? Feb 12 09:50:42 istr something about not being able to list an empty directory that might get things later, but I can't remember now. Feb 12 09:56:05 ldir: currently compiling for: cns3xxx, imx6, ar71xx, x86_64, layerscape, sunxi, mvebu, bcm2708 Feb 12 09:56:09 eta: 30 minutes or so Feb 12 09:58:05 xback: fantastic - thank you Feb 12 10:47:45 ldir: all builds mentioned above passed compilation testing (all kmods) Feb 12 11:44:13 xback: thank you - sorry for delay - work Feb 12 11:58:51 * ldir cues the explosion Feb 12 13:13:49 looks ok - phew Feb 12 13:27:12 stintel: could you test brcm2708 & brcmfmac after the last updates? Feb 12 13:27:32 no rush, just if you happen to find time for that Feb 12 13:28:08 rmilecki: firing up the building engines ;) Feb 12 13:29:04 :) Feb 12 13:53:26 rmilecki: looks good Feb 12 14:09:25 xback: that's the XM or XW platform? Feb 12 14:15:01 xback: probably XM as the XW has rgmii Feb 12 14:20:57 XM Feb 12 14:21:05 ynezz: i just added some prints and checked Feb 12 14:22:07 ynezz: The "1000" is fetched here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_phy.c;h=12fa2e301bf5c24e85fcc025cc5d10b9983b0eba;hb=db93949aa395198bbd647827a1f8220e78fbaf3e#l35 Feb 12 14:22:18 Line 37 Feb 12 14:25:39 when upping the interface, it sometimes takes a while (link negotiation running) and speed is properly set to 100. on other times, upping the iface immediatly returns 1000Mbit within a few ms after executing the up command Feb 12 14:37:41 stintel: thanks! Feb 12 14:38:33 yw Feb 12 16:23:07 ldir: pong Feb 12 16:33:48 jow: can you explain why some packages copy into /lib/upgrade/keep.d/... and when this is needed, instead of just use the conffiles define? Feb 12 16:38:57 andy2244: lacking knowledge of the keep.d mechanism I guess Feb 12 16:39:38 so you should not actually copy files there and use just conffiles section? Feb 12 16:41:53 yes Feb 12 16:42:15 ok thanks Feb 12 16:42:19 well conffiles has some properties that might be undesirable Feb 12 16:42:52 if a line in conffiles can be resolved to an existing file during build time, its recorded as conffile in the opkg control file Feb 12 16:43:02 all other things end up in keep.d/$pkgname Feb 12 16:43:38 if for whatever reason you want file to be in keep.d but not in opkg conffiles, then you have to copy a premade file to keep.d and bypass conffiles Feb 12 16:44:08 not sure if that is the case for these pacakge you've seen or if it was just pacakge assumptions Feb 12 16:45:00 no clue was just suggested to me to solve: https://github.com/Andy2244/openwrt-extra/issues/11 Feb 12 16:45:55 its included in backup.gz now for me so i guess i had just a bad conffiles section, so i assume this is solved now. Feb 12 16:46:31 ok Feb 12 16:47:28 if its listed via "opkg list-changed-conffiles" than all should be fine for a sysupgrade? Feb 12 16:49:03 yes Feb 12 21:57:06 Hauke: https://github.com/openwrt/packages/pull/8158 Feb 12 22:00:40 mangix: why not let intel do their own work? Feb 12 22:05:27 hmm? Feb 12 22:06:34 why on earth are you spending your own time on iotivity? Feb 12 22:07:09 https://downloads.openwrt.org/snapshots/faillogs/mipsel_24kc/packages/ Feb 12 22:07:56 one positive thing that did was expose a linking bug with xz. In retrospect, this could have been the cause of a bunch of Travis failures Feb 12 22:08:32 * karlp shrugs. your time. sorry I interfered Feb 12 22:08:56 no worries. i personally don't use or care about iotivity Feb 12 22:09:21 even more reason to let intel handle it. Feb 12 22:09:29 if they don't, we can drop it. Feb 12 22:10:24 to be fair, the fix was a backport. Most likely several things would break if updating it to the latest version Feb 12 22:27:14 mangix: thanks **** ENDING LOGGING AT Wed Feb 13 02:59:56 2019