Re: Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork
Hi Jonas,
On Tue, 2023-07-04 at 17:06 +0200, Jonas Smedegaard wrote:
> Hi Cristopher,
>
> Quoting Christopher Obbard (2023-07-04 16:01:19)
> > On Sat, 2023-07-01 at 11:07 +0200, Jonas Smedegaard wrote:
> > > I own a PineNote, and use rkdeveloptool for flashing software onto it,
> > > but have found the code in Debian to be inferior for that use.
> > >
> > > Please consider switching to the (slightly) newer fork done by Pine64,
> > > which fixes some bugs and improves the user interface, while seemingly
> > > fully preserving backwards compatibility:
> > > https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool
> > >
> > > What I use now is a fork of this package, maintained here:
> > > https://salsa.debian.org/js/rkdeveloptool
> > >
> > > If you like, I can push that into the official Salsa packaging git -
> > > or you can cherry-pick the bits you like from it, of course. :-)
> >
> > I'm fine with picking your patches to the packaging and changing the
> > upstream source to this (backwards-compatible) version & uploading a new
> > version.
> >
> > One question is what do we do about the version? Currently we are tracking
> > the upstream source from rockchip https://github.com/rockchip-linux/rkdeveloptool which
> > is at version 1.32+git20210408.46bb4c0 but the Pine64 version is at currently tagged at
> > version 1.1.0 which is much lower. I wonder if I should do something like tag the new
> > upstream source version with an epoch, like 2:1.1.0 ?
> >
> > The policy states that prepending an epoch to a pacakge version needs some
> > additional consensus from debian-devel:
> > > You should not change the epoch, even in experimental, without getting
> > > consensus on debian-devel first.
> >
> > so I have therefore CC the list to this bug, to see if my thinking is correct :-)
>
> Since none of these forks apparently is actively developed, I suggest to
> not take any strong action like introducing an epoch, but instead simply
> add a + to indicate that current situation is a mess - which it is:
>
> 1.32+pine64.20210904
Right, I have done this and pushed my (unreleased) changes to https://salsa.debian.org/debian/rkdeveloptool/-/commits/wip%2Fobbardc%2Fpine64
Lintian complains about the following in my unstable pbuilder:
E: rkdeveloptool: non-standard-toplevel-dir [rules.d/]
W: rkdeveloptool: file-in-unusual-dir [rules.d/99-rk-rockusb.rules]
I think it is because in meson.build udev.get_pkgconfig_variable is returning false for udevdir, and the
udev rules aren't being installed into the correct location.
udev_rules_dir = udev.get_pkgconfig_variable('udevdir') + '/rules.d'
Did you have this issue? Do you have any hints, maybe you could add a fix into your patches file?
> Also, I do not recommend to include a git hash, because that is not
> sortable like a date is. If you ever need to release twice on same day
> then simply add a .1 suffix.
I think the git hash is quite nice as it shows where the upstream source actually
came from. This seems to be a standard all around Debian, is there any official
notes/guidance you can point me to or is this mainly down to developer choice?
In any case, for this package, I doubt that upstream will release twice on the same
day, given that there hasn't been much movement since 2021 ;-). I will be careful to
make sure I consider this in future.
>
> > Note that also we have written a replacement tool in Rust called rockusb
> > (which allows you to write an image with holes to the device, which can
> > speed up the flashing), packaging this in Debian is also on my the wishlist:
> > https://github.com/collabora/rockchiprs/tree/main
>
> Ohh, that looks very nice!
>
> D you prefer to package that yourself? I am on a
> package-cool-rust-stuff frenzy and can offer to do the packaging of that
> tool if you like. Then we can maintain it together, but easiest for me
> is that I simply do the bootstrapping myself.
I would love to do more Rust packaging in Debian, but I really am out of time
to do that work currently. I looked at the dependency tree and it seems like
it would be a number of packages.
I am able to help maintain the additional package(s).
Would you be able to start another email thread about that (possibly in a new
WNPP bug?) to not pollute this bug.
Thanks!
Chris
Reply to: