Many thanks Paul for the additional review comments. I've included the changes below in a revised package.
Important Note. I've contacted the maintainer of the budgie-desktop package on a couple of issues that was raised.
He has decided to consolidate all the issues raised under one umbrella issue:
- https://github.com/solus-project/budgie-desktop/issues/465
- https://github.com/solus-project/budgie-desktop/issues/465
He has graciously (albeit time-limited) offered Debian a minor point release that can address any packaging issue or issues. Two caveats - the issue or issues must not be distro specific and he is expecting a consolidated list of points to consider - "let's get a complete action plan here so I can get my development time back. i.e. kick things into gear."
Whilst I know you do not wish to sponsor this package - do you know of someone who can? I'm keen to get one list together to to keep the maintainer positively engaged. I cannot go back now to the maintainer with individual points over a period of time.
On Fri, 2016-05-27 at 20:17 +0100, foss.freedom wrote:
> > Looking on the mentors / mypackages webpage it says that the watch
> > file I've included does not work. This is very strange because I ran
> > a uscan and it correctly downloaded the upstream release file:
> The version we use on mentors is older so that might be the issue.
> I expect if you use version=3 in the watch file it will work there.
version=3 has been used now and you are quite correct - mentors website no longer complains :)
> > In summary - users are requested to upgrade. Moving forward, the
> > maintainer intends to branch the project at the next major release
> > and will backport stuff where necessary (e.g. critical issues). This
> > will be very useful for Debian to identify issues to include in
> > updates.
> Sounds good, please refer to the dev ref for security/stable uploads:
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
Thanks for this - I'll use this info for maintenance of the package moving forward in the future.
> I suggest dropping the version number from the Upstream-Name field,
> since version numbers are usually not in the name of upstream projects.
This has now been corrected.
> > I asked this upstream: https://github.com/solus-project/budgie-desktop/issues/448
> Nice response :(
> It doesn't sound like they understood what I was trying to say.
> Perhaps the first paragraph of our upstream guide is more clear:
> https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source
> > In the debian/clean I've removed the build artifacts that upstream
> > have recommended here https://github.com/solus-project/budgie-
> > desktop/issues/446#issuecomment-221378660
> There was no need to remove those because autoreconf will automatically
> overwrite them. The other generated files need to be removed though.
> > have recommended here https://github.com/solus-project/budgie-
> > desktop/issues/446#issuecomment-221378660
> There was no need to remove those because autoreconf will automatically
> overwrite them. The other generated files need to be removed though.
I've removed the clean part of the debian/rules as requested. With regards to the build artifacts and other possible package changes, the maintainer has pointed us to this: https://github.com/solus-project/budgie-desktop/blob/master/README.md#reporting-issues--project-integration
Basically, if we change the upstream release package in anyway without the explicit consent of the maintainer and a problem that is reported that is found to be because of that change we will lose support. "Don't make other users suffer because you failed to follow our established
build and release processes. Use standard methods, and we all benefit."
> Thanks for the info. I suggest this course of action in parallel to
> finding a sponsor for budgie-desktop:
> For each of natray and gvc:
> First, get the embedded code copies documented according to this:
> https://wiki.debian.org/EmbeddedCodeCopies
I looked at that link - are you asking me to file bug reports to debian with the following body text?
"Source: natray Severity: normal Usertags: embed"
or
"Source: gvc Severity: normal Usertags: embed"
> Second, find out where they are developed and talk with upstream about
> making these stable projects that are released and can be used as
> shared libraries by each of the projects using them.
The links show that upstream (Red Hat/GNOME) are fully aware of the issue and have been for two years. There was mention of producing a standalone binary but despite comments over the last two years, no explicit commitment has been given. There is very little that myself or Debian can do other than monitor those links for movement and if/when a standalone library is produced to advise the budgie-desktop maintainer to use the standalone libraries.
> Probably not a good idea to remove authorship info from patches.
Corrected i.e. added Author (name and email address)
> > Upstream are already signing their commits. Tags/releases are not going to be signed.
> Is there a particular reason why they sign commits but not sign
> tags/releases? That seems strange to me.
Tags are to be signed in the future. However the release tarball will not be signed for the reasons stated by the maintainer.
> > This has been tidied - only one vital override exists - this is
> > needed to display the GNOME appmenu correctly in the window
> > decoration.
> Hmm, ok. I wonder if this will affect people using both GNOME and
> Budgie under different users on the same machine.
I can confirm there are not impacts on users using both GNOME-Shell and Budgie-desktop - basically GNOME-Shell ignores this override.
> Cinnamon is in Section: x11, that would be appropriate.
I've changed this to x11 now.
> > This is not installed - source only issue.
> True, you could send upstream a PR though.
Yeah - sorry - should have said "release tarball" - not "source". This is the make dist issue referred to above.
> > Maintainer has indicated otherwise - see link above
> Please ask them to read the upstream guide section I quoted above.
Yep - same response as above - all distros have to use the maintainers release tarball or it looses support.
> > > $ codespell --quiet-level=3
> > >
> > Vala to C compiler issues - not an upstream matter.
> Not entirely true, there are some in non-generated files:
The non-generated files appear to be the embedded code snippets we talked about. There is nothing we can do here. Its a RedHat/GNOME matter. Probably wiser to pursue this once the standalone libraries are produced since these would be reviewed separately.
> $ codespell --quiet-level=3
> ./raven/sound.vala:384: dont ==> don't
> ./raven/sound.vala:395: dont ==> don't
> ./raven/Makefile.am:44: calender ==> calendar
> ./gvc/gvc-mixer-control.c:514: successfull ==> successful
> ./gvc/gvc-mixer-control.c:1503: everytime ==> every time
well ... the response is self explanatory.