Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Upstream tag: barry-0.18.3-2 Upstream diff: git log -p barry-0.18.3..barry-0.18.3-2 Release URL: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/debian/barry_0.18.3-2.dsc Uploaded to sid, thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sun, Jun 03, 2012 at 10:34:04AM +0200, intrigeri wrote: Sure. However, the URLs you provided me until now did not. Did I miss a way to get the real download URL from the click-one, without firing up a web browser? I didn't understand how the .dsc file could be used until I started playing around with git-buildpackage. I'll send the .dsc URL now instead, since it is much easier. I'm also signing the .dsc file. My key is in the public servers. I had to add my personal keyring to my ~/.devscripts file, but other than that, it worked great. New release version 0.18.3-2: Upstream tag: barry-0.18.3-2 Upstream diff: git log -p barry-0.18.3..barry-0.18.3-2 Release URL: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/debian/barry_0.18.3-2.dsc After importing via git-buildpackage, the resulting trees of gbp master and my upstream tag were identical. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (31 May 2012 22:39:54 GMT) : Making every maintainer update their package in order to support hardening seems like the long way around. But so be it. :-) I agree but the decision was not made this way, so let's deal with it :) There is no guarantee either that the diffs you look at with git-log are the same changes that end up in the binary file you get out of a pristine-tar commit. It is unlikely that they will differ, but thinking that pristine-tar is somehow closer to the real git sources than a signed binary tarball from sourceforge is mistaken. There is a trust gap in both. The xdelta can contain anything. Ah. Looks like you are absolutely right. I never thought of this. Thanks a lot for educating me! :) If I find a way to make git-buildpackage run for you as expected, without pristine-tar, would that be satisfactory? Maybe that's impossible, but I'd really like to get rid of that dependency. [...] If I stop autogenerating configure in the .orig.tar.gz, and stop pre-generating html docs in it, which aren't used anyway, it should be possible for you to import the .dsc file using git-buildpackage and have a completely empty git-diff between my release tag and your git-buildpackage master tree. This would allow you to peruse my upstream git log with certainty that you're actually viewing the real changes. I don't think you'll need to use debdiff anymore. Looks great. [...] But the diff between the master branch (created by git-buildpackage) and my barry-0.18.3 tag only contained the autogenerated files for the html docs and autoconf. Without such cruft in the .orig.tar.gz release, you could easily import my releases, and review them at will, and use git-buildpackage however you like. It would make the release files smaller too. This looks like an awesome solution. Let's try it! The downloads from sourceforge worked just fine from the command line. Sure. However, the URLs you provided me until now did not. Did I miss a way to get the real download URL from the click-one, without firing up a web browser? Please let me know what you think of my above plan. If it is satisfactory, I can release barry-0.18.3-2 soon, and we can see how our workflows mesh. Yeah, let's try for real soon. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Thanks for your considerate replies, and continued patience. So far, when I think I can see the end, it is not the end, and it gets a little frustrating. :-) So your patience is appreciated. I've done some testing and experiments, and below are my results. On Tue, May 29, 2012 at 02:46:32PM +0200, intrigeri wrote: Chris Frey wrote (29 May 2012 09:45:15 GMT) : On Tue, May 29, 2012 at 10:48:43AM +0200, intrigeri wrote: Commit 85a9d87f makes debian/rules stop passing DEB_BUILD_MAINT_OPTIONS = hardening=+all to dpkg-buildflags. AFAIK, no large general-purpose distro builds all software with PIE by default; this is due to some performance problems on register-starved architectures, and the fact it breaks quite some software. So, the only practical way for Debian to get more hardening thanks to PIE is to have maintainers enable it pro-actively, on a package by package basis. Which is what I am kindly asking you to do :) Don't worry, I've added it back. Just seems wrong on a certain level. :-) I assumed that these default flags could be set on a per-architecture basis. And if they default to on, then the packages that legitimately need things turned off, could disable them. This would leverage the power of debhelper, buildflags, cdbs, etc. Making every maintainer update their package in order to support hardening seems like the long way around. But so be it. :-) They are part of what can be uploaded. I also have to build and upload the corresponding binary packages. Interesting... that's a newbie surprise for me. I thought that in the end, all packages were built with buildd. As for pristine-tar, my initial reaction is that I'm disappointed that I can't get rid of it yet. I had hoped that by taking on the role of maintainer, I could avoid that waste. What waste, exactly? The (small) binary xdelta blobs in the source repo. Except for some graphics, such as background images, buttons, etc., I believe all the files in the (huge) Barry source tree are text-based source files that can be read and understood by a human. In my mind, git is for committing source code, written and reviewed by a human at each commit, and final binary results are all based on, and extracted from, that source. Pristine-tar breaks that, by inserting automated commits in binary format. There is no guarantee either that the diffs you look at with git-log are the same changes that end up in the binary file you get out of a pristine-tar commit. It is unlikely that they will differ, but thinking that pristine-tar is somehow closer to the real git sources than a signed binary tarball from sourceforge is mistaken. There is a trust gap in both. The xdelta can contain anything. Maybe there's an easy way to diff between a git branch and a pristine-tar tarball, but that's starting to look like hack upon hack to me. I can certainly understand the convenience of using git for everything, though. And that might be worth it in itself. If I find a way to make git-buildpackage run for you as expected, without pristine-tar, would that be satisfactory? Maybe that's impossible, but I'd really like to get rid of that dependency. This would be satisfactory, but indeed it looks impossible to me: I don't know how you can ship a source package purely over Git without using pristine-tar. If you go on not using pristine-tar, I still have to fetch both from Git and (at least) the orig.tar.gz from a painful web site. pristine-tar was created *exactly* to allow shipping, over Git, the tiny delta that goes between a Git tree and a .orig.tar.gz. The debian/rules script contains the code needed to run autoreconf, so it is possible to simply checkout a tag and build Debian packages straight from there. It is also possible to extract consistent tarballs using git-archive, and do the same thing. Pristine-tar uses git-archive for the bulk of its work as well. If I stop autogenerating configure in the .orig.tar.gz, and stop pre-generating html docs in it, which aren't used anyway, it should be possible for you to import the .dsc file using git-buildpackage and have a completely empty git-diff between my release tag and your git-buildpackage master tree. This would allow you to peruse my upstream git log with certainty that you're actually viewing the real changes. I don't think you'll need to use debdiff anymore. To test this, I did: git init git remote add barrypublic git://repo.or.cz/barry.git git fetch barrypublic git-import-dsc --pristine-tar --download http://sourceforge.net/projects/barry/files/barry/barry-0.18.2/sources/barry_0.18.2-1.dsc git-import-dsc --pristine-tar --download http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/barry_0.18.3-1.dsc git diff --stat master barry-0.18.3 I hacked dget to accept unsigned .dsc files for my test. I'll have to start signing those to make this easier. But the diff between the
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Tue, May 29, 2012 at 10:48:43AM +0200, intrigeri wrote: Commit 85a9d87f makes debian/rules stop passing DEB_BUILD_MAINT_OPTIONS = hardening=+all to dpkg-buildflags. I was doing testing with and without the revert, and the lintian tests did not improve. I plan to do a few more tests though. I'm curious why we would force all hardening options on when it is not the default for Debian. I assume hardening defaults were chosen for good reason. Doesn't this make it harder to adjust the whole distro at once, if needed? This is not like -Wall where it only affects compilation. It affects runtime as well, as I understand it. 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? Well, you asked. :-) I mean no offense by the following. It reflects my perspective as an upstream focused programmer, at least so far. First, some questions: are my source packages not the files that will be uploaded? Do you need to recreate them for some reason? I had assumed that uploading was easy if you had accurate, signed source packages from me. What changes do you check when you use git? Is it not suitable to do: git log -p barry-0.18.2..barry-0.18.3 -- debian to see what changed? Also, the debian/ directory lives in master, and if I understand correctly, you're asking for it to be moved. This makes no sense to me. I can see creating new tags for Debian-only -1, -2, releases, but not splitting debian/ into its own little world. As for pristine-tar, my initial reaction is that I'm disappointed that I can't get rid of it yet. I had hoped that by taking on the role of maintainer, I could avoid that waste. I know downstream loves pristine-tar, but upstream, it looks like a hack. :-) I admire Joey Hess, but unfortunately pristine-tar rubs me the wrong way. If I find a way to make git-buildpackage run for you as expected, without pristine-tar, would that be satisfactory? Maybe that's impossible, but I'd really like to get rid of that dependency. If worse comes to worst, would it be possible to get a git repo somewhere on debian.org that I could push pristine-tar stuff to? I'm sure I could script something to do it automatically, but I don't want that waste in upstream, and it seems rude to put it on repo.or.cz too. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (29 May 2012 09:45:15 GMT) : On Tue, May 29, 2012 at 10:48:43AM +0200, intrigeri wrote: Commit 85a9d87f makes debian/rules stop passing DEB_BUILD_MAINT_OPTIONS = hardening=+all to dpkg-buildflags. I was doing testing with and without the revert, and the lintian tests did not improve. I doubt Lintian results indicate anything relevant to PIE or bindnow. The (probable false positives) Lintian warnings we've seen were about possibly not fortified functions, which is totally orthogonal, I believe, to PIE and bindnow. More useful ways to check if PIE and bindnow are being used are: - hardening-check(1) (from the hardening-includes package) - build logs: see what arguments are passed to the compiler, linker and friends. I'm curious why we would force all hardening options on when it is not the default for Debian. We would do so to get better security, very cheaply. I assume hardening defaults were chosen for good reason. They were chosen to be *safe* *defaults* that could be applied, without too much thinking, to a huge majority of the packages we ship. The idea was to make it easy, for people who work on securing Debian, to push hardening patches to package maintainers, without seeing them run away, totally scared, after it broke one of their package once due to incompatibility issues. However, all the work on hardening options (see dpkg-buildflags(1)) was done in a way that makes it easy to add, or remove, hardening options depending on what's possible / easy / doable / a pain to maintain, balanced with the security gains. Moreover, the hardening documentation I've pointed you at clearly encourages maintainers to try out the full-blown hardening options set, if possible. It's not as if we were doing anything against Debian by following the Debian security team advice :) AFAIK, no large general-purpose distro builds all software with PIE by default; this is due to some performance problems on register-starved architectures, and the fact it breaks quite some software. So, the only practical way for Debian to get more hardening thanks to PIE is to have maintainers enable it pro-actively, on a package by package basis. Which is what I am kindly asking you to do :) Doesn't this make it harder to adjust the whole distro at once, if needed? It would, but I think this is a theoretical case: I doubt we can ever do any distro-wide change wrt. PIE. What do you think? First, some questions: are my source packages not the files that will be uploaded? They are part of what can be uploaded. I also have to build and upload the corresponding binary packages. Do you need to recreate them for some reason? I'd slightly prefer to re-create the source package from a Git tag every time, to make sure the procedure works well for people who are not you, to ensure I, or anyone else, can prepare a security update against barry while you're in vacation, in a way that integrates well with your usual workflow. I had assumed that uploading was easy if you had accurate, signed source packages from me. Uploading is easy, but sponsoring means quite more than blindly uploading. What changes do you check when you use git? I read in details every change to debian/, and I glance over the upstream changes too. Is it not suitable to do: git log -p barry-0.18.2..barry-0.18.3 -- debian to see what changed? This is *exactly* what I'd like to be able to do, and see it reflect exactly the source package I'm supposed to review and upload. This is not the case currently: given your current workflow, I have to import the tarball in Git myself, to compare it to the new tag. I can't just review object 1, upload object 2, and do as if object 1 and object 2 are obviously the same, see? So, given your current workflow, what I do is use debdiff to compare the previous and new source packages, and in parallel try to match this with the Git history by hand to get the reason behind every change. This is not something I like to do by hand. Also, the debian/ directory lives in master, and if I understand correctly, you're asking for it to be moved. This makes no sense to me. I can see creating new tags for Debian-only -1, -2, releases, but not splitting debian/ into its own little world. I fully understand why mixing upstream code and Debian packaging makes things easier to you. I also do maintain a few packages I am upstream for, and this splitting clearly makes things look a bit artificial, and means a bit more work on the short term. What you'd like would be to have a perfect match between upstream and Debian versions, between upstream and Debian source tree, which is what native packages are for. However, barry is clearly no native package, and e.g. you may have to branch e.g. a wheezy branch out of an old state of you master branch at some point, e.g. to prepare a stable or security update, or a backport. At this point, you'll realize your upstream source tree may live an
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Wed, May 16, 2012 at 12:32:01PM +0200, intrigeri wrote: So, here's what Lintian tells me this time: * The no-symbols-control-file Lintian overrides were not updated. * The new hardening checks detect possible problems: I'll let you check, override false positives, and fix real problems. New version available, when you have time: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/ 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. 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. Thanks! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (14 May 2012 21:35:45 GMT) : Development continues on Barry, and I assume it is ok to upload to Debian as soon as any new version is available. Yes. In short: Uploading to Debian unstable: sure. Uploading to stable backports once the package reaches the testing suite: sure. Uploading to stable itself: only critical bugs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (16 May 2012 03:12:54 GMT) : Ok, version 0.18.2 is here: Pretty please, run the latest Lintian (== from Debian sid) with all nitpicking options enabled *yourself* on the source and binary packages before pushing them to me. My last review rounds have basically boiled down to playing the Lintian -- Chris Frey proxy, and I feel I may have a better use of my time, you see :) So, here's what Lintian tells me this time: * The no-symbols-control-file Lintian overrides were not updated. * The new hardening checks detect possible problems: I'll let you check, override false positives, and fix real problems. Cheers! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, May 14, 2012 at 07:48:04PM -0400, Chris Frey wrote: Hold the presses. I found one more issue. The pkg-config files need to be renamed to match the major version number (libbarry-18.pc instead of libbarry-0.pc). I'll be releasing 0.18.2 to fix this. Ok, version 0.18.2 is here: http://sourceforge.net/projects/barry/files/barry/barry-0.18.2/sources/ Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sat, May 12, 2012 at 10:38:23AM +0200, intrigeri wrote: The trailing : is wrong in: Files: src/vformat.h src/vformat.c: Oops, thanks. I also get: W: barry source: debhelper-but-no-misc-depends barrybackup-gui-dbg W: barry source: debhelper-but-no-misc-depends libbarry18 W: barry source: debhelper-but-no-misc-depends barrydesktop W: barry source: debhelper-but-no-misc-depends libbarry18-dbg W: barry source: debhelper-but-no-misc-depends libbarry-dev W: barry source: debhelper-but-no-misc-depends barry-util-dbg W: barry source: debhelper-but-no-misc-depends barrydesktop-dbg W: barry source: debhelper-but-no-misc-depends barrybackup-gui W: barry source: debhelper-but-no-misc-depends barry-util My lintian command didn't catch the *.dsc files. Fixed that, and fixed all the above. Hopefully this is the one. :-) You can grab it in the usual place: http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/ Thanks again for all your help! Assuming this release is acceptable, here on out, I'm hoping to match point releases (0.18.1, 0.18.2, etc) with debian uploads. Development continues on Barry, and I assume it is ok to upload to Debian as soon as any new version is available. I'm also looking forward to getting feedback through the Debian bug system, and fixing in the same manner, although I realize that sometimes those will need backported patches, depending on which version is in stable. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, May 14, 2012 at 05:35:45PM -0400, Chris Frey wrote: My lintian command didn't catch the *.dsc files. Fixed that, and fixed all the above. Hopefully this is the one. :-) You can grab it in the usual place: http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/ Hold the presses. I found one more issue. The pkg-config files need to be renamed to match the major version number (libbarry-18.pc instead of libbarry-0.pc). I'll be releasing 0.18.2 to fix this. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi,
Great changes and explanations. See bellow for a few inline replies.
Chris Frey wrote (12 May 2012 00:53:12 GMT) :
2. I don't think src/vformat.{h,c} is supported syntax in a Files:
field in debian/copyright.
Probably not, according to the spec. I changed it to list both files
separately.
The trailing : is wrong in:
Files: src/vformat.h src/vformat.c:
Also, Lintian in --info --display-info --pedantic mode still outputs
a bunch of relevant comments.
In my testing there were only info statements, which for the most part
I thought could be ignored. I beefed up the descriptions a bit to
avoid the extended-description-is-probably-too-short message.
Those were all the lintian messages that I found on my sid testing.
Did you run lintian against the source package (.dsc)?
I also get:
W: barry source: debhelper-but-no-misc-depends barrybackup-gui-dbg
W: barry source: debhelper-but-no-misc-depends libbarry18
W: barry source: debhelper-but-no-misc-depends barrydesktop
W: barry source: debhelper-but-no-misc-depends libbarry18-dbg
W: barry source: debhelper-but-no-misc-depends libbarry-dev
W: barry source: debhelper-but-no-misc-depends barry-util-dbg
W: barry source: debhelper-but-no-misc-depends barrydesktop-dbg
W: barry source: debhelper-but-no-misc-depends barrybackup-gui
W: barry source: debhelper-but-no-misc-depends barry-util
Since these issues only affected the debian/ directory, I spun a version
0.18.1-2 and have released it here:
Almost there! :)
I assume we can label the changelog version anything we want, until we
actually perform our first upload, and then it is written in stone.
OK.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi,
Chris Frey wrote (08 May 2012 06:01:58 GMT) :
I believe this release can be uploaded.
Almost :)
Next review round results in:
1. debian/copyright may be syntaxically correct, but it looks weird
compared to how people usually put things in there.
Attached patch fixes this. Please consider applying it.
2. I don't think src/vformat.{h,c} is supported syntax in a Files:
field in debian/copyright.
3. The homepage set in debian/control is not the same as the one set
in debian/copyright. This looks wrong.
4. barrydesktop Suggests: gksu. How usable is it without gksu?
5. It seems to me BARRY_FIFO_NAME is handled in a way that opens
avenues to symlink attacks. Am I wrong? Files in world-writable
directories must be treated with care.
From b6312d33c873f1e1c0ec9d151f120c84abe92500 Mon Sep 17 00:00:00 2001
From: intrigeri intrig...@boum.org
Date: Fri, 11 May 2012 09:56:33 +0200
Subject: [PATCH] Reformat debian/copyright to suit informal style habits.
---
debian/copyright | 76 --
1 file changed, 28 insertions(+), 48 deletions(-)
diff --git a/debian/copyright b/debian/copyright
index eefae85..69340fe 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,62 +2,42 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Barry
Upstream-Contact: Chris Frey cdf...@foursquare.net
Source: http://sourceforge.net/projects/barry
-License: GPL-2+
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
- .
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- .
- You should have received a copy of the GNU General Public License along
- with this program; if not, write to the Free Software Foundation, Inc.,
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- .
- On Debian systems, the complete text of the GNU General
- Public License can be found in `/usr/share/common-licenses/GPL-2'.
Files: *
+Copyright: © 2005-2012 Net Direct Inc. (http://www.netdirect.ca/)
+Copyright: © 2007-2012 Chris Frey cdf...@foursquare.net
+Copyright: © 2008 Brian Edginton (e...@edginton.net)
+Copyright: © 1995-1999 Cryptography Research, Inc.
+Copyright: © 2003 Ximian, Inc. 2005 Armin Bauer
+Copyright: © 2008-2012 Nicolas VIVIEN nico...@vivien.fr
+Copyright: © 2009 Josh Kropf j...@slashdev.ca
+Copyright: © 2010-2012 RealVNC Ltd., Toby Gray
License: GPL-2+
-See global license section for details
-Copyright:
-Copyright (C) 2005-2012, Net Direct Inc. (http://www.netdirect.ca/)
-Copyright (C) 2007-2012, Chris Frey cdf...@foursquare.net
-Copyright (C) 2008, Brian Edginton (e...@edginton.net)
-Copyright (C) 1995-9 by Cryptography Research, Inc.
-Copyright (C) 2003 Ximian, Inc. 2005 Armin Bauer
-Copyright (C) 2008-2012, Nicolas VIVIEN nico...@vivien.fr
-Copyright (C) 2009, Josh Kropf j...@slashdev.ca
-Copyright (C) 2010-2012, RealVNC Ltd., Toby Gray
Files: contrib/*
+Copyright: © 2008 Niels de Vos nixpa...@users.sourceforge.net
+Copyright: © 2008 ashley willis ba...@venamous.net
License: GPL-2+
-See global license section for details
-Copyright:
-Copyright (C) 2008 Niels de Vos nixpa...@users.sourceforge.net
-Copyright (C) 2008, ashley willis ba...@venamous.net
Files: src/vformat.{h,c}:
+Copyright: © 2003 Ximian, Inc.
+Copyright: © 2005 Armin Bauer
License: LGPL
- This library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
- .
- This library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
- .
- You should have received a copy of the GNU Lesser General Public
- License along with this library; if not, write to the Free Software
- Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+License: GPL-2+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
.
- On Debian systems, the complete text of the GNU Lesser General
- Public License can be found in `/usr/share/common-licenses/LGPL-2.1'.
-Copyright:
-Copyright (C) 2003 Ximian, Inc.
-Copyright (C) 2005 Armin Bauer
+ On Debian systems, the
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
intrigeri wrote (11 May 2012 08:23:58 GMT) : Next review round results in: Also, Lintian in --info --display-info --pedantic mode still outputs a bunch of relevant comments. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Fri, May 11, 2012, intrigeri wrote:
Next review round results in:
Thanks :-)
1. debian/copyright may be syntaxically correct, but it looks weird
compared to how people usually put things in there.
Attached patch fixes this. Please consider applying it.
I applied the patch, with a slight change.
I didn't realize that the License section could be all by itself,
so thanks for that!
2. I don't think src/vformat.{h,c} is supported syntax in a Files:
field in debian/copyright.
Probably not, according to the spec. I changed it to list both files
separately.
3. The homepage set in debian/control is not the same as the one set
in debian/copyright. This looks wrong.
The one in copyright, under the Source: field, is where you get the source
code, while the one in control, under Homepage, is where you find the
welcome and documentation. I've updated copyright to make this clearer.
4. barrydesktop Suggests: gksu. How usable is it without gksu?
I picked Suggests so that it would be easy to install without gksu.
It is for the modem mode, and if the user is a member of the dip group,
then it is not needed. But if not, the desktop warns the user to add
themselves to the same group used by /usr/sbin/pppd, and then offers a
way to continue anyway, by calling gksu.
5. It seems to me BARRY_FIFO_NAME is handled in a way that opens
avenues to symlink attacks. Am I wrong? Files in world-writable
directories must be treated with care.
I believe it is safe. Here is the comment I added to the code in git to
explain my reasoning:
// Security Note:
// --
// This should be safe from symlink attacks, since
// mkfifo(), in the constructor, will fail if any other
// file or symlink already exists, and therefore we will
// never get to this open() call if that fails. And if
// mkfifo() succeeds, then we are guaranteed (assuming /tmp
// permissions are correct) that only root or our own
// user can replace the fifo with something else, such
// as a symlink.
//
// The server side is not intended to run as root, yet
// if it is, then we are still safe, due to the above logic.
// The client side can run as root (depending on what pppd
// does with pppob), and has no control over creation of
// the fifo, but only opens it for reading, never for
// creation or writing. (See FifoClient() below.)
//
// Therefore, we can only be attacked, via symlink,
// by root or ourselves.
//
int fd = open(BARRY_FIFO_NAME, O_WRONLY | O_NONBLOCK);
if( fd == -1 ) {
...
Also, Lintian in --info --display-info --pedantic mode still outputs
a bunch of relevant comments.
In my testing there were only info statements, which for the most part
I thought could be ignored. I beefed up the descriptions a bit to
avoid the extended-description-is-probably-too-short message.
For desktop-entry-contains-encoding-key, I added overrides with the
following explanation:
# The encoding key is set to UTF-8, and this is the default, and according
# to lintian help text, this is harmless. For the sake of simplicity
# and backward compatibility, it has been left in.
For no-symbols-control-file, I did some research, and found that it is
pretty tricky business to accomplish this for C++ libraries. I added
overrides with the following message:
# Barry is a C++ library, and as such it encounters similar struggles
# as documented here: http://www.eyrie.org/~eagle/journal/2012-01/008.html
# and here: http://www.eyrie.org/~eagle/journal/2012-02/001.html
# As well, Barry already uses the ABI Compliance Checker from
# linuxtesting.org to discover ABI/API breaks, and intends to bump the
# major number each time, and has had this policy since 0.17.x.
# See the following page for details:
# http://linuxtesting.org/upstream-tracker/versions/barry.html
Those were all the lintian messages that I found on my sid testing.
Since these issues only affected the debian/ directory, I spun a version
0.18.1-2 and have released it here:
http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/
I assume we can label the changelog version anything we want, until we
actually perform our first upload, and then it is written in stone.
Otherwise I have to bump the upstream version, and I'd prefer to avoid
that if possible, as it wastes space on sourceforge.net.
Let me know what you think.
Thanks,
- Chris
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, Apr 30, 2012 at 01:46:13PM +0200, intrigeri wrote: $ sudo apt-get install libconfig-model-perl $ cme check dpkg-copyright $ cme dump dpkg-copyright Thanks intrigeri. The cme check did find a syntax oddity, although the error message it produced was a bit cryptic. :-) I believe this release can be uploaded. Let me know if you agree, and what the next steps are. I'm assuming that you will do the actual upload? Or is this something I need to process? The sources and signed SHA1SUMS file can be found here: http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/ Thanks again for all your help! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (08 May 2012 06:01:58 GMT) : I believe this release can be uploaded. I'll review this package later this week, probably on Friday. I'm assuming that you will do the actual upload? I will, once I'm happy with the state of the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Tue, May 08, 2012 at 11:22:48AM +0200, intrigeri wrote: I'm assuming that you will do the actual upload? I will, once I'm happy with the state of the package. Excellent. Thanks very much. Let me know if you find any show stoppers. :-) - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Chris Frey wrote (30 Apr 2012 00:49:23 GMT) : Is there a tool I can use to make sure I've got the new format right? I ran it against lintian on sid, but I'm not sure if that's enough. $ sudo apt-get install libconfig-model-perl $ cme check dpkg-copyright $ cme dump dpkg-copyright (See also other `cme' sub-commands if interested :) Seems like recent Lintian has a check for it too, no idea which one of those is the strictest: http://lintian.debian.org/tags/syntax-error-in-dep5-copyright.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Fri, Apr 27, 2012 at 01:38:29AM +0200, intrigeri wrote: Looks like great work. Congrats! Thanks for the feedback! * can you please convert debian/copyright to DEP5 format? (you're almost there, see http://dep.debian.net/deps/dep5/) Is there a tool I can use to make sure I've got the new format right? I ran it against lintian on sid, but I'm not sure if that's enough. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Chris Frey wrote (25 Apr 2012 23:59:02 GMT) : The latest git sources from http://repo.or.cz/w/barry.git should compile on sid, with no lintian warnings. Please let me know what you think. Looks like great work. Congrats! I've not built the package yet. A quick review only reveals: * what's the purpose of carrying debian/upstream.cl? * can you please convert debian/copyright to DEP5 format? (you're almost there, see http://dep.debian.net/deps/dep5/) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi Chris, intrigeri wrote (26 Apr 2012 23:38:29 GMT) : Chris Frey wrote (25 Apr 2012 23:59:02 GMT) : The latest git sources from http://repo.or.cz/w/barry.git should compile on sid, I concur. with no lintian warnings. I see two kinds of warnings: debhelper-but-no-misc-depends and syntax-error-in-debian-changelog. These must be fixed. Make sure you run the latest lintian on *.changes. Running lintian with all checks on also reveals a few other, less important, informational messages, that may or may not be worth fixing right now, but generally indicate suboptimal stuff here and there: lintian --info --display-info --pedantic --color auto *.changes Apart of the lintian warnings, and the other questions I sent in my previous email, all this looks almost ready to be uploaded :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Apr 26, 2012 at 03:36:45PM +0200, intrigeri wrote: The latest git sources from http://repo.or.cz/w/barry.git should compile on sid, with no lintian warnings. Please let me know what you think. Where can I find the corresponding orig.tar.gz? I'm hoping to release a real 0.18.0 this weekend, but for your testing purposes, I've spun a source package and put it here: http://foursquare.net/cdfrey/barry/ Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi Chris, Chris Frey wrote (25 Apr 2012 23:59:02 GMT) : I'm hoping you're still interested in reviewing Barry for upload to Debian sid. Sure. As for Barry itself, there's only general documentation updates, and one feature in the Desktop GUI that needs to be implemented before version 0.18 is released. Nice to hear. As for the Debian packaging, it is ready for sid, to the best of my knowledge. Great. The latest git sources from http://repo.or.cz/w/barry.git should compile on sid, with no lintian warnings. Please let me know what you think. Where can I find the corresponding orig.tar.gz? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi intrigeri, I'm hoping you're still interested in reviewing Barry for upload to Debian sid. As for Barry itself, there's only general documentation updates, and one feature in the Desktop GUI that needs to be implemented before version 0.18 is released. As for the Debian packaging, it is ready for sid, to the best of my knowledge. By default, the Barry sources will include the command line utilities, the backup GUI, and the Desktop GUI without sync mode compiled in. The opensync plugins will also not be compiled. This is because the state of opensync in unstable still needs work. But that shouldn't hold Barry back. The latest git sources from http://repo.or.cz/w/barry.git should compile on sid, with no lintian warnings. Please let me know what you think. Thanks again, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Without opensync plugins, though, we should leave the Desktop out of Debian for now. Is there an easy way to make packages optional? There is, actually, a way to make your debian/control dynamic: http://lists.debian.org/msgid-search/87y5rcla88.fsf@algernon.balabit Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, Mar 19, 2012 at 06:53:19PM +0100, intrigeri wrote: Hi, Without opensync plugins, though, we should leave the Desktop out of Debian for now. Is there an easy way to make packages optional? There is, actually, a way to make your debian/control dynamic: http://lists.debian.org/msgid-search/87y5rcla88.fsf@algernon.balabit Thanks! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (03 Mar 2012 14:50:14 GMT) : Stable is what I had handy. I realize this is a work in progress. I suggest you use a pbuilder sid chroot to build packages that are supposed to be uploaded into sid at some point. There's a large body of work on the opensync side that is not yet visible to anyone in Debian. Maybe I can get that into Debian as well, but I doubt it will make the Wheezy deadline. Yeah, see the recent announce on debian-devel (today or yesterday) about the current poor state of opensync in Debian. Not reassuring. I've also fixed some lintian errors. The following warnings remain: W: opensync0-plugin-barry: new-package-should-close-itp-bug This can be ignored, I think. Putting two source packages into the same Git repository will be a pain. Let's talk about this other, new source package (opensync0-plugin-barry) later, and keep focused on the barry one to start with. By the way, I think the source package would be better called opensync-plugin-barry; and if it really needs to be a separate source package, Lintian is right, you need to fill an ITP for opensync-plugin-barry, and close it in its debian/changelog. I named it opensync0 since that plugin depends on libopensync0, which is available in Squeeze. libopensync0 was a binary library package built from the opensync source package. Using ABI numbers in such a binary package name is recommended. But I don't see any reason to use ABI numbers in the name of this *source* package, unless you really expect to maintain multiple opensyncN-plugin-barry *source* packages concurrently in Debian, which can be done, but generally needs to be backed with solid arguments. Anyway, the dependency on a package that is not part of Debian testing/unstable makes this plugin not suitable, as is, for Debian. Let's postpone the opensync part for now. The opensync-plugin-4x plugin depends on libopensync1 which is not yet officially released, but does work. That plugin is named opensync1-plugin I can't find any such package in Debian. In order to use both 0.22 opensync and 0.4x on the same system, the specific naming was needed. Can these two versions of opensync be installed concurrently on a Debian testing/sid system? But the entire opensync side of things can be postponed for now, at least where Debian is concerned. Ok. The opensync subdirectories do not get built automatically. Do you confirm you mean that the opensync-plugin/ and opensync-plugin/debian are part of the orig.tar.gz, shipped in the source package, but not used to build any binary package? I find it misleading to write barry (0.18.0-1) unstable in debian/changelog right now; I think it should only be done at the last minute, once the package is really ready to be uploaded to Debian unstable, which is not presently the case. Until this point is reached, I find it saner to: * either keep UNRELEASED instead of unstable * or manually manage lower-than-release but increasing version numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) * or use git-dch to get automated lower-than-release but increasing version numbers I'm not sure how this is misleading, since if it doesn't exist in Debian, then Debian shouldn't care. I, as the one who's spending time to review your packaging, and offered to sponsor your packages, do care. I find it useful to be able to infer, from a given package version number (be it a source or binary package built from your Git repository, or installed on my system), if it was a package that was uploaded to Debian or a random development snapshot. With the versionning scheme you're currently using, how can we distinguish between a package built from your current Git repository, and the package (with version 0.18.0-1 as well) that will hopefully get uploaded into Debian once all this stuff is sorted out? If git-dch can completely eliminate editing the changelog file, though, that might be worth looking into. It does not completely eliminate, but it avoids many of the usual pitfalls beginners at Debian packaging often fall in. Building in a sid chroot fails for me: [...] = missing build-deps? You need to make sure your package actually builds properly in a clean sid pbuilder chroot. Seriously, this is a prerequisite for any further review of mine. The Desktop GUI currently requires either libopensync0 or libopensync1, or both, and is fairly useless without the plugins to go along with it. It is tricky to compile the Desktop for both. Just to confirm I've understood what you mean, do you mean the desktop GUI binary package should depend on libopensync1exp7, and the source package should build-depend on whatever opensync -dev package? Without opensync plugins, though, we should leave the Desktop out of Debian for now. Is there an easy way to make packages optional? I'm not sure what you mean by optional. If a given binary package should not be built, just remove it from
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (04 Mar 2012 13:59:49 GMT) : I, as the one who's spending time to review your packaging, and offered to sponsor your packages, do care. I find it useful to be able to infer, from a given package version number (be it a source or binary package built from your Git repository, or installed on my system), if it was a package that was uploaded to Debian or a random development snapshot. With the versionning scheme you're currently using, how can we distinguish between a package built from your current Git repository, and the package (with version 0.18.0-1 as well) that will hopefully get uploaded into Debian once all this stuff is sorted out? I misunderstood who you were referring to. I can see how you would care, and it's not my intention to make it confusing. But once 0.18.0-1 is uploaded to Debian, my git repo should not say 0.18.0-1 anymore. My git repo contains the version number of the next release, so I can use it in the same state that it will be released in, and fix issues that arise. As soon as the release is made, the version gets bumped again. This does not answer the how can we distinguish... problem, and will therefore make things harder for reviewers and sponsors, who will lack any kind of version numbering to distinguish between package snapshots you show them, but well, in the end you decide. I would assume that if I'm doing the maintainer work, I'd have some say over when an upload happens, and could therefore update the version numbers appropriately. Sure. *You* prepare the packages, so *you* decide when it should get uploaded :) To clarify, the Desktop GUI which is found in Barry is designed to use either opensync 0.2x or 0.3x, or both. It uses dlopen to load the library manually, so technically opensync can be uninstalled completely and the Desktop will still run, just not sync. But in order to build, you need the headers, etc. This is a ./configure compile issue, and I haven't made it work The Debian Way(TM) yet. It only works in my binary-meta system. But since opensync 0.3x probably won't exist in Debian for now, you only need libopensync0-dev to build the Desktop. Ok. Fixing this FTBFS is top-priority as far as Debian is concerned. If it ain't buildin', then we can't ship it. Barry is much like the linux kernel source tree: everything is included, almost like modules, and everything gets built during development, in order to keep all code in lock step. This is done on purpose, in order to encourage developers to build and test the whole thing. But the subprojects are separate enough that they can be extracted if necessary. Thanks for clarifying. So while Barry won't be splitting up, a script could be added to create separate tarballs for you, if that makes it easier. Personally, I won't have any use for such tarballs. As long as you throw sane source packages at me, I'm happy. Sorry if I've been unclear, I'm not pushing towards artificially splitting. I don't think such source package splitting should be decided merely as a way to answer the initial question, that is how do you make packages build optionally. There are many other much more valid reasons to split, or not to split. At some point, *you* have to make a decision about which ones of these subprojects need to get its own source package, or not. You answered yes in practice to this question for the opensync plugin. Fine with me. But please, don't artificially move $APP into a dedicated source package only to make its build optional right now. I understand this is a cheap short-term solution, but splitting has serious long-term costs, such as making it harder to upgrade the splitted bits in lock step later. Maybe just create a branch dedicated for Debian, that removes these package from debian/control, and that's all? I have no guarantee that Barry (let alone opensync) will make it into Debian. So I really hesitate ripping up Barry's existing, and working, packaging for Debian, when I'll need it to release binary packages soon anyway. Fair enough. Barry making it into Debian or not now mostly depends on you, though :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sun, Mar 04, 2012 at 01:33:14PM +0100, intrigeri wrote: I named it opensync0 since that plugin depends on libopensync0, which is available in Squeeze. libopensync0 was a binary library package built from the opensync source package. Using ABI numbers in such a binary package name is recommended. But I don't see any reason to use ABI numbers in the name of this *source* package, unless you really expect to maintain multiple opensyncN-plugin-barry *source* packages concurrently in Debian, which can be done, but generally needs to be backed with solid arguments. I already do maintain two separate opensync plugin source trees. They are both included in Barry, under the opensync-plugin and opensync-plugin-0.4x directories. The opensync API changed significantly between 0.2x and 0.3x, hence the need for two plugin sources. The opensync-plugin-4x plugin depends on libopensync1 which is not yet officially released, but does work. That plugin is named opensync1-plugin I can't find any such package in Debian. The 0.3x version of opensync was called libopensync1exp7 in Debian, but may have been removed by now. In my own binary packaging for 0.3x I moved to calling the binary package libopensync1, since that matched the pkgconfig name to some degree. In order to use both 0.22 opensync and 0.4x on the same system, the specific naming was needed. Can these two versions of opensync be installed concurrently on a Debian testing/sid system? Yes. I'd have to double check the -dev packages, but I worked specifically to make it possible to install both at the same time. The opensync subdirectories do not get built automatically. Do you confirm you mean that the opensync-plugin/ and opensync-plugin/debian are part of the orig.tar.gz, shipped in the source package, but not used to build any binary package? Yes. There are opensync-plugin/debian and opensync-plugin-0.4x/debian that are both built separately, or as make targets from the root debian/rules file. The main subprojects (the plugins, the gui/, and the desktop/ directories) have their own configure scripts and can be used standalone if desired, although they all depend on the Barry library. I find it misleading to write barry (0.18.0-1) unstable in debian/changelog right now; I think it should only be done at the last minute, once the package is really ready to be uploaded to Debian unstable, which is not presently the case. Until this point is reached, I find it saner to: * either keep UNRELEASED instead of unstable * or manually manage lower-than-release but increasing version numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) * or use git-dch to get automated lower-than-release but increasing version numbers I'm not sure how this is misleading, since if it doesn't exist in Debian, then Debian shouldn't care. I, as the one who's spending time to review your packaging, and offered to sponsor your packages, do care. I find it useful to be able to infer, from a given package version number (be it a source or binary package built from your Git repository, or installed on my system), if it was a package that was uploaded to Debian or a random development snapshot. With the versionning scheme you're currently using, how can we distinguish between a package built from your current Git repository, and the package (with version 0.18.0-1 as well) that will hopefully get uploaded into Debian once all this stuff is sorted out? I misunderstood who you were referring to. I can see how you would care, and it's not my intention to make it confusing. But once 0.18.0-1 is uploaded to Debian, my git repo should not say 0.18.0-1 anymore. My git repo contains the version number of the next release, so I can use it in the same state that it will be released in, and fix issues that arise. As soon as the release is made, the version gets bumped again. I would assume that if I'm doing the maintainer work, I'd have some say over when an upload happens, and could therefore update the version numbers appropriately. The Desktop GUI currently requires either libopensync0 or libopensync1, or both, and is fairly useless without the plugins to go along with it. It is tricky to compile the Desktop for both. Just to confirm I've understood what you mean, do you mean the desktop GUI binary package should depend on libopensync1exp7, and the source package should build-depend on whatever opensync -dev package? Well, libopensync1exp7 should not be used at all. It is too old. The latest opensync 0.3x devel tree in git should be used instead, if we're going the devel tree route. To clarify, the Desktop GUI which is found in Barry is designed to use either opensync 0.2x or 0.3x, or both. It uses dlopen to load the library manually, so technically opensync can be uninstalled completely and the Desktop will still run, just not sync. But in order to build, you need the headers,
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Mar 01, 2012 at 09:26:34AM +0100, intrigeri wrote: The answer is basically none. Once can maintain a package in Debian (as is: doing maintenance work, being responsible, and being in the Maintainer: control field) without any kind of special status. Excellent! In the latest Barry git tree, I've updated the debian packaging to Standards-Version 3.9.1 (the latest for Squeeze) and the compat level to 7 (the latest for Ubuntu 10.04 LTS). I can keep pressing forward with the Standards-Version, but not the compat, since that halts builds on older systems. But compat 7 isn't too bad. I've also fixed some lintian errors. The following warnings remain: W: opensync0-plugin-barry: new-package-should-close-itp-bug This can be ignored, I think. W: barrydesktop: binary-without-manpage usr/bin/bsyncjail W: barry-util: binary-without-manpage usr/bin/hal-blackberry bsyncjail is used by the Desktop GUI to isolate the sync process, in case opensync crashes. It is not meant to be run by the user. Is there any harm in putting this in /usr/lib/barry or /usr/lib/barrydesktop? Similarly for hal-blackberry... that is just a script run by HAL to fill in device identification info. This could go in /usr/lib as well. Is it bad form to share a /usr/lib/barry directory between multiple packages? W: barrydesktop: package-name-doesnt-match-sonames libosyncwrap18 This is a library only used by the Desktop GUI, and therefore packaged right along with it. Someday it may be useful as a standalone library, and could be packaged that way, but it is not ready for that yet. I'm thinking this warning can be ignored for now too. Barry 0.18 is not yet released yet, but the Debian packaging is just about ready for when it is released. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (03 Mar 2012 08:27:32 GMT) : In the latest Barry git tree, I've updated the debian packaging to Standards-Version 3.9.1 (the latest for Squeeze) We don't wait until all previous Debian releases are EOL'd before we start following the latest Debian Policy. Please follow the latest available Standards-Version: Debian Policy 3.9.3 was released. See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz :) and the compat level to 7 (the latest for Ubuntu 10.04 LTS). I can keep pressing forward with the Standards-Version, but not the compat, since that halts builds on older systems. But compat 7 isn't too bad. Even squeeze-backports has debhelper 9+. I agree compat level 7 is not too bad, and this is obviously not a blocker at all, but I must state I strongly dislike the idea of refraining from using compat level 9 in Debian before 2015, merely because nobody has uploaded a recent debhelper into lucid-backports. We manage to be slow enough, by ourselves, to adopt recent changes at Debian, without needing any such external help to get things stalled. I've also fixed some lintian errors. The following warnings remain: W: opensync0-plugin-barry: new-package-should-close-itp-bug This can be ignored, I think. Putting two source packages into the same Git repository will be a pain. Let's talk about this other, new source package (opensync0-plugin-barry) later, and keep focused on the barry one to start with. By the way, I think the source package would be better called opensync-plugin-barry; and if it really needs to be a separate source package, Lintian is right, you need to fill an ITP for opensync-plugin-barry, and close it in its debian/changelog. However, the barry package Debian changelog should mention the adoption and close #657076. W: barrydesktop: binary-without-manpage usr/bin/bsyncjail W: barry-util: binary-without-manpage usr/bin/hal-blackberry bsyncjail is used by the Desktop GUI to isolate the sync process, in case opensync crashes. It is not meant to be run by the user. Is there any harm in putting this in /usr/lib/barry or /usr/lib/barrydesktop? IIRC /usr/lib/$BINARY_PACKAGE/$PROGRAM is appropriate, but please check the Debian Policy and FHS. Similarly for hal-blackberry... that is just a script run by HAL to fill in device identification info. This could go in /usr/lib as well. Seems so. Is it bad form to share a /usr/lib/barry directory between multiple packages? It's fine. W: barrydesktop: package-name-doesnt-match-sonames libosyncwrap18 This is a library only used by the Desktop GUI, and therefore packaged right along with it. Someday it may be useful as a standalone library, and could be packaged that way, but it is not ready for that yet. I'm thinking this warning can be ignored for now too. Agreed. Please add a lintian override, with these reasons as comments, then. Random other notes follow. Please migrate to 3.0 (quilt) source format (done in my branch). Please add Vcs-Git and Vcs-Browser control fields. There are still duplicate short package descriptions in debian/control (barrydesktop and barrydesktop-dbg). Please enable hardening build flags to build hardened compiled binaries and libraries: https://wiki.debian.org/HardeningWalkthrough (Yes, the proper way to do so needs recent debhelper and dpkg-dev. Maybe supporting older systems will require dedicated branches to carry tiny patches.) The compiling notes on top of debian/control should really be moved to debian/README.source. debian/control is no good place for documentation. I find it misleading to write barry (0.18.0-1) unstable in debian/changelog right now; I think it should only be done at the last minute, once the package is really ready to be uploaded to Debian unstable, which is not presently the case. Until this point is reached, I find it saner to: * either keep UNRELEASED instead of unstable * or manually manage lower-than-release but increasing version numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) * or use git-dch to get automated lower-than-release but increasing version numbers About debian/changelog: * it removes history about all recent uploads to Debian; it should absolutely not do this. * I don't think we care about that granular history: + * bumped compat to level 6 (2011/06/28) + * reviewed debhelper(7) manpage changes and updated compat to 7 (2012/03/03) We've Git for this. * On the other hand, your debian/changelog seems to lack much information my own version of this file has. Possibly because you're only mentioning changes since your last own package. But we're preparing an upload to Debian, so debian/changelog must mention the changes from the last version uploaded to Debian to the current one. The debian/0.15-1.2 tag may be useful when gathering such informations, although I've already done most of the work in my branch, and I suggest starting from
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sat, Mar 03, 2012 at 02:54:34PM +0100, intrigeri wrote: We don't wait until all previous Debian releases are EOL'd before we start following the latest Debian Policy. Please follow the latest available Standards-Version: Debian Policy 3.9.3 was released. See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz :) Stable is what I had handy. I realize this is a work in progress. I used the upgrade checklist to move from 3.8.0 to 3.9.1, without much change needed. I agree compat level 7 is not too bad, and this is obviously not a blocker at all, but I must state I strongly dislike the idea of refraining from using compat level 9 in Debian before 2015, merely because nobody has uploaded a recent debhelper into lucid-backports. We manage to be slow enough, by ourselves, to adopt recent changes at Debian, without needing any such external help to get things stalled. There's a large body of work on the opensync side that is not yet visible to anyone in Debian. Maybe I can get that into Debian as well, but I doubt it will make the Wheezy deadline. I've also fixed some lintian errors. The following warnings remain: W: opensync0-plugin-barry: new-package-should-close-itp-bug This can be ignored, I think. Putting two source packages into the same Git repository will be a pain. Let's talk about this other, new source package (opensync0-plugin-barry) later, and keep focused on the barry one to start with. By the way, I think the source package would be better called opensync-plugin-barry; and if it really needs to be a separate source package, Lintian is right, you need to fill an ITP for opensync-plugin-barry, and close it in its debian/changelog. I named it opensync0 since that plugin depends on libopensync0, which is available in Squeeze. The opensync-plugin-4x plugin depends on libopensync1 which is not yet officially released, but does work. That plugin is named opensync1-plugin In order to use both 0.22 opensync and 0.4x on the same system, the specific naming was needed. There used to be an opensync-plugin-barry in Lenny, as I recall. According to the Barry PTS log (if I read it right), the entire set of barry binaries was removed because of a python 2.6 issue, which was triggered by opensync. Barry should not have been yanked due to that. Only the opensync plugin. But the entire opensync side of things can be postponed for now, at least where Debian is concerned. The opensync subdirectories do not get built automatically. IIRC /usr/lib/$BINARY_PACKAGE/$PROGRAM is appropriate, but please check the Debian Policy and FHS. I couldn't find any mention of /usr/lib in the policy. Glad to see my assumption was correct. I find it misleading to write barry (0.18.0-1) unstable in debian/changelog right now; I think it should only be done at the last minute, once the package is really ready to be uploaded to Debian unstable, which is not presently the case. Until this point is reached, I find it saner to: * either keep UNRELEASED instead of unstable * or manually manage lower-than-release but increasing version numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) * or use git-dch to get automated lower-than-release but increasing version numbers I'm not sure how this is misleading, since if it doesn't exist in Debian, then Debian shouldn't care. If git-dch can completely eliminate editing the changelog file, though, that might be worth looking into. Building in a sid chroot fails for me: checking for OPENSYNC22... no checking for OPENSYNC40... no configure: error: Unable to find development libraries for either opensync 0.22 or 0.4x. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables: OPENSYNC22_CFLAGS and OPENSYNC22_LIBS or OPENSYNC40_CFLAGS and OPENSYNC40_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure: error: ./configure failed for desktop make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 = missing build-deps? The Desktop GUI currently requires either libopensync0 or libopensync1, or both, and is fairly useless without the plugins to go along with it. It is tricky to compile the Desktop for both. Without opensync plugins, though, we should leave the Desktop out of Debian for now. Is there an easy way to make packages optional? The way I've done it so far is adding debian/ directories in the subprojects, as completely separate source trees, like the opensync plugins are. As for the rest of your list, thank you for the feedback. This will take some time to process. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble?
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (01 Mar 2012 01:59:39 GMT) : How much lag time is there between applying for maintainer status, and being able to have sponsored uploads? The answer is basically none. Once can maintain a package in Debian (as is: doing maintenance work, being responsible, and being in the Maintainer: control field) without any kind of special status. However, at some later point, you'll probably want to apply for the Debian Maintainer [1] or Debian Member [2] status and get upload rights. See [3] for disambiguation. [1] http://wiki.debian.org/DebianMaintainer [2] http://www.debian.org/devel/join/newmaint [3] http://wiki.debian.org/Maintainers If someone else steps up in the meantime, I would greatly appreciate the help! But if nobody does, I still want to have Barry in Debian, and so far it looks like it's up to me. :-) Glad to read this. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi Chris! One month has passed, and nobody adopted the barry package in Debian; the Wheezy freeze will happen in a few months. I suggest you decide whether you want to take care of barry in Debian, so that we avoid uploading packages in a hurry at the last minute. My help proposal (reviews and sponsoring) still holds :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | The impossible just takes a bit longer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Mar 01, 2012 at 01:37:42AM +0100, intrigeri wrote: Hi Chris! One month has passed, and nobody adopted the barry package in Debian; the Wheezy freeze will happen in a few months. I suggest you decide whether you want to take care of barry in Debian, so that we avoid uploading packages in a hurry at the last minute. My help proposal (reviews and sponsoring) still holds :) Hi intrigeri, Thanks for the heads-up, and the renewed offer of help. After some consideration, I'd like to release version 0.18 of Barry in the next month or so, and I'd like to do so before adding more complexity to my plate. I'm hoping this is possible. How much lag time is there between applying for maintainer status, and being able to have sponsored uploads? It would be really nice to upload 0.18 in the next month, but I still have much work to do to achieve that. If someone else steps up in the meantime, I would greatly appreciate the help! But if nobody does, I still want to have Barry in Debian, and so far it looks like it's up to me. :-) Thanks again, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (27 Jan 2012 02:58:23 GMT) : Changelog: The changelog needs to be kept up to date in Debian. I've tried to limit myself to just using my own entry at the top, but I'm willing to find a better way to share that file if downstream wants to work with me. Are you thinking of the upstream ChangeLog or of debian/changelog? I'm referring to the upstream debian/changelog. If the Debian maintainer zaps what I have, and just uses his own debian/ directory, there's no conflict, but there have been conflicts in the past, when we both update it, and so I've tried to keep my changes there minimal. I don't understand very well what you are expecting from the Debian maintainer. Be them anyone else or (soon?) yoursef, what they must put in debian/changelog is: * the entry corresponding to the new uploaded version * [optional: entries corresponding to intermediate, not uploaded versions; the version numbers must be strictly between the previously uploaded version, and the newly uploaded one.] * the content of the debian/changelog file present in the last upload to Debian The Debian maintainer *has to* maintain debian/changelog. If you're changing it too in the upstream repo, very well, but then there will be conflicts, unavoidably. The good news are: these conflicts are nothing surprising, often seen e.g. when maintaining a -backports branch, and trivial to resolve. Am I failing to see the actual problem? My suggestion would be: * only publish your changes to debian/changelog when you actually want to publish a snapshot package, be it in the upstream APT repository or into Debian. * use git-dch to get intermediary snapshots versions (this will give you something like 0.18.0-1~1.gbp9cb656, 0.18.0-1~2.gbp646619 and so on) that won't conflict between themselves or with the official Debian ones, and that will provide sane upgrade paths. But I'm a Debian user on my main system, so maybe it gets special treatment. :-) :) From my experience as an upstream developer, bug reports coming from Debian generally are more useful than the many it does not work one can repeatedly receive from other sources. In other words, they are generally *bug reports*, rather than help requests (which are fine by themselves, especially when submitted to the right place). Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Who wants a world in which the guarantee that we shall not | die of starvation would entail the risk of dying of boredom ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Fri, Jan 27, 2012 at 10:20:10AM +0100, intrigeri wrote: I don't understand very well what you are expecting from the Debian maintainer. Be them anyone else or (soon?) yoursef, what they must put in debian/changelog is: Oh, I know the changelog must be updated, but some maintainers have the opinion that upstream should not have a debian/ directory. So when they do, there's conflicts. If the Debian maintainer wants to keep it up to date, I'm happy to let him, since my main changelog is in the git commit fields anyway. I don't usually get patches to my repo for the debian/ directory, so I ended up trying to keep changes to debian/ minimal, so that the diffs for downstream would be smaller. Of course, if I'm the maintainer, I'll have to keep it more up to date than I have been. * use git-dch to get intermediary snapshots versions (this will give you something like 0.18.0-1~1.gbp9cb656, 0.18.0-1~2.gbp646619 and so on) that won't conflict between themselves or with the official Debian ones, and that will provide sane upgrade paths. Cool... I may need to look into this. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi Chris, Chris Frey wrote (24 Jan 2012 01:04:48 GMT) : 1) Version 0.18 is nearing readiness I'm hoping to release 0.18, maybe mid-Feb. There's a GUI in development to make syncing with opensync easier as well. It would be nice to have this coordinated with Debian packaging. Sure. Well, once my initial helping round is finished, I'll let you coordinate this with whoever decides to take care of this in Debian. 2) I've applied some of your changes to upstream's packaging too, thanks! There are a couple of incompatabilities between upstream and Debian's packaging. Changelog: The changelog needs to be kept up to date in Debian. I've tried to limit myself to just using my own entry at the top, but I'm willing to find a better way to share that file if downstream wants to work with me. Are you thinking of the upstream ChangeLog or of debian/changelog? udev: Also, I try to support old versions of Debian and Ubuntu... the oldest that I support is Ubuntu 8.04 (LTS) and the latest Debian stable. Ubuntu 8.04 uses udev 117, which is the oldest one I work with (even when taking Fedora 11 into account). I notice that your packaging depends on = 136. I'm not sure if there is a technical reason for this. This versionned dependency was brought in Debian by Riku Voipio's 0.15-1.1 NMU. It seems (being offline, I've not checked the actual packages) this change was actually imported from... Ubuntu's 0.15-1ubuntu1, uploaded to Ubuntu for Lucid by Bhavani Shankar right2bh...@gmail.com on 06 Nov 2009. I guess one particularly interested in supporting Ubuntu 8.04 would need to see with this person, and possibly others at Ubuntu, why they did this undocumented change in the first place. Anyway, this versioned dependency is a no-op in Debian as Squeeze has udev 164-3, so I just removed it in my own packaging repo. Nag me if I forget to push when I'm back online. 3) I rely a lot on the maintainers to funnel bug reports upstream to the barry-devel mailing list. Some bugs may be distro specific, and might only need a change in the build scripts, but others like udev changes, I'd like to hear about, and maybe fix upstream if it makes sense. Sure. What about subscribing to the package PTS? - http://packages.qa.debian.org/b/barry.html So in that respect, a distro maintainer can save himself a lot of time if he regularly pings me on the mailing list regarding bug reports. Please do! This kind of thing is part of the duties of a Debian maintainer. 4) Barry library version numbers I've been pig-headed in the past about this, and that may be why some of the Debian packaging has been so old. I've since updated my doc/VersionNotes file which explains my versioning plans. Basically, if the library API / ABI changes, I bump the major number, which wasn't always guaranteed in the past. Version 0.18 is due to API changes, as well as lots of features. The 0 is just a logical version. The 18 is used as the library's major version, and any other versions, such as 0.18.1 is the minor. The binary packaging hasn't yet made the jump. It still uses the logical version 0 as part of the binary packaging name. i.e. libbarry0. But it could just as well be libbarry18, and would allow multiple versions of the library to be installed at once. Sounds great. 5) I'm also working on a project called binary-meta. [...] But there's no reason that Debian can't take advantage of this work as well. Latest opensync development sources, which I'm maintaining, are in git repositories. I'd be happy to work with a maintainer who is interested in trying any of this out. Maybe start with filing a Request For Package bug? Sorry I can't provide URLs since I'm offline. 6) Me as a Debian maintainer I suppose this would make some sense, but if there are others who are willing to volunteer, I would be very happy to work with them. I try to be as responsive as possible to any Barry emails, whether direct or via the barry-devel mailing list. I suggest subscribing to the RFA bug filed by José, which I'm now Cc'ing this discussion to: http://bugs.debian.org/657076 This way you'll know if anyone volunteers. In case nobody volunteers, well, I guess you'll have to make your own decision. 7) Specific responses: However, on the short run, a few other problems would need fixing to get things up-to-date with current packaging standards: * deprecated debhelper compatibility level (4) At least the way -dbg packages are currently built is not compatible with newer levels. * ancient Standards-Version (3.8.0) A look at the upgrading checklist would be worth it. Hopefully the version can be
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Jan 26, 2012 at 02:04:42AM +0100, intrigeri wrote: Changelog: The changelog needs to be kept up to date in Debian. I've tried to limit myself to just using my own entry at the top, but I'm willing to find a better way to share that file if downstream wants to work with me. Are you thinking of the upstream ChangeLog or of debian/changelog? I'm referring to the upstream debian/changelog. If the Debian maintainer zaps what I have, and just uses his own debian/ directory, there's no conflict, but there have been conflicts in the past, when we both update it, and so I've tried to keep my changes there minimal. This versionned dependency was brought in Debian by Riku Voipio's 0.15-1.1 NMU. It seems (being offline, I've not checked the actual packages) this change was actually imported from... Ubuntu's 0.15-1ubuntu1, uploaded to Ubuntu for Lucid by Bhavani Shankar right2bh...@gmail.com on 06 Nov 2009. I guess one particularly interested in supporting Ubuntu 8.04 would need to see with this person, and possibly others at Ubuntu, why they did this undocumented change in the first place. Thanks! Sure. What about subscribing to the package PTS? - http://packages.qa.debian.org/b/barry.html I didn't realize this was possible. Thanks. There is an upper limit on what an upstream maintainer can subscribe to, though, given the sheer number of distros and versions of distros available, plus the number of BlackBerry forums where Barry is discussed. I can't track them all. But I'm a Debian user on my main system, so maybe it gets special treatment. :-) Feel free to ask questions. Thanks! * missing manpages for bktrans, brimtrans and btranslate ... Either they're not installed, and I will just shut up :) They've been removed. :-) I'm not sure I'll do any more active work on this topic myself, but don't hesitate asking questions; also, I'll be happy to sponsor uploads if the need arises, that is if a team without Debian developers with upload rights adopts the barry package in debian. I understand, but I appreciate the work you've done so far. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
