Quoting Christopher Obbard (2023-07-05 18:16:45) > On Tue, 2023-07-04 at 17:06 +0200, Jonas Smedegaard wrote: > > 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? Oh, indeed, there is a shitty file at the root of the filesystem.
Looks like the packaging already installs another file with different access rights, and the upstream udev file should be ignored - so perhaps my patch is wrong and instead (assuming from the comment above it) that whole section should simply be removed or commented out instead. > > 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. A version number is for aligning releases on a timeline. A git hash serves a different purpose. Please do not bloat version strings by adding useless vanity strings to it - mention in the changelog entry which git hash a new snapshot corresponds to, but avoid embedding it in the version number. Others in Debian use vanity strings as well (and I've done so in the past too), but I disagree that it is standard. If you really think that it is standard* to include git hash in version strings, then please point to where that standard is defined. I don't think we have strict rules about this, but did find this which agrees with me in advicing against including git hash in version string: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#name-version > If upstream [...] uses [...] a VCS hash value as part of the version, > make sure to remove them from the upstream version. Such information > can be recorded in the debian/changelog file. If you need to invent a > version string, use the YYYYMMDD format such as 20110429 as upstream > version. This ensures that the dpkg command interprets later versions > correctly as upgrades. If you need to ensure a smooth transition to a > normal version scheme such as 0.1 in the future, use the 0~YYMMDD > format such as 0~110429 as upstream version, instead. > Would you be able to start another email thread about [rockusb] > (possibly in a new WNPP bug?) to not pollute this bug. Sure. - 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
signature.asc
Description: signature
