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 C. On 08/05/2018 08:37, Niels Thykier wrote: > 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-ment...@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 -- To secure your emails, use PGP (e.g. enigmail on thunderbird) My key: 0xD1F93BE3 <http://pgp.mit.edu/pks/lookup?op=get&search=0xA4BD76DED1F93BE3>
