**** BEGIN LOGGING AT Thu Jan 09 02:59:58 2020 **** BEGIN LOGGING AT Thu Jan 09 05:31:58 2020 **** BEGIN LOGGING AT Thu Jan 09 06:03:43 2020 Jan 09 06:07:16 build #196 of sunxi/cortexa7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa7/builds/196 Jan 09 06:18:20 build #212 of ixp4xx/generic is complete: Failure [failed checkarch] Build details are at http://buildbot.openwrt.org/master/images/builders/ixp4xx%2Fgeneric/builds/212 blamelist: ?lvaro Fern?ndez Rojas , David Bauer , Hauke Mehrtens , Adrian Schmutzler , Ansuel Jan 09 06:18:20 Smith Jan 09 06:36:24 build #58 of mvebu/cortexa72 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mvebu%2Fcortexa72/builds/58 Jan 09 07:59:16 * ynezz going to slap that guy behind `wrong token` error in the Flyspray Jan 09 10:46:19 Hi is OpenWrt 19.0.7 ready? Jan 09 10:47:25 19.07* I want to put it up on twitter if so Jan 09 10:51:16 it's ready when it's ready = announced on the mailing list Jan 09 10:53:37 * enyc wonders if there should be a 19.07rc3 and more testing... hey-ho Jan 09 10:54:17 enyc: anything particular you're concerned about? Jan 09 10:55:39 rc3 or .1, does matter? Jan 09 10:56:31 s/does/does it/ Jan 09 10:57:20 karlp: been a while since convos with jow and all that nad bug report... thinking further i suspect the improvements jo suggests are for a later release. Jan 09 10:57:57 karlp: not sure if my screwup, i certainly had a router which worked nicesly ni 18.05 but not in 19.07 (readonly flash and loses config changes) etc but not sure if thats my mistake, and not onsite to sort that out at the moment! Jan 09 10:58:37 karlp: i observed qubes-os did a release without a further RC and then went "oh dear" and had to take it back ;p Jan 09 11:00:39 ok, so did you last try that? do you have an actual issue with the current state, or is this hypothetical? Jan 09 11:01:27 loses config changes smells like small flash Jan 09 11:01:57 what target is that? Jan 09 11:02:00 karlp: i've had a lot on latele and things way over new year, i foget exactly Jan 09 11:02:24 but you can point us to the URL at bugs.openwrt.org, right? Jan 09 11:02:42 as if it's not reported, it doesnt exist :) Jan 09 11:03:05 ynezz: you may be right ... Im not onsite and would want to have double-checekd situaios (reinstall, try other versian agin etc.) before reportnig a bug tbh Jan 09 11:03:31 ynezz: I *THINK* it may well have been a wr-740n which had the lost-config once 19.07'ed even though apparently enough space Jan 09 11:03:55 ynezz: OTHER bug i would be happy to test new basic-config/image for is https://bugs.openwrt.org/index.php?do=details&task_id=2667 Jan 09 11:03:56 enyc: after booting take a look at /proc/mtd . See if rootfs_data has more than 5 eraseblocks. Jan 09 11:04:08 (more or equal) Jan 09 11:04:55 that last bug doesn't seem to be antyhing that would require a new rc though, surely? Jan 09 11:05:08 PaulFertser: noted, emailed to myself, im not onsite at the moment, may be able to try next week Jan 09 11:05:27 karlp: i dont' know enough about process... i don't know how much changes made since last rc etc Jan 09 11:05:39 karlp: I had only wondered rather than suggesting it is needed Jan 09 11:06:19 does *seem* like quite a while since last rc hey-ho Jan 09 11:07:45 btw, talking about old small flash devices. My old 400 MHz 4 MB flash seems to be capable of doing NAT + SQM (!) with up to 40 Mb/s rates. Jan 09 11:08:36 well, that wr-740n v6 is QCA9533 with 4/32M Jan 09 11:08:59 so still good enough for most use cases Jan 09 11:18:26 build #220 of ar7/generic is complete: Failure [failed checkarch] Build details are at http://buildbot.openwrt.org/master/images/builders/ar7%2Fgeneric/builds/220 blamelist: Adrian Schmutzler , David Bauer , Hauke Mehrtens Jan 09 11:20:28 I don't know this parts to propose doable/acceptable solution, but if I were doing it, I would probably add another buildbot step, which would take imagebuilder and produce pre-defined variant of images - minimal, luci, minimal+selinux etc. Jan 09 11:22:01 I think, that it would be nice to have luci snapshots (increased testing) or release images without luci (for small devices, users not using luci etc.) Jan 09 11:22:41 ynezz: its certainly doable Jan 09 11:22:59 it just needs someone to send a patches :) Jan 09 11:23:00 question is how you want to organize things Jan 09 11:23:19 have different directoriy trees or throw all images in one directorya with different suffixes Jan 09 11:23:46 directories makes more sense (for me) Jan 09 11:24:56 that suffix in the filename would be still helpful as well Jan 09 11:25:04 so both? :) Jan 09 11:25:22 I won't get arond to it for at least another two to three months Jan 09 11:26:10 and I am sure we'll find a lot of funny bugs when we actually try to use the IB Jan 09 11:27:08 good point, increased testing of IB is additional bonus point Jan 09 11:27:11 :) Jan 09 11:34:21 build #73 of ixp4xx/harddisk is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ixp4xx%2Fharddisk/builds/73 Jan 09 11:35:19 build #65 of pistachio/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/pistachio%2Fgeneric/builds/65 Jan 09 11:36:16 build #64 of mediatek/mt7623 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mediatek%2Fmt7623/builds/64 Jan 09 14:47:27 hi, I recently added support for a new ath79 device (ruckus r500, enterprise ap). It's mostly functional (both ath10k and ath9k radios are operational, ethernet works, it's stable), but there are a number of caveats: I have yet to reverse engineer the image header format it uses (or try and obtain GPL sources from Ruckus to see how it's implemented), the LEDs don't work, and there is a hack to get openwrt to recognize the Jan 09 14:47:28 rootfs partition. Would it be worth it to try and send these patches upstream, or should I try to get these issues sorted out first? Jan 09 14:49:57 as it stands, it's possible to flash a functional image to the device, but it has to be done through the bootloader. The stock fw checks for the integrity of the image (using a 16-bit checksum, apparently) and also for a board ID string, but the bootloader doesn't verify this checksum, so the image does boot if you flash it there Jan 09 14:53:19 in terms of figuring out how the header works, I think calculating that checksum is the only missing piece, the other parameters (offset, entry/load addresses, size, board ID, version number...) were obvious to figure out Jan 09 14:58:15 I have yet to write a program to generate this header, however, which is why I came up with a simple hack to get openwrt to boot. I configured the image such that the kernel and rootfs would be padded to a certain size, then manually define the location of the rootfs in the device tree. I manually edited a header file to change the load and entry addresses to the correct ones for this kernel, and copied it to the beginning Jan 09 14:58:16 of the image. The bootloader only cares about these addresses, doesn't verify checksum or anything else, so it's able to load the image. Jan 09 15:15:01 victhor: do you need early review or advice for that? I think some support can be added if any reasonable install method is available, you do not really need to generate "factory" firmwares for the support to get upstream. A hack to find rootfs is more problematic. Support for LEDs should be nice to have too, unless it's really too hard. Jan 09 15:16:44 re. the LEDs: It's really not, it's just that I haven't gotten around to it yet, primarily because I borked the stock fw and I can't seem to restore it to a working state... So right now I can't easily get the LED GPIOs from there, like the usual method Jan 09 15:19:08 I'm not sure if I need advice, because of the hack I mentioned, I imagine I'd get told to fix the hack first before going any further with the process. So I guess it would be better to fix the hack first, and then try and submit it? Jan 09 15:20:10 and yes the install method is somewhat reasonable, other than requiring a 3.3V serial interface and a bit of attention to not accidentally erase ART or the bootloader Jan 09 15:21:13 there's also another problem I failed to mention - I neglected to write down the MAC addresses used by the stock fw, so right now the addresses loaded from ART are valid, but probably don't correspond to their appropriate interfaces, I think this is a minor problem, really. Jan 09 15:22:23 victhor: yes, the rootfs would need to be fixed for upstreaming afaict. Jan 09 15:24:07 I see. I'll get around to that, then. Thanks Jan 09 15:26:40 ynezz is https://github.com/openwrt/docker ready to use as daemon ? Jan 09 15:28:56 all I want is to run hostapd + luci ... should be possible, isnt it ? Jan 09 15:40:25 muhaha: no clue, I'm using it just for basic run time testing, for anything advanced I prefer to use QEMU Jan 09 17:01:50 build #60 of octeon/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/octeon%2Fgeneric/builds/60 Jan 09 17:34:09 build #232 of armvirt/32 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/232 blamelist: David Bauer , Daniel Golle , Maxim Anisimov Jan 09 17:34:42 build #60 of at91/sama5d3 is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/at91%2Fsama5d3/builds/60 Jan 09 17:35:01 build #231 of mediatek/mt7622 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/231 blamelist: David Bauer , Daniel Golle , Maxim Anisimov Jan 09 18:50:07 aparcar[m]: I would like to make the 19.07 announcment, can you add the misisng devices to the table of hardware: https://openwrt.org/toh/views/toh_fwdownload?dataflt[0]=supported%20current%20rel_%3D19.07.0 Jan 09 20:14:26 packages/projects using `git describe` to figure out its version (especially if it's not a relase but some random commit hash/master), get the openwrt hash returned, as the .git dir gets vanished after checkout being tarballed. Jan 09 20:14:38 not sure what's the best approach to tackle this, though.. Jan 09 21:35:06 Hauke as soon as OpenWrt 19.07 is ready to go can you ping me so I can post to twitter pleas. Jan 09 22:06:18 build #74 of ixp4xx/harddisk is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ixp4xx%2Fharddisk/builds/74 Jan 09 23:31:06 the wiki is down Jan 09 23:45:51 Tapper: could you please announce the 19.07 on twitter Jan 09 23:45:58 it is in the forum: https://forum.openwrt.org/t/openwrt-19-07-0-first-stable-release/52186/2 Jan 09 23:46:23 and on the mailing list now: https://lists.infradead.org/pipermail/openwrt-devel/2020-January/021148.html Jan 09 23:48:00 zorun: thank you for writing the release notes Jan 09 23:57:36 time to branch 20.01? :] Jan 10 00:38:19 build #198 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/198 **** ENDING LOGGING AT Fri Jan 10 02:59:58 2020