[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: libopenobex (also includes openobex-apps and ircp)



Hello,

Hendrik Sattler wrote:

Is the API/ABI sufficiently stable? I see that the Debian patch
introduces a new parameter to a function.

This is inside the apps/ subdirectory which is not part of the lib. The patch was already in the openobex-apps package and I took it over since it still applies. The referring changelog entry from openobex-apps:
  * Apply patch to enable control of creator ID with irobex_palm3.
    Thanks to Bruno David Rodrigues. (Closes: #185833)

Ah, okay. Like I said, I only glanced at the package.

That leaves the question if the previously seperated changelogs should be included?

It would help to have it documented somehow, not as if I would ever read a file called README.

Intention was to leave package in there current state and address the presently filed bugs after the first upload.

I can live with that, but expect a long delay in NEW if the diff is huge and/or complicated. Some people actually read them, I was told.

1. If it's going to end up in a separate package anyway, there is no
point in pulling in source code from other projects as a patch.

I didn't but upstream did. Previously, upstream seperated the source in three packages but gave up on that with the current release (it is a configure parameter now to build the apps).

Yes, but it shows up as added files in the Debian patch, which it shouldn't IMO, especially if it builds upon a library.

It is already in the upstream source. See
http://sourceforge.net/project/showfiles.php?group_id=8960&package_id=9047
and compare versions 1.1 and 1.0 (1.0.1 was not packaged).

Okay, so it would be safe to remove the source code from the Debian patch?

Other DDs told me that shipping the seperated patches with the package is actually wanted. That leaves only one more copy in the .pc subdir. However, deleting it means that if someone else works on an additional patch, he has to re-do all previous ones (as that is how quilt works).
Thus the only "fix" would be to not use quilt at all.

Hrm, would it be possible to try to get the "functional" patches integrated upstream? I tend to just leave them in the Debian patch and not do any further tracking on them, then silently rejoice when uupdate tells me that hunks have been ignored.

Also, there still are a number of lintian warnings.

W: openobex-apps: binary-without-manpage irobex_palm3
W: openobex-apps: binary-without-manpage irxfer
W: openobex-apps: binary-without-manpage obex_tcp
W: openobex-apps: binary-without-manpage obex_test

Those are mentioned in the TODO file of that package. It needs some work, sure. If you require that before first upload, then I'll do that. However, I'd rather move that to -2.

No problem. If I were to say otherwise, people would point at my packages. <ducking&running>

What about the linda-warning?:
W: libopenobex; Paketversion 1.1-1 ist geringer als 1:1.0.0-rel-3.

I was under the assumption that I don't have to take the epoch over to the new package (binary package names are different, source package name is different). However, the linda test may be broken.

Yes, the linda test probably goes through the changelog only, which is the only thing it can do, as it cannot check whether the package built different binaries before. Did really all of the binary package names change?

I could see a bit of merit in getting this package into unstable sooner
than later, to allow the depending packages to adapt and bugs be ironed
out before the release. As I don't see any policy violations or
regressions from a quick glimpse over the package, I might be persuaded
to upload this still (after a more thorough check) and file bugs for the
issues remaining.

Great. Don't miss the updated version (note: package version did not change!).

Okay, but it won't be until later this evening or probably tomorrow as I'm pretty busy during the week. If someone else wants to go ahead in the meantime, please drop me a line.

I also plan on packaging other OBEX related packages, e.g. wnpp bug
#238314.

Are you by chance interested in taking over ussp-push as well?

I am not sure as obexftp can do the same thing by now (and qobex, too) when using no uuid. However, I'll take a look at it, maybe there's more to it than the description says.

Really? I thought PUSH was pretty much a different protocol, with a different purpose, on a different channel, just using the same object format.

   Simon

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: