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
