Discussion:
Bug#944323: RFS: piper/0.3-1 [ITP] -- graphical frontend for libratbag
Add Reply
Stephan Lachnit
2019-11-08 10:10:02 UTC
Reply
Permalink
New version 0.3-2 with ratbagd depedency fix and added Rules-Requires-Root.

Stephan
Stephen Kitt
2019-11-08 10:30:01 UTC
Reply
Permalink
Hi Stephan,
I am looking for a sponsor for my package "piper"
I noticed a few of problems which need to be fixed:

* you need python3-dev in the build-dependencies instead of python3
(as-is, the package doesn’t build in a clean build chroot)
* your changes in -2 shouldn’t increment the package version, since
there hasn’t been an upload to the archive yet — you’re still in the
process of getting -1 ready, effectively (and it’s all still the
“initial packaging”)
* the ratbagd dependency should be (>= 0.10-1), greater than rather
than equal, otherwise the piper package ends up too closely tied to
libratbag (0.10-2 would break the dependency, as would the
forthcoming 0.11-1); in fact switching to >= means you can even drop
the package revision, and write (>= 0.10)

I noticed that your git repo only has a single branch. I find it
better in the long run to maintain an upstream branch with the
upstream code (which can effectively be the upstream master branch,
directly), and the Debian packaging in a separate branch. Check out
https://dep-team.pages.debian.net/deps/dep14/ for one possible
layout.

Regards,

Stephen
Stephan Lachnit
2019-11-08 15:00:02 UTC
Reply
Permalink
Post by Stephen Kitt
you need python3-dev in the build-dependencies instead of python3
(as-is, the package doesn’t build in a clean build chroot)
This give me the following lintian warning:
build-depends-on-python-dev-with-no-arch-any

However I don't really get what the difference between python3-dev and python3 is, the lintian tag entry doesn't really help.
Post by Stephen Kitt
the ratbagd dependency should be (>= 0.10-1), greater than rather
than equal, otherwise the piper package ends up too closely tied to
libratbag (0.10-2 would break the dependency, as would the
forthcoming 0.11-1); in fact switching to >= means you can even drop
the package revision, and write (>= 0.10)
What I tried to do with my initial (=0.10) was to let every 0.10 version work, so 0.10-1 and 0.10-2, however this doesn't work. I tried to bind piper to a specific ratbagd version because the Wiki states that ratbagd API is not stable.

I uploaded a new version with the right debian version and your suggestions.
I know I have to update the git workflow, will do that in the future.

Regards,
Stephan
Stephen Kitt
2019-11-09 20:10:03 UTC
Reply
Permalink
On Fri, 08 Nov 2019 14:47:41 +0000, Stephan Lachnit
Post by Stephan Lachnit
Post by Stephen Kitt
you need python3-dev in the build-dependencies instead of python3
(as-is, the package doesn’t build in a clean build chroot)
build-depends-on-python-dev-with-no-arch-any
However I don't really get what the difference between python3-dev and
python3 is, the lintian tag entry doesn't really help.
Right, python3 is the interpreter only, python3-dev adds a number of files
which are necessary to build Python modules. I suspect that Piper doesn’t
need python3-dev, and its meson.build could be changed to avoid that
build dependency...
Post by Stephan Lachnit
Post by Stephen Kitt
the ratbagd dependency should be (>= 0.10-1), greater than rather
than equal, otherwise the piper package ends up too closely tied to
libratbag (0.10-2 would break the dependency, as would the
forthcoming 0.11-1); in fact switching to >= means you can even drop
the package revision, and write (>= 0.10)
What I tried to do with my initial (=0.10) was to let every 0.10 version
work, so 0.10-1 and 0.10-2, however this doesn't work. I tried to bind
piper to a specific ratbagd version because the Wiki states that ratbagd
API is not stable.
OK, to do something like that you’d depend on “ratbatgd (>= 0.10), ratbagd
(<< 0.11)”. I’m not sure that’s the best approach: you’d end up having to
upload a new version of Piper every time a new upstream version of ratbagd
was released (e.g. 0.11 which is now in the archive).

I’d go for a different approach: if ratbagd changes in an incompatible way,
since it doesn’t provide API guarantees, then it should be in charge of
keeping track of that. Technically, that would mean that an incompatible
version of ratbagd would declare that it breaks the relevant versions of
Piper, which would ensure that users wouldn’t upgrade if they have an
incompatible version of Piper.

With the latter approach, non-breaking versions of ratbagd can be uploaded
without requiring a new upload of Piper. If ratbagd breaks Piper, upstream
will release a new version of Piper anyway, which would require an upload.
Post by Stephan Lachnit
I uploaded a new version with the right debian version and your suggestions.
I know I have to update the git workflow, will do that in the future.
OK, thanks!

If you don’t have anything left to do on the package, I can upload it for
you, and create the repository on Salsa in the debian namespace.

Regards,

Stephen
Stephan Lachnit
2019-11-10 16:30:02 UTC
Reply
Permalink
Post by Stephen Kitt
Right, python3 is the interpreter only, python3-dev adds a number of files
which are necessary to build Python modules. I suspect that Piper doesn’t
need python3-dev, and its meson.build could be changed to avoid that
build dependency...
Will try it out and send a patch to upstream.
Post by Stephen Kitt
With the latter approach, non-breaking versions of ratbagd can be uploaded
without requiring a new upload of Piper. If ratbagd breaks Piper, upstream
will release a new version of Piper anyway, which would require an upload.
Sounds good to me.
Post by Stephen Kitt
If you don’t have anything left to do on the package, I can upload it for
you, and create the repository on Salsa in the debian namespace.
I'm finished with it. Latest version on mentors from today is the same as the last one, the one in between was just a test for me.
Just one more technical question about maintaining the package: how exactly is this going to work? I guess it's not done by just updating/tagging the git repo.

Regards,
Stephan
Stephan Lachnit
2019-11-16 12:50:02 UTC
Reply
Permalink
Jonathan Carter pointed out, that I didn't add file specific copyright information in the copyright file. I uploaded a new version to mentors.

Regards,
Stephan
Stephan Lachnit
2019-11-19 21:00:02 UTC
Reply
Permalink
Right, that’s a good idea. I’ve uploaded the package now, it’s on its way to
the NEW queue! I’ll address your previous questions later.
The package is up, and already in Ubuntu as well! Thanks for the upload!
I also got the python3-dev build dependency removed in upstream, and some simplifications for the copyright are also on their way, which makes the next release a little bit cleaner.

Regards,
Stephan

Loading...