Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

2024-02-20 Thread Joachim Zobel
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



Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

2024-02-22 Thread Tobias Frost
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

2024-02-24 Thread Joachim Zobel
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

2024-02-26 Thread Joachim Zobel
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

2024-03-02 Thread Tobias Frost
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

2024-03-02 Thread Tobias Frost
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

2024-03-06 Thread Joachim Zobel
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

2024-03-10 Thread Tobias Frost
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

2024-03-14 Thread Tobias Frost
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

2024-03-16 Thread Joachim Zobel
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