**** BEGIN LOGGING AT Wed Jun 26 02:59:57 2019 Jun 26 05:54:15 I'll rebuild the buildslave docker images now and include python3 while we're at it Jun 26 05:54:40 debian 9 seems to use python 3.5 as "python3" Jun 26 06:00:26 jow: great, while at it, could you please describe somewhere (wiki?) how to setup build slave with that docker image? I would like to provide my spare compute resources to the the buildbot Jun 26 06:01:12 ynezz: will do - its actually quite simple but requires access credentials that need to be provisioned on the master first Jun 26 06:01:39 and I need to review the setup in more detail to ensure that we do not leak secrets on the slaves before opening this to a wider audience Jun 26 06:01:52 (not necsessarily meaning you, but the document on the wiki part) Jun 26 06:02:57 also asked Ted Hess for push access on our docker hub account, so that I can publish the image there Jun 26 06:03:08 next step will be turining the build masters into docker containers Jun 26 06:03:17 which is slightly more challanging Jun 26 06:03:31 sounds like a lot of work ahead Jun 26 06:04:00 thats openwrt Jun 26 06:04:31 ;) Jun 26 06:22:35 jow: can i call ? Jun 26 06:29:29 sure Jun 26 07:05:06 xback, lynxis, mkresin, rmilecki: ping http://lists.infradead.org/pipermail/openwrt-adm/2019-June/001053.html Jun 26 07:59:21 ynezz: it could be that I'm not included in that mailing list Jun 26 07:59:52 ynezz: +1 for all 3 from me Jun 26 08:00:42 oh, I've thought, that everybody with commit access is added to openwrt-adm mailing list Jun 26 08:01:50 jow: Could it be that I'm not present in the openwrt-adm list? (no worries should you prefer not too want me there :-) ) Jun 26 08:02:07 you can subscribe there as well Jun 26 08:02:23 oh, checking .. Jun 26 08:05:03 subscribed :) Jun 26 08:13:14 xback: could you please vote by the reply to that email 'Message-id: <29c9fd63-0cc3-1bcb-9299-741583c45906@true.cz>' ? I'm afraid, that it's going to be lost otherwise Jun 26 08:38:01 gch981213: I'm asking, because I'm tempted to upstream support for Carambola2, for this device I would need to upstream first ag71xx_gmac.c file Jun 26 08:38:42 gch981213: but I'm quite unsure where this part should go in the upstream kernel Jun 26 09:19:41 ynezz: I think PHY swapping should be done in switch driver and other MII interface configuration should be done in ag71xx. Jun 26 09:19:45 Hi, how can I change a file from read-only to writeable before opnwrt tries to apply a patch? Jun 26 09:36:50 Hallo32: https://openwrt.org/docs/guide-developer/package-policies#hooks Jun 26 09:38:12 Hallo32: even better, redefine Build/Patch: Jun 26 09:39:01 define Build/Patch Jun 26 09:39:18 \t chmod 0644 $(PKG_BUILD_DIR)/whatever Jun 26 09:39:37 \t $(Build/Patch/Default) Jun 26 09:39:38 endef Jun 26 09:40:45 jow: Thats sounds fine Jun 26 09:58:52 i have a device that comes with two firmware partitions and the device's uboot picks one of the two based on some configuration and then reports it to the kernel in uboot-env Jun 26 09:59:14 are there other devices like this? how should i handle this? Jun 26 10:00:20 ah, ok, seems like it's common among newer linksys stuff Jun 26 10:04:21 wrt1900ac does a hack in of.. hmm Jun 26 10:04:43 angelsl: you could take a look at the source code of "luci-app-advanced-reboot" to see the various flavors of dual booting Jun 26 10:05:09 thanks Jun 26 11:01:19 ynezz: ping $(call Image/pad-to,$(KDIR)/root.squashfs,$(if $(1),$(1),$(CONFIG_TARGET_ROOTFS_PARTSIZE)M)) - needs to be done in an OS independent way - not all dd understand capital letter unit specifiers, and not all understand lowercase either. Jun 26 11:02:12 I suspect that calculating PARTSIZE * 1024 * 1024 and passing the value in bytes is the safest. Jun 26 11:02:23 Unfortunately I don't know how to do that in 'make' Jun 26 11:04:43 thats unfortuantely not possible Jun 26 11:05:12 but given that we're running in a bash shell we could try to emit an expression instead Jun 26 11:05:43 $(if $(1),$(1),$(CONFIG_TARGET_ROOTFS_PARTSIZE)M) => `expr $(if $(1),$(1),$(CONFIG_TARGET_ROOTFS_PARTSIZE)) '*' 1024 '*' 1024` Jun 26 11:06:33 $((...)) would work too but escaping '$' is usually a headache since you never know how many levels deep the macro is evaluated Jun 26 11:06:54 thanks jow I shall give that a try in macOS land Jun 26 14:16:23 sorry jow - can't get it to work - probably being very stupid Jun 26 14:35:59 make it work - am moron Jun 26 14:37:48 -EPARSE Jun 26 15:04:43 make it work - am moron - and cannot type Jun 26 15:04:51 made it work Jun 26 15:04:55 aaargghhhhhh!!!!!! Jun 26 15:05:17 * ldir has been typing make too much Jun 26 15:15:47 :D Jun 26 15:16:18 wait until you start dreaming in nested code-generating, self-evaling recursive make macros Jun 26 15:16:32 jow: I believe you need help. :) Jun 26 15:16:37 Or perhaps a holiday Jun 26 15:17:50 Monkeh: jow needs a holiday for sure.... Jun 26 15:24:36 ldir: traveling this week, so I'm little bit lagged https://git.openwrt.org/de83d9bbd8cf3ce870b13644700328085209ee3a Jun 26 15:26:27 ynezz: thats way easier ;) Jun 26 15:30:22 yeah, cheating whole life Jun 26 15:32:18 testing Jun 26 15:53:24 sysupgrade: stage2: Does anyone on have a recollection of problems with sh functions returning to the wrong place -- perhaps the reason behind nand_do_upgrade_success() instead of handling it after the case-esac on upgrade type there? Jun 26 15:54:39 If I try to refactor that, nand_upgrade_* returns to the caller of nand_do_upgrade(), not to after the case-esac Jun 26 15:57:26 jeffsf: never heard of something like thatz Jun 26 15:58:09 nothing obvious in the comments with git log --follow either :( Jun 26 15:58:15 jeffsf: but you know the general process? (stage1 calling ubus upgrade, which makes procd to exec into upgraded which then through various indirections sources and executes procedures in stage2) Jun 26 15:58:39 Yes, tracing all the calls after the `exec` Jun 26 15:59:02 ok Jun 26 16:36:50 What is the preffered way? Jun 26 16:36:50 Pullrequest against master with backport request to 19.07 or pr against 19.07? Jun 26 16:48:20 PR against master with a 'please cherry-pick for 19.07' Jun 26 16:48:58 jow: can you merge this? https://github.com/openwrt-routing/packages/pull/479 Jun 26 16:49:01 unless the bug is 19.07 exclusive Jun 26 16:49:56 mangix: I have there two PRs waiting to be merged even I complained here about that multiple times, but no respond so far. Jun 26 16:50:43 interesting... Jun 26 16:55:06 KevinDB: thanks Jun 26 16:58:39 Pepe: which ones? Jun 26 16:58:49 afair almost none of the committers here maintains routing Jun 26 16:59:42 mangix: about that cjdns not on arc thing; isn't that taken care of by the fact that node already DEPENDS on !arc or did I miss something? Jun 26 17:01:12 jow: doesn't seem lime it: http://downloads.openwrt.org/snapshots/faillogs/arc_archs/routing/cjdns/compile.txt Jun 26 17:02:00 fascinating, it is using node/host ? Jun 26 17:03:07 Pepe: the bird update? Jun 26 17:05:10 jow: interesting... so I can't select cjdns but I can select cjdns-tests. Maybe that's where it comes from. Jun 26 17:05:12 jow: unfortunately yes. No respond from maintainer in any of those three PRs (including the one from tohojo), which is not good. Jun 26 17:07:13 , never mind. I can select cjdns Jun 26 17:08:10 there's no node dependency. interesting... Jun 26 17:12:24 Pepe: well I suggested a merger of openwrt-routing with openwrt/packages at least two times in the past, but it was always vetoed Jun 26 17:12:46 maybe we could pull the nuclear option and simply delist the feed Jun 26 17:13:36 but I believe that some unmerged PRs are not enough reason for that Jun 26 17:14:08 Pepe: will merge your PRs now, are you willing to do another one for openwrt-19.07 ? Jun 26 17:14:13 What were the reasons for the veto ? Jun 26 17:14:24 or actually... I guess I can simply cherry-pick Jun 26 17:14:40 ldir: https://github.com/openwrt-routing/packages/issues/184 Jun 26 17:15:53 actually I didn't look in a long time, looks like an ack after all Jun 26 17:16:08 maybe someone else has time and motivation to conclude the discussion Jun 26 17:16:41 like "there is a general consensus", "two weeks", "people will given access to openwrt packages" etc. then do it Jun 26 17:18:11 Is there an openwrt-routing irc channel, perhaps there should be and 'requests' can be redirected there ;-) Jun 26 17:18:23 I don't think so Jun 26 17:22:06 Well 'we' who are here are in the uncomfortable position of taking the flack for stuff over which apparently we have no influence. Jun 26 17:22:51 Hauke: I was going to try out the v5.2-rc6 mac80211 from your staging repository, but it looks like the backports archive is 404? Jun 26 17:23:57 * ldir is in militant nuclear option mood - but then has had a bit of a sh*tty week so is grump-o-matic :-) Jun 26 17:26:27 oh cool. interrupts work for mt7621 now Jun 26 17:26:42 I'll poke the hornet's nest tomorrow I guess. Jun 26 17:40:20 ramips has a kernel patch that wipes out the bootloader's cmdline.. but i need it to know which dual-firmware partition to pick Jun 26 17:40:49 or.. maybe i should just screw dual-firmware and merge all the partitions Jun 26 17:41:22 mamarley: yes I haven't published the tar.gz file Jun 26 17:45:46 angelsl: can't you read it from the bootloader environment? E.g. with fw_printenv? Jun 26 17:46:24 hmm Jun 26 17:46:28 that works too Jun 26 17:46:49 which means i have to include an initramfs Jun 26 17:56:20 angelsl: you don't need initramfs just for that\ Jun 26 17:57:38 whether fw1 or fw2 is booted determines which is my rootfs though Jun 26 17:57:57 angelsl: fwiw, i'll be adding support for a device with the same problem soon Jun 26 17:58:09 well, the other option is a kernel hack Jun 26 17:58:17 how are you handling it? Jun 26 17:58:37 i haven't gotten that far yet Jun 26 17:58:59 but it should be doable because other devices do it Jun 26 17:59:17 however, those are all nand, not nor Jun 26 17:59:24 my device has a nand Jun 26 17:59:31 the devices i've been looking at don't clobber the bootloader cmdline though Jun 26 17:59:44 the device i'll be adding has nor Jun 26 18:00:19 ramips has this patch https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-4.14/0007-MIPS-ralink-copy-the-commandline-from-the-devicetree.patch Jun 26 18:00:51 is the device you're adding ramips? Jun 26 18:00:54 yeah Jun 26 18:01:00 it's an mt7621 Jun 26 18:01:16 The package tools/flock is trying to download a file but shouldn't it be enough to compile the file in the src folder? Jun 26 18:01:16 Download comand flock: curl -f --connect-timeout 20 --retry 5 --location --insecure @GNU/-2.4.tar.xz Jun 26 18:01:33 what is the flash layout on the factory firmware? Jun 26 18:02:36 it has a kernel, rootfs, alt_kernel, alt_rootfs consecutively Jun 26 18:02:46 which is why i'm inclined to just merge it all Jun 26 18:02:52 i saw a device that did that Jun 26 18:03:12 although the bootloader will probably not like it if it tries to boot the alt Jun 26 18:04:18 ... which is another problem because i'm not sure how factory fw behaves when flashing from the UI but i suspect it writes to the inactive partition and then flips the uboot_env setting Jun 26 18:04:52 which means i actually can't merge it if i want to support flashing from factory fw Jun 26 18:04:57 ... sigh Jun 26 18:05:12 yes, the device i'll add has the same problem Jun 26 18:06:26 i think i'll probably just do a kernel patch Jun 26 18:06:58 have a flag in the dts to not clobber the bootloader's cmdline Jun 26 18:07:54 angelsl: https://patchwork.ozlabs.org/patch/1119874/ Jun 26 18:08:22 oh, cool Jun 26 18:15:44 that doesn't help the device i'll add Jun 26 18:28:24 angelsl: there are also many other devices which have to partially mangle the bootloader cmdline for dual-boot purposes, nbg6817, wrt1200/1900/3200/32x, ea6350/ ea8300/ ea8500, ... Jun 26 18:28:52 i was actually midway through porting that mangle patch Jun 26 18:29:33 (from ARM to MIPS) Jun 26 18:29:58 the nbg6817 has mmc instead of nand, i think Jun 26 18:30:31 DonkeyHotei: yes, but that doesn't really change the situations - and all the others mentioned are NAND based Jun 26 18:30:44 correct Jun 26 18:31:17 i guess i'll be adapting the new mips patch for nor Jun 26 18:31:47 why mangle the bootloader cmdline though? Jun 26 18:32:10 why not just ubi.mtd both partitions Jun 26 18:32:58 oh, then you still need to set the rootfs to the ubi device Jun 26 18:32:59 sigh Jun 26 18:33:24 well, looks like i have to port the arm patch to mips Jun 26 18:33:30 feels awfully hacky though Jun 26 18:34:48 oh wow: target/linux/ipq806x/patches-4.14/0067-generic-Mangle-bootloader-s-kernel-arguments.patch Jun 26 18:35:36 but for nand, you can probably just base it on the linksys patch Jun 26 18:35:51 might not be the most pretty thing, but it works (on the nbg6817 (and apparently ea8500)) Jun 26 18:37:40 there should be a filesystem-agnostic way to do this Jun 26 18:40:16 DonkeyHotei: i was porting exactly that patch, actually Jun 26 18:40:50 not this one? target/linux/kirkwood/patches-4.14/202-linksys-find-active-root.patch Jun 26 18:40:56 think i'm too used to having the luxury of an initramfs to find and mount the rootfs Jun 26 18:52:33 DonkeyHotei: thanks, i think i might adapt this **** BEGIN LOGGING AT Wed Jun 26 20:03:58 2019 Jun 26 20:47:01 whoooop Jun 26 20:47:32 i have boot :-) Jun 26 20:48:41 don't forget to add to upgrade/platform.sh to flash the *other* partition Jun 26 20:49:29 ah, right Jun 26 20:49:39 my next hurdle is mt7615 wifi drivers Jun 26 20:50:38 afaik it is in openwrt's mt76 tree already so.. i'll just see if that works Jun 26 20:53:08 is there any already supported device using that driver, or will this be the first? Jun 26 20:56:37 i'm not sure Jun 26 20:56:53 if there are, they're probably recently added too Jun 26 20:57:00 yes Jun 26 20:57:02 because the mt7615 drivers were only recently added Jun 26 20:57:10 correct Jun 26 21:11:00 is there precedent for using the syscfg partition as the overlay on linksys devices? Jun 26 21:11:46 no Jun 26 21:12:32 or rather one overlay partition per image/rootfs please, anything else will lead to weird issues when booting into the other image Jun 26 21:13:10 that's true Jun 26 21:15:35 personally, i think mtdsplit should be changed to allow more than one split partition, instead of piecemeal patches per target Jun 26 21:16:43 it's the ultimate way to despaghettify the issue Jun 26 21:17:54 you'd still need some way to figure out which partition to use from the cmdline/etc though Jun 26 21:18:35 because right now, there are conflicting patches to that effect in kirkwood, mvebu, ipq806x, and now ramips, with more to come soon Jun 26 21:19:09 heh Jun 26 21:26:41 DonkeyHotei: mtdsplit is an depreated concept anyway, having compatibles slapped at partitions is the new rage Jun 26 21:27:24 in case you didn't see, current mtdsplit is the implementation of the compatible tag Jun 26 21:27:58 the tag will not work correctly atm when specified for more than one partition Jun 26 21:28:04 this is bad Jun 26 21:29:36 DonkeyHotei: not quite sure what you are talking about Jun 26 21:32:50 the patch implementing the "compatible" tag (using mtdsplit internally) still assumes only one partition will have the tag Jun 26 21:34:27 that's not what I'm talking about, I'm talking about the upstream linux implementation, where no mtdsplit code is at all Jun 26 21:35:26 does upstream linux have a solution for "alternative" kern/root mtd blocks? Jun 26 21:38:01 that's not the job of the partitions parsing code Jun 26 21:38:48 right, but openwrt does not currently have another way to find root Jun 26 21:55:56 DonkeyHotei: upstream linux generally doesn't have to work with bootloaders not in their control Jun 26 21:56:46 upstream linux also only minimally concerns itself with the rootfs at all Jun 26 21:57:33 wasn't this one of the reasons initramfss were invnted? Jun 26 21:58:09 to find and mount the rootfs when it's not as simple as root= Jun 26 21:58:12 in openwrt, the use of initramfs precludes the use of permanent storage Jun 26 21:58:45 i mean, that's what is generally done in other linuxes i've seen Jun 26 21:59:04 yes but those are on servers and PCs Jun 26 21:59:39 is the concern space? Jun 26 21:59:52 depending on the device, it can be Jun 26 22:00:44 i mean all the initramfs needs is a statically-linked /init that does whatever magic to find the root and mount it Jun 26 22:01:11 procd already does _some_ of that magic Jun 26 22:02:08 maybe moving ALL of this logic into procd is the long-term solution? Jun 26 22:02:31 and then procd into initramfs? Jun 26 22:02:33 and now you're building systemd ;) Jun 26 22:02:51 lol Jun 26 22:08:16 well, part of what's wrong with that idea is that it would require two copies of busybox Jun 26 22:09:09 some in-kernel patch to detect rootfs in openwrt is not really avoidable Jun 26 22:11:29 but if it's done by means of root= from the bootloader, care must be taken to preserve partition numbers Jun 26 22:14:16 move squashfs into initramfs Jun 26 22:16:01 then you can do whatever you need to find and mount the overlay upper partition Jun 26 22:16:29 that would greatly increase ram usage Jun 26 22:16:50 sigh Jun 26 22:18:04 [06:08] DonkeyHotei: well, part of what's wrong with that idea is that it would require two copies of busybox Jun 26 22:18:13 what if you just kept the busybox from the initramfs Jun 26 22:18:27 well, there's still the concern of ram usage i guess Jun 26 22:18:40 a 3-way overlay? Jun 26 22:19:07 sounds like the worst of all worlds Jun 26 22:19:56 not really, you just have the initramfs mounted somewhere under / Jun 26 22:20:22 so you setup the overlayfs, then pivot_root and you're done Jun 26 22:21:49 it would be a fundamental change to openwrt's design, and i don't think the justification is sufficient atm Jun 26 22:23:10 yeah, just throwing ideas out there Jun 26 22:51:49 angelsl: many targets are already pretty low on space for the kernel, even the targets with flash in the hundreds of MB Jun 26 22:53:07 for an initramfs to work, you'd either have to append it to the kernel (not going to work on many devices, with 2-4 MB reserved as kernel partition) or come up with a way to load the initramfs from elsewhere (qhich sounds awfully like parsing root= again) Jun 26 22:53:20 (or even more fun with OEM bootloaders) Jun 26 23:13:26 * jeffsf shudders, remembering diving into assembly code in early `init`, before giving in to `bootargs-append` Jun 26 23:16:16 i think i was the one who first introduced bootargs-append Jun 26 23:16:47 and i kept being told it's the wrong solution Jun 26 23:20:36 in that case, thanks :) wrong or not, it does the job on my nbg6817 - and I don't really see a real alternative there Jun 26 23:42:19 I tried "everything" but overriding didn't help for the device as I needed the "hint" from U-Boot as to which of two firmwares to boot, and the existing platform-level override didn' Jun 26 23:42:30 t touch the arg I needed to override. Jun 26 23:43:36 jeffsf: what device was that? Jun 26 23:43:39 I still wish would have preferred something in 1init`, but it was just too fragile. When the Linux code comment is /* Crazy stuff begins here */ Jun 26 23:43:51 ipq4019 -- Linksys EA8300 Jun 26 23:44:45 init=/sbin/init rootfstype=ubifs ubi.mtd=11,2048 root=ubi0:ubifs rootwait rw Jun 26 23:45:29 Needed to be, as I recall Jun 26 23:45:52 ubi.mtd=11 root=ubi0:ubifs (where mtd=11 or mtd=13) Jun 26 23:46:09 Err, no Jun 26 23:46:23 ubi.mtd=11 root=/dev/ubiblock0_0 Jun 26 23:47:06 Different enough from the mangle the platform supplies that I couldn'tuse that Jun 26 23:47:13 that's almost certainly what angelsl will end up doing Jun 26 23:47:40 but for nor flash, it's not quite as simple Jun 26 23:48:19 Still doesn't "feel right" to me, but at least I could get upgrade from/to OEM without serial **** ENDING LOGGING AT Thu Jun 27 02:59:57 2019