Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi Chris,
Chris Frey wrote (26 May 2012 02:15:12 GMT) :
> New version available, when you have time:
Looks better and better. I trust we'll manage to get this ready in
time for Wheezy!
> I left the hardening checks as-is for now, not overriding them,
> since from the conversation on some of the mailing lists:
> http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1024761.html
> it is a work in progress, and I want to see the warnings.
OK.
> But, that said, I did test with hardening flags, and they were
> indeed used during the build, even though some of the lintian checks
> failed at the end. I'm hoping the lintian tests will improve
> over time.
> Let me know if you run into problems with this version.
Commit 85a9d87f makes debian/rules stop passing
"DEB_BUILD_MAINT_OPTIONS = hardening=+all" to dpkg-buildflags.
As a result, you stopped enabling the hardening options that are not
enabled by default (PIE, bindnow):
$ hardening-check usr/bin/barrydesktop
usr/bin/barrydesktop:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: yes
Immediate binding: no, not found!
I think you can simply revert your revert :)
Details: dpkg-buildflags(1), https://wiki.debian.org/HardeningWalkthrough
Other than that, there's not much left for me to complain about, and
this is great news!
However, process-wise, it would make things much easier for me on the
long run if you maintained this package using the "classic"
git-buildpackage + pristine-tar workflow:
- a branch dedicated to Debian packaging (usually called "master",
but since your repo is the upstream one, I suggest calling it
"debian-master" instead)
- a branch dedicated at importing upstream tarballs using
git-import-orig (called "upstream", by default)
- git-import-orig takes care of maintaining the pristine-tar branch,
merging the orig tarball into "upstream", merging "upstream" into
"debian-master", and creating tags as needed, so this should not
change your current workflow much: the main thing that changes is
how you send me your work.
This way, every time you ask me to upload a package, I can easily
check the changes using Git, run git-buildpackage, inspect and push
the result. Also, it will make maintaining official Debian backports
much easier.
What do you think?
These two things (hardening and packaging process) are the two last
I feel necessary to fix before the upload. May we aim at an upload in
a week max., so that the package has time to migrate to Debian testing
before the freeze?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
Reply to: