2008/12/30 Ruben Molina <rmol...@udea.edu.co>: > Dear Gauthier and Eric,
Hello Ruben, First of all, I apologize for this late reply. I didn't see your mail in December :-\ > I'm working on the RFP for vle filed by Gauthier [1] on Debian bug > tracking system (BTS), I checked your software and I have some > interest on it (I'll write to you about this later) so I changed your > RFP into a ITP some time ago, and I'm planning to maintain it under > DebianScience [2] as it looks to me like a good candidate for this > team... Ok, ok, Great :-) > [1] http://bugs.debian.org/485985 > [2] http://wiki.debian.org/DebianScience > > OK, I have some questions for you: > > > debian/copyright > ================ > > You reported 'Lucent Technologies' as copyrigth holder for some > functions in CSVReader.hpp, but you didn't include the license for > this code... Are you sure this code is available under a free software > license? If yes, please include the license statement granted by > Lucent in the sources; if not, please replace this code with a free > equivalent. > > vle-0.6.0/vle/data/CSVReader.hpp: > * �...@brief Copyright (C) 1999 Lucent Technologies > * Excepted from 'The Practice of Programming' > * by Brian W. Kernighan and Rob Pike This code adapted from a C++ original that was Copyright (C) 1999 Lucent Technologies Excepted from 'The Practice of Programming' by Brian W. Kernighan and Rob Pike. It included by permission It included by permission of the http://tpop.awl.com/ and http://cm.bell-labs.com/cm/cs/tpop/code.html web sites, which says: "You may use this code for any purpose, as long as you leave the copyright notice and book citation attached." But I am not sure it's valid with the GPL now. We can quickly re-write the code, it is not long. > sonames :S > ========== > > I have been following (and packaging) your sources since I saw the ITP > (v0.5.0) so I noted a soname change from 0 (on v0.5.2) to 0.6 (on > current version)... I hope you are no trying to change your soname > schema to follow release versions... > Was this soname bump necesary? (declaration changes? struct changes?, > functions semantics changes?)... In fact, the API and ABI are not stables (the API of vle 0.5, 0.6 or 0.7 are incompatibles). We tend to make them stable for the version 1.0 but it's too difficult for the moment. I thought to release a soname by release of VLE (ie. for each 0.x). However, I understand that this is difficult to manage them in a distribution. > I tried to check in your ChangeLog but (BTW) the file is empty. Yes, this file is available separately on the download page of Sourceforge. We build it with git after the release. > In any case, usually is my task to ask [4]: "have you already read the > libtool manual?" but you are using cmake... so: do you fully > understand hoe to manage the shared library process associated? :) I think :-p > We are not expecting a lot of packages depending on your libraries, > but if you try to change the soname in every release, we will need to > generate new names for the binary packages on every release... and > maintain a lot of Replaces... Conflicts... Yes, I understand. > For now, I'm packaging all your libraries in a single libvle0 package > (and its corresponding libvle-dev)... but I need to confirm how will > you be managing the sonames... We can change the soname to 0 instead of 0.7 (in vle/CMakeLists.txt, line 31) for the next release. No problem. VLE users don't care about the soname. :-) > debian/watch > ============ > > This file is used by DEHS [3] to monitorig new releases from upstream > (you) awaiting to be packaged. > > [3] http://dehs.alioth.debian.org/ > > I need to define a regexp to track the released versions... > > Until 0.5.2, it seems like you were using the following format in SF: > > vle-*.tar.gz > > In this case, I just added some mangling for the release-candidates (we > use the symbol '~' for this: 0.5.0~rc1 < 0.5.0, but 0.5.0-rc1 > 0.5.0). > > Until now my regexp was: > > opts="uversionmangle=s/-rc/~rc/" \ > http://sf.net/vle/vle-(.+)\.tar\.gz > > And it was detecting the following versions in SF: 0.1, 0.2.0, 0.3.0, > 0.3.1, 0.4.0, 0.4.1, 0.5.0-rc1, 0.5.0-rc2, 0.5.0-rc3, 0.5.0, 0.5.1, > 0.5.2... > > But in v0.6.0 series you added some other suffixes, so now I found too: > 0.6.0-Linux-i686, 0.6.0-rc1-sources, 0.6.0-rc2-sources, > 0.6.0-rc3-Linux-i686, 0.6.0-rc3-sources, 0.6.0-sources... > > You did't released a '0.6.0.tar.gz', but anyway, after the rc mangling, > a 0.6.0 version will be detected as: 0.6.0-rc* < 0.6.0 < 0.6.0-sources > < 0.6.0-Linux-i686.... > > Sure, I can add more mangling for the new suffixes... Or, if you are > planning to continue using the current format, I can change my regexp to > search for: > > vle-*-sources.tar.gz > > In this case just 0.6.0-rc*, 0.6.0 and future releases will be > detected... > > Anyway... is always better to define a filename convention with you :) Yes :-p > So, may I suggest you to continue releasing just as vle-*.tar.gz, > without another suffixes, except for the used on release candidates? Ok, no problem. For the next release (0.7.0-rc2), I build the source tarball without the "sources" suffixes. > Finally, I'm a little concerned about your 'Linux-i686' suffix... if vle > is accepted on Debian, we will (try to) prepare this package for many > archs, not just i686... and is possible that it will be prepared for > another OS too (freebsd, hurd), not just linux... Great :-p > So.. Is this suffix really relevant? Is your code arch-specific? :S All the vle-*-Linux-i686 are just compiled version of VLE for x86 processor. I build them to simplify the use of VLE for x86 users. :-) > Thanks a lot! and have a happy new year! Thanks a lot and sorry for the delay of my answer :-( Gauthier Quesnel. PS: If it can help you, I try to manage a test of debian package in [1][2], but it produces many debian packages. [1] http://vle.univ-littoral.fr/gitweb?p=deb-vle.git;a=summary [2] git clone git://vle.univ-littoral.fr/git/deb-vle.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
