**** BEGIN LOGGING AT Mon Jun 15 02:59:58 2020
Jun 15 04:13:20 <owrt-snap-builds> build #160 of bcm63xx/generic is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/160  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Pawel Dembicki <paweldembicki@gmail.com>
Jun 15 04:14:47 <owrt-snap-builds> build #460 of oxnas/ox820 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/460  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Pawel Dembicki <paweldembicki@gmail.com>
Jun 15 10:04:16 <lmore377> im porting openwrt to a router and im finally able to flash it and it boots and populates /overlay and everything works as expected but when i reboot it, it doesn't mount properly. on every boot i get a "read error in "firmware" at offset 0x19fc0000" error while it's initializing the mtd devices but there's no bad blocks and that's within the bounds of the firmware partition. do i need to format it or something?
Jun 15 10:04:36 <lmore377> to install i just booted an initramfs image and used sysupgrade
Jun 15 10:07:16 <lmore377> sometimes the read error has a slightly different location (another reboot showed 0x19fa0000)
Jun 15 10:08:53 <lmore377> wait the end of rootfs and rootfs_data are overlapping. is that normal?
Jun 15 10:11:16 <PaulFertser> lmore377: no, not normal. Is it NOR or NAND flash?
Jun 15 10:11:25 <lmore377> nand
Jun 15 10:11:34 <PaulFertser> lmore377: so are you using ubi on it?
Jun 15 10:13:07 <lmore377> PaulFertser: i've been letting openwrt handle partitioning. i defined the firmware partition but it made the rootfs and kernel partitions and as far as i know the overlay tries to format with jffs2
Jun 15 10:14:06 <lmore377> i haven't touched ubi at all, just seen mentions of it in uboot
Jun 15 10:14:51 <PaulFertser> lmore377: I think on NAND targets you're supposed to define "ubi" partition. And then it would have "rootfs" (squashfs) and "rootfs_data" (ubifs) volumes.
Jun 15 10:17:11 <lmore377> i added "(call Device/UbiFit)" to the makefile so i'll recompile and see if it works
Jun 15 10:18:22 <lmore377> do i also need to put append-ubi or is that only for factory images?
Jun 15 10:20:21 <PaulFertser> lmore377: sysupgrade-tar should be appropriate
Jun 15 10:20:51 <PaulFertser> lmore377: and nand sysupgrade code will take care of resizing/recreating ubi volumes as needed.
Jun 15 10:22:21 <PaulFertser> lmore377: partition that you define as "ubi" in DTS will be automatically mounted as ubi, and then if "rootfs"-named volume is present there, it'll be used for rootfs automatically.
Jun 15 10:29:30 <lmore377> PaulFertser: thanks for all your help. gonna get off now since compiling takes a long time on my laptop and i gotta sleep
Jun 15 10:29:47 <PaulFertser> lmore377: btw, UbiFit might be related only to how the bootloader expects to get your kernel, FIT image or not.
Jun 15 10:29:53 <PaulFertser> lmore377: sleep well
Jun 15 10:39:52 <jow> mangix: zstd is not in tools on 19.07
Jun 15 15:22:19 <guifipedro> zorun: why the PKG_RELEASE must be reset to 1 ?
Jun 15 15:22:24 <guifipedro> ( https://github.com/openwrt-routing/packages/pull/574 )
Jun 15 15:23:53 <Ivan_83> jow: https://github.com/openwrt/openwrt/pull/3110
Jun 15 15:41:16 <adrianschmutzler> guifipedro: the PKG_RELEASE is our internal version. If there is an external version (e.g. PKG_VERSION), then PKG_RELEASE refers to the changes done after this version has been pulled. On each update of the PKG_VERSION, the PKG_RELEASE is set back to 1
Jun 15 15:45:57 <guifipedro> adrianschmutzler: interesting, so according to the history of this package, looks like it was done incorrectly for long time
Jun 15 15:46:36 <guifipedro> can I add your name and sentence in the PR ? just to let other users know this
Jun 15 15:47:23 <guifipedro> I think I did not get it. That would mean that each change sets PKG_RELEASE to 1, so it is always PKG_RELEASE equal to 1 all the time?
Jun 15 15:47:55 <guifipedro> or maybe I am missing the reason to increment PKG_RELEASE
Jun 15 15:55:15 <guifipedro> OK, got it now, sorry the confusing and noise
Jun 15 15:57:45 <adrianschmutzler> each change of PKG_VERSION resets PKG_RELEASE
Jun 15 15:57:56 <adrianschmutzler> you may just paste my sentence here to the PR
Jun 15 16:02:34 <guifipedro> yeah, did it :)
Jun 15 16:40:30 <mangix> jow: I have not backported. I don't plan on doing ao either.
Jun 15 17:57:51 <dwmw2_gone> hm, export_bootdevice returns 179 24 (/dev/mmcblk0) when my root is /dev/mmcblk0p3
Jun 15 18:13:42 <student_alfa> hi
Jun 15 18:37:06 <dwmw2_gone> + ubus call system sysupgrade '{ "prefix": "\/tmp\/root", "path": "\/tmp\/openwrt-mediatek-mt7623-bpi_bananapi-r2-squashfs-sysupgrade.bin", "backup": "\/tmp\/sysupgrade.tgz", "command": "\/lib\/upgrade\/do_stage2", "options": { "save_partitions": 1 } }'
Jun 15 18:37:06 <dwmw2_gone> {
Jun 15 18:37:06 <dwmw2_gone> 	"error": {
Jun 15 18:37:06 <dwmw2_gone> 		"message": "Firmware image couldn't be validated: no JSON input"
Jun 15 18:37:08 <dwmw2_gone> 	}
Jun 15 18:37:12 <dwmw2_gone> hm, what causes that?
Jun 15 18:39:14 <aparcar[m]> jow could you help me finalize the attended sysupgrade rewrite to client side rendering?
Jun 15 18:41:42 <stintel> dwmw2_gone: I suspect your are missing | append-metadata
Jun 15 18:43:32 <dwmw2_gone> I actually don't know why openwrt-mediatek-mt7623-bpi_bananapi-r2-squashfs-sysupgrade.bin is built at all :)
Jun 15 18:46:44 <stintel> magic :)
Jun 15 18:46:50 <adrianschmutzler> dwmw2_gone: because it's defined in Device/Default?
Jun 15 18:47:40 <adrianschmutzler> in image/Makefile
Jun 15 18:47:47 <adrianschmutzler> if you don't want that, you need to use
Jun 15 18:47:53 <adrianschmutzler> IMAGES := sdcard.bin.gz
Jun 15 18:47:56 <adrianschmutzler> instead of
Jun 15 18:47:57 <adrianschmutzler> IMAGES += sdcard.bin.gz
Jun 15 18:48:52 <dwmw2_gone> upgrade with sdcard.bin may have worked.
Jun 15 18:48:52 <dwmw2_gone> thanks
Jun 15 18:49:03 <dwmw2_gone> will continue testing and make sure it did the right thing
Jun 15 18:49:09 <dwmw2_gone> And test on emmc, and then probably rename it :)
Jun 15 18:50:01 <adrianschmutzler> but that's essentially just the selection which images are built. you can set everything, independent of whether that makes sense or not
Jun 15 19:32:50 <aparcar[m]> adrianschmutzler: hi
Jun 15 19:34:19 <aparcar[m]> regarding target in filenames, I talked to dangole and he mentioned that e.g. raspberries are based on target/subtarget either 32 or 64 bit. I'd say we could put this information into profiles and thereby solve the problem
Jun 15 19:37:49 <adrianschmutzler> aparcar[m]: but isn't that bcm27xx?
Jun 15 19:38:24 <aparcar[m]> adrianschmutzler: I don't know
Jun 15 19:38:40 <aparcar[m]> Okay if that's not the only reason, I'd be very curious why we offer mutliple images for the same devices
Jun 15 19:38:41 <adrianschmutzler> or in other words: why does that help us?
Jun 15 19:39:09 <aparcar[m]> because you could have a profile name which is raspberrypi-4-32bit and raspberrypi-4-64bit
Jun 15 19:39:12 <adrianschmutzler> I haven't tried to research in bcm63xx history so far
Jun 15 19:39:59 <adrianschmutzler> maybe it's really just a remnant where subtargets were used to enable different configs
Jun 15 19:40:00 <aparcar[m]> and the image is then openwrt-raspberrypi-4-32bit-sysupgrade.bin, which seems verbose enough
Jun 15 19:41:16 <adrianschmutzler> but I stated earlier, I don't think the target should be removed
Jun 15 19:41:22 <aparcar[m]> different configs to change what?
Jun 15 19:41:41 <adrianschmutzler> generic and smp in bcm63xx.
Jun 15 19:41:59 <adrianschmutzler> to me it looks like they are just changing packages ...
Jun 15 19:42:23 <aparcar[m]> isn't that... a bit overkill?
Jun 15 19:42:41 <aparcar[m]> to introduce a new target just for different packags
Jun 15 19:42:47 <adrianschmutzler> well, as I said, i haven't looked it up in detail, I just know that the situation exists there
Jun 15 19:42:57 <adrianschmutzler> subtarget, not target
Jun 15 19:43:18 <aparcar[m]> yea that's what I meant sorry
Jun 15 19:43:40 <adrianschmutzler> what's the benefit of the whole thing again?
Jun 15 19:44:46 <aparcar[m]> human readable filenames
Jun 15 19:45:20 <adrianschmutzler> I'd consider the current filename human-readable as well, and they even provide additional information
Jun 15 19:45:56 <aparcar[m]> well you're a core developer of openwrt I'd be surprised if it wouldn't
Jun 15 19:46:43 <aparcar[m]> but for regular users i'd say it more confusing
Jun 15 19:47:54 <aparcar[m]> as stated in the mail, there are trivial ways to figure out the target anyway. but for someone not involved in targets it's some lengthy extra information, maybe containing something sounding similar to whatever else and is thereby simply confusing
Jun 15 19:48:47 <adrianschmutzler> I'd say it's helpful. Just imagine the bug report for example. I'm so glad that the filename contains the target, otherwise I'd have to ask about ath79 vs. ar71xx for almost every bug report.
Jun 15 19:49:44 <PaulFertser> People mention full filename more often than full download URL when bug reporting.
Jun 15 19:50:17 <PaulFertser> Probably the report form can be made to require /proc/cpuinfo data or some such.
Jun 15 19:50:37 <PaulFertser> Or /etc/openwrt_release
Jun 15 19:51:10 <adrianschmutzler> That could be helpful, but it requires the device to boot at least :-)
Jun 15 19:51:31 <aparcar[m]> adrianschmutzler: but doesn't that exactly show a deeper problem of not distributing multiple possible images for a release?
Jun 15 19:52:03 <adrianschmutzler> aparcar[m]: Don't understand that.
Jun 15 19:53:09 <PaulFertser> OK, let's put it another way, what exactly having target name in the file name harms? Users getting confused because of that? Probably that's not the target audience then if they can get confused by filename prefix?
Jun 15 19:53:58 <aparcar[m]> adrianschmutzler: if you have two images (ath79 plus ar71xx) in a release, people will randomly select one and you end up dealing with both. For future releases profiles could be "unique" that everyone ends up with the same image for a device
Jun 15 19:54:07 <adrianschmutzler> PaulFertser: Well, essentially aparcar wants to have unique profile names, which requires something like generic_ath25
Jun 15 19:54:31 <adrianschmutzler> PaulFertser: This however would cause "ath25" to be named twice in the file name, and that looks odd.
Jun 15 19:55:04 <adrianschmutzler> PaulFertser: However, I personally think that this is just too much and we should not add the target name there in the first place.
Jun 15 19:55:20 <PaulFertser> ath79_ath25 would be odd, ath25...ath25 is just redudant :)
Jun 15 19:55:21 <adrianschmutzler> But fix the secondary tool that has problems with non-unique profile names.
Jun 15 19:55:22 <aparcar[m]> it's a hybrid of unique profiles and easier filenames
Jun 15 19:56:20 <adrianschmutzler> aparcar[m]: But it's just not realistic to decide now that we will never have something like ath79/ar71xx again
Jun 15 19:56:39 <adrianschmutzler> just because profile names "have" to be unique
Jun 15 19:56:54 <aparcar[m]> and we don't have. just before the release all ar71xx images that already exist in ath79 could have been disabled
Jun 15 19:58:33 <aparcar[m]> I'm not saying anything has to be in whatever way, I'm just suggesting things and try to understand cases like the bcmxx situation. After trying to create tooling around OpenWrt I'm very much a fan of avoiding inconsistencies
Jun 15 19:58:34 <adrianschmutzler> but that's wishful thinking. when 19.07 was branched, not all of the ath79 devices were ready, so the release was partially experimental. In contrast, ar71xx has a completely different concept concerning board vs. device, so it wouldn't have been possible to disable "just" the devices in ath79 there.
Jun 15 19:59:05 <adrianschmutzler> despite of the necessary work required which nobody would have been wanting to do.
Jun 15 19:59:22 <aparcar[m]> adrianschmutzler: so builds can't be disabled on a per device base?
Jun 15 19:59:56 <aparcar[m]> doesn't it take like an hour to go through both targets and figure out whats there and what not?
Jun 15 20:00:19 <adrianschmutzler> build can be disabled on per-device basis, but it's different what's "a device" when you compare ath79 with ar71xx
Jun 15 20:00:39 <aparcar[m]> can you please elaborate
Jun 15 20:04:04 <aparcar[m]> are images compatible with multiple devices when using either of them or how does the mapping between image and device change?
Jun 15 20:06:48 <adrianschmutzler> e.g. for ath79 a subset of devices with individual names may be supported now, but only one for ar71xx will exist
Jun 15 20:07:21 <adrianschmutzler> or we decided to use a different naming pattern for a set of devices in ath79 compared to ar71xx
Jun 15 20:07:30 <adrianschmutzler> and that's just this single example
Jun 15 20:07:44 <adrianschmutzler> the bigger problem is that nobody will want to do this job
Jun 15 20:08:03 <adrianschmutzler> I wouldn't as well, because I don't see a need for it
Jun 15 20:08:20 <adrianschmutzler> actually, the ability to choose between ar71xx and ath79 in 19.07 is a feature for me
Jun 15 20:08:51 <aparcar[m]> how so?
Jun 15 20:09:03 <stintel> what the hell is a vlan FID?
Jun 15 20:09:15 <adrianschmutzler> because you can choose whether you want ath79 already or keep ar71xx ... :-)
Jun 15 20:09:51 <adrianschmutzler> just think of ath79 as beta-support in a stable release
Jun 15 20:10:08 <aparcar[m]> adrianschmutzler: brb, are you a bit longer around?
Jun 15 20:10:43 <adrianschmutzler> will leave in 5 min, maybe read stuff again at CEST midnight
Jun 15 20:11:23 <adrianschmutzler> anyway, I don't see a point in enforcing uniqueness across targets. I'd be all in for uniqueness with a target though, across subtargets
Jun 15 20:11:31 <adrianschmutzler> which should be much easier to achieve
Jun 15 20:12:24 <adrianschmutzler> generic will stay generic in octeon and ath25 then, but you could e.g. have generic_64, generic_32, generic_geode etc. within x86.
Jun 15 20:12:45 <adrianschmutzler> and then one may remove the subtarget from the filename.
Jun 15 20:13:14 <adrianschmutzler> however, someone will have to research bcm63xx for that, and there might be other targets making problems i don't know about yet.
**** ENDING LOGGING AT Mon Jun 15 20:36:34 2020

**** BEGIN LOGGING AT Mon Jun 15 20:38:15 2020
Jun 15 21:26:08 <owrt-snap-builds> build #161 of bcm63xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/161
Jun 15 21:45:13 <karlp> ath25 isn't really a good example anyway, as there's only one version, and everyone who actually had ath25 targets has their own forks to customize it.
Jun 15 21:59:17 <adrianschmutzler> karlp: well, if nobody bumps it to 5.4 ath25 won't be relevant anymore anyway
Jun 15 21:59:42 <aparcar[m]> adrianschmutzler: wb
Jun 15 21:59:56 <aparcar[m]> what about moving ar71xx to targets.git?
Jun 15 22:00:56 <adrianschmutzler> afair it was agreed to keep ar71xx around till after 20.xx is released (or even until 19.07 is EOL?)
Jun 15 22:01:12 <karlp> adrianschmutzler: well aware, I tipped ~150 ath25 devices into a skip few months ago.
Jun 15 22:02:52 <aparcar[m]> Noltari: Hi are you around?
Jun 15 22:02:53 <adrianschmutzler> what's the meaning of that phrase "tip into a skip"?
Jun 15 22:03:37 <karlp> threw out.  a skip is a word for a big open container at a dump/recyling yard
Jun 15 22:03:56 <aparcar[m]> Noltari: can you explain why bcm63xx imply "adds" smp.mk to the generic profiles resulting in duplicate images for the same devices
Jun 15 22:04:42 <aparcar[m]> adrianschmutzler: okay good to know regarding ar71xx
Jun 15 22:05:44 <adrianschmutzler> karlp: k
Jun 15 22:07:17 <adrianschmutzler> aparcar[m]: but ar71xx is source-only since shortly after 19.07 was branched, so for master you just don't have to care.
Jun 15 22:07:32 <adrianschmutzler> ... as far as images are concerned
Jun 15 22:08:12 <adrianschmutzler> but my argument was not limited to ar71xx vs. ath79, it's just probably that something similar will happen in the future
Jun 15 22:08:25 <adrianschmutzler> probably->probable
Jun 15 22:10:05 <owrt-snap-builds> build #461 of oxnas/ox820 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/461
Jun 15 22:14:23 <aparcar[m]> adrianschmutzler: how about disabling it for releases then? You mentioned before that ath79 was a "stable beta test" which sounds like something to avoid. I see that betas are important and better than just telling someone to install a snapshot, however sneaking that into stable releases?
Jun 15 22:14:41 <aparcar[m]> * it = targets in file names
Jun 15 22:16:15 <adrianschmutzler> aparcar[m]: for 20.xx, we will only include what's on kernel 5.4, so ar71xx (and all other targets on 4.14) will be removed from the stable branch after branched
Jun 15 22:17:18 <adrianschmutzler> while for 19.07, with ath79 itself ready but only less than half of the devices from ar71xx, it was reasonable IMO to include both.
Jun 15 22:17:25 <aparcar[m]> sure great
Jun 15 22:18:00 <aparcar[m]> sorry that came out one message to late
Jun 15 22:18:01 <adrianschmutzler> So, current ar71xx is only relevant for backporting, and you just don't have to care about it at all for anything after 19.07
Jun 15 22:18:46 <adrianschmutzler> I also always skip it when doing treewide changes
Jun 15 22:20:14 <adrianschmutzler> btw: last time I removed targets, I didn't move them to targets.git, as that's rather pointless without the rest of the openwrt tree
Jun 15 22:20:19 <aparcar[m]> Say we clean up bcm63xx because it turns out we don't actually need two images for a single device, drop ath25, rename x86/generic to x86/32 and rename the profiles to generic_<target/subtarget>, would there be any additional issues?
Jun 15 22:20:38 <aparcar[m]> From my understanding you can add remote targets
Jun 15 22:20:57 <adrianschmutzler> Yes, because a similar situation like ar71xx/ath79 can arise at any moment
Jun 15 22:22:06 <adrianschmutzler> just image Noltari merging https://github.com/openwrt/openwrt/pull/2957
Jun 15 22:22:10 <adrianschmutzler> image->imagine
Jun 15 22:22:17 <aparcar[m]> but ideally not within a stable release right?
Jun 15 22:22:56 <adrianschmutzler> Why not? It may be desirable to make both available to people, and have them choose their speed to adopt
Jun 15 22:23:33 <adrianschmutzler> Despite, you also have to think of all the downstream, which might be interested in taking either to old or the new target depending on their preferences
Jun 15 22:23:45 <adrianschmutzler> it can both be "stable"
Jun 15 22:24:49 <adrianschmutzler> I'm deeply convinced we should have the ability to provide the same device with different architectures if necessary
Jun 15 22:25:09 <adrianschmutzler> unless there is a very good reason not to. And I don't see that reason
Jun 15 22:26:48 <adrianschmutzler> there will always be a way to force the repo to fulfill the "unique profile" concept, it's not the question whether we can, but whether we should. And I just don't think we should
Jun 15 22:27:14 <aparcar[m]> Just as a checkpoint, right now we talk more of "should the same device be supported by multiple, probably legacy, architectures, within releases and snapshots"and not about "target in filenames".
Jun 15 22:27:28 <aparcar[m]> Which seems important
Jun 15 22:28:33 <adrianschmutzler> "should it _be possible_ to support the same device ..."
Jun 15 22:28:47 <aparcar[m]> right
Jun 15 22:30:06 <adrianschmutzler> of course, it's simpler to discuss the image name itself, as e.g. downstream won't care much about that. while downstream would be interested in which targets we make available. The images can be easily renamed in contrast.
Jun 15 22:30:46 <aparcar[m]> and I think it does make sense withn snapshots. I'm guessing that bmips eventually replaces bcm63xx due to device tree support so both should be available in master until bmips is considered stable and supports all devices of bcm63xx. however for a stable release it does seem like a waste of resource to keep them both updated?
Jun 15 22:30:47 <adrianschmutzler> However, my argument here is the same: Removing the target for the name seems to be a bigger disadvantage to me that the benefit we get from it.
Jun 15 22:31:32 <adrianschmutzler> I don't think that can be answered in such a general manner.
Jun 15 22:31:49 <aparcar[m]> Sorry I wasn't clear, I don't think of filenames right now but of multiple images in a release
Jun 15 22:32:56 <adrianschmutzler> I can't tell the future, I just see that there is a chance both will be there.
Jun 15 22:33:44 <adrianschmutzler> But anyway, I don't think you will convince me at this point. The question will be whether somebody else has an opinion in this context.
Jun 15 22:35:29 <aparcar[m]> Okay let's leave it for now :)
Jun 15 22:35:44 <adrianschmutzler> I will leave now anyway, it's bedtime
Jun 15 22:35:51 <adrianschmutzler> bye
Jun 15 22:37:23 <aparcar[m]> bye bye sleep well
Jun 16 02:34:21 <lmore377> i have my firmware flash and everthing's good now, but sysupgrade fails because it can't find the firmware mtd device. the router has nand flash so im using ubi as the main mtd name. do i need to define something somewhere that tells sysupgrade how to update?
Jun 16 02:34:32 <lmore377> flashed*
Jun 16 02:40:37 <pkgadd> yes, https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/base-files/lib/upgrade/platform.sh;hb=HEAD
Jun 16 02:41:09 <lmore377> oh thanks
**** ENDING LOGGING AT Tue Jun 16 03:06:37 2020