Hi Inrigeri,
Thanks very much for your feedback. I have a few comments:
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.
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.
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.
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.
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!
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.
5) I'm also working on a project called binary-meta.
I'm slowly working on opensync integration with Barry, as well
as general opensync functionality. I want to see opensync 0.4x
released, and I need testers to help with that. To that end,
I've created binary-meta, which I'm using to help create binary
packages for both opensync and Barry, as one harmonious system.
The binary-meta tree is just a git repo, that uses git submodules
to pull in git repositories of the opensync library, the supported
opensync plugins, and Barry, with a top level makefile that
supports building the whole thing without installing anything
along the way. This makes it easy for end users to create
binary packages to test with, as well as for me to create an
apt-get repo for users. This is my plan for the upcoming version
0.18.
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.
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.
7) Specific responses:
> Additionally, I think the new upstream release may also fix the
> following issues, although I've not checked in details:
>
> * Debian bug #600469: No mount possible due to 10-blackberry.rules
Yes, there were USB claim changes made. I would highly encourage
trying 0.17 or the upcoming 0.18. Either should fix this. I haven't
heard of a USB claim error in a long time.
> * Debian bug #582195: Cannot backup content as a regular user
> (permissions issue)
If udev is working, this bug won't show up. Again 0.17 / 0.18 should
have this fixed. But he makes a good point about a user-friendly
error message. I've added it to my todo list to double check this.
> 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 bumped with no changes.
I'm still trying to support old distros, but I'm not sure how to check
the levels on, say, Ubuntu 8.04. I agree that these things should be
updated, but this reflects my non-expert status when it comes to
packaging and especially policy.
> * missing manpages for bktrans, brimtrans and btranslate
These are really development tools... used to translate USB logs into
something more useful, with hex + ascii dumps, for USBSnoop logs
on Windows (btranslate), RIM driver logs (brimtrans), and usb snoop
Linux kernel logs. I'm not sure they should even be installed, since
someone poking around at the USB level is probably going to be coding
anyway. :-)
> Would be nice to fix too:
>
> * missing debian/watch
Interesting. Can be done... I hadn't thought that tarball location
mattered until now. :-)
> * package descriptions are quite short and rough on the edges
True. Suggestions very welcome.
> * no symbols control file for libbarry0
Do you have a pointer to an example for this?
> * libraries package name not reflecting soname
This can be changed now, as I mentioned above.
Thanks again for this work!
- Chris
On Mon, Jan 23, 2012 at 10:09:21PM +0100, intrigeri wrote:
> Hi,
>
> I am writing all interested parties I have heard of because I am
> slightly concerned about the state of the barry packages in Debian,
> and consequently in Ubuntu: the last maintainer upload (by Jose Carlos
> Garcia Sogo) is more than two years old. Since then, two
> non-maintainer uploads fixed the most important problems, but the
> general state has room for improvements, and it's been lagging behind
> upstream for more than two years.
>
> However, I'm pretty sure we can reach some kind of successful outcome
> if a handful of us give a hand.
>
> In the hope to get things started, I have imported all recent Debian
> uploads into a Git repository - gbp + pristine-tar -style. Then,
> I have cherry-picked a trunkload of commits that seemed worth it from
> upstream's packaging repository, maintained by Chris; the resulting
> delta is quite small, most differences can be easily explained and
> hopefully resolved; I must say Chris already does most of the work of
> maintaining Debian packages of barry, although unfortunately not as
> part of Debian (more to come later, please read on). While I was at
> it, I've also fixed a bunch of trivial packaging errors detected
> by Lintian.
>
> The resulting source package builds properly. I cannot test it as
> I don't own the hardware barry is meant to support. I think it's worth
> being uploaded to Debian unstable, and is unlikely to make things much
> worse than they already are.
>
> My Git repository can be cloned this way:
>
> gbp-clone git://gaffer.ptitcanardnoir.org/barry.git
>
> The resulting package would solve at least the following issues:
>
> * deprecated Udev rules issues
> https://bugs.launchpad.net/ubuntu/+source/barry/+bug/500370
> * Debian bug #582187: Manpage references to a non-existant URL
> * Debian bug #598878: typo in package description
> * Debian bug #582189: New upstream version available
>
> Additionally, I think the new upstream release may also fix the
> following issues, although I've not checked in details:
>
> * Debian bug #600469: No mount possible due to 10-blackberry.rules
> * Debian bug #582195: Cannot backup content as a regular user
> (permissions issue)
>
> 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 bumped with no changes.
> * missing manpages for bktrans, brimtrans and btranslate
>
> Would be nice to fix too:
>
> * missing debian/watch
> * package descriptions are quite short and rough on the edges
> * no symbols control file for libbarry0
> * libraries package name not reflecting soname
>
> So, what to do from here?
>
> Let me state very clearly I will *not* maintain this package in
> Debian. I'm merely interested in it because we have been shipping it
> in Tails??[0] for a while, and getting it in a backportable state
> implied to fix the RC bugs in it to start with. But I'm far from being
> interested enough to commit myself to do good work on the long run on
> this package.
>
> [0] https://tails.boum.org/
>
> However, I'm happy to help bootstrap some process that would make
> barry's state better in Debian and Ubuntu. I'd be happy to help anyone
> wanting to take responsibility of this. Both Chris and Martin have
> been working on barry packaging recently, you may be interested to do
> so directly in Debian, maybe by helping Jose, as part of a team,
> maybe together?
>
> Jose, please tell us what your plans regarding barry are. Are you
> still interested in this package? Maybe you only needed a heads up and
> some help to catch up with the backlog?
>
> 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
