Bug#485985: vle on debian [ITP]

2009-03-29 Thread Gauthier Quesnel
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 

Bug#485985: vle on debian [ITP]

2008-12-30 Thread Ruben Molina
Dear Gauthier and Eric,

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...

[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 


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?)... I tried to check in your ChangeLog but
(BTW) the file is empty.

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? :)

[4]
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

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... 

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...


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 :)
So, may I suggest you to continue releasing just as vle-*.tar.gz,
without another suffixes, except for the used on release candidates?

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... 

So.. Is this suffix really relevant? Is your code arch-specific? :S

Thanks a lot! and have a happy new year!

Ruben Molina


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente