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 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. > 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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature