Bug#663916: New phonetisaurus package available
Il 25/10/2012 15:37, Jakub Wilk ha scritto: > Please bump Standards-Version to 3.9.4. (But note that lintian isn't aware of > it yet, so you'll get a spurious newer-standards-version, which you should > ignore for the time > being.) Done. > Would it be possible to enable parallel builds? Done. > g2p segfaults if the model doesn't exist: > > $ phonetisaurus-g2p --model=/nonexistent > ERROR: ExpandedFst::Read: Can't open file: /nonexistent > Segmentation fault Fixed. > debian/copyright_hints are out-of-date again. :) Fixed again... :-) > The copyright file says: > > Files: src/3rdparty/sparsehash/google/* > Copyright: 2005-2007, Google Inc. > > but one of the files has this notice: > > // Copyright (c) 2010, Google Inc. Fixed. 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/508bfe8d.2020...@gmail.com
Bug#663916: New phonetisaurus package available
Please bump Standards-Version to 3.9.4. (But note that lintian isn't aware of it yet, so you'll get a spurious newer-standards-version, which you should ignore for the time being.) Would it be possible to enable parallel builds? g2p segfaults if the model doesn't exist: $ phonetisaurus-g2p --model=/nonexistent ERROR: ExpandedFst::Read: Can't open file: /nonexistent Segmentation fault debian/copyright_hints are out-of-date again. :) The copyright file says: Files: src/3rdparty/sparsehash/google/* Copyright: 2005-2007, Google Inc. but one of the files has this notice: // Copyright (c) 2010, Google Inc. -- Jakub Wilk -- 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/20121025133741.ga5...@jwilk.net
Bug#663916: New phonetisaurus package available
Il 24/10/2012 16:56, Jakub Wilk ha scritto: > * Giulio Paci , 2012-10-22, 23:55: >>> 1) Upstream "make clean" is not idempotent: it fails it there's nothing to >>> clean. Replacing "rm" with "rm -f" should fix this issue. >> Fixed by using $(RM). > > This fix appears to be part of 1002_remove_some_warnings.patch. Could you > move it into a separate patch? Done. > Please also bump date in the changelog. Done. -- 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/50883518.7060...@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-22, 23:55: 1) Upstream "make clean" is not idempotent: it fails it there's nothing to clean. Replacing "rm" with "rm -f" should fix this issue. Fixed by using $(RM). This fix appears to be part of 1002_remove_some_warnings.patch. Could you move it into a separate patch? Please also bump date in the changelog. -- Jakub Wilk -- 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/20121024145607.ga5...@jwilk.net
Bug#663916: New phonetisaurus package available
Il 23/10/2012 21:36, Jakub Wilk ha scritto: > * Giulio Paci , 2012-10-22, 23:55: >>> There's also a few dozens of compiler warnings. Is upstream aware of them? >> I just sent an email about them, along with a patch removing most of them. > > I think "fix" would be a better verb than "remove" here (in the patch name > and its description). You are right. Fixed. ;-) -- 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/5087151b.9000...@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-22, 23:55: There's also a few dozens of compiler warnings. Is upstream aware of them? I just sent an email about them, along with a patch removing most of them. I think "fix" would be a better verb than "remove" here (in the patch name and its description). -- Jakub Wilk -- 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/20121023193638.ga...@jwilk.net
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-23, 00:24: 2) cdbs doesn't ignore errors from "make clean". This was reported in #441020 over 5 years ago. (Sigh...) I just read the bug report. Actually cdbs ignores errors in "make clean". So the problem here seems to be that building should fail on "make clean", but it was working anyway. Right? D'oh! I meant s/doesn't/shouldn't/. So yes, you are right. Sorry for the confusion. -- Jakub Wilk -- 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/2012103716.ga3...@jwilk.net
Bug#663916: New phonetisaurus package available
Errata corrige. Il 22/10/2012 23:55, Giulio Paci ha scritto: > Il 22/10/2012 17:48, Jakub Wilk ha scritto: >> * Giulio Paci , 2012-10-21, 15:04: >>> Is it mandatory to identify "possibly useless" flags and to hide them? >> >> I understand that removing/hiding unneeded option might be infeasible, but I >> would expect that these no-ops are documented as such in the manual page (or >> alternative: that >> they are not documented in the manpage at at all). > > Removed those flags from the manpages. > >> 1) Upstream "make clean" is not idempotent: it fails it there's nothing to >> clean. Replacing "rm" with "rm -f" should fix this issue. > > Fixed by using $(RM). >> 2) cdbs doesn't ignore errors from "make clean". This was reported in >> #441020 over 5 years ago. (Sigh...) I just read the bug report. Actually cdbs ignores errors in "make clean". So the problem here seems to be that building should fail on "make clean", but it was working anyway. Right? >> There's a warning about debian/copyright_hints not being up-to-date. > > Fixed. I re-created the problem by adding the new patch. Now it is fixed (again). >> There's also a few dozens of compiler warnings. Is upstream aware of them? > > I just sent an email about them, along with a patch removing most of them. I > left untouched those warnings that I was not sure how to solve properly. I am > waiting upstream > to solve them. The patch header was broken, I fixed it. 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/5085c7ad.8030...@gmail.com
Bug#663916: New phonetisaurus package available
Il 22/10/2012 17:48, Jakub Wilk ha scritto: > * Giulio Paci , 2012-10-21, 15:04: >> Is it mandatory to identify "possibly useless" flags and to hide them? > > I understand that removing/hiding unneeded option might be infeasible, but I > would expect that these no-ops are documented as such in the manual page (or > alternative: that > they are not documented in the manpage at at all). Removed those flags from the manpages. > 1) Upstream "make clean" is not idempotent: it fails it there's nothing to > clean. Replacing "rm" with "rm -f" should fix this issue. Fixed by using $(RM). > There's a warning about debian/copyright_hints not being up-to-date. Fixed. > There's also a few dozens of compiler warnings. Is upstream aware of them? I just sent an email about them, along with a patch removing most of them. I left untouched those warnings that I was not sure how to solve properly. I am waiting upstream to solve them. 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/5085c0d2@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-21, 15:04: What does --fst_field_separator exactly do? In my experiments it did not affect phonetisaurus-align in any way. Unfortunately I do not know most of the options of this program. I asked upstream about this option. Upstream replied that these flags are automatically added by openfst: http://www.openfst.org/twiki/bin/view/FST/FstAdvancedUsage#Command_Line_Flags Some of them affect the behaviour of functions that are not used by phonetisaurus-align. However he does not know how to hide those inherited options (and I do not know as well) without rewriting all the flags parsing code. Do you know how to hide them? No idea, sorry. Is it mandatory to identify "possibly useless" flags and to hide them? I understand that removing/hiding unneeded option might be infeasible, but I would expect that these no-ops are documented as such in the manual page (or alternative: that they are not documented in the manpage at at all). There are some warnings in the build log: | /usr/bin/make -C src CFLAGS="-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall" CXXFLAGS="-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security" CPPFLAGS="-D_FORTIFY_SOURCE=2" LDFLAGS="-fPIE -pie -Wl,-z,relro -Wl,-z,now" THIRD_PARTIES_INCLUDE="-I3rdparty/utfcpp" -k clean | make[1]: Entering directory `/build/phonetisaurus-DN3moq/phonetisaurus-0.6/src' | rm ../phonetisaurus-g2p ../phonetisaurus-align ../phonetisaurus-arpa2fst *.o | rm: cannot remove `../phonetisaurus-g2p': No such file or directory | rm: cannot remove `../phonetisaurus-align': No such file or directory | rm: cannot remove `../phonetisaurus-arpa2fst': No such file or directory | rm: cannot remove `*.o': No such file or directory | make[1]: *** [clean] Error 1 | make[1]: Leaving directory `/build/phonetisaurus-DN3moq/phonetisaurus-0.6/src' | make: [makefile-clean] Error 2 (ignored) The above indicates two problem: 1) Upstream "make clean" is not idempotent: it fails it there's nothing to clean. Replacing "rm" with "rm -f" should fix this issue. 2) cdbs doesn't ignore errors from "make clean". This was reported in #441020 over 5 years ago. (Sigh...) There's a warning about debian/copyright_hints not being up-to-date. There's also a few dozens of compiler warnings. Is upstream aware of them? -- Jakub Wilk -- 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/20121022154809.ga8...@jwilk.net
Bug#663916: New phonetisaurus package available
Il 21/10/2012 04:39, Giulio Paci ha scritto: > Il 20/10/2012 22:55, Jakub Wilk ha scritto: >> What does --fst_field_separator exactly do? In my experiments it did not >> affect phonetisaurus-align in any way. > > Unfortunately I do not know most of the options of this program. I asked > upstream about this option. Upstream replied that these flags are automatically added by openfst: http://www.openfst.org/twiki/bin/view/FST/FstAdvancedUsage#Command_Line_Flags Some of them affect the behaviour of functions that are not used by phonetisaurus-align. However he does not know how to hide those inherited options (and I do not know as well) without rewriting all the flags parsing code. Do you know how to hide them? Is it mandatory to identify "possibly useless" flags and to hide them? 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/5083f2e0.7090...@gmail.com
Bug#663916: New phonetisaurus package available
Il 20/10/2012 22:55, Jakub Wilk ha scritto: > * Giulio Paci , 2012-10-20, 00:00: >> I just had a look to the already opened bugs and I found that there is an >> RFP bug for utfcpp: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552618 >> >> Do you think I should do anything else (e.g., reply to the bug with the >> maintainers of the packages you identified in CC)? > > I think reply+cc would be a good idea, but I won't insist. Done. > If I run phonetisaurus-align without arguments, it segfaults: > | $ phonetisaurus-align > | Loading input file: > | Starting EM... > | Finished first iter... > | Iteration: 1 Change: nan > | Iteration: 2 Change: nan > | Iteration: 3 Change: nan > | Iteration: 4 Change: nan > | Iteration: 5 Change: nan > | Iteration: 6 Change: nan > | Iteration: 7 Change: nan > | Iteration: 8 Change: nan > | Iteration: 9 Change: nan > | Iteration: 10 Change: nan > | Iteration: 11 Change: nan > | Last iteration: > | Segmentation fault > > The manpage seems to imply that --input and --ofile options are mandatory, so > I'm not sure what it is even trying to do... But it certainly shouldn't > segfault. --input is mandatory indeed. I added a patch to prevent segfaults. The message is not very clear, but I hope is enugh. > Shouldn't phonetisaurus-align input format be documented somewhere? BTW, it > aborts without any helpful error message if the input file is not valid: > | $ echo foobar > invalid.txt > | $ phonetisaurus-align --input=invalid.txt --ofile=invalid.corpus > | Loading input file: tiny.bsf > | terminate called after throwing an instance of 'std::out_of_range' > | what(): vector::_M_range_check > | Aborted I documented the format in the manpage. The input format is very generic and it would be probably difficult to detect invalid input files. The error above is because the program expects a two columns file and only one column was provided. Now this error is not reported anymore (in my opinion one column files are still valid input, but I am waiting confirm from upstream). > What does --fst_field_separator exactly do? In my experiments it did not > affect phonetisaurus-align in any way. Unfortunately I do not know most of the options of this program. I asked upstream about this option. 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/50836073.7050...@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-20, 00:00: I just had a look to the already opened bugs and I found that there is an RFP bug for utfcpp: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552618 Do you think I should do anything else (e.g., reply to the bug with the maintainers of the packages you identified in CC)? I think reply+cc would be a good idea, but I won't insist. If I run phonetisaurus-align without arguments, it segfaults: | $ phonetisaurus-align | Loading input file: | Starting EM... | Finished first iter... | Iteration: 1 Change: nan | Iteration: 2 Change: nan | Iteration: 3 Change: nan | Iteration: 4 Change: nan | Iteration: 5 Change: nan | Iteration: 6 Change: nan | Iteration: 7 Change: nan | Iteration: 8 Change: nan | Iteration: 9 Change: nan | Iteration: 10 Change: nan | Iteration: 11 Change: nan | Last iteration: | Segmentation fault The manpage seems to imply that --input and --ofile options are mandatory, so I'm not sure what it is even trying to do... But it certainly shouldn't segfault. Shouldn't phonetisaurus-align input format be documented somewhere? BTW, it aborts without any helpful error message if the input file is not valid: | $ echo foobar > invalid.txt | $ phonetisaurus-align --input=invalid.txt --ofile=invalid.corpus | Loading input file: tiny.bsf | terminate called after throwing an instance of 'std::out_of_range' | what(): vector::_M_range_check | Aborted What does --fst_field_separator exactly do? In my experiments it did not affect phonetisaurus-align in any way. -- Jakub Wilk -- 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/20121020205526.ga7...@jwilk.net
Bug#663916: New phonetisaurus package available
Hi!
Il 17/10/2012 16:19, Jakub Wilk ha scritto:
> * Giulio Paci , 2012-10-17, 00:05:
How can I set Built-Using field? Should I set it by hand? Is it possible
to set it automatically?
>>> Value of this field must be generated at build time. Unfortunately, there
>>> are currently no convenient tools to help you with this task; see bug
>>> #689062.
> [...]
>> Thank you very much. I read the bug thread and I added a Built-Using field
>> (I used mednafen as a base).
>
> It looks good. Support for ${source:Package} and ${source:Version} variables
> was added to dpkg in 1.16.2, so please bump the version in Build-Depends.
Bumped.
>> I just tried to collect the list of maintainers for the package that you
>> suggested are using utf8-cpp (drizzle fife gdcm gource librime libvoikko
>> love md5deep megaglest
>> mkvtoolnix paraview ruby-passenger supertuxkart vtk), however I have
>> problems obtaining the list:
>> The following command:
>>
>> for i in drizzle fife gdcm gource librime libvoikko love md5deep megaglest
>> mkvtoolnix paraview ruby-passenger supertuxkart vtk; do echo $i; LANG=C
>> apt-cache show $i | grep
>> Maintainer; done
> [...]
>> How did you get the list?
>
> http://http.debian.net/debian/dists/unstable/main/Contents-source.gz is an
> index of files in all source packages. IIRC I searched for "/unchecked.h" and
> then manually
> filter out false-positives. (I was told that you can also use apt-file to
> search through these files.)
Thank you very much, this file will make my life easier.
>> fife, gdcm, librime and libvoikko seem not to exist, while vtk seems to be a
>> virtual package.
>
> These were source package names, not binary package names. s/show/showsrc/
> should help. :) There's also a dedicated tool to make lists of package
> maintainers: dd-list in
> devscripts.
And this command even more. :-)
I just had a look to the already opened bugs and I found that there is an RFP
bug for utfcpp:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552618
Do you think I should do anything else (e.g., reply to the bug with the
maintainers of the packages you identified in CC)?
> Files: src/3rdparty/utfcpp/utf8/* src/3rdparty/utfcpp/utf8.h
>
> could be simplified to:
>
> Files: src/3rdparty/utfcpp/*
Done.
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/5081cd7f.9090...@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-17, 00:05:
How can I set Built-Using field? Should I set it by hand? Is it
possible to set it automatically?
Value of this field must be generated at build time. Unfortunately,
there are currently no convenient tools to help you with this task;
see bug #689062.
[...]
Thank you very much. I read the bug thread and I added a Built-Using
field (I used mednafen as a base).
It looks good. Support for ${source:Package} and ${source:Version}
variables was added to dpkg in 1.16.2, so please bump the version in
Build-Depends.
I just tried to collect the list of maintainers for the package that
you suggested are using utf8-cpp (drizzle fife gdcm gource librime
libvoikko love md5deep megaglest mkvtoolnix paraview ruby-passenger
supertuxkart vtk), however I have problems obtaining the list:
The following command:
for i in drizzle fife gdcm gource librime libvoikko love md5deep megaglest
mkvtoolnix paraview ruby-passenger supertuxkart vtk; do echo $i; LANG=C
apt-cache show $i | grep
Maintainer; done
[...]
How did you get the list?
http://http.debian.net/debian/dists/unstable/main/Contents-source.gz is
an index of files in all source packages. IIRC I searched for
"/unchecked.h" and then manually filter out false-positives. (I was told
that you can also use apt-file to search through these files.)
fife, gdcm, librime and libvoikko seem not to
exist, while vtk seems to be a virtual package.
These were source package names, not binary package names.
s/show/showsrc/ should help. :) There's also a dedicated tool to make
lists of package maintainers: dd-list in devscripts.
Files: src/3rdparty/utf8/* src/3rdparty/utf8.h
The directory has been renamed, please update it.
Fixed.
Now it's:
Files: src/3rdparty/utfcpp/utf8/* src/3rdparty/utfcpp/utf8.h
which is okay, but since there are no other files in the utfcpp/
subdirectory, it could be simplified to:
Files: src/3rdparty/utfcpp/*
--
Jakub Wilk
--
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/20121017141940.ga6...@jwilk.net
Bug#663916: New phonetisaurus package available
Hi! Il 16/10/2012 17:12, Jakub Wilk ha scritto: > * Giulio Paci , 2012-10-13, 15:54: >> How can I set Built-Using field? Should I set it by hand? Is it possible to >> set it automatically? > > Value of this field must be generated at build time. Unfortunately, there are > currently no convenient tools to help you with this task; see bug #689062. In > the mean time, > you can take a look at how other packages do it: > > $ grep-aptavail -F Built-Using . -s Source:Package -n | sort -u > binutils-mingw-w64 (2) > debian-installer (20120930) > debian-installer-netboot-images > gamera > gcc-mingw-w64 (7) > gdb-mingw-w64 (5) > mednafen > nvidia-graphics-modules (304.48+2) > win32-loader > xen Thank you very much. I read the bug thread and I added a Built-Using field (I used mednafen as a base). I just tried to collect the list of maintainers for the package that you suggested are using utf8-cpp (drizzle fife gdcm gource librime libvoikko love md5deep megaglest mkvtoolnix paraview ruby-passenger supertuxkart vtk), however I have problems obtaining the list: The following command: for i in drizzle fife gdcm gource librime libvoikko love md5deep megaglest mkvtoolnix paraview ruby-passenger supertuxkart vtk; do echo $i; LANG=C apt-cache show $i | grep Maintainer; done On my system results in: drizzle Maintainer: Tobias Frost Maintainer: Tobias Frost fife E: No packages found gdcm E: No packages found gource Maintainer: Andrew Caudwell librime E: No packages found libvoikko E: No packages found love Maintainer: Debian Games Team md5deep Maintainer: Debian Forensics megaglest Maintainer: Debian Games Team mkvtoolnix Maintainer: Christian Marillat paraview Maintainer: Debian Science Team ruby-passenger Maintainer: Debian Ruby Extras Maintainers supertuxkart Maintainer: Debian Games Team vtk How did you get the list? fife, gdcm, librime and libvoikko seem not to exist, while vtk seems to be a virtual package. >> 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)? > > Nothing will happen automatically. But if someone (you, or sparsehash > maintainer, or somebody else) decides it would be beneficial to rebuild > phonetisaurus against new > sparsehash, they can ask the Release Team to schedule binNMUs, i.e. > recompilation without source changes. See also: > https://wiki.debian.org/binNMU I read this quickly. But it starts being more clear to me. > Now looking again at the copyright file: > >> Files: src/3rdparty/utf8/* src/3rdparty/utf8.h > > The directory has been renamed, please update it. Fixed. >> License: MIT-like > > The license UTF8-CPP uses is commonly know as Boost Software License, Version > 1.0, so a short name like "BSL-1.0" or "Boost-1.0" might be better here. I chose "Boost-1.0". >> Files: src/3rdparty/google/* > > This directory has been renamed, too. Fixed. 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/507dda0e.6080...@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-13, 15:54: How can I set Built-Using field? Should I set it by hand? Is it possible to set it automatically? Value of this field must be generated at build time. Unfortunately, there are currently no convenient tools to help you with this task; see bug #689062. In the mean time, you can take a look at how other packages do it: $ grep-aptavail -F Built-Using . -s Source:Package -n | sort -u binutils-mingw-w64 (2) debian-installer (20120930) debian-installer-netboot-images gamera gcc-mingw-w64 (7) gdb-mingw-w64 (5) mednafen nvidia-graphics-modules (304.48+2) win32-loader xen 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)? Nothing will happen automatically. But if someone (you, or sparsehash maintainer, or somebody else) decides it would be beneficial to rebuild phonetisaurus against new sparsehash, they can ask the Release Team to schedule binNMUs, i.e. recompilation without source changes. See also: https://wiki.debian.org/binNMU Now looking again at the copyright file: Files: src/3rdparty/utf8/* src/3rdparty/utf8.h The directory has been renamed, please update it. License: MIT-like The license UTF8-CPP uses is commonly know as Boost Software License, Version 1.0, so a short name like "BSL-1.0" or "Boost-1.0" might be better here. Files: src/3rdparty/google/* This directory has been renamed, too. -- Jakub Wilk -- 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/20121016151218.ga3...@jwilk.net
Bug#663916: New phonetisaurus package available
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 , 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 ne
Bug#663916: New phonetisaurus package available
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 , 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 ne
Bug#663916: New phonetisaurus package available
Hi! Thank you for your review. Il 13/10/2012 00:02, Jakub Wilk ha scritto: > * Giulio Paci , 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: * >> Cop
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-11, 03:52: git://git.debian.org/git/collab-maint/phonetisaurus.git. The ugly hack in debian/rules is indeed ugly. :) I definitively agree. I found a cleaner way to do that and applied it (by setting DEB_CLEAN_EXCLUDE in debian/rules). Much better, thanks. :) 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. I already contacted the author and the file will go away with next releases (and so the ugly hack). Great, thanks. 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). 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; Convince upstream not to include them in the tarball and they will magically stop being part of the source. (Sometimes we need to keep exact source for license reasons; that's what Built-Using field is for. This reminded me that I should review the copyright file; see below.) 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. 3) I will need to maintain patches to use the system-wide copy; 4) an additional dependency is introduced; Again, convince upstream to drop the embedded copy, and these problems will go away. :) 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? 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. 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)? 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. 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. Files: debian/phonetisaurus-g2p.1 No such file or directory. 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? Copyright/license information for src/3rdparty/google/ is missing. -- Jakub Wilk -- 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/20121012220207.ga1...@jwilk.net
Bug#663916: New phonetisaurus package available
Il 10/10/2012 22:59, Jakub Wilk ha scritto: > * Giulio Paci , 2012-10-09, 02:16: >> git://git.debian.org/git/collab-maint/phonetisaurus.git. > > The ugly hack in debian/rules is indeed ugly. :) I definitively agree. I found a cleaner way to do that and applied it (by setting DEB_CLEAN_EXCLUDE in debian/rules). > 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. I already contacted the author and the file will go away with next releases (and so the ugly hack). > 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. 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; 2) fixes in sparsehash will not be available to phonetisaurus unless phonetisaurus is recompiled; 3) I will need to maintain patches to use the system-wide copy; 4) an additional dependency is introduced; 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. 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. 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". 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/50762672.8080...@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci , 2012-10-09, 02:16: git://git.debian.org/git/collab-maint/phonetisaurus.git. The ugly hack in debian/rules is indeed ugly. :) Could you split it into multiple lines? 410 characters is really too long. Why is the filename between two -e expressions? 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. 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. -- Jakub Wilk -- 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/20121010205941.ga9...@jwilk.net
Bug#663916: New phonetisaurus package available
Hi Jakub! Finally a new upstream release of phonetisaurus came out with the pending issues solved (i.e., non-free data files have been dropped, the only remaining script does not have an extension). I just updated the Debian package on git://git.debian.org/git/collab-maint/phonetisaurus.git. Could you have a look at it? 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/50736ceb.8080...@gmail.com
