On Wed, Jul 8, 2020 at 2:52 AM Samuel Henrique <samueloph@debian.org> wrote: > [...] > Awesome, you don't need to bother with mentors since we are working as > a team and we have salsa, anytime you need a review/sponsor you can > ask for one and we will take a look at the head of debian/master, that > will make things slightly easier. > Oh that makes it easier indeed. > [...] > The correct distribution will be unstable, that is unless you have an > explicit reason to keep it experimental, but those cases are rare and > I don't think it applies here. > [...] > So the gist of it is that you can either set it to unstable when you > think the package is ready or wait for the sponsor to do so, it's up > to you. > Ok, I set it to unstable. > > - Since I used CDBS, the maximum debhelper compat version I could use is 10. > > IIUC, this is fine? > > I took a look at d/rules and it looks like you're not using anything > specific to cdbs, I recommend switching to debhelper fully as cdbs is > considered legacy. > The switch should be fairly easy, you just need to remove cdbs from > B-D and add the vanilla debhelper catch-all target on d/rules: > %: > dh $@ > TIL. I rather liked CDBS for its ease of use, but the new version is just as simple. Done. > [...] > I also recommend using > "debhelper-compat" in d/control, as the other packages, so you can > remove the file d/compat (debhelper-compat declares both the compat > level and the debhelper version). > > With the move to debhelper, you will be able to use version 13. > Done. I left the debian/compat file, though, as my "debuild -- clean" complained about it being missing otherwise. Or maybe I'm doing it wrong. Maybe look at my control file? A nice side-effect is that the build is now invoked with the equivalent of make -j$(nproc) :-) > > - Upstream does not provide GPG signatures, so I can ignore the > > debian-watch-does-not-check-gpg-signature warning, right? > > That's right, strictly speaking only lintian errors are blockers, the > rest of them are good to fix but sometimes it's not something doable > from the packaging side. In this specific case we are talking about a > possible improvement that needs to be done on the upstream side > (provide a key and signature of tarballs). Considering you're also > upstream you can fix it, but it's totally up to you. > I'm only kind of upstream. I'm not one of the regular contributors, but I work with them. So yes, we'll get this done, too. > [...] > If you package a snapshot of a repo, the version needs to have this > information appended in the upstream part of it, like in the example > of one package we have: > 3.7.18+git20200706.10c91c7-1 > instead of 3.7.18-1 Ah sure. Maybe I didn't make this clear. By "snapshot" I didn't mean a snapshot of Git master, but rather a full copy of the source code as of version 2.9 (the latest release). > [...] > Sometimes there are issues related to submodules, but they happen > because the submodule is a library that should be packaged separately. > Not all libraries need/should be packaged separately, but some do, so > it's on a per case basis. > Yeah the submodule in question is about "Kafel", a domain-specific language for writing syscall filters. I don't believe we should package this separately as of now. So I'll keep it in the original tarball. > I will review the package soon, so I will be able to give a more > specific feedback, > Nice. I committed the requested changes to Salsa. PTAL. > [...] -- Christian Blichmann | Senior Software Engineer | Google™ m: +41 79 7 18 79 43 | cblichmann@google.com
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature