Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Jakub Wilk]

* Giulio Paci , 2016-03-08, 22:24:

we do seem to have an s390x buildd with only 3GB of RAM:
https://db.debian.org/machines.cgi?host=zemlinsky


So we may have a failure there. :-/


Perhaps. But with the current limits, the package would be built with 
-j1 there, so reducing parallelism further wouldn't help. Let's not 
worry about zemlinsky for now. :)


Comments in src/extensions/python/*.cc say that the files were generated 
by Cython, but I don't see their Cython sources in the tarball. :-\


--
Jakub Wilk

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

Hi Jakub,

On 08/03/2016 19:00, Jakub Wilk wrote:
> * Giulio Paci , 2016-03-07, 17:44:
>> I added a README.source
> 
> I don't like the phrase "build environment must not change during automated 
> builds". It makes me think of that you must not install or remove packages 
> when you package is
> building, which is technically true, but certainly not what you meant.

I rewrote that phrase so that now it is, hopefully, more clear.

>> On Friday I discovered an issue with this patch that, randomly, prevents 
>> tests to complete.
> 
> I saw the patch was updated in f083eb6924bf. Is this fixed now?

Probably.
The situation seems much much better than before (I did not experience test 
failures anymore), but, according to the author, it still requires testing.

> Typo in the patch header:
> idemppotent -> idempotent

Fixed.

> Why is "HopCroft" spelled with capital C?
> I've never seen this name spelled like that before.
> (Searching for "HopCroft" in codesearch.d.n revealed that there's an embedded 
> code copy of OpenFST in src:hfst. *sigh*)

I think the author of the patch just reproduced what he found on the code.
In the same code "Hopcroft" is spelled "HopCroft", "Hopcroft", "hopcroft", so I 
think the correct spelling is "Hopcroft".
However I would prefer not to fix it until the patch is known to be stable.

>>> I think the 500 MB/job limit is insufficient.
> [...]
>> I increased the limit to 2Gb/job, but I am not completely convinced about 
>> this new limit.
> 
> s/Gb/GB/ (unless you meant gigabits :-P)

And I also made this mistake two times in a single package... :-/

> Sounds good enough for me. Let's not overthink this. :)

Perfect!

>> How likely is it that we are going to compile with parallel=2 on an amd64 
>> system with 4Gb of RAM, without swap available?
> 
> Unlikely. Although we do seem to have an s390x buildd with only 3GB of RAM:
> https://db.debian.org/machines.cgi?host=zemlinsky

So we may have a failure there. :-/

> I'd remove "Increase per job required memory to 2Gb for parallel builds.", 
> because the previous version didn't have any limits, and you already said 
> "Limit parallelism on
> buildds in order not to run out of RAM" earlier.

You are right.

>>> We have automatic debug packages these days, so I'd drop the -dbg package.
>> Dropped the -dbg package.
> 
> Hmm, "According to https://wiki.debian.org/AutomaticDebugPackages; looks like 
> truncated sentence. Anyway, IMO the announcement message is a better source 
> of information on
> this: https://lists.debian.org/5675e791.6060...@thykier.net

I tried to improve that sentence.

> cppcheck says:
> [src/bin/fstcompile.cc:57]: (error) Memory leak: istrm
> [src/bin/fstdraw.cc:72]: (error) Memory leak: ostrm
> [src/bin/fstprint.cc:67]: (error) Memory leak: ostrm

Added a patch for these.

Bests,
Giulio.

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Jakub Wilk]

* Giulio Paci , 2016-03-07, 17:44:

I added a README.source


I don't like the phrase "build environment must not change during 
automated builds". It makes me think of that you must not install or 
remove packages when you package is building, which is technically true, 
but certainly not what you meant.


On Friday I discovered an issue with this patch that, randomly, 
prevents tests to complete.


I saw the patch was updated in f083eb6924bf. Is this fixed now?

Typo in the patch header:
idemppotent -> idempotent

Why is "HopCroft" spelled with capital C?
I've never seen this name spelled like that before.
(Searching for "HopCroft" in codesearch.d.n revealed that there's an 
embedded code copy of OpenFST in src:hfst. *sigh*)



I think the 500 MB/job limit is insufficient.

[...]
I increased the limit to 2Gb/job, but I am not completely convinced 
about this new limit.


s/Gb/GB/ (unless you meant gigabits :-P)

Sounds good enough for me. Let's not overthink this. :)

How likely is it that we are going to compile with parallel=2 on an 
amd64 system with 4Gb of RAM, without swap available?


Unlikely. Although we do seem to have an s390x buildd with only 3GB of 
RAM:

https://db.debian.org/machines.cgi?host=zemlinsky

I'd remove "Increase per job required memory to 2Gb for parallel 
builds.", because the previous version didn't have any limits, and you 
already said "Limit parallelism on buildds in order not to run out of 
RAM" earlier.



We have automatic debug packages these days, so I'd drop the -dbg package.

Dropped the -dbg package.


Hmm, "According to https://wiki.debian.org/AutomaticDebugPackages; looks 
like truncated sentence. Anyway, IMO the announcement message is a 
better source of information on this: 
https://lists.debian.org/5675e791.6060...@thykier.net


cppcheck says:
[src/bin/fstcompile.cc:57]: (error) Memory leak: istrm
[src/bin/fstdraw.cc:72]: (error) Memory leak: ostrm
[src/bin/fstprint.cc:67]: (error) Memory leak: ostrm

--
Jakub Wilk

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

A quick update.

On 07/03/2016 17:44, Giulio Paci wrote:
> 1005_kaldi_patch.patch has been submitted, but it is still under revision and 
> may require some work.
> 
> On Friday I discovered an issue with this patch that, randomly, prevents 
> tests to complete.
> I am not able to deal with the issue myself, but upstream and the original 
> author of the patch has both been notified and are
> looking into it.
> According to preliminary investigation, the main issue is in the unpatched 
> openfst, but the patched version seems to suffer more problems.
> The main issue should be present in the currently packaged version as well, 
> altough I did not check it myself.
> 
> If possible I would like to have this package uploaded anyway and later open 
> a bug report, as this package will let further work to be
> conducted on other packages (kaldi in particular).
> 
> I do not know yet when we may expect to see a proper fix for this issue. 
> Probably a few months.

A quick update: the original author of the patch is working on it and already 
sent an update to me and to upstream.
So my estimation is probably wrong and probably it is better to wait a few days 
until the updated patch is tested a little bit.

Bests,
Giulio

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

On 04/03/2016 21:12, Jakub Wilk wrote:
> * Giulio Paci , 2016-03-02, 09:45:
>> - added a new patch 1008_fix_linking_issues.patch, replacing and extending 
>> unresolved_symbols.diff.
> At the moment there's nothing in the changelog indicating any relation 
> between 1008_fix_linking_issues.patch and unresolved_symbols.diff.

Added a note about it.

> When you saying you're dropping a patch, please also say why you're dropping 
> it. (AIUI, all dropped patches except for unresolved_symbols were merged 
> upstream.)

All of the patches have been merged upstream, with some changes.

For 2001_put_libfst_extension_libraries_in_usr_lib.patch an alternative patch 
was submitted and accepted.
Apparently unresolved_symbols.diff was also merged, but then a subsequent 
change broke its fixes again.

> Do the leading numbers in patch names mean something?

I added a README.source file to report the meaning. Essentially they encode 
information similar to the one present in DEP-3 headers:

0xxx patches come from upstream
1xxx are interesting for upstream
2xxx are Debian-only (or were refused by upstream)

The xxx part is a (mostly) chronological sequence number, but is not related to 
the order in which the patches should be applied.

> Is it intentional that they out of order in debian/patches/series?

It is due just to the fact that 1008_fix_linking_issues.patch has already been 
submitted and accepted.
1005_kaldi_patch.patch has been submitted, but it is still under revision and 
may require some work.

On Friday I discovered an issue with this patch that, randomly, prevents tests 
to complete.
I am not able to deal with the issue myself, but upstream and the original 
author of the patch has both been notified and are
looking into it.
According to preliminary investigation, the main issue is in the unpatched 
openfst, but the patched version seems to suffer more problems.
The main issue should be present in the currently packaged version as well, 
altough I did not check it myself.

If possible I would like to have this package uploaded anyway and later open a 
bug report, as this package will let further work to be
conducted on other packages (kaldi in particular).

I do not know yet when we may expect to see a proper fix for this issue. 
Probably a few months.

> The package FTBFS in minimal environments:
> 
> libtool: compile:  g++ -DHAVE_CONFIG_H -I./../../include -Wdate-time 
> -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -std=c++11 -c
> compress-script.cc  -fPIC -DPIC -o .libs/compress-script.o
> In file included from ./../../include/fst/extensions/compress/compress.h:18:0,
> from 
> ./../../include/fst/extensions/compress/compress-script.h:13,
> from compress-script.cc:13:
> ./../../include/fst/extensions/compress/gzfile.h:19:18: fatal error: zlib.h: 
> No such file or directory
> compilation terminated.
> Makefile:543: recipe for target 'compress-script.lo' failed

I added zlib1g-dev dependency.

> I think the 500 MB/job limit is insufficient. I did some poor man's memory 
> profiling[0] on i386: it turns out that are many files that require more than 
> that for compiling,
> and one outlier needs over 2 GB! (See the attachment for details.) And the 
> memory requirements are most likely even bigger on 64-bit architectures...

I tried the same experiment on amd64. The critical files are the same ones and 
in particular algo_test.cc is still an outlier, requiring ~3.7Gb of RAM.
The other critical files required about 2Gb each.

I increased the limit to 2Gb/job, but I am not completely convinced about this 
new limit.
The reasoning behind this limit is that the outlier is compiled during tests, 
after all other critical files have been compiled, so it should not happen that 
a critical
file should be compiled at the same time of the outlier.
So, with 4Gb available it should still be possible to compile the package with 
parallel=2. Probably increasing this limit to 2.5Gb would be more safe, as 
there still is a
file requiring more than 600Mb that may be compiled at the same time of the 
outlier.

On the other end, increasing the limit will "waste" more RAM with the increase 
of parallel value and on other architectures.

What is your opinion about this limit? How likely is it that we are going to 
compile with parallel=2 on an amd64 system with 4Gb of RAM, without swap 
available?

> adequate(1) tells me that the obsolete conffile wasn't removed on upgrade:
> libfst-tools: obsolete-conffile /etc/bash_completion.d/openfstbc

I added libfst-tools.maintscript to remove it.
I also added a section in rules to run dh_bash-completion, as it was not run 
automatically.

> We have automatic debug packages these days, so I'd drop the -dbg package.

Dropped the -dbg package.

Bests,
Giulio

> [0] "ps -u $(whoami) -o rss,args" in a loop, plus some manual post-processing.

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Jakub Wilk]

* Giulio Paci , 2016-03-02, 09:45:
- added a new patch 1008_fix_linking_issues.patch, replacing and 
extending unresolved_symbols.diff.


At the moment there's nothing in the changelog indicating any relation 
between 1008_fix_linking_issues.patch and unresolved_symbols.diff.


When you saying you're dropping a patch, please also say why you're 
dropping it. (AIUI, all dropped patches except for unresolved_symbols 
were merged upstream.)


Do the leading numbers in patch names mean something?
Is it intentional that they out of order in debian/patches/series?

The package FTBFS in minimal environments:

libtool: compile:  g++ -DHAVE_CONFIG_H -I./../../include -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -std=c++11 -c compress-script.cc  -fPIC -DPIC -o 
.libs/compress-script.o
In file included from ./../../include/fst/extensions/compress/compress.h:18:0,
from 
./../../include/fst/extensions/compress/compress-script.h:13,
from compress-script.cc:13:
./../../include/fst/extensions/compress/gzfile.h:19:18: fatal error: zlib.h: No 
such file or directory
compilation terminated.
Makefile:543: recipe for target 'compress-script.lo' failed

I think the 500 MB/job limit is insufficient. I did some poor man's 
memory profiling[0] on i386: it turns out that are many files that 
require more than that for compiling, and one outlier needs over 2 GB! 
(See the attachment for details.) And the memory requirements are most 
likely even bigger on 64-bit architectures...


adequate(1) tells me that the obsolete conffile wasn't removed on 
upgrade:

libfst-tools: obsolete-conffile /etc/bash_completion.d/openfstbc

We have automatic debug packages these days, so I'd drop the -dbg 
package.



[0] "ps -u $(whoami) -o rss,args" in a loop, plus some manual 
post-processing.


--
Jakub Wilk
2104872 algo_test.cc 
1185224 disambiguate.cc -D PIC
1177164 disambiguate.cc
1101672 determinize.cc
1101628 determinize.cc -D PIC
1038388 push.cc -D PIC
1038116 push.cc
826588  fstloglinearapply.cc 
803072  minimize.cc
803036  minimize.cc -D PIC
706596  pdtscript.cc -D PIC
706492  pdtscript.cc
701360  randequivalent.cc -D PIC
701068  randequivalent.cc
618580  farscript.cc
618460  farscript.cc -D PIC
586304  epsnormalize.cc
586104  epsnormalize.cc -D PIC
510892  rmepsilon.cc -D PIC
503492  shortest-path.cc -D PIC
502372  shortest-path.cc
501428  mpdtscript.cc
500388  rmepsilon.cc
500020  mpdtscript.cc -D PIC
498412  compose.cc -D PIC
497504  compose.cc
497200  fst.cc -D PIC
493300  linearscript.cc -D PIC
492856  fst.cc
492252  linearscript.cc
490152  intersect.cc -D PIC
486832  intersect.cc
486420  fst_test.cc 
481376  replace.cc -D PIC
480556  replace.cc
478976  equivalent.cc
478520  equivalent.cc -D PIC
471620  compress-script.cc -D PIC
466604  compress-script.cc
457956  shortest-distance.cc
455384  shortest-distance.cc -D PIC
397756  prune.cc
396696  difference.cc
396576  difference.cc -D PIC
393308  randgen.cc
393288  randgen.cc -D PIC
393264  linear-classifier-fst.cc -D PIC
392692  linear-classifier-fst.cc
392628  synchronize.cc -D PIC
392320  ilabel_lookahead-fst.cc -D PIC
392304  ilabel_lookahead-fst.cc
392248  linear-tagger-fst.cc
392084  linear-tagger-fst.cc -D PIC
391804  prune.cc -D PIC
391792  olabel_lookahead-fst.cc -D PIC
391788  olabel_lookahead-fst.cc
391480  map.cc -D PIC
391424  map.cc
380180  synchronize.cc
373860  fst-class.cc -D PIC
372512  fst-class.cc
365844  far-class.cc
364020  far-class.cc -D PIC
363812  ngram-fst.cc
359140  info.cc
355692  ngram-fst.cc -D PIC
353580  compile.cc -D PIC
352980  info.cc -D PIC
350432  compile.cc
341260  compact64_weighted_string-fst.cc
340656  compact8_acceptor-fst.cc -D PIC
340192  compact8_weighted_string-fst.cc -D PIC
340188  compact8_weighted_string-fst.cc
339584  compact16_weighted_string-fst.cc
336924  compact8_acceptor-fst.cc
335572  compact64_unweighted_acceptor-fst.cc
335372  compact64_acceptor-fst.cc -D PIC
335228  compact8_string-fst.cc
334776  compact64_unweighted_acceptor-fst.cc -D PIC
334548  compact16_acceptor-fst.cc -D PIC
333228  compact64_weighted_string-fst.cc -D PIC
332928  compact64_acceptor-fst.cc
330548  decode.cc
330500  compact16_acceptor-fst.cc
330180  compact8_unweighted-fst.cc -D PIC
329432  compact16_weighted_string-fst.cc -D PIC
329272  compact16_unweighted_acceptor-fst.cc
327760  compact8_string-fst.cc -D PIC
327532  compact8_unweighted-fst.cc
327428  compact8_unweighted_acceptor-fst.cc
326976  compact16_unweighted-fst.cc
326460  compact8_unweighted_acceptor-fst.cc -D PIC
326452  compact64_string-fst.cc
326032  compact16_unweighted_acceptor-fst.cc -D PIC
325708  compact64_unweighted-fst.cc -D PIC
325596  compact64_string-fst.cc -D PIC
325564  compact64_unweighted-fst.cc
325256  compact16_string-fst.cc
324916  compact16_unweighted-fst.cc -D PIC
323932  decode.cc -D PIC
323908  compact16_string-fst.cc -D PIC
318252  weight_test.cc 
303440  

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

On 29/02/2016 16:37, Jakub Wilk wrote:
> * Giulio Paci , 2016-02-29, 13:24:
>> 1) I need to package latest version, as the differences are not trivial 
>> anymore;
>> 2) I have to convince upstream stop these bad practices (however it seems 
>> very hard, as they stop for one release and then start again a immediately 
>> after);
>> 3) *mangle mechanism seems not enough in this case as we need some math (we 
>> have to compute "+1") and the math has to be applied to a value 
>> that is not the
>> current one
> 
> Nah, we don't have to do any arithmetic. The last revision number is written 
> down on the download page. It's not part of any link, but we can use 
> pagemangle to shove it
> into the href attribute. I've attached watch file that implements this idea.

Thank you very much for this file: it would have been taken ages to me to 
understand how to write something similar.

During these days, I:
- integrated the watch file in the Debian package;
- imported latest upstream revision of openfst 1.5.1;
- discussed with upstream about tarball versioning and soname;
- added a new patch 1008_fix_linking_issues.patch, replacing and extending 
unresolved_symbols.diff.

I hope the package is now in a better state for upload.

Bests,
Giulio

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Jakub Wilk]

* Giulio Paci , 2016-02-29, 13:24:
1) I need to package latest version, as the differences are not trivial 
anymore;
2) I have to convince upstream stop these bad practices (however it 
seems very hard, as they stop for one release and then start again a 
immediately after);
3) *mangle mechanism seems not enough in this case as we need some math 
(we have to compute "+1") and the math has to be applied to 
a value that is not the current one


Nah, we don't have to do any arithmetic. The last revision number is 
written down on the download page. It's not part of any link, but we can 
use pagemangle to shove it into the href attribute. I've attached watch 
file that implements this idea.


--
Jakub Wilk
version=3
opts="pagemangle=s!\1\s*\s*]*>\s*r(\d+)!!g, 
uversionmangle=s/\.(\d+)$/+r$1/;s/\+r1$//, 
filenamemangle=s/.*filename=//;s/.rev=.*//, pgpmode=none" \
http://www.openfst.org/twiki/bin/view/FST/FstDownload \
/twiki/bin/viewfile/FST/FstDownload\?filename=openfst-(\d[\d\.]*)\.(?:zip|tgz|tbz2|txz|tar\.gz|tar\.bz2|tar\.xz)[&;]rev=(\d+)

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

Hi Jakub,

On 29/02/2016 00:27, Jakub Wilk wrote:
> * Giulio Paci , 2016-02-28, 23:19:
>> I packaged 
>> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=1;
>>  and noticed the behaviour when upstream was at
>> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=3;.
>> Right now they are at 
>> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=8;.
>> I still did not check the last revision.
>> I have not found any reasonable way to detect when the package changes. 
>> Essentially the algorythm should be: check for latest version of the 
>> package, if the same package
>> exist with rev=, then the package is at the "same version" + 
>> revision +1.
>>
>> Given the current situation, do you think I should upgrade the upstream 
>> files in pristine-tar?
>> Should I have different versioning with respect to upstream or should I 
>> maintain the same version scheme even if several versions collapse into the 
>> same version?
> 
> Hmm. With pagemangle (available in devscripts >= 2.15.10) we could probably 
> teach uscan about different revisions of the same file. But that'd be 
> probably very brittle...
> 
> So how about asking uscan to always download revision 1? This should be 
> straight-forward:
> 
> opts="downloadurlmangle=s!.*/FstDownload/(.+)!http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=$1=1!;
> 
> (I had to use "&" instead of ";", because you can't use semicolons in mangle 
> rules. I hate uscan.)

Today I checked the differences between rev 8 and current packaged version... 
And they are not just minor changes as it happened before, they also changed 
ABI, without
changing SONAME (again :-().

I think:
1) I need to package latest version, as the differences are not trivial anymore;
2) I have to convince upstream stop these bad practices (however it seems very 
hard, as they stop for one release and then start again a immediately after);
3) *mangle mechanism seems not enough in this case as we need some math (we 
have to compute "+1") and the math has to be applied to a value that 
is not the
current one (we have to check that 
/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=
 exist, in order to compute +1 on
http://www.openfst.org/twiki/pub/FST/FstDownload/openfst-1.5.1.tar.gz).

I am going to write to upstream again.

In the meanwhile, do you think I can package openfst-1.5.1.tar.gz rev 8 under 
openfst-1.5.1.tar.gz name?

Bests,
Giulio

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Jakub Wilk]

Hi Giulio!

* Giulio Paci , 2016-02-28, 23:19:
I packaged 
"http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=1; 
and noticed the behaviour when upstream was at 
"http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=3;.

Right now they are at 
"http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=8;.
I still did not check the last revision.
I have not found any reasonable way to detect when the package changes. 
Essentially the algorythm should be: check for latest version of the 
package, if the same package exist with rev=, then the 
package is at the "same version" + revision +1.


Given the current situation, do you think I should upgrade the upstream 
files in pristine-tar?
Should I have different versioning with respect to upstream or should I 
maintain the same version scheme even if several versions collapse into 
the same version?


Hmm. With pagemangle (available in devscripts >= 2.15.10) we could 
probably teach uscan about different revisions of the same file. But 
that'd be probably very brittle...


So how about asking uscan to always download revision 1? This should be 
straight-forward:


opts="downloadurlmangle=s!.*/FstDownload/(.+)!http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=$1=1!;

(I had to use "&" instead of ";", because you can't use semicolons in 
mangle rules. I hate uscan.)


--
Jakub Wilk

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

Hi Jakub,

On 27/02/2016 19:04, Jakub Wilk wrote:
> [When filing a bug, please use X-Debbugs-CC instead of plain CC, so that the 
> copied person receives the message with bug number from the BTS.]

Thank you for the hint. I will do that next time.

> * Giulio Paci , 2016-02-16, 01:03:
>> https://anonscm.debian.org/git/collab-maint/openfst.git
> 
> I had only a very quick look at the package so far:
> 
>> * Drop 1001, 1002, 1003.
>> * Avoid 2001 patch usage.
> 
> Someone who's not familiar with the package history would have no idea what 
> this means. Please be more verbose here.

I added full patch names and reported that "2001" patch is no more needed.

> Do you plan to forward unresolved-symbols.diff upstream?

Actually I already did it (several times).
I updated the patch header accordingly.

> Typo in README.Debian:
> binaries depends -> binaries depend
> 
> Typos in fstlinear.1 and fstloglinearapply.1:
> chracter -> character

I fixed those typos.

> The tarball uscan downloads is different that the one pristine-tar generates:
> 
> $ md5sum openfst_1.5.1.orig.tar.gz.*
> 9b6e9a5042b986919f62c5184e3e352d  openfst_1.5.1.orig.tar.gz.pristine-tar
> 8869e44c5a4af65409ae78b9f482b40e  openfst_1.5.1.orig.tar.gz.uscan
> 
> Do you know how did that happen?

Yes, I know. Upstream uploaded more than one tarball with minimal changes 
fixing minor issues.
I already talked about this issue with upstream and about the implications. But 
still I do not know about their decision on this subject.
I packaged 
"http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=1;
 and noticed the behaviour when upstream was at
"http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=3;.
Right now they are at 
"http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=8;.
I still did not check the last revision.
I have not found any reasonable way to detect when the package changes. 
Essentially the algorythm should be: check for latest version of the package, 
if the same package
exist with rev=, then the package is at the "same version" + 
revision +1.

Given the current situation, do you think I should upgrade the upstream files 
in pristine-tar?
Should I have different versioning with respect to upstream or should I 
maintain the same version scheme even if several versions collapse into the 
same version?

Bests,
Giulio

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Jakub Wilk]

Control: owner -1 !

Hi Giulio!

[When filing a bug, please use X-Debbugs-CC instead of plain CC, so that 
the copied person receives the message with bug number from the BTS.]


* Giulio Paci , 2016-02-16, 01:03:

https://anonscm.debian.org/git/collab-maint/openfst.git


I had only a very quick look at the package so far:


* Drop 1001, 1002, 1003.
* Avoid 2001 patch usage.


Someone who's not familiar with the package history would have no idea 
what this means. Please be more verbose here.


Do you plan to forward unresolved-symbols.diff upstream?

Typo in README.Debian:
binaries depends -> binaries depend

Typos in fstlinear.1 and fstloglinearapply.1:
chracter -> character

The tarball uscan downloads is different that the one pristine-tar 
generates:


$ md5sum openfst_1.5.1.orig.tar.gz.*
9b6e9a5042b986919f62c5184e3e352d  openfst_1.5.1.orig.tar.gz.pristine-tar
8869e44c5a4af65409ae78b9f482b40e  openfst_1.5.1.orig.tar.gz.uscan

Do you know how did that happen?

--
Jakub Wilk

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

Package: sponsorship-requests
  Severity: wishlist

  Dear Jakub,

  I am looking for a sponsor for my package "openfst", that you sponsored in 
the past
  and that recently I managed to update.

 * Package name: openfst
   Version : 1.5.1-1
   Upstream Author : Cyril Allauzen , Michael Riley 

 * URL : http://www.openfst.org/
 * License : Apache-2.0
   Section : libs


  It builds these binary packages:

openfst -  weighted finite-state transducers library
libfst-tools - weighted finite-state transducers library (tools)
libfst2 - weighted finite-state transducers library (runtime)
libfst2-dbg - weighted finite-state transducers library (debug symbols)
libfst2-plugins-base -  weighted finite-state transducers library (base 
plugins)
libfst-dev - weighted finite-state transducers library (development)

  To access further information about this package, please visit the
following Vcs URL:

 https://anonscm.debian.org/git/collab-maint/openfst.git

  Regards,
   Giulio Paci