Hi! There has been a new phonetisaurus release (0.6). All the patches have been applied upstream, the backup file in sparsehash has been removed, FstPathFinder.* have been rewritten from scratch.
I updated the Debian package files accordingly. All the phonetisaurus files have a BSD-2-clause header, but the README.txt reports BSD-3-clause. I will ask upstream about this. Bests, Giulio. Il 13/10/2012 15:54, Giulio Paci ha scritto: > Hi! > Thank you for your review. > > Il 13/10/2012 00:02, Jakub Wilk ha scritto: >> * Giulio Paci <giuliop...@gmail.com>, 2012-10-11, 03:52: >>>>> git://git.debian.org/git/collab-maint/phonetisaurus.git. > >>>> Last but not least, why do you need to recover this file? It looks like it >>>> shouldn't have been included in the upstream tarball in the first place. >>> Just because it was in the original tarball and I want that a "debian/rules >>> clean" results in the same content of the original tarball. >> >> Now I seem to recall that you told me that your workflow depends on such >> restoration. Sorry for the noise. > > No problem. > >>>> Oh, and Google sparse hash implemented is already packaged in Debian. >>>> Please build-depend on libsparsehash-dev and make sure that the >>>> system-wide copy is used, not the >>>> bundled one. >>>> >>>> Packaging the UTF-8 library (currently in src/3rdparty/utf8/) might be >>>> also worth considering, in order to comply with Policy §4.13. >>> >>> As we are not talking about shared libraries, but about a few headers >>> files, I do not understand the benefits of doing so. >> >> The main benefit is the same: you can fix bugs in one place, instead of >> doing it N places (where N is usually >> 1). > > Yes, I understand the goal, but I am worried that using external source code > would make it harder to replicate possible issues (I will need the exact > version of the > libsparsehash-dev binary package that was used to compile the library). > However this is probably true for many other C++ libraries. It is just more > evident here, where the libraries are just simple header files. > >>> I see only disadvantages: >>> 1) using system wide files will prevent me to easily know the source code >>> used to compile the phonetisaurus debian package; >> (Sometimes we need to keep exact source for license reasons; that's what >> Built-Using field is for.) > > How can I set Built-Using field? Should I set it by hand? Is it possible to > set it automatically? > >>> 2) fixes in sparsehash will not be available to phonetisaurus unless >>> phonetisaurus is recompiled; >> >> That's not worse than status quo. Also: binNMUs are cheap. > > Maybe I am missing something in the upload process (well, I am missing almost > everything to be honest). > Can you point some reference that will help me understanding what will happen > when new releases of libsparsehash-dev will be released (and phonetisaurus > will need > recompilation)? > >>> 3) I will need to maintain patches to use the system-wide copy; > > Created, applied and forwarded a patch for this. > >>> 4) an additional dependency is introduced; >> >> Again, convince upstream to drop the embedded copy, and these problems will >> go away. :) > > Additional dependency introduced. :-) If the patch will be accepted upstream, > the patch will let upstream to compile embedded copy of the libraries and us > to compile using > the system-wide dependency. > >>> 5) If I will package UTF-8 I will need to invest time maintaining a new >>> package that I do not care about and that contains just 4 headers files. >> >> I checked that there are at least 14 source packages in Debian that bundle >> UTF8-CPP: >> >> drizzle fife gdcm gource librime libvoikko love md5deep megaglest mkvtoolnix >> paraview ruby-passenger supertuxkart vtk >> >> Hopefully one of their maintainers would be interested in packaging it >> separately. Maybe file an RFP, CCing them all? > > If you think it is useful, I will do this. However I would like to understand > how I am supposed to deal with this kind of libraries before doing this. > With the patch above, it will be very easy to use the system-wide utfcpp > library once it is packaged. > >>> Do you think that policy §4.13 apply in this case? I seems to me that it is >>> more related to shared libraries than static ones and headers. >> >> No, §4.13 it's not only about shared library. It does apply here. > > Ok, using libsparsehash-dev then. > >>> Moreover I think that the last part of the following sentence applies: >>> "Debian packages should not make use of these convenience copies unless the >>> included package is explicitly intended to be used in this way". >> >> Do you have any evidence that this is the case (e.g. links to upstream >> documentation saying this is the preferred way of using the libraries)? > > No, I have no evidence about it, but the documentation is scarce in this > sense. Both libraries report something like: > "You just need to put the .h files somewhere your compiler can see this." > I just thought that sparsehash and utf8 are similar enough to gnulib that > people would use them in the same way. > >> FWIW, I'm personally not fond of this exception to §4.13. I think we would >> be better without it. Fixing autotools bugs is definitely not fun. > > I see your point of view. > But not being able to understand if autotools files are not working on > others' systems because of different version of tools or because problems in > the environment is also > not fun. :-) > >> Now the promised review of d/copyright: >> >>> Files: * >>> Copyright: 2011-2012, Josef Robert Novak >>> License: GPL-3+ >> >> As far as I can see, the code has been relicensed to 2-clause BSD. > > Right, fixed. > >>> Files: debian/phonetisaurus-g2p.1 >> >> No such file or directory. > > Also fixed. > >>> Files: FstPathFinder.cpp FstPathFinder.hpp >>> Copyright: Chris Taylor >>> 2011, Josef Novak >>> License: Apache-2.0 and GPL-3+ >> >> These now contain 2-clause BSD headers, though README.md says the "code was >> licensed under the Apache license". Could you clarify this with upstream? > > This code is partially covered by Apache 2.0 license and partially by the > BSD-2-clause license. > Upstream tried to contact Chris Taylor in the past, but he was not able to > talk to him. > He is thinking about rewriting these files from scratch. > >> Copyright/license information for src/3rdparty/google/ is missing. > > Added. > > Bests, > Giulio. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/507c7a7d.2060...@gmail.com