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
<right2bhavi@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 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.
The desire to provide packages compatible with older distributions is
one thing. The need to provide package that are correct enough by
today's distributions standards, to make it possible for them to ship
barry in their next releases, is another thing. I'm sure you don't
want to sacrifice the later to keep the former. In any case, backports
exist exactly for this: the master packaging branch should always
target next Debian release, but it does not prevent at all maintaining
separate branches, if needed, with the minor changes that might be
necessary for lucid-backports, squeeze-backports, or hardy-backports.
> I agree that these things should be updated, but this reflects my
> non-expert status when it comes to packaging and especially policy.
My own experience was that updating such compatibility and standards
level is an excellent, although non-trivial, way to learn much in this
field :)
Feel free to ask questions.
>> * 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. :-)
It seems to me you're the best one to decide.
Either they're installed, and they need (even basic) manpages, and
people will use them and report bugs.
Either they're not installed, and I will just shut up :)
>> * package descriptions are quite short and rough on the edges
> True. Suggestions very welcome.
$ sudo apt-get install developers-reference maint-guide
I'm sure one of these documentations has very good guidelines and do /
don't lists.
>> * no symbols control file for libbarry0
> Do you have a pointer to an example for this?
Lintian tells me:
I: libbarry0: extended-description-is-probably-too-short
I: libbarry0: no-symbols-control-file usr/lib/libbarrybackup.so.17.0.1
N:
N: Although the package includes a shared library, the package does not
N: have a symbols control file.
N:
N: dpkg can use symbols files in order to generate more accurate library
N: dependencies for applications, based on the symbols from the library
N: that are actually used by the application.
N:
N: Refer to the dpkg-gensymbols(1) manual page and
N: http://wiki.debian.org/UsingSymbolsFiles for details.
BTW, I seriously recommend running lintian *systematically* against
your source and binary packages.
>> * libraries package name not reflecting soname
> This can be changed now, as I mentioned above.
Just do it? :)
> Thanks again for this work!
:)
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.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Did you exchange a walk on part in the war
| for a lead role in the cage?
Reply to: