Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Il gio 25 nov 2021, 13:21 Andrey Rahmatullin  ha scritto:

> On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote:
> > The double values refer to timing information. The specific format,
> > known as CTM, stores information in seconds in decimals (e.g. "30.66"
> > seconds) from the beginning of the stream.
> > The failing tool reads this information into double variables
> Sounds like it just shouldn't read this data into a float type but use
> some fixed-point data type instead.
>

This is also my opinion (and already suggested upstream), although it would
make the code a little bit less readable.

Moreover I am still wondering if the compiler behavior is correct in this
case and why it is so unstable. Apart from this corner case (which in my
opinion should also work), I have not seen bad assumptions about double
arithmetics in the rest of the failing tool.

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Hi Paul,

On Thu, Nov 25, 2021 at 3:24 AM Paul Wise  wrote:
> Giulio Paci wrote:
>
> > 3) what is the most appropriate solution.
>
> As I understand it, floating point values should not be compared
> without some kind of accuracy/precision factor. Zero idea about the
> best reference for how to do it correctly, but here is a random one:
>
>
https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

Thanks for this link.
It is a very great resource and summarizes very well what I already
know about double/float and much more.

Since the test case is dealing with timings, I think the most related
article is [1].
However even after reading that article it seems to me that in this
case it should be reasonable to expect stable behavior of those
operators.

I have uploaded simplified code that showcase the issue and some of
the instabilities [2]. The code seems to behave as if the last value
is different from the other 3, supposed equal values.
I am not even sure what I am seeing in the debugger, since most of the
values are optimized out (and I am not so skilled with debuggers).

[1] https://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/
[2] https://pastebin.com/embed_js/T3g560UV

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

On Thu, Nov 25, 2021 at 8:54 AM Andrey Rahmatullin  wrote:
>
> On Wed, Nov 24, 2021 at 06:38:07PM +0100, Giulio Paci wrote:
> > Dear mentors,
> >   while updating SCTK package I enabled the execution of the test suite
> > which was previously disabled. The tests are working fine on x86_64
> > architecture, but a couple of them are failing on i386.
> > After investigation [1] I found out that tests are failing because they
> > rely on the assumptions that, when a and b have the same double value:
> > 1) "a < b" is false;
> > 2) "a - b" is 0.0.
> What do they actually test, why do they use these assumptions?

SCTK is a toolkit to evaluate speech recognition (and other related
tasks) tools performance.
These tools usually read audio streams and produce simple text files
containing the transcriptions and time information (relative to the
stream) to synchronize the transcription to the stream. These files
are very similar to video subtitles files.
The SCTK compares two textual files (usually one is a manually created
file and the other is created by an automatic tool) to score how
different these outputs are.
The tests are checking that SCTK produces the same score reports when
provided with the same input files.

The double values refer to timing information. The specific format,
known as CTM, stores information in seconds in decimals (e.g. "30.66"
seconds) from the beginning of the stream.
The failing tool reads this information into double variables and, to
simplify, it compares "up to when the timings in one file is less than
the timings in the other files. If it exceeds or is the same, it
checks the difference".

In this kind of application you are not usually going beyond what you
can store uncompressed on a filesystem in PCM. So, even assuming audio
samples of 1 byte, int64 should be a reasonable type to store timings
(in samples, rather then seconds). But I understand that doing so
would complicate the logic of the tool, especially since it is very
unlikely that math approximation would be an issue. To be honest I did
not expect the corner case above would fail since it is comparing a
value against another value that should just be the same.

I have uploaded simplified code that showcase the issue and some of
the instabilities [1]. The code seems to behave as if the last value
is different from the other 3, supposed equal values.

[1] https://pastebin.com/embed_js/T3g560UV

Bests,
Giulio

Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Dear mentors,
  while updating SCTK package I enabled the execution of the test suite
which was previously disabled. The tests are working fine on x86_64
architecture, but a couple of them are failing on i386.
After investigation [1] I found out that tests are failing because they
rely on the assumptions that, when a and b have the same double value:
1) "a < b" is false;
2) "a - b" is 0.0.
Unfortunately, these assumptions do not always hold on i386 as the behavior
of those operators seem to change according to compilation flags (e.g.,
optimization or debug flags) or the surrounding instructions (e.g., if a
function is invoked nearby or not).

I think the reason for this behavior is probably related to gcc
options -mfpmath
[2] and -ffloat-store [3]. Using -ffloat-store option indeed seems to fix
the issue.

However I am wondering:
1) if enabling -ffloat-store is an acceptable solution;
2) if this is a compiler bug (I always expect approximated results with
double arithmetics, but the above assumptions seem very basic to me,
considering that they cover the special case where a and b are equal);
3) what is the most appropriate solution.

Do you have any suggestion?

I just asked the same question upstream, but I would appreciate your
opinion as well.

Bests,
Giulio

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981030#39
[2]
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options
[3]
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Giulio Paci]

Hi Bastian,

Il sab 23 ott 2021, 11:58 Bastian Germann  ha scritto:

> Am 23.10.21 um 10:43 schrieb Giulio Paci:
> > Since the NMU has already solved the FTBFS, I think I can try to upgrade
> > the tool as well. Unfortunately upstream did not add neither a tag nor a
> > release to github. I have just asked if it is possible to add them
> > (before moving to github upstream used to release tarballs with any new
> > release).
>
> As the last commit is the one changing the version and is from 2018, it
> is reasonable to assume that that commit is the release. There is no
> activity since then and I do not expect upstream to react to your
> request. So please package 2.4.11 regardless of tags.
>

I have discussed with upstream and they agreed to merge some of the
currently open pull requests, as well as tag new versions, so I will
package latest version (currently 2.4.12) as soon as I find time.

>
> I have invited you to https://salsa.debian.org/debian/sctk which also runs
> the Salsa CI pipelines to demonstrate the i386 issue. Please use that repo
> going forward.


I will do. Thank you for setting it up.

Build tests on i386 fail with:

test17: Vietnamese case conversion

Executions complete: Comparing output

   Removing DIFF tests

   Removing SLM tests

!  TESTS HAVE FAILED  !


I checked the issue and found out that the failing tests are test13 and
test13b in sclite.
The failing test case relies on the assumptions that, when a and b have the
same double value:
1) "a < b" is false;
2) "a - b" is 0.0.
For some reason the two above assumptions are sometime disattended on i386,
and thus the "overlap" function in src/sclite/ctm2ctm.c is not always
providing the expected results.
The overlap behavior is unstable and varies according to specific flags
being used to compile the executable (e.g., enabling debug is often enough
to not trigger the failure, but enabling -O3 and -mtune=native generally is
enough to trigger the failure again) or the context surrounding the
operations (e.g., accessing the memory address of the operands).

I guess the main reason for this weird behavior is described in (option
-mfpmath):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options

and in (option -ffloat-store):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Giulio Paci]

Dear Bastian,
thanks for your feedback.

Il sab 23 ott 2021, 02:36 Bastian Germann  ha scritto:

> Control: tags -1 moreinfo
>
> Why don't you package the version 2.4.11 from
> https://github.com/usnistgov/SCTK? It is from Nov 2018.
>
> Usually, you keep the changelog entry for NMUs if you acknowlege (keep
> the patch) them. You did not for -3.1.
>

I did not aknowledge the NMU since those changes were not included in this
RFS. The NMU happened several months after I opened this RFS and, in
absence of a prospect sponsor, I did not update the RFS after the NMU.
Are you interested in sponsoring this package?

I did not update to 3.11, because I mainly wanted to clear out FTBFS bug,
other known issues and update the packaging to recent standards.
Since the NMU has already solved the FTBFS, I think I can try to upgrade
the tool as well. Unfortunately upstream did not add neither a tag nor a
release to github. I have just asked if it is possible to add them (before
moving to github upstream used to release tarballs with any new release).


> Build tests on i386 fail with:
> test17: Vietnamese case conversion
>
> Executions complete: Comparing output
> Removing DIFF tests
> Removing SLM tests
>
>   !  TESTS HAVE FAILED  !
>

I will check what is causing the issue.

Bests,
Giulio

>

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Giulio Paci]

Hi Adam,
  thank you for your review.

Il mar 26 gen 2021, 03:02 Adam Borowski  ha scritto:

> On Mon, Jan 25, 2021 at 06:05:24PM +0100, Giulio Paci wrote:
> > I am looking for a sponsor for an updated version of the package "sctk"
> >
> >  * Package name: sctk
> >Version : 2.4.10-20151007-1312Z+dfsg2-4
>
> A lot of text, eg in debian/copyright_hints, is seriously garbled.
>

debian/copyright_hints has been automatically generated through
licensecheck command.
It can be used to double check what changed about licenses when you upgrade
the upstream sources.
In this package there are a lot of small files that confuses that tool
though, and this causes the mostly broken content in debian/copyright_hints.

In recent versions the sctk sources did not change too much, so this file
is less useful than it was a few years ago and can be dropped.

Do you think I should drop this file?
Do you have other examples of garbled text?

Best regards,
Giulio

>

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: bal...@balintreczey.hu

Dear Balint and mentors,

I am looking for a sponsor for an updated version of the package "sctk"

 * Package name: sctk
   Version : 2.4.10-20151007-1312Z+dfsg2-4
   Upstream Author : Jon Fiscus 
 * URL : http://www.nist.gov/itl/iad/mig/tools.cfm
 * License : public-domain and GPL-2+
   Section : libs

It builds those binary packages:

 sctk - speech recognition scoring toolkit
 sctk-doc  - speech recognition scoring toolkit (documentation)

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

 git clone https://salsa.debian.org/giuliopaci-guest/sctk.git

Can you sponsor this package?

Bests,
Giulio.

Bug#980340: RFS: sptk/3.9-3 -- speech signal processing toolkit

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: andre...@debian.org

Dear Andrew,

I am looking for a sponsor for my package "sptk"

* Package name: sptk
  Version : 3.9
  Upstream Author : Keiichiro Oura 
* URL : http://sp-tk.sourceforge.net/
* License : BSD
  Programming Lang: (C, tcsh)
  Section : misc

It builds those binary packages:

sptk  - speech signal processing toolkit
libsptk-dev - speech signal processing toolkit - development files

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

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

https://salsa.debian.org/debian/sptk.git

Can you sponsor this package?

Regards,
   Giulio Paci

Bug#874305: RFS: mitlm/0.4.2-1 -- MIT Language Modeling toolkit

[Giulio Paci]

Hi Mo,
   thank you for your offer and review.
Unfortunately I do not know when I will be able to handle these issues as I
have very limited time at the moment.

Il dom 9 set 2018, 07:46 Mo Zhou  ha scritto:

> control: owner -1 !
> control: tags -1 +moreinfo
>
> I can sponsor this package. However this package looks old and needs
> updating before the upload.
>
> 1. please have a look and fix the following lintian warnings:
> -


> And the latest standards version is 4.2.1 .
>

As you can see from git, the package as not been updated since a long time.
As soon as I can work on it again I will update the package.
Given the long time that has passed since my last update, during the last
few months I have also thought about orphaning, but I am still hoping to
find time in the close future.

2. why is the SOVERSION bump from 0 to 1?
> --
>
> Has upstream bumped ABI/API?
>

I do not remember the exact reason, but I confirm that SOVERSION has been
bumped upstream as well.
The original upstream author is not active anymore, so I also act as
upstream for this package.

Besides, I'd suggest add symbols control file for this package such
> that ABI changes can be tracked more easily. One will obtain a symbols
> list from buildlog after creating an empty .symbols file and rebuild.
>

I was never able to use symbols files with C++ ABI, as I always receive
errors on architectures that are different from the one that I use to
create the symbols file. Moreover I have also tried different approaches to
track symbols, in order to guarantee that the ABI has not changed in any
platform (e.g., if the API changes a parameter from int64 to size_t, the
change is not always reflected in the ABI). In the end I gave up trying to
track them. When I described the issue upstream, in many cases some of them
simply started bumping SOVERSION at every release, just to stay on the safe
side. Do you have any better strategy to solve these issues?

Best regards,
Giulio

Bug#874305: RFS: mitlm/0.4.2-1 -- MIT Language Modeling toolkit

[Giulio Paci]

X-Debbugs-CC: jw...@debian.org
Control: tags -1 - moreinfo

Hi Adam and Tobias,
  thank you for having a look at this.

On 15/12/2017 14:09, Adam Borowski wrote:
> On Mon, Sep 04, 2017 at 10:49:36PM +0200, Giulio Paci wrote:
>> Dear Jakub,
>>
>>   I am looking for a sponsor for an updated version of my package "mitlm"
> 
> Apparently you forgot to CC jwilk; this RFS went only to the mentors
> mailinglist -- yet, upon seeing the first line, we assumed you want your
> usual sponsor.

You are right. I am CCing him now.

>> * Package name: mitlm
>>   Version : 0.4.2
> 
> I'm afraid it fails to build:
> /<>/./configure: line 20515: AX_CXX_HEADER_TR1_UNORDERED_MAP: 
> command not found
> /<>/./configure: line 20516: syntax error near unexpected token 
> `noext,'
> /<>/./configure: line 20516: `AX_CXX_COMPILE_STDCXX_11(noext, 
> optional)'

I added the autoconf-archive missing dependency.

On 04/01/2018 11:58, Tobias Frost wrote:
> Other notes: (Note that I did NOT a complete review)
> - Are you sure you want it uploaded to experimental? Why?

Indeed I am not sure, and actually prefer to have mitlm in unstable.

We decided to upload it to experimental, because of many uncertainties about 
both upstream development and about the package development (I was new to 
packaging when we
uploaded there).

As my long term goal is to have typical "development" packages for speech 
recognition and speech synthesis in Debian, I would really like to see mitlm in 
unstable.

> - d/compat could be bumped.

Done.

> - (S-V has increased in the meantime too, when over it you might want
> to update that to the latest)

Done.

> - maybe consider switching to debhelper (and dh_autoreconf). I'm pretty
> sure that will simplify d/rules a lot. (This would be whishlist entry
> of mine, not required at all)

Considered and done. :-)

> Please fix the FTBFS (and if you want the stuff above), then remove the
> moreinfo when ready!

Done by adding the missing dependency.

Bug#876623: RFS: yamcha/0.33-2 -- General purpose chunker annotator

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for an updated version of my package "mitlm"

* Package name: yamcha
  Version : 0.33
  Upstream Author : Taku Kudo <taku...@is.aist-nara.ac.jp>
* URL : http://www.chasen.org/~taku/software/yamcha/
* License : LGPL-2.1+
  Programming Lang: (C++, Python, Perl)
  Section : science

It builds those binary packages:

 libyamcha1  - general purpose chunker annotator - runtime library
 libyamcha-dev - general purpose chunker annotator - development files
 yamcha - general purpose chunker annotator

The upload closes #875993.

You can find the source of the package at:

  https://anonscm.debian.org/cgit/collab-maint/yamcha.git

Regards,
   Giulio Paci





signature.asc
Description: OpenPGP digital signature

Bug#874305: RFS: mitlm/0.4.2-1 -- MIT Language Modeling toolkit

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear Jakub,

  I am looking for a sponsor for an updated version of my package "mitlm"

* Package name: mitlm
  Version : 0.4.2
  Upstream Author : Bo-June (Paul) Hsu <bo...@mit.edu>
* URL : https://github.com/mitlm/mitlm
* License : BSD
  Programming Lang: (C, C++, Fortran)
  Section : misc

It builds those binary packages:

 libmitlm1  - MIT Language Modeling toolkit library
 libmitlm1-dev - MIT Language Modeling toolkit development files
 mitlm - MIT Language Modeling toolkit

You can find the source of the package at:

  https://anonscm.debian.org/cgit/collab-maint/mitlm.git

Regards,
   Giulio Paci



signature.asc
Description: OpenPGP digital signature

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Il giorno 31/ago/2017 00:25, "Adam Borowski" <kilob...@angband.pl> ha
scritto:
>
> On Wed, Aug 30, 2017 at 10:58:05PM +0200, Adam Borowski wrote:
> > On Wed, Aug 30, 2017 at 10:37:43PM +0200, Giulio Paci wrote:
> > > Are you able to try it on the kfreebsd-i386 building machine?
> >
> > You do know you have a kfreebsd-i386 capable machine right on your desk,
> > right?  All you need is qemu or virtualbox [...]
>
> > I've started a build (-smp 4 -m 2048 but no
DEB_BUILT_OPTIONS=parallel=X)
> > but you can do this on your machine whenever you wish.

I know it. It is just a temporary lack of time and bandwidth. :-)

> Test build succeeded.  I'm running another, this time with parallel=4
(same
> VM settings), but it smells good enough.
>
> Do we want this version uploaded?

I think so.

Cheers,
Giulio

Bug#872559: RFS: opengrm-ngram/1.3.2-1 -- opengrm n-gram library

[Giulio Paci]

I noticed that the building failed on several architectures.

I have the impression that some of them failed due to memory exhaustion and 
some other were aborted.

I monitored RAM on amd64 and found out that most files require about 650MB of 
RAM in order to be compiled, but a couple of them require 3.5GB and 2.0GB.

So I decided to artificially limit parallelism if it cannot be guaranteed that 
each process will have at least 2.0GB of RAM.

The idea is that the build may still fail on amd64 build machines with 2 cores 
and 4.0GB of RAM, but should work on larger machines. On 32bit systems it 
should work even
with 2 core and 4.0GB as those files are expected to require less memory on 
32bit systems.

Can you upload the new version?
On mips64el the build failed while running the test suite. However I cannot see 
why (i.e., the build logs are not showing src/test/test-suite.log), can you 
provide me that
file?

Best regards,
Giulio

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

On 29/08/2017 18:43, Giulio Paci wrote:
> On Tue, Aug 29, 2017 at 12:31, "Adam Borowski" <kilob...@angband.pl 
> <mailto:kilob...@angband.pl>> wrote:
>>
>> On Mon, Aug 28, 2017 at 12:49:22PM +0200, Giulio Paci wrote:
>> > Hi Adam,
>> >   I just saw that building on freebsd-i386 failed due to memory exhaustion
>> > during compilation of tests. The only workaround that I can see is to
>> > prevent tests to be compiled if the memory is not enough to compile them.
>> > Do you see any better alternative?
>>
>> Do you think it's a matter of just available memory, or of address space?
>>
>> It did build on all other architectures, including 32-bit ones, so the
>> former is more likely, but you know the package better.
> 
> As far as I know it is just a matter of available memory. In the past we 
> estimated how much memory is needed to compile the package and limited the 
> number of compilation
> processes according to available memory, with a minimum of 1 process.

I just remembered that openfst used to FTBFS on hurd-i386, for the same reason.
I was able to make it compile by disabling optimizations for checks, so I just
pushed a commit that should fix the compilation on kfreebsd-i386.

Are you able to try it on the kfreebsd-i386 building machine?

Cheers,
Giulio

Bug#872559: RFS: opengrm-ngram/1.3.2-1 -- opengrm n-gram library

[Giulio Paci]

On 29/08/2017 12:39, Adam Borowski wrote:
> On Fri, Aug 18, 2017 at 03:48:26PM +0200, Giulio Paci wrote:
>>  * Package name: opengrm-ngram
>>Version : 1.3.2-1
> 
>> It closes BUG:
>>   #871061
>>
>> It builds those binary packages:
>>
>>  libngram-dev - opengrm n-gram library (development)
>>  libngram-tools - opengrm n-gram library (tools)
>>  libngram2  - opengrm n-gram library (runtime)
> 
> Looks good.
> 
> It does FTBFS on kfreebsd-i386 against the outdated openfst, which is good
> (no misbuilt packages).  I wonder, though, perhaps an explicit
> "Build-Depends: libfst-dev >= 1.6.3-1" wouldn't be better to avoid it being
> tried over and over?

I agree. I added an explicit dependency on 1.6.3 instead of 1.5.2.

Cheers,
Giulio

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

On Tue, Aug 29, 2017 at 12:31, "Adam Borowski" <kilob...@angband.pl> wrote:
>
> On Mon, Aug 28, 2017 at 12:49:22PM +0200, Giulio Paci wrote:
> > Hi Adam,
> >   I just saw that building on freebsd-i386 failed due to memory
exhaustion
> > during compilation of tests. The only workaround that I can see is to
> > prevent tests to be compiled if the memory is not enough to compile
them.
> > Do you see any better alternative?
>
> Do you think it's a matter of just available memory, or of address space?
>
> It did build on all other architectures, including 32-bit ones, so the
> former is more likely, but you know the package better.

As far as I know it is just a matter of available memory. In the past we
estimated how much memory is needed to compile the package and limited the
number of compilation processes according to available memory, with a
minimum of 1 process.

> kfreebsd-i386 is not a release architecture, though, so it's not vital to
> fix it immediately.  You really don't want reverse-dependencies to get
> misbuilt, but I've just checked -- opengrm-ngram FTBFSes on kfreebsd-i386
> with the old openfst so this should be safe.

Ok, I will add explict version dependency to other packages.

Giulio

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Hi Adam,
  I just saw that building on freebsd-i386 failed due to memory exhaustion
during compilation of tests. The only workaround that I can see is to
prevent tests to be compiled if the memory is not enough to compile them.
Do you see any better alternative?

Bests,
Giulio
Il giorno 18/ago/2017 19:54, "Giulio Paci" <giuliop...@gmail.com> ha
scritto:

> Il 18/ago/2017 16:20, "Adam Borowski" <kilob...@angband.pl> ha scritto:
> > Let's upload openfst now, then opengrm-ngram once openfst passes binNEW
> and
> > hits the buildds.  phonetisaurus can be ignored for now -- it will be
> > uninstallable but people who already have it installed have libfst4 which
> > satisfies its needs.
> >
> >
> > Does this sound good to you?
>
> It sounds good to me.
>
> Cheers,
> Giulio
>

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Il 18/ago/2017 16:20, "Adam Borowski"  ha scritto:
> Let's upload openfst now, then opengrm-ngram once openfst passes binNEW
and
> hits the buildds.  phonetisaurus can be ignored for now -- it will be
> uninstallable but people who already have it installed have libfst4 which
> satisfies its needs.
>
>
> Does this sound good to you?

It sounds good to me.

Cheers,
Giulio

Bug#872559: RFS: opengrm-ngram/1.3.2-1 -- opengrm n-gram library

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for a new version of the package "opengrm-ngram"

 * Package name: opengrm-ngram
   Version : 1.3.2-1
   Upstream Author : Brian Roark 
 * URL : http://www.openfst.org/twiki/bin/view/GRM/NGramLibrary
 * License : APACHE-2.0
   Section : libs

It closes BUG:
  #871061

It builds those binary packages:

 libngram-dev - opengrm n-gram library (development)
 libngram-tools - opengrm n-gram library (tools)
 libngram2  - opengrm n-gram library (runtime)

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

 git clone git://anonscm.debian.org/collab-maint/opengrm-ngram.git

Bests,
Giulio.



signature.asc
Description: OpenPGP digital signature

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Dear Adam,

On 17/08/2017 22:07, Adam Borowski wrote:
> On Thu, Aug 17, 2017 at 08:24:59PM +0200, Giulio Paci wrote:
>> Dear mentors,
>>  as Jakub, my former sponsor for this package, is not available, I am 
>> looking for a new sponsor.
>>
>> Please note that this package also closes #871170 (FTBFS with gcc-7).
> 
> I've already test-built for a subset of architectures (arm64 43189 seconds,
> armhf 27725, unjay!), then got distracted.  Sorry for that.

No problem. :-)

> How are you going to handle the transition?  Have you tried rebuilding your
> reverse dependencies?  If not, should I do that for you?

I had not, but I did today.

phonetisaurus is not building and will require an update in order to make it 
work with openfst 1.6.3.
I talked with upstream and there are a lot of unreleased updates (probably 
there will be a new release next week).
Unfortunately the build system and requirements have several differences from 
the current packaged version, so it will require some time to fix this package.

opengrm-ngram is not building with gcc-7, but I have already packaged the 
latest upstream release, that fixes gcc-7 compilation and that compiles with 
openfst 1.6.3.

> As you maintain all of the rdeps, you'll handle the transition as a single
> block, right?

I guess we should upload openfst and opengrm-ngram at the same time (even now).
I will need more extensive work for phonetisaurus and I am not currently able 
to predict when that package will be ready.

How do you suggest to deal with this situation?

Best regards,
Giulio

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Dear mentors,
as Jakub, my former sponsor for this package, is not available, I am 
looking for a new sponsor.

Please note that this package also closes #871170 (FTBFS with gcc-7).

Thank you for your help.

Best regards,
Giulio

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: jw...@debian.org


Dear Jakub,

I am looking for a sponsor for my package "openfst".

 * Package name: openfst
   Version : 1.6.3-1
   Upstream Author : Cyril Allauzen <allau...@google.com>, Michael Riley 
<ri...@google.com>
 * URL : http://www.openfst.org/
 * License : Apache-2.0
   Section : libs

It builds these binary packages:

libfst-tools - weighted finite-state transducers library (tools)
libfst8 - weighted finite-state transducers library (runtime)
libfst8-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



signature.asc
Description: OpenPGP digital signature

Re: Start to help with a RFA package (or else)

[Giulio Paci]

Hi Vincent,

On 17/dic/2016 01:18, "Vincent Carluer"  wrote:
>
> I have a question: The upstream have not change since 15 years!
> Instead of applying patch to make it works on debian, won't it be
> better for me to fork the source and correct it directly (for gcc-6
> compatibility for instance or this one
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401440)

It is best practice to have all the patches applied upstream.
If upstream is not active anymore, you may want to have a look if there is
an alternative (e.g., a maintained fork, ...) to this software.
If you also want to become upstream maintainer for that software, you can
do that, but keep in mind that the upstream maintainer role and the Debian
package maintainer role are two different roles and you will still write
patches for Debian (e.g., to fix a bug without importing new features). The
main purpouse in becoming upstream maintainer is to include patches, to
further develop the tool and to make all these changes available outside of
Debian as well.

Best,
Giulio

Re: phonetisaurus in unstable

[Giulio Paci]

Hi Jakub,
thank you for your comments.

On 05/06/2016 13:35, Jakub Wilk wrote:
> In #825236, Giulio asked me about uploading phonetisaurus to unstable.
> If I were the maintainer, I would hesitate to make such upload until the 
> following is done:
> 
> * 1001_fix_binaries_return_values.patch is accepted upstream. (Are they 
> alive?)

They are alive (latest commit in their repository is from 3 months ago), 
although they have not made any proper release since a long time.

They indeed accepted that patch a few years ago, however I noticed they 
reintroduced the same error in phonetisaurus-align later.

I will try to understand if they are planning to release a new version. :-)

> * The system-wide UTF8-CPP is used, instead of the embedded copy.

You are right, I updated the sources in the git repository accordingly.

> * There's at least a minimal automated test suite.

This seems to be the major blocking issue. I will try to provide some tests.

> BTW, the small change I made to the 0.7.8-2 changelog (see the bottom of 
> #701679) seems to have been lost...

Now added in the git repository as well. :-)

Bests,
Giulio



signature.asc
Description: OpenPGP digital signature

Bug#826337: RFS: opengrm-ngram/1.3.0-1 -- opengrm n-gram library

[Giulio Paci]

On 04/06/2016 21:39, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 2016-06-04, 18:42:
>> git clone git://anonscm.debian.org/collab-maint/opengrm-ngram.git
> 
> Let me see:
> 
>> +  * Drop 1001_fix_compilation_issues.patch.
>> +No more needed.
> 
> I'm not a native speaker of English, but shouldn't it be s/more/longer/?

I did a quick search and it seems you are right.

>> +Maximum number of ngrams to leave in model after pruning.Value less than 
>> zero means no target number, just use theta.
> 
> Space is missing between "pruning." and "Value".

Added a patch and updated the manpage.

> There's an unholy mixture of tabs and spaces in update-man.sh: the line you 
> added is indented by 8 spaces, whereas the surrounding lines are indented by 
> tabs.

Fixed.

> There's a similar mixture of tabs and spaces in the definition of BACKUP in 
> debian/rules.

Fixed.

> In #687563, I asked you to talk to upstream about insecure use of /tmp in the 
> test suite. Did anything happen about this?

Just my notification and a quick aknoweldge.
I reproposed the issue to upstream.

> Now that OpenFST is in unstable, should we upload this package to unstable 
> too?

I think so: updated changelog accordingly.

Bests,
Giulio

Bug#826339: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-3 -- speech recognition scoring toolkit

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: bal...@balintreczey.hu

Dear Balint and mentors,

I am looking for a sponsor for an updated version of the package "sctk"

 * Package name: sctk
   Version : 2.4.10-20151007-1312Z+dfsg2-3
   Upstream Author : Jon Fiscus 
 * URL : http://www.nist.gov/itl/iad/mig/tools.cfm
 * License : public-domain and GPL-2+
   Section : libs

It builds those binary packages:

 sctk - speech recognition scoring toolkit
 sctk-doc  - speech recognition scoring toolkit (documentation)

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

 git clone git://anonscm.debian.org/collab-maint/sckt.git

Bests,
Giulio.

Bug#826337: RFS: opengrm-ngram/1.3.0-1 -- opengrm n-gram library

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: jw...@debian.org

Dear Jakub and mentors,

I am looking for a sponsor for a new version of the package "opengrm-ngram"

 * Package name: opengrm-ngram
   Version : 1.3.0-1
   Upstream Author : Brian Roark 
 * URL : http://www.openfst.org/twiki/bin/view/GRM/NGramLibrary
 * License : APACHE-2.0
   Section : libs

It builds those binary packages:

 libngram-dev - opengrm n-gram library (development)
 libngram-tools - opengrm n-gram library (tools)
 libngram2  - opengrm n-gram library (runtime)

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

 git clone git://anonscm.debian.org/collab-maint/opengrm-ngram.git

Bests,
Giulio.

Re: Problems building phast against clapack

[Giulio Paci]

I just noticed that I did not include mentors list in my answer...

Il 03/giu/2016 13:53, "Giulio Paci" <giuliop...@gmail.com> ha scritto:

>

> Hi all,
>
> Il 03/giu/2016 12:47, "Andrey Rahmatullin" <w...@debian.org> ha scritto:
> >
> > On Fri, Jun 03, 2016 at 11:20:09AM +0200, Andreas Tille wrote:
> > > In other words you mean this is a bug in libf2c2 package
> > Yes, an RC one.
> >
> > > - but how to fix this?
> > I have no idea. MAIN__ is used by the library, but not defined in it.
>
> As far as I know this is the intended behavior and is needed so that the
library can perform initialisation before main(). Just define main as
MAIN__ when compiling your binaries and they should work (have a look at
[0]).
>
> BTW: other fortran compilers implements similar strategies, with
different naming; autoconf has a macro detecting the most common setups.
>
> [0] https://gcc.gnu.org/onlinedocs/gcc-2.95.3/g77_16.html

Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library

[Giulio Paci]

On 31/05/2016 11:52, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 2016-05-31, 09:33:
>> I just checked the building status of openfst and noticed failures on arm 
>> architectures and on kfreebsd-amd64.
>>
>> On arm it seems to me that a timeout occurred,
> 
> One suspicious thing I found in armhf build log is:
> 
> /usr/bin/make -C . -j4 -k distclean
> 
> but this machine has only 4GB of RAM. So our parallelism limits don't seem to 
> be enforced.

Indeed I was wondering how much memory was available on that build machine. :-)

> This line
> 
> ifneq "$(wildcard /build/buildd-*/)" ""
> 
> was supposed to detect if the package is being built on a buildd, but buildds 
> do longer use build directories like this. I don't think there's any reliable 
> and future-proof
> way to detect this, so I'd suggest to drop this ifneq (i.e., start limiting 
> parallelism everywhere).

I was thinking about removing this line in any case, as the limit is useful 
everywhere.


>> on kfreebsd-amd64 it seems a compiler failure.
> 
> I suspect that cc1plus was killed by OOM killer, for the same reason as above.

Probably yes.
The limit we set (~2GB) is not enough when we have to deal with 64bit build 
machines building the test suite with optimization flags turned on.

So I implemented a workaround that sets different limits for the build phase 
and the check phase.

Can you review my changes and eventually upload them?

Bests,
Giulio

Re: Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Hi Jakub and all,
   I just checked the building status of openfst and noticed failures on
arm architectures and on kfreebsd-amd64.

On arm it seems to me that a timeout occurred, on kfreebsd-amd64 it seems a
compiler failure.

Am I right? Is there anything that could be done?

Bests,
Giulio

Il 24/mag/2016 23:42, "Giulio Paci" <giuliop...@gmail.com> ha scritto:
>
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-CC: jw...@debian.org
>
>
> Dear Jakub,
>
> I am looking for a sponsor for my package "openfst".
>
>  * Package name: openfst
>Version : 1.5.3-1
>Upstream Author : Cyril Allauzen <allau...@google.com>, Michael Riley <
ri...@google.com>
>  * URL : http://www.openfst.org/
>  * License : Apache-2.0
>Section : libs
>
> It builds these binary packages:
>
> libfst-tools - weighted finite-state transducers library (tools)
> libfst3 - weighted finite-state transducers library (runtime)
> libfst3-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
>

Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library

[Giulio Paci]

On 26/05/2016 18:48, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 2016-05-25, 19:10:
>>>> https://anonscm.debian.org/git/collab-maint/openfst.git
> [...]
>> I added some code to restrict the build to mips, mipsel and hurd-i386.
> 
> Just like the last time[1], -O0 wasn't enough to get the tests built on mips:
> | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat 
> -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -o .libs/algo_test_log
> algo_test_log-algo_test.o  ../lib/.libs/libfst.so -lm -ldl
> | algo_test_log-algo_test.o: In function 
> `fst::LookAheadCompose(fst::Fst<fst::ArcTpl<fst::TropicalWeightTpl > > 
> const&,
> fst::Fst<fst::ArcTpl<fst::TropicalWeightTpl > > const&, 
> fst::MutableFst<fst::ArcTpl<fst::TropicalWeightTpl > >*)':
> | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:54:(.text+0x304): 
> relocation truncated to fit: R_MIPS_GOT16 against 
> `__stack_chk_guard@@GLIBC_2.4'
> | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:67:(.text+0x4e8): 
> relocation truncated to fit: R_MIPS_GOT16 against 
> `__stack_chk_guard@@GLIBC_2.4'
> | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:55:(.text+0x588): 
> relocation truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0'
> | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:67:(.text+0x598): 
> relocation truncated to fit: R_MIPS_CALL16 against 
> `__stack_chk_fail@@GLIBC_2.4'
> | algo_test_log-algo_test.o: In function `main':
> | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:41:(.text+0x5f4): 
> relocation truncated to fit: R_MIPS_GOT16 against 
> `__stack_chk_guard@@GLIBC_2.4'
> | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:42:(.text+0x600): 
> relocation truncated to fit: R_MIPS_GOT16 against 
> `FLAGS_fst_verify_properties'
> | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:43:(.text+0x60c): 
> relocation truncated to fit: R_MIPS_GOT16 against `FailedNewHandler()'
> | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:43:(.text+0x610): 
> relocation truncated to fit: R_MIPS_CALL16 against `std::set_new_handler(void 
> (*)())@@GLIBCXX_3.4'
> | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:44:(.text+0x64c): 
> relocation truncated to fit: R_MIPS_CALL16 against `SetFlags(char const*, 
> int*, char***, bool, char
> const*)'
> | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:48:(.text+0x674): 
> relocation truncated to fit: R_MIPS_CALL16 against `time@@GLIBC_2.0'
> | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:49:(.text+0x6a4): 
> additional relocation overflows omitted from the output
> | collect2: error: ld returned 1 exit status
> | Makefile:641: recipe for target 'algo_test_log' failed
> 
> Appending "-mxgot" to CXXFLAGS fixed this error.
> Inconveniently, "-mxgot" is not a valid option on hurd, so you'll have to add 
> another ifneq.

I added two separate ifneq, one for hurd-i386 and one for mips/mipsel 
architectures. By reading the option description and the above error messages, 
I guess that the flag
is needed only for the test suite, so I added the flag only there. Let me know 
if I have to change it

> Minor stylistic nitpick: I find
> 
>  ifneq "$(foobar)" ""
> 
> much more readable than
> 
>  ifneq (,$(foobar))

I changed the syntax.

> [1] https://lists.debian.org/20160418195914.ga5...@jwilk.net
> 
> 
>> Do you think phonetisaurus [0] can also be uploaded to unstable?
>>
>> [0] https://anonscm.debian.org/cgit/collab-maint/phonetisaurus.git
> 
> I'll have a look at it later.

Fine.

Thank you very much for your time and hints.

Bests,
Giulio

Re: Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library

[Giulio Paci]

On 25/05/2016 13:22, Jakub Wilk wrote:
> Control: tags -1 + moreinfo
> 
> * Giulio Paci <giuliop...@gmail.com>, 2016-05-24, 23:38:
>> https://anonscm.debian.org/git/collab-maint/openfst.git
> 
> The package FTBFS (on i386):
> 
> | Making check in test
> | make[3]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test'
> | /usr/bin/make  fst_test weight_test algo_test_log algo_test_tropical 
> algo_test_minmax algo_test_lexicographic algo_test_power
> | make[4]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test'
> | g++ -DHAVE_CONFIG_H   -I./../include  -Wdate-time -D_FORTIFY_SOURCE=2  -g 
> -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
> -std=c++11 -c -o fst_test.o
> fst_test.cc
> | /bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O0 -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security -std=c++11  -fPIE 
> -pie -Wl,-z,relro
> -Wl,-z,now -o fst_test fst_test.o ../lib/libfst.la -lm -ldl
> | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat 
> -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -o .libs/fst_test
> fst_test.o  ../lib/.libs/libfst.so -lm -ldl
> | g++ -DHAVE_CONFIG_H   -I./../include  -Wdate-time -D_FORTIFY_SOURCE=2  -g 
> -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
> -std=c++11 -c -o
> weight_test.o weight_test.cc
> | /bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O0 -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security -std=c++11  -fPIE 
> -pie -Wl,-z,relro
> -Wl,-z,now -o weight_test weight_test.o ../lib/libfst.la -lm -ldl
> | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat 
> -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -o .libs/weight_test
> weight_test.o  ../lib/.libs/libfst.so -lm -ldl
> | g++ -DHAVE_CONFIG_H   -DTEST_LOG -Wdate-time -D_FORTIFY_SOURCE=2  -g -O0 
> -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c 
> -o
> algo_test_log-algo_test.o `test -f 'algo_test.cc' || echo './'`algo_test.cc
> | In file included from algo_test.cc:6:0:
> | ./algo_test.h:9:24: fatal error: fst/fstlib.h: No such file or directory
> | compilation terminated.

I added a patch for this.

> (I tested 1.5.3-1, but I don't see anything changed in 1.5.3+r2-1 that would 
> fix it...)
> Please reduce optimization level to -O0 only on architectures where it is 
> strictly required. Otherwise there's a risk that bugs that only trigger with 
> optimization enabled
> go under our radar even on mainstream archs.

I added some code to restrict the build to mips, mipsel and hurd-i386.

> I'm fine with uploading openfst to unstable.

Fine, I updated changelog accordingly.

Do you think phonetisaurus [0] can also be uploaded to unstable?

[0] https://anonscm.debian.org/cgit/collab-maint/phonetisaurus.git

Bests,
Giulio

Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: jw...@debian.org


Dear Jakub,

I am looking for a sponsor for my package "openfst".

 * Package name: openfst
   Version : 1.5.3-1
   Upstream Author : Cyril Allauzen <allau...@google.com>, Michael Riley 
<ri...@google.com>
 * URL : http://www.openfst.org/
 * License : Apache-2.0
   Section : libs

It builds these binary packages:

libfst-tools - weighted finite-state transducers library (tools)
libfst3 - weighted finite-state transducers library (runtime)
libfst3-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

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

Hi Balint and all,

On 16/05/2016 16:50, Bálint Réczey wrote:
> Hi Giulio,
> 
> 2016-05-08 14:32 GMT+02:00 Giulio Paci <giuliop...@gmail.com>:
>> Hi Balint and all,
>>
>> Il 08/mag/2016 14:15, "Bálint Réczey" <bal...@balintreczey.hu> ha scritto:
>>>
>>> Control: owner -1 bal...@balintreczey.hu
>>>
>>> 2016-05-06 23:44 GMT+02:00 Gianfranco Costamagna
>>> <locutusofb...@debian.org>:
>>>> Hi Balint, so I presume you want to set yourself as owner of this bug,
>>>> right?
>>>
>>> Sure, and I'm also about to upload the package in the current state.
>>> Feel free to continue the discussion about bringing irstlm under Debian
>>> Science
>>> in this bug or or on the team's mailing list.
>>
>> I currently do not need this version (I am using the old one in production,
>> so I think we can wait a few days before uploading this package and upload
>> it under Debian science).
>>
>> If I understand correctly, given its current state, the only things that I
>> need to do are:
>> 1) ensure that I am part of Debian Science team;
>> 2) change maintainer and uploaders;
>> 3) move git repository under Debian Science and update Vcs fields in the
>> package;
>> 4) update changelog.
>>
>> Is that all?
> 
> I think so.
> 
>>
>> In order to move the repository, is it fine if I setup a new repository in
>> Debian Science, change my remote url and push there? Or will I cause
>> troubles  acting in this way (eg.: too many commits emails)?
>> Do you have a better migration workflow?
> 
> I think pushing is OK.

As you probably noticed I moved the package under Debian Science and Mattia 
already uploaded the new version. :-)

> Since I have uploaded the package and FTP Masters already accepted it
> I close this bug.
> 
> Regarding the package, providing a symbols file would be nice. :-)

Given my previous attempt at providing symbols files for C++ packages I am 
reluctant to do so.
If possible I will avoid adding that file for a while:
upstream is not answering my emails since a while and I still have to instruct 
them about SONAMEs and many other things (e.g., binary name conflicts, scripts 
extensions,
...); I would like to have better interaction with them, before trying to keep 
track of symbols.

> Feel free to ping me on ask for sponsorship on debian-science in the
> future, there is no
> need to file formal RFS-s to BTS if there are people who regularly
> sponsor upload for you. :-)

Fine, thank you. :-)

Cheers,
Giulio

Re: Binaries under "/usr/lib/"

[Giulio Paci]

Hi all,


On 18/05/2016 11:48, Ben Finney wrote:
> On 18/05/2016 10:21, Tiago Ilieve wrote:
>> On 17 May 2016 at 21:06, Ben Finney  wrote:
>>> How many process calls are there? The ideal solution IMO is to:
>> Not much of them. In my case, there's just one. I was thinking about a
>> corner case, where there would be multiple process calls, possible
>> making a patch like this somewhat hard to maintain.

>>> * Make the location of application-private binaries configurable at
>>>   build time, with a simple one-point-of-truth (e.g. a Makefile
>>>   variable).
>>>
>>> * Patch every call to those application-private binaries to use the
>>>   configured location.
>>>
>>> * Submit that patch upstream, explaining why it's superior behaviour.
>>>
>>> * Maintain the patch in Debian for the (short?) time while upstream
>>>   incorporates the patch.


>> Thanks for your input. I like your suggestions, as they look pretty
>> straightforward, but this is how this is being done for other
>> packages?
>
> Differently, depending on the state of upstream.

I agree with Ben, that it depends on the package.

One approach that usually fits my needs is the one proposed by Thibaut Paumard 
[1], that I am reproposing here with minimal changes:

1) install the binaries with the original names into /usr/lib//bin
2) install a small script (possibly named ) in /usr/bin
this script should provide an interface so that calling:
 
will grant that any required variable is set to the right value
and that /usr/lib//bin/ is executed; it is also
possible to drop extensions in the new interface;
3) ideally add "help" and "path" command, in order to simplify the life
of the users.

This approach works well also in case of binary names conflicts, is usually not 
invasive and allows smooth transitions to the new approach.

For an example you can see irstlm [2]. I think the example is nice as:
- irstlm has many scripts with extensions that people are using in their own 
scripts;
- it has a "dict" command (so we have a nice conflict with a famous tool);
- recently upstream introduced "plsa" and "plsa.sh" commands, so, after 
extension removal it has a collision with itself;
- there are "compile-lm" and "score-lm" commands that are very likely to 
conflicts with many other frameworks in this field;
- I provided a bash-autocompletion file for it.

Bests,
Giulio

[1] https://lists.debian.org/debian-mentors/2012/04/msg00012.html
[2] https://anonscm.debian.org/git/debian-science/packages/irstlm.git/

Re: Private Debian package: Quilt | git | add files to package

[Giulio Paci]

Hi Denny,
  I think most of the confusion comes from the two roles that you are
trying to have. I think it would be easier to try to gain some experience
in the Debian packager role, before trying to mix them. Well, this is how
it works with me. :-)

Anyway...

Il 10/mag/2016 13:23, "Denny Fuchs" <linuxm...@4lin.net> ha scritto:

> Am 10.05.2016 11:15, schrieb Giulio Paci:
>
> [...]
>
>> No changes are allowed to files outside the debian/ directory. So it
>> seems that you changed and commited sandbox_simulators/apache.conf,
>> making it different with respect to what you have in the tarball file.
>
>
> that is the point, where I get lost. I have no tarball, because,
everything is committed via Git.
> So git-buildpackage creates its own tarball, and I expected, that the
newly added file is simply there (it is) and also in the new (on the fly)
created tarball. But the process complains ... that there is no patch.

Reading your tutorial, at some point you create a tarball (make dist) and
you import it to git (gbp import-orig). From that point, you have a tarball
and you should stop changing any file outside the debian directory. Unless
a new tarball is available and you are going to import it using gbp
import-orig.

> I'm relative sure, if I drop the git repo and create a brand new one,
also included with the apache.conf, it works again.
> So, there is some fundamental error, I have done, or git-buildpackage.

I often wear the two hats of upstream and packager. The approach that works
best for me is having one separate branch (or more) for Debian packaging
and one for the pristine-tar, on top of my upstream development setup.
As upstream developer I continue to develop as usual. As a packager, from
time to time (usually decided on development or deployment needs) I create
tarballs, import them and merge in the debian branch, and start doing
packaging work on that branch.

I personally do not have a straregy for "continuos packaging" (i.e., a
system that creates a Debian package from the development git branch),
although it is possible to setup CI on both development and packaging
branches.
So I cannot give you hints about it.

In practice your goal is to create a Debian package with every push on the
development branch, right?

If yes, I have no experience with that.

>> In practice, before building the package, with all patches removed,
>> you have to grant that all the files outside of the debian directory
>> are exactly as they are in the tarball (with a few exceptions, like
>> .gitignore file).
>
>
> See above :-)
>
>
>>> I red (somewhere), that a Git commit (the new file for example) has
>>
>> to be added via a (quilt) patch
>>
>> I never tried, but, as soon as quilt pop -a, makes the changes outside
>> the debian directory go away, it should work. I suggest to avoid
>> commit files outside the debian directory anyway.
>
>
> jupp, right, but you can cleanup the whole directory or remove and do a
git clone  and try again. It breaks on the newly added file.
>
>
>
>>> In the Makefile (also a quilt patch, to copy all files to the right
>>
>> place ...), I tried to copy the created apache.conf file to
>> /usr/share/doc//apache.conf.example
>>
>> Here I do not get... What Makefile?
>
>
> Something like:
>
> all:
>
> install:
>  mkdir -p 
>  [...]
>  cp -r webfiles/* $(DESTDIR)/usr/share/webfiles
>  [...]
>  
>  cp apache.conf
$(DESTDIR)/usr/share/doc/sandbox-emulators/apache-example.conf
>
>
> [...]
>
> The Makefile is created via quilt
(debian/patches/01_create_makefile.diff) and is easy enough for the most
jobs.
>
>
>> start thinking that, as a Debian package,r you are not going to
>> develop the software itself: you have a tarball and you have to
>
>
> In that case, I'm own both roles (if I understand you correct). I'm the
maintainer and one of the upstream developer.
>
>
>> package the tarball. When upstream will release new tarballs, you will
>> package them. Your goal is to simplify system administration.
>
>
> ( ... and make it working with Jenkins ;-) ..)
>
> thanks for the suggestions ... but for the git part ... I didn't
understand it :-)
>
> cu denny
>

Re: Private Debian package: Quilt | git | add files to package

[Giulio Paci]

Hi Denny,

(I am resending because I forgot to add mentors in the reply)

Il 10/mag/2016 10:02, "Denny Fuchs" > ha scritto:

> I trying to create a own private Debian package which mostly worked [...] 
> until I wanted to add a file (an example Apache configuration). Now it fails 
> ... and I don't get
it in the right way.

> dpkg-source: info: local changes detected, the modified files are:
>  sandbox_simulators/apache.conf
> dpkg-source: error: aborting due to unexpected upstream changes, see 
> /tmp/sandbox-simulators_1.0-4.diff.NYXrUc

No changes are allowed to files outside the debian/ directory. So it seems that 
you changed and commited sandbox_simulators/apache.conf, making it different 
with respect to
what you have in the tarball file.

In practice, before building the package, with all patches removed, you have to 
grant that all the files outside of the debian directory are exactly as they 
are in the
tarball (with a few exceptions, like .gitignore file).

> I red (somewhere), that a Git commit (the new file for example) has to be 
> added via a (quilt) patch

I never tried, but, as soon as quilt pop -a, makes the changes outside the 
debian directory go away, it should work. I suggest to avoid commit files 
outside the debian
directory anyway.

> In the Makefile (also a quilt patch, to copy all files to the right place 
> ...), I tried to copy the created apache.conf file to 
> /usr/share/doc//apache.conf.example

Here I do not get... What Makefile?
Anyway I think you may have a look at dh_install and dh_installdocs.
You can just add the file somewhere in the debian directory and add 
.install and .docs to install them in the proper location.

> My last Howto: http://www.lpenz.org/articles/debgit/

> Any suggestions are welcome :-)

I just had a quick look at it. The prerequisites you listed are not needed for 
the tutorial. And their descriptions can be improved and made more general.

The tutorial is mixing at least two roles: upstream developer and debian 
packager. These roles have different goals and operates in different ways. So, 
I suggest to make it
clear in the tutorial, and start thinking that, as a Debian package,r you are 
not going to develop the software itself: you have a tarball and you have to 
package the
tarball. When upstream will release new tarballs, you will package them. Your 
goal is to simplify system administration.

Please add relevant documentation from Debian. At least the debian policy and, 
as you are targeting upstream developers: https://wiki.debian.org/UpstreamGuide

Regarding this last document, please, read it and try to review your tutorial 
according to it. I think small practical examples are useful, as long as they 
do not conflict
with reference guidelines.

Cheers,
Giulio




signature.asc
Description: OpenPGP digital signature

Bug#823849: RFS: opengrm-ngram/1.2.2-1 -- opengrm n-gram library

[Giulio Paci]

On 09/05/2016 23:58, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 2016-05-09, 17:40:
>> git://anonscm.debian.org/collab-maint/opengrm-ngram.git
> 
> Let me see:
> 
>> +  * Import Upstream version 1.2.2.
>> +(Closes: #707826)
> 
> This sounds as if #707826 was a request to package new upstream release.

Right: added a separate entry for the FTBFS bug.

>> +- replace automake1.13 with automake
> 
> This is inaccurate: the previous version has build-depends on automake1.11.

Fixed.

>> +  * Refresh 1005_fix_libraries_linking.patch and +
>> 1002_remove_bashisms.patch.
> 
> I wouldn't call changes to 1002_remove_bashisms.patch a "refresh". The 
> content of the patch is now radically different.

Right, I separated the entry and expanded the change description.

>> +  * Drop 1003_fix_spelling.patch and 1004_fix_ngram_h_file.patch.
> 
> If you are dropping them because they were applied upstream, then please say 
> so explicitly.

This was the reason, so I added a note about it.

>> +  * Change Section from text to science.
> 
> Note that updating d/control is not enough to convince dak that the package 
> is in the new section. After the upload, you'll have to file a bug against 
> ftp.d.o to update it.
> (Use "reportbug ftp.debian.org", then choose "override".)

Thank you for this note, I was not aware of it... And I will need for another 
package as well.

>> + Running tests in parallel with make resulted in many tests
>> + failure, due to several file access race conditions. This
> 
> Typo: failure -> failures

Fixed.

> Typo in NEWS:
> Compatability -> Compatibility

Added and forwarded a new patch for it.

Bests,
Giulio

Bug#823849: RFS: opengrm-ngram/1.2.2-1 -- opengrm n-gram library

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: jw...@debian.org

Dear Jakub and mentors,

I am looking for a sponsor for an updated version of the package "opengrm-ngram"

 * Package name: opengrm-ngram
   Version : 1.2.2-1
   Upstream Author : Brian Roark 
 * URL : http://www.openfst.org/twiki/bin/view/GRM/NGramLibrary
 * License : APACHE-2.0
   Section : libs

It builds those binary packages:

 libngram-dev - opengrm n-gram library (development)
 libngram-tools - opengrm n-gram library (tools)
 libngram1  - opengrm n-gram library (runtime)

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

 git clone git://anonscm.debian.org/collab-maint/opengrm-ngram.git

I did not realize it took me two years before reacting to your last email about 
this package... :-/
I am sorry about that.

Bests,
Giulio.

Bug#823806: RFS: mongo-cxx-driver-legacy/1.1.1-1 -- MongoDB C++ Driver

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear all,

I am looking for a sponsor for my package "mongo-cxx-driver-legacy"

 * Package name: mongo-cxx-driver-legacy
   Version : 1.1.1-1
   Upstream Author : MongoDB community 
 * URL : https://github.com/mongodb/mongo-cxx-driver
 * License : Apache-2.0 and AGPL-3 and Zlib and Expat and BSD-3-clause 
and Loki-library and public-domain
   Section : devel

It builds these binary packages:

mongo-cxx-driver-legacy-dev - MongoDB C++ Driver (development)
libmongoclient0 - MongoDB C++ Driver (runtime)


You can download the package with git using this command:

   git clone git://anonscm.debian.org/collab-maint/mongo-cxx-driver-legacy.git

More information about the software can be obtained from 
https://github.com/mongodb/mongo-cxx-driver/wiki/.

The software is very similar to libmongoc [1] (the only difference being the 
target language).

I wonder if it would be better to follow libmongoc naming and description, 
rather than current naming and description (that mimic upstream words).

A package review is very welcome.

Regards,
 Giulio

[1] https://packages.qa.debian.org/libm/libmongoc.html

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

Hi Balint and all,

Il 08/mag/2016 14:15, "Bálint Réczey"  ha scritto:
>
> Control: owner -1 bal...@balintreczey.hu
>
> 2016-05-06 23:44 GMT+02:00 Gianfranco Costamagna :
> > Hi Balint, so I presume you want to set yourself as owner of this bug,
right?
>
> Sure, and I'm also about to upload the package in the current state.
> Feel free to continue the discussion about bringing irstlm under Debian
Science
> in this bug or or on the team's mailing list.

I currently do not need this version (I am using the old one in production,
so I think we can wait a few days before uploading this package and upload
it under Debian science).

If I understand correctly, given its current state, the only things that I
need to do are:
1) ensure that I am part of Debian Science team;
2) change maintainer and uploaders;
3) move git repository under Debian Science and update Vcs fields in the
package;
4) update changelog.

Is that all?

In order to move the repository, is it fine if I setup a new repository in
Debian Science, change my remote url and push there? Or will I cause
troubles  acting in this way (eg.: too many commits emails)?
Do you have a better migration workflow?

Bests,
Giulio

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

On 06/05/2016 10:52, Ghislain Vaillant wrote:
> On 06/05/16 09:30, Giulio Paci wrote:
>> Il 06/mag/2016 08:36, "Ghislain Vaillant" <ghisv...@gmail.com
>> <mailto:ghisv...@gmail.com>> ha scritto:
>>  > You just need to join the team
>>  > on alioth, which will grant you access to the team's git repositories.
>>
>> If I remember correctly I am already part of the team, although I never
>> contributed to package maintainance.
>> The wiki page of the team also report me as a team member.
> 
> Good.
> 
>>  > Then, you can move the packaging repository over, change the
>> Maintainer field to "Debian Science Maintainers >  > maintain...@lists.alioth.debian.org
>> <mailto:maintain...@lists.alioth.debian.org>>" and move yourself to the
>>  > Uploaders field.
>>
>>  >> Regarding the tasks, I think "linguistics" is fine. In addition,
>> what about "machine learning" and/or "statistics"?
>>  >>
>>  >> How can I add them to the tasks? I have found this repository
>> https://anonscm.debian.org/cgit/blends/projects/science.git but no clear
>> instructions.
> 
> You are supposed to checkout the repository with:
> 
>   git+ssh://git.debian.org/git/blends/projects/science.git
> 
> Edit the relevant task files, commit and push. The sentinels will
> be refreshed accordingly on the next job.
>
>>  > This process is actually independent of having the package maintained
>>  > under the DST or not. However, you need to join the team to be able to
>>  > modify the task files.
>>
>> Are the task files the only files that needs to be changed? Am I
>> expected to make the changes directly on the repository?
> 
> Indeed.

I have not enough permissions to push to that repository.
So I pushed some changes to linguistics task here: 
https://github.com/giuliopaci/science_blends.git

Can you review and import those changes into 
git+ssh://git.debian.org/git/blends/projects/science.git ?

>>  > I can add the package to linguistics, machine
>>  > learning and statistics.
>>
>> What I meant with my question is: are those two tasks right for this
>> package? They are surely strongly related, probably more than
>> linguistics, but, I do not know if the intended users of these tasks may
>> expect to find this package on their system. Are there a description of
>> the tasks which includes some use case description (or use case
>> description that includes tasks suggestion)? If not, probably it would
>> be nice to have some use case description somewhere that my help users
>> to better understand if the task is useful for them or not and may
>> further help us in deciding if a package is suitable for a given task.
> 
> Linguistics sounds the most appropriate. I'd say machine-learning and
> statistics should rather be for more generic packages, since any piece
> of software which is a minimum applied (such as this one) is expected to
> use a mixture of those.

For me it is a bit confusing, because I see a mixture of "use cases" vs 
"topics" in the current tasks definitions, that makes them very ambiguos in my 
mind.

linguistics is probably too generic as a topic to be able to avoid adding a lot 
of tools that are not useful to the greatest part of the users.

I would personally include many tools that are required to my work on 
linguistics that are probably not relevant to many other people working on 
linguistics.
Namely: ffmpeg, sox and sptk (among the other). Anyway I added some of these 
tools that I use very often as suggestions (transcriber, praat and wavesurfer), 
as they are
targeted to linguistics.

There are several tools that are also very relevant, like espeak or festival, 
which includes many technologies that are very handy to people doing research 
on linguistics.

Maybe I should suggest "speech technologies" task, or similar, somewhere?


Cheers,
Giulio



signature.asc
Description: OpenPGP digital signature

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

Il 06/mag/2016 08:36, "Ghislain Vaillant" <ghisv...@gmail.com> ha scritto:
>
> On 06/05/16 02:48, Giulio Paci wrote:
>>
>> On 05/05/2016 19:45, Ghislain Vaillant wrote:
>>>
>>> On 05/05/16 17:16, Giulio Paci wrote:
>>>>
>>>> Package: sponsorship-requests
>>>> Severity: normal
>>>> X-Debbugs-CC: rbal...@debian.org
>>>>
>>>> Dear Balint,
>>>>
>>>> I am looking for a sponsor for an updated version of my package
"irstlm"
>>>>
>>>>* Package name: irstlm
>>>>  Version : 6.00.05-1
>>>>  Upstream Author : Marcello Federico <feder...@fbk.eu>
>>>>* URL : https://github.com/irstlm-team/irstlm/
>>>>* License : LGPL-2.1
>>>>  Programming Lang: C++, Perl, Bash
>>>>  Description : IRST Language Modeling Toolkit
>>>>  Section : misc
>>>>
>>>> This package includes latest upstream releases and several package
updates.
>>>>
>>>> You can found the sources for the package and additional information
at:
>>>>
>>>> https://anonscm.debian.org/cgit/collab-maint/irstlm.git/
>>>>
>>>> A review of the package is more than welcome.
>>>>
>>>> Regards,
>>>>  Giulio Paci
>>>>
>>>
>>> Hi Giulio,
>>>
>>> You might be interested to move this package to co-maintenance under the
>>> Debian Science Team [1] and integrate it to one of the tasks [2] in the
>>> future (perhaps the linguistics task [3]?).
>>
>>
>> You are right, and it is my intention to do so in future.
>> The only thing stopping me is that at the moment the sponsorhip for this
package is working and I have very scarce time, so that I had not yet
reread the rules of the team
>> (last time I read them was a few years ago).
>
>
> It is not that much overhead actually.

You are probably right, but still I think it would be nice to know the team
policy and workflows before the change.

> You just need to join the team
> on alioth, which will grant you access to the team's git repositories.

If I remember correctly I am already part of the team, although I never
contributed to package maintainance.
The wiki page of the team also report me as a team member.

> Then, you can move the packaging repository over, change the Maintainer
field to "Debian Science Maintainers  maintain...@lists.alioth.debian.org>" and move yourself to the
> Uploaders field.

>> Regarding the tasks, I think "linguistics" is fine. In addition, what
about "machine learning" and/or "statistics"?
>>
>> How can I add them to the tasks? I have found this repository
https://anonscm.debian.org/cgit/blends/projects/science.git but no clear
instructions.
>
>
> This process is actually independent of having the package maintained
> under the DST or not. However, you need to join the team to be able to
> modify the task files.

Are the task files the only files that needs to be changed? Am I expected
to make the changes directly on the repository?

> I can add the package to linguistics, machine
> learning and statistics.

What I meant with my question is: are those two tasks right for this
package? They are surely strongly related, probably more than linguistics,
but, I do not know if the intended users of these tasks may expect to find
this package on their system. Are there a description of the tasks which
includes some use case description (or use case description that includes
tasks suggestion)? If not, probably it would be nice to have some use case
description somewhere that my help users to better understand if the task
is useful for them or not and may further help us in deciding if a package
is suitable for a given task.

Anyway, if you can add the package to relevant tasks, I will try to learn
by example how to do that. ;-)

> You might want to add some upstream metadata [1], so our sentinels can
> display additional information about the software such as screenshots,
> citations...
> [1] https://wiki.debian.org/UpstreamMetadata

I will read the page during the next few days. I think citations is
important for upstream of these packages.

> Thanks for working on this package.

Thank you for your suggestions.

Giulio

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

On 05/05/2016 19:45, Ghislain Vaillant wrote:
> On 05/05/16 17:16, Giulio Paci wrote:
>> Package: sponsorship-requests
>> Severity: normal
>> X-Debbugs-CC: rbal...@debian.org
>>
>> Dear Balint,
>>
>> I am looking for a sponsor for an updated version of my package "irstlm"
>>
>>   * Package name: irstlm
>> Version : 6.00.05-1
>> Upstream Author : Marcello Federico <feder...@fbk.eu>
>>   * URL : https://github.com/irstlm-team/irstlm/
>>   * License : LGPL-2.1
>> Programming Lang: C++, Perl, Bash
>> Description : IRST Language Modeling Toolkit
>> Section : misc
>>
>> This package includes latest upstream releases and several package updates.
>>
>> You can found the sources for the package and additional information at:
>>
>>https://anonscm.debian.org/cgit/collab-maint/irstlm.git/
>>
>> A review of the package is more than welcome.
>>
>> Regards,
>> Giulio Paci
>>
> 
> Hi Giulio,
> 
> You might be interested to move this package to co-maintenance under the
> Debian Science Team [1] and integrate it to one of the tasks [2] in the
> future (perhaps the linguistics task [3]?).

You are right, and it is my intention to do so in future.
The only thing stopping me is that at the moment the sponsorhip for this 
package is working and I have very scarce time, so that I had not yet reread 
the rules of the team
(last time I read them was a few years ago).

Regarding the tasks, I think "linguistics" is fine. In addition, what about 
"machine learning" and/or "statistics"?

How can I add them to the tasks? I have found this repository 
https://anonscm.debian.org/cgit/blends/projects/science.git but no clear 
instructions.

> A few remarks:
> d/control: the source package is Section: text. Section: libs or
> Section: science is probably more appropriate.

I think science is more appropriate than libs in this case. I switched to 
science section.

> d/control: Homepage should probably be http://hlt-mt.fbk.eu/technologies
> /irstlm

Fixed.

> d/copyright: Source should probably be the Github repository, not the
> sourceforge page, which clearly says: "IRSTLM is no more supported on
> SourceForge."

Fixed.

> 
> [1] https://wiki.debian.org/DebianScience
> [2] http://blends.debian.org/science/tasks/
> [3] http://blends.debian.org/science/tasks/linguistics
> 
> Best regards,
> Ghis




signature.asc
Description: OpenPGP digital signature

Bug#823470: RFS: sequitur-g2p/0.0.r1668.r3-1 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

On 05/05/2016 19:07, Christian Kastner wrote:
> On 2016-05-05 17:16, Giulio Paci wrote:
>>> One thing I'm not quite sure I follow yet is the change in the version
>>> numbering scheme, both upstream and in the package. This is how it looks
>>> to me:
>>>
>>>   1. Upstream re-used revision r1668 and added a -r3 suffix
>>>   -> "r1668" trades a bit of revision semantic for version semantic
>>>
>>>   2. Hence your switch to version semantic in d/changelog
>>>
>>> Is my interpretation correct?
>>
>> You are right. The change is due to the fact that they relied on svn 
>> revisions for releases in the past. Now they have switched to another 
>> repository (probably still svn),
>> and I understand that they are around revision 70 on the new one.
>>
>> My understanding is that they have private versions of intermediate packages 
>> that they did not publish.
>>
>> I have not talked with upstream about this anyway.
> 
> I'd do that when you get the chance, just to clarify what release plans
> they have. Some upstreams may even benefit from a bit of guidance, eg:
> 
> https://wiki.debian.org/UpstreamGuide#Releases_and_Versions

Thank you for this pointer.
I will probably do in future, if I will see further development happening.

Unfortunately this software, as many other developed by students, is very 
important in its field,
but lacks further development once the student is graduated. So I cannot 
foresee any future releases,
unless I (or others) propose further changes and these are accepted.

> In this particular case, I'd actually suggest that you stick to your
> previous approach, and just modify it slightly:
> 
>g2p-r1668.tar.gz => 0+r1668
> g2p-r1668-r3.tar.gz => 0+r1668.r3 (or even just keep -r3!)

I decided to follow the suggestion from 
https://www.debian.org/doc/manuals/maint-guide/first.en.html#idp39551808 :

"You should choose the upstream version to consist only of alphanumerics 
(0-9A-Za-z), plus (+), tildes (~), and periods (.). It must start with a digit 
(0-9)."

> The solution above retains the largest flexibility in the face of
> the current ambiguity. For example, if upstream were to release a version
> '0.0.1', your new solution would no longer work:
> 
> $ dpkg --compare-versions '0.0.r1668.3-1' lt '0.0.1-1' || echo "oops!"
> oops!

You are right. I am still wondering how it happened that I changed the version 
scheme...
Probably the error came from the watch file... Anyway it should be fixed now.

> You can achieve the aforementioned modification by chaining patterns in
> uversionmangle using a semicolon. Based on your previous version:
> 
> -opts="uversionmangle=s/^(.*)$/0+$1/"
> +opts="uversionmangle=s/^(.*)$/0+$1/; s/-r(\d+)/.r$1/"
> 
> $ uscan --report-status | grep -A4 'newest first'
> uscan info: Found the following matching hrefs on the web page (newest 
> first):
>g2p-r1668-r3.tar.gz (0+r1668.r3) index=0+r1668.r3-1 
>g2p-r1668.tar.gz (0+r1668) index=0+r1668-1 
>g2p-r103.tar.gz (0+r103) index=0+r103-1 
>g2p-r96.tar.gz (0+r96) index=0+r96-1
> 
> On a side note: I believe you can simplify the version matching pattern
> in your watch file. You currently match for many possible suffixes, but
> upstream apparently only uses .tar.gz.

I simplified suffix matches.

Bests,
Giulio



signature.asc
Description: OpenPGP digital signature

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: rbal...@debian.org

Dear Balint,

I am looking for a sponsor for an updated version of my package "irstlm"

 * Package name: irstlm
   Version : 6.00.05-1
   Upstream Author : Marcello Federico <feder...@fbk.eu>
 * URL : https://github.com/irstlm-team/irstlm/
 * License : LGPL-2.1
   Programming Lang: C++, Perl, Bash
   Description : IRST Language Modeling Toolkit
   Section : misc

This package includes latest upstream releases and several package updates.

You can found the sources for the package and additional information at:

  https://anonscm.debian.org/cgit/collab-maint/irstlm.git/

A review of the package is more than welcome.

Regards,
   Giulio Paci

Bug#823470: RFS: sequitur-g2p/0.0.r1668.r3-1 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Hi Christian,

On 05/05/2016 11:08, Christian Kastner wrote:
> On 2016-05-05 03:57, Giulio Paci wrote:
> 
>> I am looking for a sponsor for an updated version of my package 
>> "sequitur-g2p"
> 
>>git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git
> 
>> A package review is very welcome as well.
> 
> Looks good to me. Nice to see that upstream included so many of your
> patches.

Yeah, I am also very happy about it. Also because they already integrated some 
suggestions and seems to want to integrate others suggestions as well. :-)

> One thing I'm not quite sure I follow yet is the change in the version
> numbering scheme, both upstream and in the package. This is how it looks
> to me:
> 
>   1. Upstream re-used revision r1668 and added a -r3 suffix
>   -> "r1668" trades a bit of revision semantic for version semantic
> 
>   2. Hence your switch to version semantic in d/changelog
> 
> Is my interpretation correct?

You are right. The change is due to the fact that they relied on svn revisions 
for releases in the past. Now they have switched to another repository 
(probably still svn),
and I understand that they are around revision 70 on the new one.

My understanding is that they have private versions of intermediate packages 
that they did not publish.

I have not talked with upstream about this anyway.

Cheers,
Giulio

Bug#823470: RFS: sequitur-g2p/0.0.r1668.r3-1 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear all,

I am looking for a sponsor for an updated version of my package "sequitur-g2p"

 * Package name: sequitur-g2p
   Version : 0.0.r1668.r3-1
   Upstream Author : Maximilian Bisani 
 * URL : 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html
 * License : GPL-2
   Section : science

It builds those binary packages:

   sequitur-g2p - Grapheme to Phoneme conversion tool


You can download the package with git using this command:

   git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git

More information about sequitur-g2p can be obtained from 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html.

A package review is very welcome as well.

Regards,
 Giulio

Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit

[Giulio Paci]

Il 24/apr/2016 12:54, "Jakub Wilk" <jw...@debian.org> ha scritto:
>
> * Giulio Paci <giuliop...@gmail.com>, 2016-04-24, 01:13:
>
>>>> +  * Update Source field in copyright.
>>>
>>> Policy §12.5 says that the “the copyright file must say where the
upstream sources (if any) were obtained”, but they are not available (and
never were AIUI) at the new location. So I think keeping the original
Source would be better^Wless wrong, at least until the tarball Debian uses
appears on the new site.
>>
>> Reverted the change
>
>
> But the changelog still say it's been updated.

Removed the line.

>>> spellintian(1) says:
>>> debian/patches/1003_make_logger_more_flexible.patch: Allows to ->
Allows one to
>>
>> Fixed.
>
> But not documented in the changelog...

Added a line for it.

Bests,
Giulio

Bug#822360: RFS: sequitur-g2p/0.0.r1668-3 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Hi Christian,

On 24/04/2016 00:02, Christian Kastner wrote:
> control: owner -1 !
> I'd be happy to sponsor your package.

Thank you.

> On 2016-04-23 21:06, Giulio Paci wrote:
>> I am looking for a sponsor for an updated version of my package 
>> "sequitur-g2p"
>>
>> You can download the package with git using this command:
>>
>>git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git
> 
> First, a general note: more specific commit messages would facilitate
> reviewing (at least for me). For example:
> 
>     commit c98be9ed397b0ba4be9aa6c82f1ce1be54e06acf
> Author: Giulio Paci <giuliop...@gmail.com>
> Date: Tue Apr 19 21:56:57 2016 +0200
> 
> Updated control file.
> 
> What update was that? From the other commits, I can deduce that this was
> merely a refreshing of d/control from d/control.in, and the actual
> changes -- namely bumping Standards-Version, and updating Vcs-* --
> happened earlier. This was a bit confusing, so being explicit about this
> could be helpful.

You are perfectly right.
I think "Refreshed" is a much better word in this case, so I will use this word 
in future.

> Furthermore, the "better" your commit structure and messages, the more
> you get out of them yourself. You seem to be using git-buildpackage, so
> using the magic command `gbp dch`, you can have gbp initialize a
> debian/changelog entry from your commit history for you. And the better
> your commit history, the less polishing you need to do.

Already using it, and indeed I need some polishing every time. :-)

> On to the specific notes:
>   * d/copyright:
> - Refers twice to the "GNU _Lesser_ General Public License". Seems
>   to be copy-pasta, as all other references to GPL-2 are correct

Fixed.

>   * d/patches:
> - Please consider making the headers DEP3-compliant (although it's
>   not a "hard" requirement): http://dep.debian.net/deps/dep3/

Can you point me to what the current headers are missing in order to be 
DEP3-compliant?
Did I miss some mandatory field?

> - Patches should be sufficiently self-describing. I can understand
>   the motivation for 1013, 1014, and 1015 but not the others:
> + 1011: Why change multigram size? Did this improve something?
> + 1012: Why add SWIG options? How did this affect the build?


>   * d/changelog:
> - Please indicate why Vcs-* fields were changed. Something like:
>   "Switch to secure URIs in Vcs-* fields"

I used exactly these words. :-)

> Your package built cleanly and without lintian errors or warnings, so as
> soon as you address the above issues, I'd be ready to upload.

I just pushed the changes to the repository.

Bests,
Giulio

Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit

[Giulio Paci]

On 23/04/2016 22:00, Jakub Wilk wrote:
> Control: owner -1 !
> 
> * Giulio Paci <giuliop...@gmail.com>, 2016-04-23, 21:13:
>> https://anonscm.debian.org/cgit/collab-maint/mitlm.git
> 
> Let me see:
> 
>> +  * Add 0001_add_am_prog_ar_to_configure.ac.
> 
> Please explain (in the changelog) what this patch does.

Done.

>> +  * Allow recent autotools usage.
> 
> I have no idea what this means...

I think just an error... Essentially it summarizes the two points above.

>> +  * Update Vcs-* and Homepage fields in control file.
> 
> Nitpicking: Vcs-* and Homepage are unrelated, so I'd put them in separate 
> items.

Done.

>> +  * Update watch file.
> 
> Hmm, but there are no tags at the new location. Have you talked to upstream 
> about this?

I think I can be considered upstream for this package, as I am "maintaining" it 
since a few years (essentially since last official release).
I left the reference to Paul because he is still available (I have active 
communication with him) to answer questions that I may not know how to answer.
My plan is to use tags for the next releases, but there are no commit that are 
exactly reflecting the current one.

>> +  * Update Source field in copyright.
> 
> Policy §12.5 says that the “the copyright file must say where the upstream 
> sources (if any) were obtained”, but they are not available (and never were 
> AIUI) at the new
> location. So I think keeping the original Source would be better^Wless wrong, 
> at least until the tarball Debian uses appears on the new site.

Reverted the change until a new release will be available, then I will switch 
again.

> spellintian(1) says:
> debian/patches/1003_make_logger_more_flexible.patch: Allows to -> Allows one 
> to

Fixed.

Bests,
Giulio

Bug#822360: RFS: sequitur-g2p/0.0.r1668-3 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

On 23/04/2016 21:22, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 2016-04-23, 21:06:
>>   git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git
> [...]
>> Would you like to review and upload it?
> 
> I'm sorry, but I don't do Python these days. Please seek another sponsor. 
> Perhaps ask on debian-python@ldo?

I am sorry as well: you already said me so. I will try to remember for the next 
time. ;-)

Giulio

Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: Jakub Wilk <jw...@debian.org>

Dear Jakub,

  I am looking for a sponsor for an updated version of my package "mitlm"

* Package name: mitlm
  Version : 0.4
  Upstream Author : Bo-June (Paul) Hsu <bo...@mit.edu>
* URL : https://github.com/mitlm/mitlm
* License : BSD
  Programming Lang: (C, C++, Fortran)
  Section : misc

It builds those binary packages:

 libmitlm0  - MIT Language Modeling toolkit library
 libmitlm0-dev - MIT Language Modeling toolkit development files
 mitlm - MIT Language Modeling toolkit

You can find the source of the package at:

  https://anonscm.debian.org/cgit/collab-maint/mitlm.git

Regards,
   Giulio Paci

Bug#822360: RFS: sequitur-g2p/0.0.r1668-3 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: Jakub Wilk 

Dear Jakub,

I am looking for a sponsor for an updated version of my package "sequitur-g2p"

 * Package name: sequitur-g2p
   Version : 0.0.r1668-3
   Upstream Author : Maximilian Bisani 
 * URL : 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html
 * License : GPL-2
   Section : science

It builds those binary packages:

   sequitur-g2p - Grapheme to Phoneme conversion tool


You can download the package with git using this command:

   git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git

More information about sequitur-g2p can be obtained from 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html.

Would you like to review and upload it?

Regards,
 Giulio

openfst 1.5.2 high memory usage at compile time

[Giulio Paci]

Hi Jakub and all,
I noticed that openfst 1.5.2-1 [0] is failing to build on mips and 
mipsel architectures [1].

You already pointed out that algo_test.cc compilation requires more than 2GB on 
i386, and we already set some reasonable limits for parallel builds to cope 
with several
possible memory issues.

My understanding of the failure is that there is a 2GB limit per process on 
mips architecture. Is it right?

algo_test.cc is used only in the test suite, so I wonder if we can just 
workaround the issue by disabling optimization and using "-O0" for that 
specific file. Is this a
possible workaround?

I am thinking about adding something like this to rules file:

ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
common-build-arch::
+$(DEB_MAKE_INVOKE) CXXFLAGS="$(CXXFLAGS:-O%=-O0) -std=c++11" -C 
src/test  algo_test.o
endif

In the meanwhile I also asked upstream if it is possible to simplify that code, 
in order to reduce its memory requirements.

Bests,
Giulio

[0] https://anonscm.debian.org/cgit/collab-maint/openfst.git/
[1] 
https://buildd.debian.org/status/fetch.php?pkg=openfst=mips=1.5.2-1=1460909743



signature.asc
Description: OpenPGP digital signature

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

[Giulio Paci]

Hi Jakub,
upstream released a new version of openfst.

On 15/03/2016 11:33, Giulio Paci wrote:
> On 11/03/2016 16:34, Jakub Wilk wrote:
>> * Giulio Paci <giuliop...@gmail.com>, 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. :-\
> 
> You are right. I did not notice as I have disabled that extension (it is 
> available also in pypi, so that one can be packaged if anybody is interested).
> I asked upstream and they agreed to release the .pyx file in the next openfst 
> release.
> 
> Essentially we are waiting:
> 1) .pyx file release;

This issue has been addressed.

> 2) openfst patch for Kaldi review.

This issue has not been addressed. As far as I know no progress at all has been 
made.
If you agree as this patch is a prerequisite for having Kaldi in Debian (which 
is one of my goals), I would include this patch without having it approved by 
upstream.
I am confident that they will approve it once they will find time to evaluate 
it, but I am not confident they will evaluate it very soon.

Bests,
Giulio

Bug#820754: RFS: m2m-aligner/1.0-2 -- many-to-many alignments for string transduction

[Giulio Paci]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: Jakub Wilk <jw...@debian.org>

  Dear mentors,

  I am looking for a sponsor for my package "m2m-aligner"

 * Package name: m2m-aligner
   Version : 1.0-2
   Upstream Author : Sittichai Jiampojamarn
 * URL : https://github.com/letter-to-phoneme/m2m-aligner/
 * License : MIT
   Section : science

  It builds those binary packages:

m2m-aligner - many-to-many alignments for string transduction

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

  https://anonscm.debian.org/git/collab-maint/m2m-aligner.git


  Regards,
   Giulio Paci

Re: Request service reload after package install

[Giulio Paci]

Hi Gianfranco and The Wanderer,

On 22/03/2016 15:04, The Wanderer wrote:
> On 2016-03-22 at 09:28, Gianfranco Costamagna wrote:
>> Hi, do the post* files in virtualbox-ext-pack package help? they have
>> some user interaction, and restart of services IIRC.
> 
> Restarting services after package installation is relatively common, and
> can be seen in the postinst files of many packages. The one which I most
> often see, as a prompt with a list of services to be restarted, is
> libc6.

I think libc6 post* files are closer to what I want to achieve than 
virtualbox-ext-pack post* files.
Thank you for this example...
Especially because it gives me another goal: to also trigger restart whenever 
dependencies are updated. But I think this is not possible without the 
cooperation of the
dependency package, right?
In this particular case the main dependency that should trigger the restart 
would be openjdk-7-jre.

> However, as far as I'm aware, all of them have one flaw in common: if
> you install multiple packages which require restart of the same service
> (including, e.g., multiple architectures' versions of the same package;
> this happens with libc6 on a multiarch system), the service will be
> restarted multiple times - once per package. Giulio specifically cited
> having only one service restart per "session" as one of his goals.

It is one of my goal, because the service requires about 10 seconds to start.
And the typical installation involves more than ten independent plugins.

Another option would be to prevent automatic restart during installation/update
and always perform manual restart at the end of the update.

> I don't know of any way to avoid or work around this multiple-restart
> behavior which would be clean and robust enough to be worth
> implementing, except for adding support for this sort of state handling
> to the tools which do the installation - apt and dpkg, probably in an
> interlocking way. Unfortunately, I don't know of a good design for this,
> and I infer from the fact that it's never been done that no one else has
> come up with one either.

Clear enough.

Bests,
Giulio




signature.asc
Description: OpenPGP digital signature

Request service reload after package install

[Giulio Paci]

Hi to all,
  I am trying to package a software that is composed by a server and
several optional plugins.

I would like to package the plugins independently.

The server needs to be restarted whenever it is updated or whenever a
plugin is updated/installed/uninstalled.

However I do not know how to do it properly. Is there anybody that can
point me to relevant documentatiin/examples?

What I want to achieve is:
1) the restart should be done only if the server is running;
2) the restart is done only if user agree with it;
3) only one restart is done when updating/installing/uninstalling packages.

Thank you for your help.

Bests,
Giulio

Bug#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

On 20/03/2016 22:37, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 2016-03-20, 03:05:
>>> I'm looking partly shocked at the commit
>>> 6fc1eec66c259cefeeb13453c3ceeb206fb24a55 why did you *substituted* the 
>>> pristine-tar data?  You should always just add them.
>>
>> This is just because upstream never tagged a version, nor released a package.
>> I imported one using 0.0.1 version, but later noticed that 1.0 was set in 
>> the source and so I renamed the package.
> 
> Um. If upstream didn't make a release, then you ask them to make one, instead 
> of declaring yourself that this random git snapshot will be called 1.0.
> 
> That the source says it's "1.0" is not very relevant, unless upstream bumps 
> version in every commit; and they don't.

You are right. I wrote an email to Brad asking for a release.

> Also, you probably want to fix your debian/watch. :)

This for sure. Although steelskin is an interesting project as well... ;-)

Thank you for these comments.

Bests,
Giulio

Bug#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

Hi Mattia,
thank you for your review and for wishing to sponsor this package.

On 19/03/2016 13:37, Mattia Rizzolo wrote:
> control: tag -1 moreinfo
> control: owner -1 !
> 
> On Fri, Feb 05, 2016 at 03:04:19PM +0100, Giulio Paci wrote:
>>   I am looking for a sponsor for my package "msi-keyboard":
> 
> alright.
> 
>>   https://anonscm.debian.org/cgit/collab-maint/msi-keyboard.git
> 
> cool!  finally somebody coming here with a git repository!
> 
> though:
> * I see no tags, I expect to see at least the upstream/* tags (also
>   otherwise gbp can be noisy and annoying)

Added a tag.

> * the HEAD points to master; given that the packaging branch is
>   "debian", please configure the remote repository on collab-maint to
>   have HEAD point to "debian" instead, so that cloning the repository
>   gives you the packaging branch even without specifying it.

Fixed.

> * as said you are using a non-standard repository layout, so I expect
>   debian/gbp.conf to be explicitly configured to use
>   'debian-branch = debian' and 'upstream-branch = master'

Fixed.

> * also, Vcs-Git does not specify the branch (which is kinda optional if
>   you set correctly HEAD on the remote repository, but it wouldn't harm
>   to write it here too)

Fixed.

> * I'm looking partly shocked at the commit
>   6fc1eec66c259cefeeb13453c3ceeb206fb24a55 why did you *substituted* the
>   pristine-tar data?  You should always just add them.

This is just because upstream never tagged a version, nor released a package.
I imported one using 0.0.1 version, but later noticed that 1.0 was set in the 
source and so I renamed the package.
This was before publishing the repository, while doing preliminary package work.
Then I forgot to cleanup the history before publishing it. :-(

> that's just about the git repository.
> 
> review on the package itself:
> * debian/control:
>   + please sort the build-deps with wrap-and-sort or with cme or

Done.

>   + please bump Standards-Version to 3.9.7

Done.

>   + please drop the build-dep on dpkg-dev, that version is old enough
> and dpkg-dev is in build-essential

Ok.

>   + please build-dep on debhelper (>= 9), no need for that ~

Ok.

>   + please drop the version constriction on qt5-qmake, that version is
> old enough

Ok.

> * debian/changelog:
>   + I see there is a weird space between the month and the year, how so?

Manual editing instead of using dch.

> * debian/copyright:
>   + there is a \t at line 9, please just use spaces for consistency.  I
> have a feeling you editor is configured to show a tab as 8 spaces,
> but this is not everybody's configuration, in fact here the line is
> indeed in a weird way.

Fixed (and correct guess about the editor configuration).

>   + please use the license names as specified by DEP-5, so name it
> "BSD-3-clause" and not lowercase

Fixed.

> * debian/msi-keyboard.{post,pre}inst:
>   + what aree these?  Quasi-empty files?

Dropped. I added them while trying to understand how to deal udev files... And 
then forgot about them.
BTW: do you know how to make the udev file work after installation, without 
rebooting the system?

> * debian/patches:
>   + debian/patches/series is empty, please remove the whole directory

Ok.

> Then, here it fails to build:
> 
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/build/msi-keyboard-1.0'
> PATH="`pwd`":"$PATH" help2man msi-keyboard --no-info --name="MSI steelseries 
> keyboard color changer" > debian/msi-keyboard.1
> help2man: can't get `--help' info from msi-keyboard
> Try `--no-discard-stderr' if option outputs to stderr
> debian/rules:12: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2
> make[1]: Leaving directory '/build/msi-keyboard-1.0'
> debian/rules:6: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> E: Failed autobuilding of package

Fixed. The issue was the build order vs help2man run, as Jakub said.

> I wonder why not just use `help2man ./msi-keyboard ...` instead of
> messing around with PATH (which is probably what went wrong here).

As Jakub pointed out, this is needed to get proper command name in the man page.

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

[Giulio Paci]

On 11/03/2016 16:34, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 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. :-\

You are right. I did not notice as I have disabled that extension (it is 
available also in pypi, so that one can be packaged if anybody is interested).
I asked upstream and they agreed to release the .pyx file in the next openfst 
release.

Essentially we are waiting:
1) .pyx file release;
2) openfst patch for Kaldi review.

Probably they will be both handled within the next couple of months.

Bests,
Giulio

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 <giuliop...@gmail.com>, 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

[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 <giuliop...@gmail.com>, 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

[Giulio Paci]

On 29/02/2016 16:37, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 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

[Giulio Paci]

Hi Jakub,

On 29/02/2016 00:27, Jakub Wilk wrote:
> * Giulio Paci <giuliop...@gmail.com>, 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

[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 <giuliop...@gmail.com>, 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#815791: RFS: gtranscribe/0.3-1 [ITP] -- simple GTK+ tool focussed on easy transcription of spoken words

[Giulio Paci]

On 25/02/2016 10:08, Paul Wise wrote:
> On Thu, 2016-02-25 at 09:42 +0100, Philip Rinn wrote:
> 
>> I think you misunderstood the purpose of gTrcanscribe. It's not about 
>> subtitles, 
>> it's about transforming spoken words (like recorded interviews) into text 
>> files 
>> by transcription. I only see one other program for this purpose in Debian, 
>> transcriber[1], which I find much less intuitive to use.
> 
> Sounds like pretty much the same process as subtitling to me, but OK.
> 

I agree with Philip Rinn that we have three different tasks here.

Apparently gtranscribe targets users that just want the transcription of an 
audio file, with the purpouse to obtain a written form of the audio, to be 
used, for example, in
a blog.

In Debian we have several subtitling software (e.g. gnome-subtitles) that 
serves a similar purpose. But subtitles will not help providing a written form 
of the audio and
will force users to deal with time synchronization. It is possible to export 
the subtitles in a text file and edit afterwards, but I agree that is not very 
convenient for
the simple transcription task.

As far as I know, in Debian we only have one software that is dealing with 
audio annotation, that is transcriber. The annotation task is actually a 
superset of the
subtitling task, as the main difference is that there are much more machine 
readable information that should be produced. I also agree that transcriber is 
suboptimal for
the simple transcription task, as it will try to push the user to deal with 
time synchronization, channels, speakers, noises, ... On the other end, the 
output of
transcriber will be much more convenient to edit for the simple transcription 
task, because the additional available information can be exploited for this 
purpose.

In the past I have tried to perform all of these tasks. I have never been 
comfortable with any of the subtitles software in Debian. Even for subtitling, 
so, I now use
transcriber for everything.

On the other end, when users just want a simple transcriptions (think about 
students transcribing teacher lessons, so that they can study on it), both 
subtitling software
and transcriber fail shortly and the right tool is probably a player with an 
embedded text editor, with convenient shortcuts for the playback (there should 
be one-key
shortcuts for most of the functions).

Bests,
Giulio

Bug#815791: RFS: gtranscribe/0.3-1 [ITP] -- simple GTK+ tool focussed on easy transcription of spoken words

[Giulio Paci]

Hi Philip,
I am not a DD, so I cannot sponsor this package.
However I am interested in this kind of tools and also maintain transcriber,
that, despite of its age, is still one of the best available alternatives.

Below you may find my comments:

On 24/02/2016 14:35, Philip Rinn wrote:
>   I am looking for a sponsor for my package "gtranscribe"
>   The packaging is available at:
> 
> https://anonscm.debian.org/cgit/collab-maint/gtranscribe.git

I checked out the repository and built the package.

1) I think you should consider upgrading the codebase from python2 to python3, 
as there is a long term goal to drop support to python2
(https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html).

2) dh_python2 is reporting some warnings and I think they should be addressed.

3) gtranscribe.1 file reports "image-file" instead of "audio-file".

4) Running gtranscribe produces warnings on my system:

/usr/bin/gtranscribe:22: PyGIWarning: Gtk was imported without specifying a 
version first. Use gi.require_version('Gtk', '3.0') before import to ensure 
that the right
version gets loaded.
  from gi.repository import GLib, GObject, Gtk, Gdk, GtkSpell
/usr/bin/gtranscribe:22: PyGIWarning: GtkSpell was imported without specifying 
a version first. Use gi.require_version('GtkSpell', '3.0') before import to 
ensure that the
right version gets loaded.
  from gi.repository import GLib, GObject, Gtk, Gdk, GtkSpell


5) I tried gtranscribe with a small wav file (1 channel, 16bit signed int PCM 
little endian, 16kHz)  invoked with:
"gtranscribe "

I got these additional warning lines on the console:
(gtranscribe:10990): Gtk-CRITICAL **: gtk_widget_grab_default: assertion 
'gtk_widget_get_can_default (widget)' failed
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
AL lib: (EE) UpdateDeviceParams: Failed to set 16000hz, got 48000hz instead

I tried the playback (and worked), then I changed the playback slowdown factor 
and tried the playback again (and it worked). Then I tried to change the 
slowdown factor
again at i got a segmentation fault.

6) as soon as a value for the slowdown factor is stored in the user cache, 
running playback and then changing the factor again results in segmentation 
fault.

7) slowdown factor is taken into account only during the first playback.

8) I do not know if these warnings can be addressed or not, but every time I 
add a new line I see this line in the console:

** (gtranscribe:12100): CRITICAL **: enchant_dict_check: assertion 'len' failed

9) Is there any information that can help users understand what format will be 
produced and how to use the file with other tools?
Is the output of this tool supposed to be machine readable?
Because if the answer is yes, it is too easy for a user to completely destroy 
the annotation, as the text is not escaped.

Bests,
Giulio

Re: Bug#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

Hi Paul,

Il 22/feb/2016 07:52, "Paul Wise" <p...@debian.org> ha scritto:
>
> On Sun, Feb 21, 2016 at 6:59 PM, Giulio Paci wrote:
>
> > Do you have any suggestions about where to look for sponsor (maybe a
group
> > dedicated to hardware support or laptops or gaming)?
>
> A couple of possibilities:
>
> <https://lists.debian.org/debian-laptop/>https
<https://lists.debian.org/debian-laptop/>://
<https://lists.debian.org/debian-laptop/>lists.debian.org
<https://lists.debian.org/debian-laptop/>/
<https://lists.debian.org/debian-laptop/>debian-laptop
<https://lists.debian.org/debian-laptop/>/
<https://lists.debian.org/debian-laptop/>
> <https://wiki.debian.org/Games/Team>https
<https://wiki.debian.org/Games/Team>:// <https://wiki.debian.org/Games/Team>
wiki.debian.org <https://wiki.debian.org/Games/Team>/Games/Team
<https://wiki.debian.org/Games/Team>

Thank you!
I started my search on DebianOn wiki page, but did not find these lists (by
reading more carefully, now, I can see the Mobile link there).

Bests,
Giulio

Re: Bug#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

Hi to all,
  I am looking for a sponsor for this package, that is needed to support a
feature (it is possible to change the backlight colors) of the keyboard of
my laptop (MSI GS60).

Is there anybody in this list willing to review/sponsor this package?

Do you have any suggestions about where to look for sponsor (maybe a group
dedicated to hardware support or laptops or gaming)?

Thank you for your help,
Giulio
Il 05/feb/2016 15:06, "Giulio Paci" <giuliop...@gmail.com> ha scritto:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "msi-keyboard":
>
> * Package name: msi-keyboard
>   Version : 1.0
>   Upstream Author : Brad Parker
> * URL : https://github.com/bparker06/msi-keyboard/
> * License : BSD 3-clause
>   Programming Lang: C++
>   Description : command line tool to change MSI steelseries keyboards
> color setup
>
> It builds this binary package:
>
>   msi-keyboard - command line tool to change MSI steelseries keyboards
> color setup
>
> The sources for the package can be found at:
>
>   https://anonscm.debian.org/cgit/collab-maint/msi-keyboard.git
>
> Regards,
> Giulio Paci
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCgAGBQJWtKvfAAoJEM7JlC23rbhv+78P/3MdAbfnhgo4j4IQANWjQbHY
> PXs44AKBJ/gaN4E6Hrx5dVoG2lzmYVqJDhnPsajI6gHCVlZX5yge9DhRzeq+VMyQ
> rbJE7Ou3TfOjxl9lumkO0Rh1kJQsoe3hxDqqgfAhr0tREjwTzgPdS/rcnzMldeZF
> Ygbcd+x155dZ1fH9aq0xZXbUcV5O3ROj32b5H6kFGlP9WtvFPkg/Aw1AYNy5+SDF
> cqf8qhBuuVaNdakQ7Q8vrEPbdXO2PF5lKtmz1H8XNHEGGpNyu4jlHrWawR2PAKuC
> arTKKyEAwZGCB67HyK0f/aTiFAbBw0fA/Y/sXzOKvza2sIxkIUYm1wJ9YQi4EbPb
> 0sBd17DIuK9icSd7n0rMoPrtEnX5qsUTYiqgNLsJip5bHpyIMHv9FNZnDh0DEdlt
> vZZCHGE+GPUbqrXFFwAigSD4NRP3nGOgq6yjKkkHZw6GosR942kQfDN7schPgv9l
> pftk6kEkQn3TjniDUa9FFs7ibNFKA1OWKE0GNNiuBZ8P5N7As1FZvvT/CoE7vrbN
> UoKCMYwbaKprvZzZDcPOAuETJoqaO25o620Gga4AlNdk2tih1gAtwzzX/aqa3RQz
> srq3QWwkWbZmY3XQgB11alW6xJHQFl7g6EwWim43E1VZpTppXQLZcVUlX1m5mGuE
> d0OTX5lBOTOnSTVbvhzp
> =7IJc
> -END PGP SIGNATURE-
>
>

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 <allau...@google.com>, Michael Riley 
<ri...@google.com>
 * 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

Bug#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "msi-keyboard":

* Package name: msi-keyboard
  Version : 1.0
  Upstream Author : Brad Parker
* URL : https://github.com/bparker06/msi-keyboard/
* License : BSD 3-clause
  Programming Lang: C++
  Description : command line tool to change MSI steelseries keyboards color 
setup

It builds this binary package:

  msi-keyboard - command line tool to change MSI steelseries keyboards color 
setup

The sources for the package can be found at:

  https://anonscm.debian.org/cgit/collab-maint/msi-keyboard.git

Regards,
    Giulio Paci
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWtKvfAAoJEM7JlC23rbhv+78P/3MdAbfnhgo4j4IQANWjQbHY
PXs44AKBJ/gaN4E6Hrx5dVoG2lzmYVqJDhnPsajI6gHCVlZX5yge9DhRzeq+VMyQ
rbJE7Ou3TfOjxl9lumkO0Rh1kJQsoe3hxDqqgfAhr0tREjwTzgPdS/rcnzMldeZF
Ygbcd+x155dZ1fH9aq0xZXbUcV5O3ROj32b5H6kFGlP9WtvFPkg/Aw1AYNy5+SDF
cqf8qhBuuVaNdakQ7Q8vrEPbdXO2PF5lKtmz1H8XNHEGGpNyu4jlHrWawR2PAKuC
arTKKyEAwZGCB67HyK0f/aTiFAbBw0fA/Y/sXzOKvza2sIxkIUYm1wJ9YQi4EbPb
0sBd17DIuK9icSd7n0rMoPrtEnX5qsUTYiqgNLsJip5bHpyIMHv9FNZnDh0DEdlt
vZZCHGE+GPUbqrXFFwAigSD4NRP3nGOgq6yjKkkHZw6GosR942kQfDN7schPgv9l
pftk6kEkQn3TjniDUa9FFs7ibNFKA1OWKE0GNNiuBZ8P5N7As1FZvvT/CoE7vrbN
UoKCMYwbaKprvZzZDcPOAuETJoqaO25o620Gga4AlNdk2tih1gAtwzzX/aqa3RQz
srq3QWwkWbZmY3XQgB11alW6xJHQFl7g6EwWim43E1VZpTppXQLZcVUlX1m5mGuE
d0OTX5lBOTOnSTVbvhzp
=7IJc
-END PGP SIGNATURE-

Bug#786558: RFS: sequitur-g2p/0.0.r1668-2 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Hi Luca!
Yes I am still looking for a sponsor for this package. You are welcome.
:-)

Bests,
Giulio.
Il giorno 06/set/2015 10:59, "Luca Falavigna"  ha
scritto:

> Hi Giulio,
>
> are you still looking for a sponsor for sequitur-g2p? I could have a
> look at it if you want. I'm mostly interested in having python-support
> removed (#786139), but I'll be happy to help you with other issues.
>
> --
> Cheers,
> Luca
>

Re: Bug#786558: RFS: sequitur-g2p/0.0.r1668-2 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Hi Jakub and Debian science team,

* Jakub Wilk jw...@debian.org, 2015-05-22, 22:53:
 * Giulio Paci giuliop...@gmail.com, 2015-05-22, 22:31:
 git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git
 Would you like to review and upload it?

 I'm sorry, but I don't do Python these days. Please seek another sponsor. 
 Perhaps ask on debian-python@ldo?

I am sorry to hear that. However I remember that a couple of years ago we 
received an offer to have this package in Debian Science.
Is the offer still valid? If yes, what are the necessary steps?

Bests,
Giulio.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55679aa8.2020...@gmail.com

Bug#786558: RFS: sequitur-g2p/0.0.r1668-2 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear Jakub,

I am looking for a sponsor for an updated version of my package sequitur-g2p

 * Package name: sequitur-g2p
   Version : 0.0.r1668-2
   Upstream Author : Maximilian Bisani bis...@informatik.rwth-aachen.de
 * URL : 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html
 * License : GPL-2
   Section : science

It builds those binary packages:

   sequitur-g2p - Grapheme to Phoneme conversion tool


You can download the package with git using this command:

   git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git

More information about sequitur-g2p can be obtained from 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html.

Would you like to review and upload it?

Regards,
 Giulio


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/555f923f.4060...@gmail.com

Bug#736437: RFS: phonetisaurus/0.7.8-3 -- Grapheme to Phoneme conversion tool

[Giulio Paci]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package phonetisaurus

 * Package name: phonetisaurus
   Version : 0.7.8-3
   Upstream Author : Josef Novak josef.robert.no...@gmail.com
 * URL : http://code.google.com/p/phonetisaurus/
 * License : BSD-2-clause
   Section : science

  It fixes a bug in phonetisaurus-calculateER.
  I do not think the included patch is relevant to upstream as it does not 
really solve the issue in the general case. I will inform upstream about the 
issue and also ask
if it is possible to do anything in order to fix the remaining two pedantic 
lintian warnings.

  It builds those binary packages:

phonetisaurus - Grapheme to Phoneme conversion tool

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

 git://anonscm.debian.org/collab-maint/phonetisaurus.git

  Regards,
   Giulio Paci


-- 
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/52e1476e.8070...@gmail.com

Bug#687564: RFS: irstlm/5.80.01-1 -- [ITP] IRST Language Modeling Toolkit

[Giulio Paci]

Hi,
I fetched and merged your commits with some minor edits:

1) debian/control is automatically generated from debian/control.in with the 
command:

DEB_MAINTAINER_MODE=1 fakeroot debian/rules pre-build

so I edited your commit to change debian/control.in and then added a commit 
that propagates the change to debian/control.
2) I reworded your commit messages (fixed two mispellings, added first capital 
letter and a final dot);
3) I updated the timestamp in debian/changelog (I am used that this is always 
the last step, whenever I want to inform my sponsor that I think the package is 
ready).

Would you mind to update the package on mentors?

Bests,
Giulio.


Il 09/01/2014 07:01, Koichi Akabe ha scritto:
 Hi,
 
 I fixed debian/ a little bit and pushed it to my personal git repository:
 git://git.debian.org/users/vbkaisetsu-guest/irstlm.git
 http://anonscm.debian.org/gitweb/?p=users/vbkaisetsu-guest/irstlm.git
 
 Could you merge it if you have a time?
 (Now I'm asking permission for collab-maint repository)
 
 
 
 Iwamatsu-san,
 
 I uploaded a package to:
 http://mentors.debian.net/debian/pool/main/i/irstlm/irstlm_5.80.03-1.dsc
 
 Could you check and upload it?
 
 Thanks.
 
 On Wed, 8 Jan 2014 12:03:02 +0100
 Giulio Paci giuliop...@gmail.com wrote:
 
 Hi to all!

 Il 08/gen/2014 09:19 Nobuhiro Iwamatsu iwama...@nigauri.org ha scritto:
 I am a sponsor of Koichi.
 If you need sponsor , I can sponsor this package.

 We need a sponsor for this package and you are very welcome.
 Unfortunately I will have very few spare time until February.

 However I think that Koichi can fix what is still needed (if anything). I
 checked what is still needed. The package is compiling with some warnings,
 but should be in a good shape. The git repository is the latest version and
 the package should be compliant with Debian policy 3.9.5. Yesterday I added
 me and Koichi as uploaders.

 I never used it extensively, so I think it would be better to upload to
 experimental.

 Bests,
 Giulio.

 Please feel free to contact me.

 Best regards,
   Nobuhiro
 
 


-- 
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/52cef2c2.9000...@gmail.com

Bug#734815: RFS: peg/0.1.15-1 -- recursive-descent parser generators for C

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package peg

 * Package name: peg
   Version : 0.1.15-1  Upstream Author : Ian Piumarta
i...@piumarta.com
* URL : http://piumarta.com/software/peg/
* License : MIT/X

   Section : devel

  It builds this binary package:

peg   - recursive-descent parser generators for C

The package source can be downloaded from the git repository on
collab-maint:

git://git.debian.org/git/collab-maint/peg.git

  Regards,
   Giulio Paci


-- 
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/52cf5680.90...@gmail.com

Bug#687564: RFS: irstlm/5.80.01-1 -- [ITP] IRST Language Modeling Toolkit

[Giulio Paci]

Hi to all!

Il 08/gen/2014 09:19 Nobuhiro Iwamatsu iwama...@nigauri.org ha scritto:
 I am a sponsor of Koichi.
 If you need sponsor , I can sponsor this package.

We need a sponsor for this package and you are very welcome.
Unfortunately I will have very few spare time until February.

However I think that Koichi can fix what is still needed (if anything). I
checked what is still needed. The package is compiling with some warnings,
but should be in a good shape. The git repository is the latest version and
the package should be compliant with Debian policy 3.9.5. Yesterday I added
me and Koichi as uploaders.

I never used it extensively, so I think it would be better to upload to
experimental.

Bests,
Giulio.

 Please feel free to contact me.

 Best regards,
   Nobuhiro

Bug#687564: RFS: irstlm/5.80.01-1 -- [ITP] IRST Language Modeling Toolkit

[Giulio Paci]

The package should be in good shape and should only need some minor updates.
More recent upstream version is also available.

If you are interested in sponsoring this package, I can do the work during
the next few days.

If you want to co-maintain the package, feel free to do the work yourself,
but please let me know before doing it.

Bests,
Giulio.

Il 23/dic/2013 14:27 Koichi Akabe vbkaise...@gmail.com ha scritto:

 Hi,

 I'm interested in this package, but this BTS report is not updated for
 a year. How is the status of this package?

 I tried building the newest package on your git repository in sid.
 There is no warning without 1) and 2) you mentioned at Message #50.

 Thanks.

 --
 Koichi Akabe
  vbkaisetsu at {gmail.com, debian.or.jp}


 --
 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/20131223222409.7f1a6174c0ffc00ffc9db...@gmail.com

Bug#712982: RFS: peg/0.1.14-1 -- recursive-descent parser generators for C

[Giulio Paci]

Hi Jakub,
this is just to inform you that I have pushed to git the Debian package
files for peg 0.1.14. The new upstream release includes:
1) a fix to LICENSE.txt;
2) a ChangeLog file;
3) the changes included in the 1001 patch.

Bests,
Giulio.

On 01/12/2013 19:41, Giulio Paci wrote:
 Il 30/11/2013 17:22, Jakub Wilk ha scritto:
 * Giulio Paci giuliop...@gmail.com, 2013-11-29, 17:13:
 What do you mean by Drop manpages?
 I dropped the manpages file. Do you think is ok to rephrase the entry as 
 Drop manpages file?

 I'd write something akin Drop debian/manpages. Upstream makefile now takes 
 care of installing the manpages, so the is no longer needed.
 
 Updated changelog according to your suggestion.
 
 Apparently upstream released a new tarball with some changes, without 
 updating the version number. I will inform upstream to avoid it in future.

 Very well.
 
 Informed upstream.
 
 I am going to update the content in git accordingly to latest 0.1.13 
 package and let you know when it is ready.

 OK.
 
 
 Updated files in git.
 
 Could it be uploaded to unstable instead of experimental?
 I think so.

 Let's do it then. :)
 
 Changed changelog accordingly.
 
 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/529c4606@gmail.com

Bug#712982: RFS: peg/0.1.11-1 -- recursive-descent parser generators for C

[Giulio Paci]

On 02/12/2013 09:54, Jakub Wilk wrote:
 In the changelog you wrote Change patches order, but AFAICS patches
 are in the same order as in 0.1.9-1.

You are right. The patche that changed its position is the one that has
just been dropped.

It should be fixed now.

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/529c5a40.2060...@gmail.com

Bug#712982: RFS: peg/0.1.11-1 -- recursive-descent parser generators for C

[Giulio Paci]

Il 30/11/2013 17:22, Jakub Wilk ha scritto:
 * Giulio Paci giuliop...@gmail.com, 2013-11-29, 17:13:
 What do you mean by Drop manpages?
 I dropped the manpages file. Do you think is ok to rephrase the entry as 
 Drop manpages file?
 
 I'd write something akin Drop debian/manpages. Upstream makefile now takes 
 care of installing the manpages, so the is no longer needed.

Updated changelog according to your suggestion.

 Apparently upstream released a new tarball with some changes, without 
 updating the version number. I will inform upstream to avoid it in future.
 
 Very well.

Informed upstream.

 I am going to update the content in git accordingly to latest 0.1.13 package 
 and let you know when it is ready.
 
 OK.


Updated files in git.

 Could it be uploaded to unstable instead of experimental?
 I think so.
 
 Let's do it then. :)

Changed changelog accordingly.

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/529b82d0.8000...@gmail.com

Bug#712982: RFS: peg/0.1.11-1 -- recursive-descent parser generators for C

[Giulio Paci]

Il 29/nov/2013 14:18 Jakub Wilk jw...@debian.org ha scritto:

 What do you mean by Drop manpages?

I dropped the manpages file. Do you think is ok to rephrase the entry as
Drop manpages file?

 I can't build the source package:

 dpkg-source: info: building peg using existing ./peg_0.1.13.orig.tar.gz
 patching file src/peg.1
 Hunk #38 FAILED at 1006.
 Hunk #39 succeeded at 1074 (offset 37 lines).
 Hunk #40 succeeded at 1082 (offset 37 lines).
 Hunk #41 succeeded at 1121 (offset 37 lines).
 1 out of 41 hunks FAILED


 I downloaded peg_0.1.13.orig.tar.gz using uscan. Apparently the file in
question is different in .orig.tar than in git. :\

Apparently upstream released a new tarball with some changes, without
updating the version number. I will inform upstream to avoid it in future.

I am going to update the content in git accordingly to latest 0.1.13
package and let you know when it is ready.

 Could it be uploaded to unstable instead of experimental?

I think so.

Giulio.

Bug#730156: RFS: transcriber/1.5.1.1-9 [RC] -- Transcribe speech data using an integrated editor

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package transcriber

* Package name: transcriber
  Version : 1.5.1.1-9
  Upstream Author : Transcriber Team transcriber-requ...@etca.fr
* URL : http://trans.sf.net/
* License : GPL-2+
  Programming Lang: C, Tcl
  Section : sound

It builds this binary package:

transcriber - Transcribe speech data using an integrated editor

It closes the following bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728833

You can get latest sources from the following git repository:

git://git.debian.org/git/collab-maint/transcriber.git


More information about transcriber can be obtained from
http://trans.sf.net/.

Regards,
   Giulio Paci


-- 
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/528ea2a2.5000...@gmail.com

Re: Sponsorship request for peg and opengrm-ngram

[Giulio Paci]

Dear mentors,
I am re-asking for sponsorship for peg and opengrm-ngram.

My usual sponsor is out of time and the new versions of both packages are 
waiting for upload since more than one month.

Is there anybody willing to check/upload these two packages (or at least peg, 
that is very straightforward to review)?

Bests,
Giulio.

 On 13/09/2013 13:29, Giulio Paci wrote:
 Dear mentors,

 my sponsor for peg and opengrm-ngram has currently no time to check and
 upload my latest changes to these packages.

 Is there anybody willing to review and possibly upload these two packages?

 Here are the relevant information:

 * peg
 ** RFS report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712982
 ** Latest package source version
git://anonscm.debian.org/collab-maint/peg.git

 * opengrm-ngram
 ** RFS report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707828
 ** Latest package source version
git://anonscm.debian.org/collab-maint/opengrm-ngram.git


-- 
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/52599f85.4050...@gmail.com

Bug#725314: RFS: transcriber/1.5.1.1-8 [RC] -- Transcribe speech data using an integrated editor

[Giulio Paci]

Il 04/10/2013 09:58, Florian Schlichting ha scritto:
 Hi Giulio,
 
 On Fri, Oct 04, 2013 at 03:14:51AM +0200, Giulio Paci wrote:
 I am looking for a sponsor for my package transcriber
  
 It closes the following two bugs:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725254
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725255
 
 could you drop the version on the tcl-tclex dependency? The dependency
 on tclex (=1.2a1-3) was the reason transcriber wouldn't be build on the
 buildds, after the first issue there had been solved. tclex had become a
 virtual package over the last few weeks, only provided by tcl-tclex, and
 versioned build-dependencies don't work on virtual packages I was
 reminded yesterday: 

Dropped.

 did you have a chance to look into the more pedantic lintian
 warnings?

Unfortunately I had no time to fix the duplicate files issue.
There is no distributed upstream changelog, so I just added a lintian-overrides 
file for 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/524e7f8a.6070...@gmail.com

Bug#725314: RFS: transcriber/1.5.1.1-8 [RC] -- Transcribe speech data using an integrated editor

[Giulio Paci]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package transcriber

* Package name: transcriber
  Version : 1.5.1.1-8
  Upstream Author : Transcriber Team transcriber-requ...@etca.fr
* URL : http://trans.sf.net/
* License : GPL-2+
  Programming Lang: C, Tcl
  Section : sound

It builds those binary packages:

transcriber - Transcribe speech data using an integrated editor

It closes the following two bugs:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725254
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725255

You can get latest sources from the following git repository:

git://git.debian.org/git/collab-maint/transcriber.git


More information about transcriber can be obtained from
http://trans.sf.net/.

Regards,
   Giulio Paci


-- 
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/524e168b.9050...@gmail.com

Bug#707828: (no subject)

[Giulio Paci]

The new upstream package (1.1.0) introduced a new test suite that should not 
fail anymore on different architectures.

The debian package sources are available at:
git://anonscm.debian.org/collab-maint/opengrm-ngram.git

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/5248c31e.4040...@gmail.com

Re: Bug#722450: RFS: osmctools/0.1-1 [ITP] -- Some tools to manipulate OpenStreetMap files

[Giulio Paci]

Dear mentors,

my sponsor for peg and opengrm-ngram has currently no time to check and
upload my latest changes to these packages.

Is there anybody willing to review and possibly upload these two packages?

Here are the relevant information:

* peg
** RFS report
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712982
** Latest package source version
   git://anonscm.debian.org/collab-maint/peg.git

* opengrm-ngram
** RFS report
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707828
** Latest package source version
   git://anonscm.debian.org/collab-maint/opengrm-ngram.git

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/5232f72b.70...@gmail.com

Sponsorship request for peg and opengrm-ngram

[Giulio Paci]

Hi to all!

I just sent my previous email (below) with the wrong topic.

Sorry about that.

Bests,
Giulio.

On 13/09/2013 13:29, Giulio Paci wrote:
 Dear mentors,
 
 my sponsor for peg and opengrm-ngram has currently no time to check and
 upload my latest changes to these packages.
 
 Is there anybody willing to review and possibly upload these two packages?
 
 Here are the relevant information:
 
 * peg
 ** RFS report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712982
 ** Latest package source version
git://anonscm.debian.org/collab-maint/peg.git
 
 * opengrm-ngram
 ** RFS report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707828
 ** Latest package source version
git://anonscm.debian.org/collab-maint/opengrm-ngram.git
 
 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/523305b5.8010...@gmail.com

Re: Bug#707828: RFS: opengrm-ngram/1.1.0-1 -- opengrm n-gram library

[Giulio Paci]

Il 11/06/2013 02:28, Giulio Paci ha scritto:
 Il 11/06/2013 00:03, Jakub Wilk ha scritto:
 * Giulio Paci giuliop...@gmail.com, 2013-05-26, 15:27:
 Do you know what it FTBFS on amd64? Last time I checked amd64 was 
 little-endian, so #707826 can't be the reason. ;)
 The problem is not the same, but the fix is.

 Well, I'd rather have the test suite fixed that disabled.
 
 According to upstream they are planning to completely rewrite the test suite 
 for the next release (expected to come soon),
 so I do not see a great advantage in trying to fix it now.

opengrm-ngram 1.1.0 has been released, hopefully fixing the test suite issue.

As usual, the source code for the debian package can be found here:
git://anonscm.debian.org/collab-maint/opengrm-ngram.git

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/52324fff.2090...@gmail.com

Bug#712026: transcriber review

[Giulio Paci]

Il 12/08/2013 09:41, Paul Wise ha scritto:
 A new blocker:
 
 The upstream website contains this text:
 
 New! Jul 11 Transcriber has been superseded by TranscriberAG: see
 http://transag.sourceforge.net/!
 
 I wonder if it would be best to replace Transcriber with TranscriberAG
 in Debian. TranscriberAG uses GTK+ and C++ instead of Tcl/Tk.

In my opinion it is not:
1) neither Transcriber nor TranscriberAG are very active upstream, but I would 
define Transcriber as quite stable while TranscriberAG is still in alpha stage;
2) TranscriberAG is not a real replacement for Transcriber (I.e., it cannot 
modify .trs files, that are used in a lot of pipelines of people working with 
audio annotation);
3) Transcriber has an uglier interface, but very functional (even more than 
TranscriberAG).

This said, TranscriberAG has the potentiality to become a very good software 
(it has a better annotation format, a modern GUI, it annotates both audio and 
video) and
eventually become a good replacement for Transcriber, but given the current 
development state, I do not think it will become such software soon.

This discussion raised several times during the last two years, so I published 
this repository:
https://github.com/giuliopaci/transcriber-ag-debian
It is my first attempt to create a TranscriberAG package, before giving up. The 
package source are in a very bad shape, but, just in case someone wants to work 
on it, at
least compiles everything and install most of the files in the correct location.

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/52089c69.5040...@gmail.com

Bug#712026: transcriber review

[Giulio Paci]

Il 12/08/2013 09:41, Paul Wise ha scritto:
 On Mon, 2013-08-12 at 00:05 +0200, Giulio Paci wrote:
 
 [...] copyright_hints [...]
 
 Maybe it would be best to drop it entirely, it doesn't seem that useful.

I have not yet a strong opinion on it.
More often than not, its presence just created small problems, like the one you 
reported, but sometime it also spotted real issues and proved to be useful.
I prefer to keep it there for now.

 I do not think it is possible to solve this in transcriber. Am I wrong?
 
 From debian/rules:
 
 DEB_DH_INSTALL_ARGS = debian/transcriber.desktop usr/share/applications

I completely forgot that line... I got so used to that message not being 
correct in the past that I even did not check the rules... Sorry about that.
It is fixed now.

 The sphere audio format is designed to cheat text editors: the header is 
 1024 bytes long and is plain ascii, so that most text editors will open the 
 file as text.
 So it is not a text file, but a binary one.
 
 Hmm, ok. A weird audio format, I wonder why it is used instead of just
 ogg, flac or similar.

It is a little bit weird, I agree, but is also very widespread in the speech 
community.
Actually sphere is a container and not a codec and its direct competitor is 
Wav. The long and detailed header usually contains a lot of information about 
the recording
environment and this explains its large usage.
With respect to flac (the container, not the codec), it is able to contain 
A-law and u-law streams (useful when studying telephone speech) and shorten
(http://www.etree.org/shncom.html, used by some widespread speech Corpora, 
especially those from LDC).
If I remember correctly the ogg container is able to contain all the streams 
(probably with the exception of shorten) that can be contained by sph files and 
probably it is
also able to contain all the header information, but I am not sure of this and 
the format is much younger.

 Unless any of the following is blocker, I prefer to fix/decide to not fix 
 them later.
 
 None are.

Fine.

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/5208ae70.1000...@gmail.com

Bug#712026: transcriber review

[Giulio Paci]

Il 11/08/2013 19:47, Paul Wise ha scritto:
 A review:
 
 Blockers:
 
 The changes to debian/copyright_hints look weird, could you explain?

I do not understand what you mean.
The whole content of debian/copyright_hints usually looks weird to me, but it 
is useful to:
1) write debian/copyright from scratch;
2) being notfied that new files exists or that copyright information changed.

 licensecheck complains during the build process about this.

The problem was that generated copyright_hints before applying all the patches, 
while at build time licensecheck is run after applying all the patches.
I just regenerated the file.

 1005_avoid_to_put_transcriber_in_background.patch looks wrong, the case
 you patched is explicitly about putting the program in the background.

This was explicitly requested and I agreed with the person making the request.
I see no point always putting transcriber in background when it is so easy to 
write transcriber  when needed.
Despite the name of the variable bg, its purpose is to detect if the program 
should be run in batch mode or in interactive mode.
Upstream decided that interactive mode implies not only the use of wish instead 
of tclsh, but also to always start transcriber in background.

 Things that might be nice to fix one day:
 
 Please include the .desktop file, icon, manual page and patches
 upstream.

I already started sending some of the patches upstream, but I have not yet 
received an answer yet.

 You might want to wrap debian/menu one item per line.

Done.

 Is debian/dirs still needed?

No it is not. I just dropped the file.

 Automated checks:
 
 https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

Thank you for pointing it.

 cdbs:
 
 /usr/share/cdbs/1/rules/buildcore.mk:109: WARNING:  DEB_DH_INSTALL_ARGS is a 
 deprecated variable

I do not think it is possible to solve this in transcriber. Am I wrong?

 cme:

 Warning in 'patches:1008_update_contacts_and_urls.patch Synopsis' value 
 'updates contacts and references information in program messages': Synopsis 
 is too long.
 Warning in 'patches:1009_update_contacts_and_urls_in_doc.patch Synopsis' 
 value 'updates contacts and references information in program documentation': 
 Synopsis is too
long.

 Warning in 'copyright Format' value 
 'http://www.debian.org/doc/copyright-format/1.0': Format does not match the 
 recommended URL for DEP-5

Fixed.


 suspicious-source:

 demo/know.sph appears to be a text file with a bunch of binary junk appended 
 to the end?

The sphere audio format is designed to cheat text editors: the header is 1024 
bytes long and is plain ascii, so that most text editors will open the file as 
text.
So it is not a text file, but a binary one.

 desktop-file-validate:

 ./debian/transcriber.desktop: error: value Audio;AudioVideo for string list 
 key Categories in group Desktop Entry does not have a semicolon (';') as 
 trailing character
 ./debian/transcriber.desktop: error: value application/wav for string list 
 key MimeType in group Desktop Entry does not have a semicolon (';') as 
 trailing character

Fixed.

 xmllint:

 ./doc/en/sample.xml:19: parser error : Input is not proper UTF-8, indicate 
 encoding !
 Bytes: 0xFB 0x72 0x20 0x3F
 s�r ?
  ^

Fixed.


Unless any of the following is blocker, I prefer to fix/decide to not fix them 
later.

 cme:

 Warning in 'control source Build-Depends:3' value 'debhelper (= 9~)': should 
 be (= 9) not (= 9~) because compat is 9

 gcc:
 
 lots of warnings, please send upstream.
 
 dpkg-shlibdeps:
 
 dpkg-shlibdeps: warning: package could avoid a useless dependency if 
 debian/transcriber/usr/lib/tcltk/transcriber1.5/libtrans.so was not linked 
 against libdl.so.2 (it uses none of the library's symbols)
 dpkg-shlibdeps: warning: package could avoid a useless dependency if 
 debian/transcriber/usr/lib/tcltk/transcriber1.5/libtrans.so was not linked 
 against libpthread.so.0 (it uses none of the library's symbols)
 
 uscan:
 
 Newest version on remote site is 1.5.1, local version is 1.5.1.1
  = remote site does not even have current version

 lintian:
 
 P: transcriber: no-upstream-changelog
 X: transcriber: duplicate-files 
 usr/share/doc/transcriber/html/de/refFrame.html 
 usr/share/doc/transcriber/html/fr/refFrame.html
 X: transcriber: duplicate-files usr/share/doc/transcriber/html/de/pause.bmp 
 usr/share/doc/transcriber/html/img/pause.bmp
 X: transcriber: duplicate-files 
 usr/share/doc/transcriber/html/de/userMenu.html 
 usr/share/doc/transcriber/html/fr/userMenu.html
 X: transcriber: duplicate-files usr/share/doc/transcriber/html/de/play.bmp 
 usr/share/doc/transcriber/html/img/play.bmp
 X: transcriber: duplicate-files usr/share/doc/transcriber/html/de/info.bmp 
 usr/share/doc/transcriber/html/img/info.bmp
 X: transcriber: duplicate-files 
 usr/share/doc/transcriber/html/de/userFrame.html 
 usr/share/doc/transcriber/html/fr/userFrame.html
 X: transcriber: duplicate-files 
 

Bug#712982: RFS: peg/0.1.11-1 -- recursive-descent parser generators for C

[Giulio Paci]

Il 23/06/2013 19:29, Jakub Wilk ha scritto:
 How are win/getopt.* licensed? As I understand it, the original IBM license 
 applies only to the code that is copyrighted by IBM. But what about portions 
 that are Copyright
 (C) 2008, PlexFX?

I have tried several times to contact someone at PlexFX, without any luck.
So I contacted the peg author and we agreed to replace those two files with 
others under a more clear license.

I updated the package with the new release containing replacements for 
win/getopt.*.

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/51eda304.4010...@gmail.com