Alan wrote (27 May 2014 17:36:04 GMT) : > - gnome-theme-windows8 (@git.tails.boum.org)
If there's any Debian packaging in there, please assign the ticket to me. > - gnome-panel-applet-window-picker (@git.tails.boum.org). Please review > C code as I'm not knowledgable enough. The package builds for me, and Lintian is happy. There are a few problems, though, including some major ones => a bit more work is needed. Sadly, most of it would have been avoid if things had been done right from the beginning. But that's how one learns, I guess :) This package was converted to a native one. I really don't get why, and see no indication other than "Update packaging". I doubt we're now upstream for this code. We don't want to release window-picker-applet-$UPSTREAM_VERSION.tar.gz, with a different content, but the same version, as upstream's tarball. Also, I assume that we'll be happy if Debian or any derivative wants to base their work on ours, so I think this really ought not to be a non-native one. That's the top blocker to me. The changelog entries until 0.5.8-2 (last version that was part of Debian) were deleted. Same for Ubuntu's changelog entries for 0.5.10-*. Uh? Should be trivial to fix, especially considering that: A Vcs-Git packaging repo is available in Debian, but apparently our own one has no shared ancestor with it. I really don't get why. I see the packaging was somehow inherited from there anyway, before Ubuntu packaged 0.5.10, so it should be quite easy to get things right. Reconciliating these histories is perhaps not a blocker for 1.1, *if* someone commits to do it on their way to getting this package ready for Debian. OTOH, *now* is probably the best time to rewrite the Git history. Doing it later will be harder. Please don't add "configure", or any such auto-generated autotools files, to Git. That's a blocker. The Homepage control field points to https://launchpad.net/window-picker-applet, while you're packaging a fork https://github.com/lanoxx/window-picker-applet. That's a blocker. I see the package build-depends on GTK2 stuff, while the GitHub fork we're packaging says it's a port to GTK3. Upstream's README mentions other build-deps, so it maybe something is wrong. src/common.h is GPL-2+, and not mentionned in debian/copyright. Hint: `licensecheck -r .' avoids to miss the most obvious problems of this class. That's a blocker. You know as well as I do why commit tickets and changelog entries like "Update packaging" (4 files changed, 20 insertions(+), 104 deletions(-)) are to be avoided, so I won't state the obvious. Too late for the commit message, but please fix debian/changelog. And now, a few non-blockers (for 1.1). The upstream tarball doesn't live in Git, so I had to go retrieve it from the right suite in our APT repo. No big deal, but in the future please prefer source format 3.0 (quilt) + git-buildpackage branches layout, that is self-contained in Git, like we do for basically all of our non-native packages (and that's also a very popular setup in Debian as well). Consistency among packaging workflows makes it easier for others to work on a package they've not touched before, makes the RM's work easier, lowers the bar to contribution, and increases chances we understand what we're doing when we type pseudo-random lines in `$EDITOR debian/...'. Still, that's not a blocker, as long as someone commits to do it while preparing the upload to Debian. The obsolete debian/watch was dropped for some reason. It should be updated instead, to point to the place where you're taking releases from. Not a blocker, as long as [...]. You were concerned about the security of this code, so I suggest building with all hardening flags, and not only the default ones, if possible. Not a blocker, as long as [...]. I see that compat level was raised to 8. I'm curious why not use the latest one, while you were at it? Any particular reason why the Git repo isn't called neither the same way as the source or binary package? If not, I'm happy to rename it myself. To end with, I've just documented in our Gitolite config's README how to properly create a new repo. I've fixed the ones you created. Cheers! _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
