On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
On Thu, 20 Apr 2023 at 11:28, Roger Shimizu <rosh@debian.org> wrote:
On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
On Wed, 19 Apr 2023 at 10:06, Roger Shimizu <rosh@debian.org> wrote:
On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
On Tue, 18 Apr 2023 at 21:36, Roger Shimizu <rosh@debian.org> wrote:
Hello Roger, FTP masters,
Short story: the uploaded linux-board-support-package-dragonboard845c package (currently in NEW) contains a file with unclear license background and as such it should not be allowed into the archive.
The orig.tar.gz file needs to be repackaged before uploading.
I tried to repack the orig, and re-upload, but got REJECTED by:
linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc:
Does not match file already existing in the pool.
Usually one would use suffix like -dfsg to mark the repacked package.
The -dfsg doesn't make sense in the case of a non-free package, so you
can probably use -repack.
Yes, but upstream uses .zip archive anyhow.
So we have to repack to .orig.tar.*
To notify possible users that it's not just a repack of zip, but also
More importantly I'm not sure that this package should be a part of
Debian at all.
Why?
Without bootloader part, we cannot support installer in Debian.
This bootloader is already installed by the manufacturer. Please
consider these partitions as a firmware. One does not modify the
device firmware during Debian installation.
Maybe I misunderstand something about the usecase you are facing.
Could you please describe it?
RB3 is an open platform.
You do not know what system user previously installed.
Yes, that's the point. It could have been customized by the user.
I always hated some W operating system rewriting the MBR
unconditionally and really liked the way Debian asks user if this is a
desired theing.
With prompting user, your concern can be resolved.
And even Linaro provided two different system, with different
partition layouts, aosp and linux:
- https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/
And usually they differ only in the partitioning scheme, in GPT data.
So. Repartitioning the UFS sounds correct to me. Reflashing the
bootloader doesn't sound good.
I'm not sure why you suppose the bootloader has to be original.
I suppose that it's not a task of the DI to update the bootloader.
For linaro's image, if user want to switch between AOSP (Android) and
Debian, the bootloader has to be flashed.
So I think the logic for D-I should be the same.
Any way, it's out of scope of this ticket. Let's discuss more when
integrating to D-I.
Linaro's rescue image also rewrite those partitions.
I think Debian should do the same.
My current understanding:
- The device comes from the factory with the bootloaders flashed
- DI repartitions one of UFS LUNs to replace vendor+system+userdata
with the rootfs/home/etc
- DI installs all the packages to the target rootfs, including the
package with custom kernel hooks
- the kernel hooks write the generated android boot img to the boot partition
Is there anything else?
Anyway, this is not for this ITP ticket. We can discuss when porting
to installer.
Sure. Please ping either me directly or the linux-arm-msm mailing list
when you'd like to discuss it. Getting DI to work on these boards
would be a very welcomed and appreciated both by our group and by the
overall community.
Thanks for your understanding!
I doubt that DI should touch these partitions. Firstly, because of the
reasons I expressed in my previous email (risk of bricking the board,
custom bootloaders being used on these devboards, etc).
Secondly, I'd like to point out that RB3/RB5 (and other dragonboards)
are in a pretty unique position. Other development boards (QRD, HDK,
Open-Q, etc.) do not have public redistributable bootloader archives.
No worries about the brick issue.
Actually, no. Bricking the device during installer is a very bad thing.
I said no worries, because we need to fix those issue when porting to installer.
This is ITP ticket, and we need to be focus on packaging firmware first.
I checked other bootloaders (lilo, syslinux, grub, etc). All of them
push data to /usr/lib/something. I think this approach should be
adopted by your packages.
Other bootloaders are not non-free, and can be built by debian infrastructure.
For non-free bootloader, I think we need to treat them as firmware.