Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Tobias. Am Donnerstag, dem 14.03.2024 um 17:20 +0100 schrieb Tobias Frost: > - $2 might be empty, you need to quote it: use "$2" otherwise dpkg will fail That was a stupid one, thanks. Fixed and uploaded. Sincerely, Joachim
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Joachim && dpkg --compare-versions $2 le-nl 0.8.3 \ && dpkg --compare-versions $2 ge 0.8.2; then - $2 might be empty, you need to quote it: use "$2" otherwise dpkg will fail: $ dpkg --compare-versions $empty le-nl 0.8.3 dpkg: error: --compare-versions takes three arguments: Type dpkg --help for help about installing and deinstalling packages [*]; Use 'apt' or 'aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through 'less' or 'more' ! -- tobi
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags -1 moreinfo Hi Joachim approaching upload :) beside the remark on postinst below, packaging is looking good already. d/copyright: - minor thing, please write in d/copyright "GPL-3.0-or-later" as license indicator, as this makes it clearer. - the debian/ directory - change the year to 2023-2024 -modules/GetGitRevisionDescription.cmake* is undocumented and licensed under modules/GetGitRevisionDescription.cmake (copyright review done) On Thu, Mar 07, 2024 at 06:02:56AM +0100, Joachim Zobel wrote: > Control: tags -moreinfo > > Hi Tobias. > > Thanks for looking into the package. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > d/source/lintian-overrides > > - delete the overrides, seems to be some remnant of earlier packaging. > > > > d/DEBIAN_RELEASE.txt > > - delete this file; the information contained in this files would not > >be a process how to create a package for Debian. (and if you need a > >file describing certain unusal aspects of the Debian packaging, it > >would be README.source (see Debian Policy §4.14) > >I recommend checking out git-buildpackage: > >https://honk.sigxcpu.org/piki/projects/git-buildpackage/ > >https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ > >- remove Debian_release.patch -- this is not needed, you work with > >your debian/ directory and evolve it, you do not patch it when you > >create a new version. > > > > d/control > > - specify Rules-Require-Root > > - you manually depend on libsml1. Can you expand why this is needed? > > - Build-Depend: s/pkg-config/pkgconf > > - remove versions from the versioned build dependencies, if the > >debpendency is already fulfilled in oldstable: > >- libjson-c-dev, libcurl4-openssl-dev, > > > > > > d/postinst / postrm > > - When you create a user, it should start with "_" - see policy 9.2.1 > >- Another option might be using systemd's DynamicUser feature to > > create the user at runtime. (bonus: some hardening for free.) > >- there's systemd-sysuser (works also without systemd as init system) > > to use sysusers.d > >- do not delete users/groups on package removal. > > All changes have been done. In addition the repository has been moved > to DEP-14 layout. Thanks! I see that you've decided to migrate the user. However, you should do so only when the package is upgraded from an old version, which had the old name, to avoid collisions down the road. your postinst needs a conditional based on the old version, (which is be passed to postinst.) Those might be helpful: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html# https://www.debian.org/doc/debian-policy/ap-flowcharts.html deb-postinst(5) Example for how to check for the required version using dpkg --compare-version: https://codesearch.debian.net/show?file=pam-pgsql_0.7.3.2-1%2Fdebian%2Fpostinst&line=32 -- tobi signature.asc Description: PGP signature
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags -moreinfo Hi Tobias. Thanks for looking into the package. Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > d/source/lintian-overrides > - delete the overrides, seems to be some remnant of earlier packaging. > > d/DEBIAN_RELEASE.txt > - delete this file; the information contained in this files would not >be a process how to create a package for Debian. (and if you need a >file describing certain unusal aspects of the Debian packaging, it >would be README.source (see Debian Policy §4.14) >I recommend checking out git-buildpackage: >https://honk.sigxcpu.org/piki/projects/git-buildpackage/ >https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ >- remove Debian_release.patch -- this is not needed, you work with >your debian/ directory and evolve it, you do not patch it when you >create a new version. > > d/control > - specify Rules-Require-Root > - you manually depend on libsml1. Can you expand why this is needed? > - Build-Depend: s/pkg-config/pkgconf > - remove versions from the versioned build dependencies, if the >debpendency is already fulfilled in oldstable: >- libjson-c-dev, libcurl4-openssl-dev, > > > d/postinst / postrm > - When you create a user, it should start with "_" - see policy 9.2.1 >- Another option might be using systemd's DynamicUser feature to > create the user at runtime. (bonus: some hardening for free.) >- there's systemd-sysuser (works also without systemd as init system) > to use sysusers.d >- do not delete users/groups on package removal. All changes have been done. In addition the repository has been moved to DEP-14 layout. Sincerely, Joachim
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
On Tue, Feb 27, 2024 at 06:50:56AM +0100, Joachim Zobel wrote: > Hi. > > Thanks for taking the time to review my package. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > d/postinst / postrm > > - When you create a user, it should start with "_" - see policy > > 9.2.1 > This has been implemented and is on its way, see > https://github.com/volkszaehler/vzlogger/pull/628 > > It was a bit complicated because I need to rename an existing user. > There are installations of the existing native package. I am therefore > unsure if it is good to do this. Going by the letter which is > "When maintainers choose a new hardcoded or dynamically generated > username" the username has already been choosen when the > debian/vzlogger.init script was created. > > Since it is a now or never situation and since the number of existing > installations is still low I tend to rename the user. Any opinions are > appreciated. If you think the existing user base is large enough, you can also migrate the username, if you detect in your postinst script that you are upgrading from an version with the old username. (This code could then be dropped in trixie+1, assuming the package will be in trixie, of course) > Sincerely, > Joachim >
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Joachim, On Sat, Feb 24, 2024 at 06:37:02PM +0100, Joachim Zobel wrote: > Hi. > > I'll reply to the DEP-14 issue while working on the others. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > > https://github.com/volkszaehler/vzlogger.git > > > > > > on branch debian-0.8.3-1. > > > > (There is no such branch on that repo, but a "debian" one.) > > Sorry, forgot to merge that. > > > Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for > > recommendation how to layout the repository used for packaging, I'd > > even recommend to use an extra repository for the packaging. > > I know about DEP-14 and actually tried it. I found it however very > inconvenient to use and I think this is because it is inappropriate for > the current situation. Sorry, I don't get what you mean. Why is it inappropiate? Putting DEP14 (branch names[1]) aside, Debian packagaing is supposed to be "linear", you work on a package, upload it, and the next iteration you base your work on the already uploaded version. It makes no sense to have a branch for every Debian package revision, because once it has been uploaded it will become immuteable, you cannot reupload the same revesion, the upload will be rejected. We *tag* Debian package releases to mark them, and when the next one is ready, it will be based on the old revision, so it is more natural to continue on that branch. Also, you are supposed to note the branch in VCS-Git where packaging is happening, and this is _a_ branch (that's singular!), see the Debian Policy for extra reasoning. [1] which are only getting important if you need to manage different Debian release suites or backports on top. the scheme /, e.g debian/unstable is meant to aid here. note: you cannot have branches "debian" _and_ "debian/$suite", because git won't allow that. If you use "debian" as branch, this will make it harder to deploy DEP14 later. > The package is maintained in the upstream repository as a native > package (by me). This is necessary because Debian packages are built as > part of the upstream releases. So all packaging changes happen upstream > first. If you are in control of upstream packaging, well, frankly, than you are in control to do things propoerly upstream. The first thing is: stop building native packages. Native packages are the wrong approach 99% of the time. [2] This will also save you a lot of time, you won't need to maintain two flavours. (As Debian packages need to follow Debian rules and not upstream rules, a native package will not be acceptable for Debian.) The upstream guide discourages to have a debian/ directory in the upstream main branch [3], but if you do, and base your packaging on it. Having a debian directory in "main" and another branch, especially if they are divereged, will only confuse people. (and they might to need to work on your package, e.g if there is a need for an NMU.) So pick one. [2] https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F You should only use a native Debian package when it is clear that the package would not be useful outside the context of a Debian system, and would never be distributed except packaged for Debian or its derivatives. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native [3] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source, third paragraph. > The changes that are later needed to turn an upstream native > release into a Debian release are few and won't change much over time. > So a patch makes sense IMHO. As said, native is wrong anyways, but the packaging directory should be orthogonal to the upstream version, as the upstream version needs also to work on non-Debian systems, don't they? > This situation can change when vzlogger reaches stable (and as a result > reaches Raspbian). At that point maintaining a package in the upstream > repo is no longer necessary. This sounds wrong. Either you package in an dedicated repository, or you don't. That is orthogonal to whether the package is in Debian or not. > For now I would prefer to use the suggested release workflow (which I > am already using for libsml, where the situation is the same). tracker.d.o is unhappy: "The VCS repository is not up to date, push the missing commits." Your process breaks tooling in Debian. It is broken. > I am > aware that the DEP-14 layout works well if upstream is not doing > package maintenance and I am not generally against it. It is not significant for DEP-14 whether upstream is doing package maintaince or not. In your instance, you are in control of the upstream repository, so you *can* change things. In situations where this is not possible, we'd ignore the debian/ directory from upstream completly. My other current > ITP #1062335 i
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi. Thanks for taking the time to review my package. Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > d/postinst / postrm > - When you create a user, it should start with "_" - see policy > 9.2.1 This has been implemented and is on its way, see https://github.com/volkszaehler/vzlogger/pull/628 It was a bit complicated because I need to rename an existing user. There are installations of the existing native package. I am therefore unsure if it is good to do this. Going by the letter which is "When maintainers choose a new hardcoded or dynamically generated username" the username has already been choosen when the debian/vzlogger.init script was created. Since it is a now or never situation and since the number of existing installations is still low I tend to rename the user. Any opinions are appreciated. Sincerely, Joachim
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi. I'll reply to the DEP-14 issue while working on the others. Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > https://github.com/volkszaehler/vzlogger.git > > > > on branch debian-0.8.3-1. > > (There is no such branch on that repo, but a "debian" one.) Sorry, forgot to merge that. > Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for > recommendation how to layout the repository used for packaging, I'd > even recommend to use an extra repository for the packaging. I know about DEP-14 and actually tried it. I found it however very inconvenient to use and I think this is because it is inappropriate for the current situation. The package is maintained in the upstream repository as a native package (by me). This is necessary because Debian packages are built as part of the upstream releases. So all packaging changes happen upstream first. The changes that are later needed to turn an upstream native release into a Debian release are few and won't change much over time. So a patch makes sense IMHO. This situation can change when vzlogger reaches stable (and as a result reaches Raspbian). At that point maintaining a package in the upstream repo is no longer necessary. For now I would prefer to use the suggested release workflow (which I am already using for libsml, where the situation is the same). I am aware that the DEP-14 layout works well if upstream is not doing package maintenance and I am not generally against it. My other current ITP #1062335 is using it. https://salsa.debian.org/debian-iot-team/tasmota-device-manager Sincerely, Joachim
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags -1 moreinfo Hi Joachim, review based on the dsc containing: Checksums-Sha256: 75aa7ed495b21d360340c84a4def6e16e25ecc36dab91e2481631993b2624bde 5128639 vzlogger_0.8.3.orig.tar.gz c6737877696173e8daa4c9e4d4a1b6663ae5256f669c87554360e665f154e292 6252 vzlogger_0.8.3-1.debian.tar.xz It is only a partial review, especially I did not do a d/copyright review yet. Please check my remarks and remove the moreinfo tag when ready. On Tue, Feb 20, 2024 at 12:34:04PM +0100, Joachim Zobel wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "vzlogger": > > * Package name : vzlogger > Version : 3.1-4 > Upstream contact : Joachim Zobel > * URL : http://wiki.volkszaehler.org/software/controller/vzlogger > * License : GPL-3 > * Vcs : https://github.com/volkszaehler/vzlogger > Section : net > > The source builds the following binary packages: > > vzlogger - program to read measurements from smart meters and log them > to Influxdb or forward them via MQTT. > > vzlogger is a tool to read and log measurements of a wide variety of > smart meters and sensors. It supports various commonly used protocols > such as s0, d0, sml, oms and others. It can write these data to an > Influxdb, forward them via MQTT, make them available via HTTP or eport > them to a volkszaehler.org middleware. > > The package is maintained in the upstream repository. Upstream (which I > am part of) currently builds native packages. These are patched (a > switch from native to quilt, a different changelog and a version >= 3.0 > for the dependency on openssl) to make them more suitable for debian. > The package is therefore availabe in the upstream repo Yeah, format 3.0 quilt is the way, it is not a native package. > https://github.com/volkszaehler/vzlogger.git > > on branch debian-0.8.3-1. (There is no such branch on that repo, but a "debian" one.) Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for recommendation how to layout the repository used for packaging, I'd even recommend to use an extra repository for the packaging. > Alternatively, you can download thepackage with 'dget' using this > command: > > dget -x > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc > > Regards, > -- > Joachim Zobel As you are upstream: https://wiki.debian.org/UpstreamGuide d/source/lintian-overrides - delete the overrides, seems to be some remnant of earlier packaging. d/DEBIAN_RELEASE.txt - delete this file; the information contained in this files would not be a process how to create a package for Debian. (and if you need a file describing certain unusal aspects of the Debian packaging, it would be README.source (see Debian Policy §4.14) I recommend checking out git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/ https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ - remove Debian_release.patch -- this is not needed, you work with your debian/ directory and evolve it, you do not patch it when you create a new version. d/control - specify Rules-Require-Root - you manually depend on libsml1. Can you expand why this is needed? - Build-Depend: s/pkg-config/pkgconf - remove versions from the versioned build dependencies, if the debpendency is already fulfilled in oldstable: - libjson-c-dev, libcurl4-openssl-dev, d/postinst / postrm - When you create a user, it should start with "_" - see policy 9.2.1 - Another option might be using systemd's DynamicUser feature to create the user at runtime. (bonus: some hardening for free.) - there's systemd-sysuser (works also without systemd as init system) to use sysusers.d - do not delete users/groups on package removal. As you are involved with upstream: The manpage, initfile, systemd service file should probably be included in the upstream part, it is not only useful for Debian alone. Linitian emits: W: vzlogger source: build-depends-on-obsolete-package Build-Depends: pkg-config (>= 0.25) => pkgconf W: vzlogger: groff-message troff::5: warning: cannot select font 'CB' [usr/share/man/man8/vzlogger.8.gz:1] I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:12] I: vzlogger: file-references-package-build-path [usr/bin/vzlogger] I: vzlogger: file-references-package-build-path [usr/lib/static/libvz.a] I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] I: vzlogger: hardening-no-fortify-functions [usr/bin/vzlogger] I: vzlogger: systemd-service-file-missing-documentation-key [usr/lib/systemd/system/vzlogger.service] I: vzlogger source: unused-override odd-historical-debian-changelog-version *0.3.4-rc1* [debian/source/lintian-overrides:2] P: vzlogger source: capitalization-in-override-comment odd-historical-debian-changelog-version debian Debian [debian/source/lintian-overrides:1] P: vzlogger source: silent-on-rules-requiring-root [debian/c
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "vzlogger": * Package name : vzlogger Version : 3.1-4 Upstream contact : Joachim Zobel * URL : http://wiki.volkszaehler.org/software/controller/vzlogger * License : GPL-3 * Vcs : https://github.com/volkszaehler/vzlogger Section : net The source builds the following binary packages: vzlogger - program to read measurements from smart meters and log them to Influxdb or forward them via MQTT. vzlogger is a tool to read and log measurements of a wide variety of smart meters and sensors. It supports various commonly used protocols such as s0, d0, sml, oms and others. It can write these data to an Influxdb, forward them via MQTT, make them available via HTTP or eport them to a volkszaehler.org middleware. The package is maintained in the upstream repository. Upstream (which I am part of) currently builds native packages. These are patched (a switch from native to quilt, a different changelog and a version >= 3.0 for the dependency on openssl) to make them more suitable for debian. The package is therefore availabe in the upstream repo https://github.com/volkszaehler/vzlogger.git on branch debian-0.8.3-1. Alternatively, you can download the package with 'dget' using this command: dget -x http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc Regards, -- Joachim Zobel