Thx a lot for this very accurate and truly useful reply.
FYI, I'm the person who created the debian source package, and I
will fix it to corresponds to Debian standards.
In particular, the Qt4 dependency is simply a mistake from the
OBS maintainer. When creating packages manually, our script (works
for ubuntu+debian) replaces debian/control it with a custom file
that depends on the distribution and uses Qt5 most of the time, so
it shoudn't be hard to fix.
Best regards
Cyril Soler:
The retroshare software already ships debian packages for Debian 8+9, as can be seen here:
https://build.opensuse.org/project/show/network:retroshare
Ok, so there is an initial packaging. That is a good start.
[...]
What's missing is the distribution part. So according to the document you're citing page 45, what we
need is:
(quoting out of order to answer the most important point first)
- "find a Debian developer that will sponsor your package". This what I thought I was asking for.
Maybe the tag "RFP" is not appropriate then?
This is probably the source the confusion. The RFP is a "Request For
Package" in the sense "I would like someone to create and maintain a
package". If one is actively working on the package, it should be
renamed to "ITP" (Intend To Package) to avoid duplicated work.
However, it is not useful to request sponsor ship and reviews on wnpp
bugs (e.g. this bug). This is partly because of historical reasons and
partly because there are way too many wnpp bugs for people to be able to
sanely track them.
Sponsorship requests are instead filed as (separate) bugs against the
sponsorship-requests pseudo package (e.g. via "reportbug
sponsorship-request"). You can see existing requests here:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=sponsorship-requests
- "prepare a source package". We have this already. Packages build perfectly well with pbuilder. the
-pedantic flag may raise a few bits that I can fix easily.
I had a superficial look at the package (apologies if it is a bit
technical/assumes too much Debian specific knowledge). Based on it, I
have some suggestions for things you may want to look at before
requesting a review (all of this is based on the OBS link you sent me):
* The debian/control file lists QT4 libraries. Unfortunately, the QT
team is actively trying to remove the last remains of QT4 (in favour
of QT5). A potential sponsor will probably be aware of this and be
hesitant of introducing a new QT4 relation now.
- Note that all uploads will target Debian unstable (and not Debian
stable or oldstable). Generally "new" packages are not added to
the existing stable release (though they can be added to
stable-backports)
* Ideally, the final "non-native" source package will be downloadable
from a "dget'able" URL (i.e. an URL where you can run "dget <URL>"
and it will download the Debian source package). I cannot get that
to work with OBS.
Among because the [.dsc file on OSB] is for a native package with an
"invalid" name for the tarball (Debian only allows lower-case
characters). I note the OBS seems to rewrite it and create a valid
[non-native source package during the build].
- Note: native packages are "built by Debian only for Debian" and the
most obvious case would be "dpkg". Admittedly, there are some that
believe this distinction is no longer useful and that "native"
packages should be universally converted to what we call
"non-native" packages.
- If OBS cannot provide this functionality, you can upload the
package to mentors.debian.net, which does provide it. As will any
other plain static hosting site
- You can find "dget" in the devscripts package on a Debian-based
system.
* The debian/changelog will be reserved for "Debian related changes"
(it is acceptable to highlight important upstream changes, but it is
not the upstream changelog). The Debian changelog will be expected
to have a new entry with a single line formatted as:
" * Initial release to Debian. (Closes: #659069)".
For most parts, you can simply rename the existing changelog and
create one with:
"dch --create --package retroshare --newversion 0.6.4-1'
The "existing" changelog will still be useful for documenting
upstream changes.
- Note that the Debian changelog includes a "-1". This is known as
the Debian revision and is incremented whenever there is a package
change without changing the upstream version (it is then reset to
"-1" when a new upstream release is packaged).
- See also:
https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-debian-changelog
(Note it assumes that debian/changelog is solely used for the
Debian packaging.
The items above are probably the most important ones to resolve as they
can trigger "canned" responses from reviewers.
* The "dget" part is the primary method for downloading source packages
to review.
* On the changelog and native/non-native source package parts, then
those are "common mistakes" for new packagers.
* The QT4 item is (as mentioned above) being retired from Debian
unstable.
Beyond that, you may also want to look at the following:
* debian/rules can probably be reduced to something like:
"""
#!/usr/bin/make -f
%:
dh $@
override_dh_auto_configure:
dh_auto_configure --buildsystem qmake-qt4 -- \
CONFIG-=debug CONFIG+=release
"""
(Admittedly, untested). This would remove a few deprecated
tools/cmdline arguments plus add some (now) required features
that are not present in the existing rules file. Notably the
"build-arch" and "build-indep" targets (via the %: wildcard).
* If you can, run lintian from unstable or stable-backports on the
the .changes files from a build that produces both a source package
and binary packages (.debs) in unstable.
- Note: "lintian-info -t <tag-name>" is useful for getting more
information about findings from lintian.
- Additional review can be obtained via -I and then finally
-L +pedantic. Mind you at this point you are dealing a lot more
with "style and best practises" rather than "issues".
Lintian is the source of many canned responses as well. It helps
a lot if you have already seen the lintian output and know whether
it is a false-positive or something you need help with fixing (or,
in case of pedantic tags, not worth fixing).
Hope this is useful. Remember that you can use
debian-mentors@lists.debian.org or #debian-mentors on IRC (irc.oftc.net)
if you have any questions to the above (note that IRC have some periods
where no one is around, so you may need to stay online for a while to
get a response).
Thx for the help. We're definitely making some progress!
Cyril
[...]
You are welcome. :) Thanks for your interest in improving Debian.
~Niels
[.dsc file on OSB]:
https://build.opensuse.org/package/view_file/network:retroshare/RetroShare/retroshare.dsc?expand=1
[non-native source package during the build]:
"""
[ 2504s] DEBS/retroshare_0.6.4_amd64.deb
[ 2504s] DEBS/retroshare-nogui_0.6.4_amd64.deb
[ 2504s] DEBS/retroshare_0.6.4.diff.gz
[ 2504s] DEBS/retroshare_0.6.4.dsc
[ 2504s] DEBS/retroshare_0.6.4_amd64.changes
[ 2504s] DEBS/retroshare_0.6.4.orig.tar.gz
"""
Note the .diff.gz and the .orig.tar.gz