Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
On Thu, 14 Oct 2021 at 00:33:44 +0100, Christian Rauch wrote: > I am not familiar with the processes and timelines in Debian. It appears > that "libdecor-0" is stuck in this queue for 2 months and other packages > are waiting for far longer. Yes, it's waiting for legal checks from the archive administrators. > Is there a timeline for when packages are scheduled for upload to the > respective package archives (e.g. experimental in this case) There is no fixed timeline, we just have to wait for someone with the right permissions to get round to reviewing it. smcv
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
Simon, thank you for uploading the package to the ftp. I am not familiar with the processes and timelines in Debian. It appears that "libdecor-0" is stuck in this queue for 2 months and other packages are waiting for far longer. Is there a timeline for when packages are scheduled for upload to the respective package archives (e.g. experimental in this case) or what unresolved issues are blocking the upload? Best, Christian Am 11.08.21 um 17:24 schrieb Simon McVittie: > Control: tags -1 + pending > Control: forwarded -1 https://ftp-master.debian.org/new.html > > On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote: >> "libdecor" is a library that can be used by Wayland clients to implement >> client-side window decorations. > > Initial package uploaded to NEW, now waiting for ftp team processing. > > I made some more packaging improvements before uploading: > https://salsa.debian.org/sdl-team/libdecor-0/-/commits/debian/latest/ > > smcv >
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
Control: tags -1 + pending Control: forwarded -1 https://ftp-master.debian.org/new.html On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote: > "libdecor" is a library that can be used by Wayland clients to implement > client-side window decorations. Initial package uploaded to NEW, now waiting for ftp team processing. I made some more packaging improvements before uploading: https://salsa.debian.org/sdl-team/libdecor-0/-/commits/debian/latest/ smcv
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
Thanks for the tip. I already updated the package names and licence information in the pull-request: https://salsa.debian.org/sdl-team/libdecor-0/-/merge_requests/1 Best, Christian Am 24.07.21 um 15:17 schrieb Dominique Dumont: > Hi > > I would suggest to use cme to generate debian/copyright file. > > See > https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme > > You can also try cme to fix small mistakes in debian package files. > > See > https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme > > HTH >
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
Hi I would suggest to use cme to generate debian/copyright file. See https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme You can also try cme to fix small mistakes in debian package files. See https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme HTH
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
On Fri, 23 Jul 2021 at 19:00:02 +0100, Christian Rauch wrote: > Am 23.07.21 um 11:35 schrieb Simon McVittie: > > Is the packaging you used in that Ubuntu PPA already available as a > > git tree? > > Yes. The ppa is using my "libdecor-packaging" repo [1] for the packaging > information. The ppa is merging the source tree and the packaging tree > to generate the packages daily. Thanks, I've pulled from there as a basis for an initial packaging repo: https://salsa.debian.org/sdl-team/libdecor-0 I would strongly prefer the git repo to be "source included", like the one for libsdl2 - that fits the policies of both the SDL and GNOME teams. > How should I update the package information according to your > suggestions? Shall I just update my packaging repo and you pull from it? > Or do you have to create a repo at salsa.debian.org and take pull > requests from me? Some of the changes I suggested will make it incompatible with the packages currently in your PPA (i.e. break upgrades), so it might be best to have a "clean break" between the PPA and the official Debian packaging, by forking https://salsa.debian.org/sdl-team/libdecor-0 on salsa.debian.org and doing new packaging work there. I can give you commit access to that packaging repo when we've got a bit further, but you'll need an account on salsa.debian.org first, and it might be best to do at least the first few changes as merge requests. smcv
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
Am 23.07.21 um 11:35 schrieb Simon McVittie: > Is the packaging you used in that Ubuntu PPA already available as a > git tree? Yes. The ppa is using my "libdecor-packaging" repo [1] for the packaging information. The ppa is merging the source tree and the packaging tree to generate the packages daily. > I'm in both teams and would be willing to > co-maintain. I can help to implement the suggestions below, or you > could do them, whichever you'd prefer. Thank you. I don't mind implementing your suggestions, while you take a look at the code. How should I update the package information according to your suggestions? Shall I just update my packaging repo and you pull from it? Or do you have to create a repo at salsa.debian.org and take pull requests from me? Best, Christian [1] https://gitlab.gnome.org/christian-rauch/libdecor-packaging
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote:
> I am already maintaining an Ubuntu ppa at:
> https://launchpad.net/~christianrauch/+archive/ubuntu/libdecoration
> but would like to upstream the package into Debian.
Is the packaging you used in that Ubuntu PPA already available as a
git tree?
> Since this is my first time packaging a library for Debian, I could use
> support from a co-maintainer who is familiar with Wayland
More important would be to have a co-maintainer who is familiar with
packaging shared libraries, I think. There are some subtleties that are
important to get right.
It would probably make sense for the SDL team and/or the GNOME team to
be in Maintainer and/or Uploaders for this package - SDL wants to use it,
and it comes from GNOME infrastructure and uses GNOME-adjacent libraries
and coding conventions. I'm in both teams and would be willing to
co-maintain. I can help to implement the suggestions below, or you
could do them, whichever you'd prefer.
I haven't yet reviewed the upstream code at all (except for the build
system MR), but a Debian Developer will need to do that before upload,
to check for legality/licensing issues and make sure the code isn't
malicious or obviously broken (I'm sure it isn't, but someone should check).
Some quick review of the version from the PPA:
Package naming:
- Source package name should be libdecor-0 now that upstream has
co-installable naming conventions
- libdecor binary package should be renamed libdecor-0-0 to match the
SONAME libdecor-0.so.0, with Conflicts: libdecor, Replaces: libdecor
to avoid conflicts with the unofficial PPA package
- libdecor-dev binary package should be renamed libdecor-0-dev to match
the .pc file, with Conflicts: libdecor-dev, Replaces: libdecor-dev
- libdecor-plugin-cairo should maybe be renamed libdecor-plugin-1-cairo
or something, to reflect plugin_api_version
d/control:
- libdecor dependency on libwayland-client0 should be unnecessary, you
should find that ${shlibs:Depends} adds a suitable dependency
- Similarly libdecor-plugin-cairo dependency on libcairo2 and
libpangocairo-1.0-0 should come from ${shlibs:Depends}
- libdecor-plugin-cairo should probably have Provides: libdecor-plugin-1
- libdecor-0-0 should probably have
Recommends: libdecor-plugin-1-cairo | libdecor-plugin-1
so that third-party plugins (if any) can Provides: libdecor-plugin-1
- The Standards-Version is very out of date, please check that the package
follows current Debian Policy and then set it to the current Policy
version (4.5.1 at time of writing)
- libdecor-plugin-cairo needs a long Description
d/compat:
- Please use the recommended debhelper compat level (13) for new packages,
unless there is a very good reason to require an older compat level.
The preferred way to do this is to add
Build-Depends: debhelper-compat (= 13) and delete d/compat.
d/copyright:
- The version of the MIT/X11 license quoted here is called "Expat" in
d/copyright files, to distinguish it from the many other licenses
used by MIT and X11.
- You can probably use
Files: *
Copyright: (the same as you have now)
License: Expat
on the assumption that .gitignore, README, meson.build, etc. have the
same copyright holders and licensing as the rest of the package.
- Please declare a copyright holder (you or your employer) and a license
(probably Expat) for the debian directory.
- The copyright file isn't following copyright-format 1.0 syntax yet.
Please see the python3-vdf package (which I maintain) for an example of
a copyright file for a package with the same license as this one.
d/README.Debian:
- If you don't have anything to say here, please delete it
d/rules:
- Probably best to remove the commented-out stuff
- I would suggest enabling the demos and installing them in a new
libdecor-tests package - otherwise it'll be hard to do manual testing
on this package without having the patched SDL available. This will
need some extra build-dependencies.
If this package later gains automated tests, the libdecor-tests package
could contain those too.
Ideally the libdecor-tests package would have Build-Profiles:
(I can help with this).
d/source/format:
- Should be 3.0 (quilt) instead of 3.0 (native) for a package with an
upstream developer outside Debian
d/git-build-recipe.manifest:
- This should be removed for an official Debian package.
Other:
- There should be a debian/watch to download the latest official upstream
release. If upstream doesn't release tarballs then use something similar
to
https://salsa.debian.org/gnome-team/gnome-desktop-testing/-/blob/debian/2018.1+git20210629-1/debian/watch
to download it directly from git.
- I think all shared library packages should have at least a superficial
autopkgtest, for example similar to the ones in
or
Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland
Package: wnpp Owner: Christian Rauch Severity: wishlist * Package name: libdecor-0.1 Version : 0.1.0 Upstream Author : Jonas Ådahl Christian Rauch * URL : https://gitlab.gnome.org/jadahl/libdecoration * License : MIT Programming Lang: C Description : client-side decoration library for Wayland "libdecor" is a library that can be used by Wayland clients to implement client-side window decorations. Client-side decorations are needed on Wayland if the compositor/server does not support server-side decorations (such as mutter/GNOME Shell). This library is mainly intended to be used by applications or frameworks which do not use a toolkit that already implements client-side decorations (such as GTK or Qt). Candidates for this are SDL, GLFW, Blender, and any other pure OpenGL application. SDL intends to adapt "libdecor" once a 0.1 release has been tagged: https://github.com/libsdl-org/SDL/pull/4068. At this point, "libdecor" will become a dependency. I am already maintaining an Ubuntu ppa at: https://launchpad.net/~christianrauch/+archive/ubuntu/libdecoration but would like to upstream the package into Debian. Since this is my first time packaging a library for Debian, I could use support from a co-maintainer who is familiar with Wayland. Potentially, the maintainer for SDL would be a suitable match to better coordinate the dependency tracking. The package itself is easy to maintain, but it could become a dependency for many other packages in the future. I will also need a sponsor to upload the package.
