Re: RFS: libopenobex (1.2-2) and obexftp (0.19-2)
Hi, Michael Meskes was so kind to sponsor libopenobex :) Someone interested to sponsor obexftp? HS pgpVugCea0FcI.pgp Description: PGP signature
RFS: libopenobex (1.2-2) and obexftp (0.19-2)
Hi, both packages are already in the archive and I am already the maintainer of both (source) packages. However, my sponsors for each of the packages didn't react upon my please upload mails for quite some time now. The (signed) packages can be found at http://www.stud.uni-karlsruhe.de/~ubq7/debian/ ready for apt-get source or whatever access is prefered. For libopenobex, it fixes #359061, #359201 and #359026. For obexftp, it now uses the new libopenobex and supports quite some more models (e.g. Nokia USB access). Maybe someone is willing to sponsor those packags. Thanks a lot. Hendrik Sattler PS: Please CC me as I am not subscribed. pgp8AAI8X5IZ6.pgp Description: PGP signature
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Hi, there is still no sponsor for these packages, so this is another post to find sponsors for obexobex. Am Montag, 20. Februar 2006 12:33 schrieb Simon Richter: 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. See http://openobex.triq.net/obexftp/services So to replace ussp-push, you can simply use the obexftp options -H -U none And maybe omit the -l option in this case. If the phone still differs, define the proper bluetooth channel. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Hello, Am Montag, 20. Februar 2006 02:43 schrieb Simon Richter: Hendrik Sattler schrieb: The new package can be found at: http://www.stud.uni-karlsruhe.de/~ubq7/debian/ The source package got renamed (libopenobex1.0 - libopenobex) as it was once (in oldstable) and the binary packages got renamed, too (libopenobex-1.0-0 - libopenobex1). The naming is thus consistent with the libpkg-guide. 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) That leaves the question if the previously seperated changelogs should be included? Intention was to leave package in there current state and address the presently filed bugs after the first upload. I also notified the maintainer of ircp but did not get any answer so far. However, I included any patches of the previously seperated packages. The patches are handled by quilt (no build-time patching). There are two issues I have with that: 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). I believe this to be too broad a change for a simple package. If it is a separate project, it is a separate package. If it is not, it should be contained in the upstream source already (on the very extreme side of that, when I packaged spandsp I packaged the library on its own and added the example code, a bunch of asterisk plugins, by creating a tarball from the loose files that were on the author's website). It is already in the upstream source. See http://sourceforge.net/project/showfiles.php?group_id=8960package_id=9047 and compare versions 1.1 and 1.0 (1.0.1 was not packaged). 2. Every file that is added is contained three times in the diff (look at the diffstat output), once for quilt's hidden directory, once for debian/patches and once for the actual file being patched. 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. 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. W: openobex-apps: old-fsf-address-in-copyright-file W: libopenobex1-dev: old-fsf-address-in-copyright-file W: libopenobex1: old-fsf-address-in-copyright-file W: ircp: old-fsf-address-in-copyright-file That should be changed before uploadingdone. A new version of the 1.1-1 is available. 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. I hope that someone can sponsor this new version; getting obexftp-0.19 also uploaded would be a bonus :) 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!). 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. HS pgpvOZpQluif0.pgp Description: PGP signature
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Am Montag, 20. Februar 2006 12:33 schrieben Sie: 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. I'll see what can be done to include them... 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. Ok, I'll remove them the .pc directory 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? For the previous library: yes. The now two additional packages previously had: openobex-apps (1.0.0-rel-6) ircp (0.3-2) Should be ok. I just got approval from the ircp maintainer to take over. 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. As I said, I'll have a look at it. The effects on my hardware (several Siemens mobile phones) is the same for both. HS pgptEko3drJlo.pgp Description: PGP signature
RFS: libopenobex (also includes openobex-apps and ircp)
Hi,
This is about changing maintainership of a new version of libopenobex which is
already in Debian.
libopenobex is a GPL'ed library for the OBEX protocol which supports
Bluetooth, IrDA, TCP and in this new version also USB.
The new control is listed at the bottom of this mail.
I am currently the obexftp maintainer (sponsored by Michael Banck) and would
like to maintain libopenobex, too. However, not being a DD, I need
sponsorship and Edd Dumbill is pretty busy currently. The history is shown at
in the BTS as bug #237386
The new package can be found at:
http://www.stud.uni-karlsruhe.de/~ubq7/debian/
The source package got renamed (libopenobex1.0 - libopenobex) as it was once
(in oldstable) and the binary packages got renamed, too (libopenobex-1.0-0 -
libopenobex1). The naming is thus consistent with the libpkg-guide.
The following packages currently use libopenobex:
affix
kdebluetooth
libaffix2
libmultisync-plugin-irmc
libmultisync-plugin-irmc-bluetooth
obexserver
ussp-push
Once uploaded, I would notify the respective maintainers.
The following packages are directly affected by this source:
libopenobex-1.0-0: renamed to libopenobex1 in the new package
libopenobex-1.0-0-dev: now libopenobex1-dev (both provide libopenobex-dev)
openobex-apps: not shipped seperately anymore, same source as libopenobex
ircp: not shipped seperately anymore, same source as libopenobex
and
obexftp: above repository has obexftp-0.19 that uses the new lib
I also notified the maintainer of ircp but did not get any answer so far.
However, I included any patches of the previously seperated packages. The
patches are handled by quilt (no build-time patching).
I hope that someone can sponsor this new version; getting obexftp-0.19 also
uploaded would be a bonus :)
I also plan on packaging other OBEX related packages, e.g. wnpp bug #238314.
- libopenobex debian/control
Source: libopenobex
Priority: optional
Section: admin
Maintainer: Hendrik Sattler [EMAIL PROTECTED]
Build-Depends: debhelper ( 4.0.0), autotools-dev, libbluetooth1-dev (=
2.2), libusb-dev (= 2:0.1.11), pkg-config, docbook-utils
Standards-Version: 3.6.2.0
Package: libopenobex1-dev
Section: libdevel
Conflicts: libopenobex-dev
Provides: libopenobex-dev
Architecture: any
Depends: libopenobex1 (= ${Source-Version}), libbluetooth1-dev (= 2.2),
libusb-dev (= 2:0.1.11), pkg-config
Description: OBEX protocol library - development files
The Object Exchange protocol can best be described as binary HTTP.
OBEX is optimised for ad-hoc wireless links and can be used to exchange
all kind of objects like files, pictures, calendar entries (vCal)
and business cards (vCard).
.
OBEX is builtin in devices like PDA's like the Palm Pilot, and mobile
phones like the Ericsson R320, Siemens S25, Siemens S45, Siemens ME45,
Nokia NM207 and Nokia 9110 Communicator.
.
This package contains the development files.
Package: libopenobex1
Section: libs
Depends: ${shlibs:Depends}
Architecture: any
Description: OBEX protocol library
The Object Exchange protocol can best be described as binary HTTP.
OBEX is optimised for ad-hoc wireless links and can be used to exchange
all kind of objects like files, pictures, calendar entries (vCal)
and business cards (vCard).
.
OBEX is builtin in devices like PDA's like the Palm Pilot, and mobile
phones like the Ericsson R320, Siemens S25, Siemens S45, Siemens ME45,
Nokia NM207 and Nokia 9110 Communicator.
Package: openobex-apps
Architecture: any
Depends: ${shlibs:Depends}
Description: Applications for OpenOBEX
The Object Exchange protocol can best be described as binary HTTP.
OBEX is optimised for ad-hoc wireless links and can be used to exchange
all kind of objects like files, pictures, calendar entries (vCal)
and business cards (vCard).
.
OBEX is builtin in devices like PDA's like the Palm Pilot, and mobile
phones like the Ericsson R320, Siemens S25, Siemens S45, Siemens ME45,
Nokia NM207 and Nokia 9110 Communicator.
.
This package contains some small utilities to control such devices.
Package: ircp
Architecture: any
Depends: ${shlibs:Depends}
Description: Utility for beaming files via IRDA
ircp transfers files to/from Linux, Windows and PDAs
via IRDA. It is designed for working e.g. with Quickbeam.
- libopenobex debian/control
Hendrik Sattler
PS: on answers, please CC me
pgpnhXuhw5TRe.pgp
Description: PGP signature
