From: Marcel H. <ma...@ho...> - 2009-05-18 21:28:55
|
Hi guys, so I think it is time to release openobex-1.6 during some time next week. What are the pending patches? Regards Marcel |
From: Alex K. <ak...@se...> - 2009-05-19 06:18:50
|
2009/5/19 Marcel Holtmann <ma...@ho...>: > so I think it is time to release openobex-1.6 during some time next > week. What are the pending patches? Er, those six patches that I sent to this list back in February. -- Alexander |
From: Marcel H. <ma...@ho...> - 2009-05-19 06:44:11
|
Hi Alex, > > so I think it is time to release openobex-1.6 during some time next > > week. What are the pending patches? > > Er, those six patches that I sent to this list back in February. seems that I lost them, please send them again. Regards Marcel |
From: Alex K. <ak...@se...> - 2009-05-19 15:48:31
|
2009/5/19 Marcel Holtmann <ma...@ho...>: >> > so I think it is time to release openobex-1.6 during some time next >> > week. What are the pending patches? >> >> Er, those six patches that I sent to this list back in February. > > seems that I lost them, please send them again. Just sent. -- Alexander |
From: Manuel N. <nar...@gm...> - 2009-05-19 18:07:03
|
> Hi guys, > > so I think it is time to release openobex-1.6 during some time next > week. What are the pending patches? > > Regards > > Marcel > Hi Marcel, Hey I sent some patches for obexftp client, do you plan any new release sometime soon? Manuel |
From: Christian Z. <Christian@Zuckschwerdt.org> - 2009-05-19 19:14:45
|
Manuel, that patch went into the tree nearly three months ago: http://github.com/zuckschwerdt/obexftp/commit/c64d58b39bdcb0277996737ca9eb55edbb08e49c You can download a snapshot at: http://github.com/zuckschwerdt/obexftp/archives/master A new release will be shortly after the next OpenOBEX release. Am 19.05.2009 um 20:06 schrieb Manuel Naranjo: > Hey I sent some patches for obexftp client, do you plan any new > release sometime soon? regards, Christian |
From: Manuel N. <nar...@gm...> - 2009-05-19 19:36:24
|
Christian, > Manuel, > > that patch went into the tree nearly three months ago: http://github.com/zuckschwerdt/obexftp/commit/c64d58b39bdcb0277996737ca9eb55edbb08e49c > Nice didn't knew you were using github :S > You can download a snapshot at: http://github.com/zuckschwerdt/obexftp/archives/master > > A new release will be shortly after the next OpenOBEX release. I have 2 pending patches, you can find those in my build branch: http://kienhoefer.com/~manuel/kwort_repo/devel/build/obexftp-svn/01_retries.patch This one allows users to tell obexftp how many times to retry to send a file before returning, if no option is passed then it fall backs to 3 times. http://kienhoefer.com/~manuel/kwort_repo/devel/build/obexftp-svn/00_errno.patch This other patch extends error reporting by giving back errno which is the real error number. I sent those to a few months ago, I guess they were lost in the eter. Thanks, Manuel |
From: Hendrik S. <po...@he...> - 2009-05-20 08:36:04
|
Zitat von Marcel Holtmann <ma...@ho...>: > so I think it is time to release openobex-1.6 during some time next > week. What are the pending patches? I will update my "updates" branch on gitorious.org until Sunday, I guess. It will contain CMake support for LibUSB 1.x, your maintainer-mode compiler switches, docbook build updates, etc. I guess you can wait till after the long week-end ;) TODOs tagged not-me: * Someone needs to integrate building the manpages into the autotools files. The CMake code supports xsltproc, saxon-6.5.x and xalan2 but using xsltproc may be sufficient for autotools support. Else, no manpages will be created when using ./configure to build openobex. * Maybe someone can make autotools use the doc/Doxyfile.in file instead of the hardcoded doc/Doxyfile. The variables are already autotools-compatible. I can also add a patch that changes the version in all places or maybe a small release checklist file, so nothing gets left out. I still don't thing that 6:0:0 is the right library version. Libtool's way of versioning libraries is.... ugly :-( Is there a way to trick it into creating files like libopenobexs.so -> libopenobex.so.1.6.0 libopenobex.so.2 -> libopenobex.so.1.6.0 ? Currently, that will rename libopenobex.so.1.5.0 (old) to libopenobex.so.6.0.0 (new) which looks like a marketing versioning. HS |
From: Christian Z. <Christian@Zuckschwerdt.org> - 2009-05-20 10:26:01
|
Hendrik, Am 20.05.2009 um 09:50 schrieb Hendrik Sattler: > I still don't thing that 6:0:0 is the right library version. Libtool's > way of versioning libraries is.... ugly :-( > Is there a way to trick it into creating files like > libopenobexs.so -> libopenobex.so.1.6.0 > libopenobex.so.2 -> libopenobex.so.1.6.0 > ? > Currently, that will rename libopenobex.so.1.5.0 (old) to > libopenobex.so.6.0.0 (new) which looks like a marketing versioning. in libtool terms 1.6 means support for 6 API versions since version 1 (i.e. not version 0 but every version since). On the other hand 6.0 means support for version 6 API only. Maybe "1.6" and "6.0" look very different to the casual observer but they both convey the same fact: we are at API version 6. I don't recall the API changes, wasn't it about the USB structures? If so Maybe we'll get away with advertising compatibility, where in fact structure sizes have changed (but are not used by apps anyway, are they?). regards, Christian |
From: Alex K. <ak...@se...> - 2009-05-20 10:43:26
|
2009/5/20 Christian Zuckschwerdt <Chr...@zu...>: > in libtool terms 1.6 means support for 6 API versions since version 1 > (i.e. not version 0 but every version since). > On the other hand 6.0 means support for version 6 API only. Maybe > "1.6" and "6.0" look very different to the casual observer but they > both convey the same fact: we are at API version 6. > > I don't recall the API changes, wasn't it about the USB structures? If > so Maybe we'll get away with advertising compatibility, where in fact > structure sizes have changed (but are not used by apps anyway, are > they?). Check the patch 3 of the series I send - I changed the USB access functions. Yes, this breaks source compatibility and doesn't support the previous API, but fixes the problem of changing USB structures once and for all (we got burned by that once in openobex 1.4). -- Alexander |
From: Marcel H. <ma...@ho...> - 2009-05-20 10:51:11
|
Hi Hendrik, > > so I think it is time to release openobex-1.6 during some time next > > week. What are the pending patches? > > I will update my "updates" branch on gitorious.org until Sunday, I > guess. It will contain CMake support for LibUSB 1.x, your > maintainer-mode compiler switches, docbook build updates, etc. > I guess you can wait till after the long week-end ;) depends on which long weekend you are talking about. Mine was last weekend and I plan to release it some time next week. Just before the long weekend in Germany :) > TODOs tagged not-me: > * Someone needs to integrate building the manpages into the autotools > files. The > CMake code supports xsltproc, saxon-6.5.x and xalan2 but using > xsltproc may be > sufficient for autotools support. Else, no manpages will be created when > using ./configure to build openobex. It is acceptable for me since manpages are for the testing tools anyway. The main focus is on the library and not the tools. So that would not stop me from doing the release. > * Maybe someone can make autotools use the doc/Doxyfile.in file instead of the > hardcoded doc/Doxyfile. The variables are already autotools-compatible. Isn't it enough to just have autoconf generate Doxyfile from Doxyfile.in and that just works then? > I can also add a patch that changes the version in all places or maybe > a small release checklist file, so nothing gets left out. > > I still don't thing that 6:0:0 is the right library version. Libtool's > way of versioning libraries is.... ugly :-( > Is there a way to trick it into creating files like > libopenobexs.so -> libopenobex.so.1.6.0 > libopenobex.so.2 -> libopenobex.so.1.6.0 > ? > Currently, that will rename libopenobex.so.1.5.0 (old) to > libopenobex.so.6.0.0 (new) which looks like a marketing versioning. Sine the USB changes break the API compatibility, -version-info 2:0:0 should be the right thing to do. Or not? Regards Marcel |
From: Hendrik S. <po...@he...> - 2009-05-20 13:22:10
|
Hi, Zitat von Marcel Holtmann <ma...@ho...>: >> TODOs tagged not-me: >> * Someone needs to integrate building the manpages into the autotools >> files. The >> CMake code supports xsltproc, saxon-6.5.x and xalan2 but using >> xsltproc may be >> sufficient for autotools support. Else, no manpages will be created when >> using ./configure to build openobex. > > It is acceptable for me since manpages are for the testing tools anyway. > The main focus is on the library and not the tools. So that would not > stop me from doing the release. The policy in Debian is to provide manpage for all programs. But I do build using CMake so it's also not a show-stopper for me. >> * Maybe someone can make autotools use the doc/Doxyfile.in file >> instead of the >> hardcoded doc/Doxyfile. The variables are already autotools-compatible. > > Isn't it enough to just have autoconf generate Doxyfile from Doxyfile.in > and that just works then? Exactly. In CMake I create doc/Doxyfile_HTML and doc/Doxyfile_LATEX from doc/Doxyfile.in when cmake is run (which is equivalent of running ./configure). Using the doc/Doxyfile.in is one file less to change the version number in (@DOC_VERSION@) and allows out-of-source builds with both, autotools and cmake (@DOC_BINARY_DIR@ and @DOC_SOURCE_FILES@). Additional, it allows to choose what types of documentation to build (@DOC_HTML_OUTPUT@ and @DOC_LATEX_OUTPUT@). >> I can also add a patch that changes the version in all places or maybe >> a small release checklist file, so nothing gets left out. >> >> I still don't thing that 6:0:0 is the right library version. Libtool's >> way of versioning libraries is.... ugly :-( >> Is there a way to trick it into creating files like >> libopenobexs.so -> libopenobex.so.1.6.0 >> libopenobex.so.2 -> libopenobex.so.1.6.0 >> ? >> Currently, that will rename libopenobex.so.1.5.0 (old) to >> libopenobex.so.6.0.0 (new) which looks like a marketing versioning. > > Sine the USB changes break the API compatibility, -version-info 2:0:0 > should be the right thing to do. Or not? Not according to libtool documentation. But Christian doesn't seem to have a problem with the strange numbering... HS |
From: Christian Z. <Christian@Zuckschwerdt.org> - 2009-05-20 13:22:58
|
Marcel, > Sine the USB changes break the API compatibility, -version-info 2:0:0 > should be the right thing to do. Or not? You may want to reset the age and release numbers, but decreasing the API version ('current' in libtool terms) is obviously a bad choice. You need to stick with 6:0:0 (that's 6:0:5 in case we want to fake compatibility). regards, Christian |
From: Christian Z. <Christian@Zuckschwerdt.org> - 2009-05-20 13:29:21
|
On libtool again, Am 20.05.2009 um 15:21 schrieb Hendrik Sattler: >> Sine the USB changes break the API compatibility, -version-info 2:0:0 >> should be the right thing to do. Or not? > > Not according to libtool documentation. But Christian doesn't seem to > have a problem with the strange numbering... Those numbers are not intended to convey any meaning to the user. They are used by the runtime linker. In fact it's a premier example of bad practice to cripple the linker capabilities in favour of questionable 'looks' regards, Christian |
From: Hendrik S. <po...@he...> - 2009-05-20 14:05:14
|
Zitat von Christian Zuckschwerdt <Christian@Zuckschwerdt.org>: > On libtool again, > > Am 20.05.2009 um 15:21 schrieb Hendrik Sattler: >>> Sine the USB changes break the API compatibility, -version-info 2:0:0 >>> should be the right thing to do. Or not? >> >> Not according to libtool documentation. But Christian doesn't seem to >> have a problem with the strange numbering... > > Those numbers are not intended to convey any meaning to the user. They > are used by the runtime linker. No, the runtime linker (at least on Linux) uses the SONAME value which is libopenobex.so.2 for the new version. That happens to be a link to the real library file. I agree that the .2 has no value to the user but represent the ABI and is solved with the SONAME feature. The .6.0.0 is just libtool non-sense. I fully do not agree with their arguments (yes, I read them). That could be anyhting (e.g. "v1.6" and the linker wouldn't care. > In fact it's a premier example of bad practice to cripple the linker > capabilities in favour of questionable 'looks' Libtool always had a questionable concept of doing things. HS |
From: Marcel H. <ma...@ho...> - 2009-05-20 20:07:18
|
Hi Christian, > > Sine the USB changes break the API compatibility, -version-info 2:0:0 > > should be the right thing to do. Or not? > > You may want to reset the age and release numbers, but decreasing the > API version ('current' in libtool terms) is obviously a bad choice. > > You need to stick with 6:0:0 (that's 6:0:5 in case we want to fake > compatibility). now you confused me. We break the ABI and API compatibility and so enforcing a new SONAME is important. What is the importance to jump from 1 to 6 in this case. I don't see any reason for that. Hence I was just going back to 2:0:0 to start over with a new SONAME. Regards Marcel |
From: Christian Z. <Christian@Zuckschwerdt.org> - 2009-05-20 22:21:26
|
Marcel, Am 20.05.2009 um 22:06 schrieb Marcel Holtmann: > Hi Christian, > >>> Sine the USB changes break the API compatibility, -version-info >>> 2:0:0 >>> should be the right thing to do. Or not? >> >> You may want to reset the age and release numbers, but decreasing the >> API version ('current' in libtool terms) is obviously a bad choice. >> >> You need to stick with 6:0:0 (that's 6:0:5 in case we want to fake >> compatibility). > > now you confused me. We break the ABI and API compatibility and so > enforcing a new SONAME is important. What is the importance to jump > from > 1 to 6 in this case. I don't see any reason for that. Hence I was just > going back to 2:0:0 to start over with a new SONAME. We are currently at ABI version 5, stepping back to ABI version 2 could lead to trouble. But you are right, starting fresh and with a soname that hasn't been in use, any pick is fine. Details about the original thought: OpenOBEX uses a version-info of 5:1:4 now which translates to a soname of 1.4.1. (The scheme here is current : revision : age which is translated to a soname of current-age . age . revision.) The soname of .2.0 (ABI 2, age 0) tells to be compatible to e.g. the soname of .1.1 (ABI 2, age 1, revisions ommited). But that's just the theoretical side -- I can't even say if some linker might choose librarys that liberal. Also there shouldn't be any apps linked to ABI 2 around any more, right? regards, Christian |
From: Alex K. <ak...@se...> - 2009-05-21 09:26:16
|
2009/5/21 Christian Zuckschwerdt <Chr...@zu...>: > We are currently at ABI version 5, stepping back to ABI version 2 > could lead to trouble. > > But you are right, starting fresh and with a soname that hasn't been > in use, any pick is fine. > > > Details about the original thought: > > OpenOBEX uses a version-info of 5:1:4 now which translates to a soname > of 1.4.1. > (The scheme here is current : revision : age which is translated to a > soname of current-age . age . revision.) > The soname of .2.0 (ABI 2, age 0) tells to be compatible to e.g. the > soname of .1.1 (ABI 2, age 1, revisions ommited). > > But that's just the theoretical side -- I can't even say if some > linker might choose librarys that liberal. Also there shouldn't be any > apps linked to ABI 2 around any more, right? I know nothing about sonames, but this page http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html makes it clear that version-info should become 6:0:0, if we're at 5:1:4 now. -- Alexander |
From: Hendrik S. <po...@he...> - 2009-05-21 20:09:20
|
Am Donnerstag 21 Mai 2009 00:21:21 schrieb Christian Zuckschwerdt: > Details about the original thought: > > OpenOBEX uses a version-info of 5:1:4 now which translates to a soname > of 1.4.1. > (The scheme here is current : revision : age which is translated to a > soname of current-age . age . revision.) > The soname of .2.0 (ABI 2, age 0) tells to be compatible to e.g. the > soname of .1.1 (ABI 2, age 1, revisions ommited). > > But that's just the theoretical side -- I can't even say if some > linker might choose librarys that liberal. Also there shouldn't be any > apps linked to ABI 2 around any more, right? Please note: the libtool scheme has absolutely nothing to do with the linker on any compiler/system I know of. On Linux a binary gets linked to libopenobex.so, the linker reads the SONAME from libopenobex.so and adds that to the dependency list of the other binary. That would work even with having only libopenobex.so.2 as the real binary library file. With CMake I can just name the files: libopenobex.so libopenobex.so.2 libopenobex.so.1.6.0 Asuming anything from the name of the latter file name is libtool miseducation. You can only do this if you know that this library was built using libtool and not renamed afterwards. Since most system administrators will not know about the libtool naming scheme, it is fairly useless (because the encoding information is not understood). You can use -version-number 2:0:0 instead of -version-info 6:0:0 I just don't know if this is Debian specific or a normal libtool feature. It still extracts the soname automatically from the first given part (that really hurts, why don't they provide an option instead of guessing?), so 2:0:0 must be used instead if 1:6:0 At that point, I don't care anymore. When using libtool, you obviously have to live with it guessing values. HS |
From: Marcel H. <ma...@ho...> - 2009-05-21 21:16:12
|
Hi Hendrik, > > Details about the original thought: > > > > OpenOBEX uses a version-info of 5:1:4 now which translates to a soname > > of 1.4.1. > > (The scheme here is current : revision : age which is translated to a > > soname of current-age . age . revision.) > > The soname of .2.0 (ABI 2, age 0) tells to be compatible to e.g. the > > soname of .1.1 (ABI 2, age 1, revisions ommited). > > > > But that's just the theoretical side -- I can't even say if some > > linker might choose librarys that liberal. Also there shouldn't be any > > apps linked to ABI 2 around any more, right? > > Please note: the libtool scheme has absolutely nothing to do with the linker > on any compiler/system I know of. > > On Linux a binary gets linked to libopenobex.so, the linker reads the SONAME > from libopenobex.so and adds that to the dependency list of the other binary. > That would work even with having only libopenobex.so.2 as the real binary > library file. > With CMake I can just name the files: > libopenobex.so > libopenobex.so.2 > libopenobex.so.1.6.0 > > Asuming anything from the name of the latter file name is libtool miseducation. > You can only do this if you know that this library was built using libtool and > not renamed afterwards. > Since most system administrators will not know about the libtool naming > scheme, it is fairly useless (because the encoding information is not > understood). > > You can use > -version-number 2:0:0 > instead of > -version-info 6:0:0 > I just don't know if this is Debian specific or a normal libtool feature. It > still extracts the soname automatically from the first given part (that really > hurts, why don't they provide an option instead of guessing?), so 2:0:0 must > be used instead if 1:6:0 > At that point, I don't care anymore. When using libtool, you obviously have to > live with it guessing values. I decided to with -version-info 2:0:0 since that bumps the SONAME and that is the important part here. Everything else is just pointless on most Unix/Linux systems. Regards Marcel |
From: Hendrik S. <po...@he...> - 2009-05-24 11:34:21
|
Am Montag 18 Mai 2009 23:02:10 schrieb Marcel Holtmann: > Hi guys, > > so I think it is time to release openobex-1.6 during some time next > week. What are the pending patches? You can pull the "updates" branch from git://gitorious.org/openobex/mainline.git When Alex patches are applied, I need an additional round to further adapt to it. The patches are already there, just not uploaded, yet. Alex patch 4 gave me an error in "git am" for doc/Doxyfile.in. HS |
From: Marcel H. <ma...@ho...> - 2009-05-25 14:35:35
|
Hi Hendrik, > > so I think it is time to release openobex-1.6 during some time next > > week. What are the pending patches? > > You can pull the "updates" branch from > git://gitorious.org/openobex/mainline.git pulled and pushed them back out. Thanks. > When Alex patches are applied, I need an additional round to further adapt to > it. The patches are already there, just not uploaded, yet. > > Alex patch 4 gave me an error in "git am" for doc/Doxyfile.in. Why don't you just apply them to your tree and then I pull from you. If it causes troubles then I gonna try to apply them manually. Regards Marcel |
From: Alex K. <ak...@se...> - 2009-05-24 13:10:47
|
2009/5/24 Hendrik Sattler <po...@he...>: > Alex patch 4 gave me an error in "git am" for doc/Doxyfile.in. That's due to all of the lines in that file ending with ^M. I only followed that, which results in git-am giving a warning about whitespace. Or is it something else? -- Alexander |
From: Hendrik S. <po...@he...> - 2009-05-24 17:52:34
|
Am Sonntag 24 Mai 2009 15:10:43 schrieb Alex Kanavin: > 2009/5/24 Hendrik Sattler <po...@he...>: > > Alex patch 4 gave me an error in "git am" for doc/Doxyfile.in. > > That's due to all of the lines in that file ending with ^M. I only > followed that, which results in git-am giving a warning about > whitespace. Or is it something else? Something in the chain cannot just handle 8bit correctly. Maybe git, maybe some mailserver, maybe kmail. I inserted a patch that converts doc/Doxyfile.in to unix line endings and then your patches apply. HS |
From: Hendrik S. <po...@he...> - 2009-05-24 17:34:01
|
Am Sonntag 24 Mai 2009 13:36:01 schrieb Hendrik Sattler: > Am Montag 18 Mai 2009 23:02:10 schrieb Marcel Holtmann: > > Hi guys, > > > > so I think it is time to release openobex-1.6 during some time next > > week. What are the pending patches? > > You can pull the "updates" branch from > git://gitorious.org/openobex/mainline.git > > When Alex patches are applied, I need an additional round to further adapt > to it. The patches are already there, just not uploaded, yet. If you pull from "usb" branch instead, you also get Alex' patches. I already changes version and SONAME but with CMake, I do not follow the libtool naming scheme, thus using .so.1.6.0 instead of .so.2.0.0. This has no practical implications, as both have the .so.2 link. HS |