Bug#1037145: rtw88_8822ce: connection is very unstable

[Giulio Paci]

Package: src:linux
Version: 6.1.27-1
Severity: important
X-Debbugs-Cc: giuliop...@gmail.com



-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=619d22b9-2257-43b7-9995-1c48e5e89e07 ro reboot=bios

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[   18.660669] Key type cifs.idmap registered
[   18.661602] CIFS: No dialect specified on mount. Default has changed to a 
more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use 
the less secure SMB1 dialect to access old servers which do not support 
SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[   18.661714] CIFS: Attempting to mount \\secondary.scanner.local\scanner
[   18.677837] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for 
information.
[   18.678552] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld 
. All Rights Reserved.
[   22.081135] pcieport :00:1d.1: AER: Uncorrected (Non-Fatal) error 
received: :03:00.0
[   22.086224] rtw_8822ce :03:00.0: PCIe Bus Error: severity=Uncorrected 
(Non-Fatal), type=Transaction Layer, (Requester ID)
[   22.088074] rtw_8822ce :03:00.0:   device [10ec:c822] error 
status/mask=4000/0040
[   22.089135] rtw_8822ce :03:00.0:[14] CmpltTO(First)
[   22.090186] rtw_8822ce :03:00.0: AER: can't recover (no error_detected 
callback)
[   22.091271] pcieport :00:1d.1: AER: device recovery failed
[   24.812780] CIFS: VFS: Error connecting to socket. Aborting operation.
[   24.815065] CIFS: VFS: cifs_mount failed w/return code = -113
[   24.817289] CIFS: Attempting to mount \\primary.scanner.local\scanner
[   24.867761] process '/usr/bin/anydesk' started with executable stack
[   25.470440] Bluetooth: RFCOMM TTY layer initialized
[   25.470449] Bluetooth: RFCOMM socket layer initialized
[   25.470468] Bluetooth: RFCOMM ver 1.11
[   30.956641] CIFS: VFS: Error connecting to socket. Aborting operation.
[   30.956679] CIFS: VFS: cifs_mount failed w/return code = -113
[   30.956821] CIFS: Attempting to mount \\tertiary.scanner.local\scanner
[   37.100840] CIFS: VFS: Error connecting to socket. Aborting operation.
[   37.100896] CIFS: VFS: cifs_mount failed w/return code = -113
[  328.416330] rtw_8822ce :03:00.0: firmware failed to report density after 
scan
[  328.972253] rtw_8822ce :03:00.0: failed to get tx report from firmware
[  333.021395] wlo1: authenticate with 1c:5f:2b:cb:90:7c
[  333.344403] wlo1: send auth to 1c:5f:2b:cb:90:7c (try 1/3)
[  333.354471] wlo1: authenticated
[  333.356201] wlo1: associate with 1c:5f:2b:cb:90:7c (try 1/3)
[  333.364348] wlo1: RX AssocResp from 1c:5f:2b:cb:90:7c (capab=0x431 status=0 
aid=1)
[  333.364726] wlo1: associated
[  335.003129] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65455 DF PROTO=UDP 
SPT=37340 DPT=50001 LEN=173 
[  335.004543] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65456 DF PROTO=UDP 
SPT=54049 DPT=50002 LEN=173 
[  335.005539] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65457 DF PROTO=UDP 
SPT=42322 DPT=50003 LEN=173 
[  337.009984] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65474 DF PROTO=UDP 
SPT=52551 DPT=50001 LEN=173 
[  337.011616] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65475 DF PROTO=UDP 
SPT=60442 DPT=50002 LEN=173 
[  337.013004] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65476 DF PROTO=UDP 
SPT=51910 DPT=50003 LEN=173 
[  338.016468] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=140 DF PROTO=UDP 
SPT=52128 DPT=50001 LEN=173 
[  338.018238] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=141 DF PROTO=UDP 
SPT=35654 DPT=50002 LEN=173 
[  338.019507] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=142 DF PROTO=UDP 
SPT=43360 DPT=50003 LEN=173 
[  339.022375] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=152 DF PROTO=UDP 
SPT=57966 DPT=50001 LEN=173 
[  653.065118] [UFW BLOCK] IN=wlo1 OUT= 
MAC=01:00:5e:00:00:01:1c:5f:2b:cb:90:7c:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 
TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 
[  778.506336] [UFW BLOCK] IN=wlo1 OUT= 
MAC=01:00:5e:00:00:01:1c:5f:2b:cb:90:7c:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 
TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 
[  903.952679] [UFW BLOCK] IN=wlo1 OUT= 

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
.

Using -ffloat-store option indeed seems to fix the issue.


However I am wondering:
1) is this the proper solution?
2) is it correct that the compiler does not guarantee the above assumptions?

Do you have any suggestion?

Best regards,
Giulio

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#962439: sctk: diff for NMU version 2.4.10-20151007-1312Z+dfsg2-3.1

[Giulio Paci]

Dear Adrian,
   thank you for taking care of this issue.

Several months ago I filed a RFS bug #981030 taking care of this and other
issues. Unfortunately the RFS is still open. If I update the package in
order to include this NMU changes, will you consider sponsoring the package?

Best regards,
Giulio

Il mar 3 ago 2021, 08:51 Adrian Bunk  ha scritto:

> Dear maintainer,
>
> I've prepared an NMU for sctk (versioned as
> 2.4.10-20151007-1312Z+dfsg2-3.1).
> The diff is attached to this message.
>
> cu
> Adrian
>

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#957839: sptk: ftbfs with GCC-10

[Giulio Paci]

Hi Logan,
   thank you for this patch.

I have included it in the Debian package (I just opened RFS) as well
and submitted upstream.

Cheers,
Giulio

On Sun, Jan 10, 2021 at 12:36 AM Logan Rosen  wrote:
>
> Package: sptk
> Version: 3.9-2
> Followup-For: Bug #957839
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu hirsute ubuntu-patch
> X-Debbugs-Cc: lo...@ubuntu.com
> Control: tags -1 patch
>
> Hi,
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
>   * d/p/gcc-10.patch: Fix compilation with GCC 10.
>
> Thanks for considering the patch.
>
> Logan

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#882602: ocaml-mingw-w64: create bytecode shared objects that makes C programs using it to segfault

[Giulio Paci]

Package: ocaml-mingw-w64
Version: 4.01.0~20140328-1+b2
Severity: normal

I am trying to produce libraries usable from C with OCaml and to compile them
using CMake, for which I created a module that tries to simplify this process
[1].
As part of the CMake module for building C libraries with OCaml, I have
automated the building of a few combinations of options [2].
Among those combinations, cross-compiling for Windows with currently packaged
x86_64-w64-mingw32-ocamlopt and i686-w64-mingw32-ocamlopt is producing some
unusable binaries [3] [4].
Using opam-cross-windows [5], with the same C compiler, does not pose the same
issue [2].

In order to reproduce the issue you can perform the following steps:

git clone https://github.com/giuliopaci/ocaml-cmake.git
cd ocaml-cmake
mkdir build
cd build
cmake ../examples/hello_world_lib -DCMAKE_VERBOSE_MAKEFILE=on
-DCMAKE_TOOLCHAIN_FILE=../toolchains/Toolchain-mingw32.cmake
make
wine ./main-libhelloworld-bytecode.exe

[1] https://github.com/giuliopaci/ocaml-cmake
[2] https://travis-ci.org/giuliopaci/ocaml-cmake/builds/287518762
[3] https://travis-ci.org/giuliopaci/ocaml-cmake/jobs/287518771#L1580
[4] https://travis-ci.org/giuliopaci/ocaml-cmake/jobs/287518772#L1590
[5] https://github.com/ocaml-cross/opam-cross-windows



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages ocaml-mingw-w64 depends on:
ii  ocaml-mingw-w64-i6864.01.0~20140328-1+b2
ii  ocaml-mingw-w64-x86-64  4.01.0~20140328-1+b2

ocaml-mingw-w64 recommends no packages.

ocaml-mingw-w64 suggests no packages.

-- no debconf information

Bug#854368: gcc-mingw-w64: programs built with --coverage do not create *.gcda files

[Giulio Paci]

I confirm the bug with gcc-mingw-w64-i686 version 6.3.0-18+19.3+b3 as well.

Upstream has recently closed the bug as non-reproducible:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79392

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#873841: opengrm-ngram: Fix mips/mipsel FTBFS by reducing g++ memory usage

[Giulio Paci]

Hi Adrian,
thank you very much for this bug report and for the patch.

Do you think the same approach will work on sh4 as well?

Cheers,
Giulio


On Thu, 31 Aug 2017 17:52:40 +0300 Adrian Bunk  wrote:
> Source: opengrm-ngram
> Version: 1.3.2-2
> Severity: serious
> Tags: patch
> 
> https://buildd.debian.org/status/package.php?p=opengrm-ngram=sid
> 
> ...
> libtool: compile:  g++ -DHAVE_CONFIG_H -I./../include -Wdate-time 
> -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c 
> hist-arc.cc  -fPIC -DPIC -o .libs/hist-arc.o
> ...
> virtual memory exhausted: Cannot allocate memory
> Makefile:481: recipe for target 'hist-arc.lo' failed
> make[4]: *** [hist-arc.lo] Error 1
> 
> 
> Fix:
> 
> --- debian/rules.old  2017-08-30 11:17:38.431222040 +
> +++ debian/rules  2017-08-30 11:19:57.964547509 +
> @@ -1,5 +1,12 @@
>  #!/usr/bin/make -f
>  
> +DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> +
> +# reduce g++ memory usage to fix FTBFS
> +ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
> +export DEB_CXXFLAGS_MAINT_APPEND = --param ggc-min-expand=10
> +endif
> +
>  export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>  export DEB_CFLAGS_MAINT_APPEND = -Wall
>  include /usr/share/dpkg/buildflags.mk
> 
> 
> 
> The mips64el FTBFS is unrelated, this is likely caused by the
> known gcc-7 breakage on mips64el (#871514).
> 
> 

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

Bug#865883: ocaml-mingw-w64: missing link flags while creating custom bytecode binaries

[Giulio Paci]

Package: ocaml-mingw-w64
Version: 4.01.0~20140328-1+b2
Severity: important

Trying to compile a "custome" bytecode executable with x86_64-w64-mingw32-ocamlc
or i686-w64-mingw32-ocamlc fail at link time.

The following commands

cat > main.ml <

Bug#844629: transcriber: sound stops after less than a second

[Giulio Paci]

Hi,
  thank you for your bug report. Unfortunately using transcriber with 
pulseaudio has always lead to issues.
As far as I know, the issues are shared among all the software that use snack 
library.

Can you check if you have similar experience with wavesurfer?

Best,
Giulio


On 17/11/2016 18:28, Frank Doepper wrote:
> Package: transcriber
> Version: 1.5.1.1-10
> Severity: important
> 
> Dear Maintainer,
> 
> trying to use transcriber in stretch I experience that the sound output
> stops after less than a second, although the cursor moves on. Stopping
> (with tab) and restarting starts playing again, which stops then again
> in the same way. Pulseaudio is installed, the transcriber sound source
> does not dissapear.
> 
> I would expect to hear the sound without interruption. I remember it
> worked some time ago (wheezy?), before Pulseaudio.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages transcriber depends on:
> ii  libc6  2.24-5
> ii  libx11-6   2:1.6.3-1
> ii  sox14.4.1-5+b1
> ii  tcl-snack  2.2.10.20090623-dfsg-6
> ii  tcl-tclex  1.2a1-16
> ii  tcl8.5 8.5.19-2
> ii  tk 8.6.0+9
> ii  tk8.5  8.5.19-1
> 
> transcriber recommends no packages.
> 
> transcriber suggests no packages.
> 
> -- no debconf information
> 

Bug#833055: Packaging of mongoclient replacement library: mongocxx

[Giulio Paci]

Hi Apollon,

Il 04/nov/2016 14:13, "Apollon Oikonomopoulos"  ha
scritto:
> First of all, thanks for packaging the MongoDB C++ driver!

You are welcome. :-)

> Now that Debian has moved to MongoDB 2.6+, it would be great if we could
> upload libmongoclient-dev to unstable

What is blocking me from trying to move it to unstable is this discussion
that I had with upstream:

https://jira.mongodb.org/plugins/servlet/mobile#issue/CXX-923

They finally released mongocxx 3.0.x, that they currently recommend for new
development. On the other hand, my use case for this package (Orion context
broker, https://github.com/telefonicaid/fiware-orion), seems to still use
the version I packaged, so I kept the package in experimental.

> (and possibly have
> mongo-cxx-driver-legacy provide mongodb-dev as a metapackage as well),

What is the purpouse of this metapackage?

> as at least one package (uwsgi) could make use of it.

Maybe the new driver could be an alternative for this package?

> Please let me know if you need any assistance; I'm also available to
> sponsor the upload.

Currently I have no time at all (and will likely not have time for the next
few months). So feel free to work on this package as you want/need.
I am open to co-maintainance or even to orphan this package, if you want to
adopt it.

Best,
Giulio

Bug#768030: Different hts_engine versions are not compatible

[Giulio Paci]

Hi,
any news on this?

Would you evaluate to fix this issue (or, better, these issues) if I try to 
help?

Bests,
Giulio

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.

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

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

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

Bug#824138: [ftp.debian.org] override: irstlm/section

[Giulio Paci]

Package: ftp.debian.org
Severity: normal

Hi to all,
  is it possible to move irstlm package from section text to section science?

The section science seems more appropriate for the package and Section field 
has thus be changed accordingly with latest upload.

Thank you,
Giulio





signature.asc
Description: OpenPGP digital signature

Bug#824135: [ftp.debian.org] override: opengrm-ngram/section

[Giulio Paci]

Package: ftp.debian.org
Severity: normal

Hi to all,
  is it possible to move opengrm-ngram package from section text to section 
science?

The section science seems more appropriate for the package and Section field 
has thus be changed accordingly with latest upload.

Thank you,
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#789740: python2.7: import ctypes crashes with error "ffi_prep_cif failed with 2"

[Giulio Paci]

Apparently  this is the same bug as #735681.

I am currently experiencing it with python 2.7.11-1 on sparc64 while trying to 
build sequitur-g2p for experimental distribution
(https://buildd.debian.org/status/fetch.php?pkg=sequitur-g2p=sparc64=0%2Br1668-3=1461506544).

On other architectures compilation seems to correctly work, powerpc included.

Bests,
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

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

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.

Bug#818286: ITP: mongo-cxx-driver-legacy -- MongoDB C++ Driver

[Giulio Paci]

Package: wnpp
Severity: wishlist
Owner: Giulio Paci <giuliop...@gmail.com>

* Package name: mongo-cxx-driver-legacy
  Version : 1.1.0
  Upstream Author : MongoDB community
* URL : https://github.com/mongodb/mongo-cxx-driver/
* License : Apache-2.0
  Programming Lang: C++
  Description : MongoDB C++ Driver

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#815543: [g++] errors in parsing templates

[Giulio Paci]

Hi again,

On 25/02/2016 01:12, Matthias Klose wrote:
> On 22.02.2016 11:15, Matthias Klose wrote:
>> Control: tags -1 + moreinfo
>> Control: reassign -1 g++-5
>>
>> please provide the preprocessed source (from one of these platforms).
>>
>> On 22.02.2016 10:39, Giulio Paci wrote:
>>> Package: g++
>>> Version: 4:5.3.1-8
>>> Severity: important
>>>
>>> --- Please enter the report below this line. ---
>>>
>>> Recently I updated phonetisaurus package and it failed to compile on a few
>>> architectures, where it used to compile (See
>>> https://buildd.debian.org/status/package.php?p=phonetisaurus=experimental).
>>>
>>> On hppa, x32 and sparc64 I obtain the following error:
>>>
>>> "/usr/include/fst/interval-set.h: In member function 'bool
>>> fst::IntervalSet::Contains(const fst::IntervalSet&) const':
>>> /usr/include/fst/interval-set.h:351:54: error: expected ')' before 'it1'
>>>   } else if (it2->begin < it1->begin || it2->end > it1->end) {  // no C"
>>>
>>> that seems a bug in g++.
>>>
>>> According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 it also 
>>> seems
>>> to be a recurrent bug, apparently solved upstream.
> 
> this works for me at least on x32.

You are right... Indeed the issue is with g++ 4:6-20160101-2 and g++-6 
6-20160205-1.

I got confused by the fact that buildd installs both g++-5_5.3.1-8 and 
g++-6_6-20160205-1 (phonetisaurus has been uploaded to experimental), and 
g++-5_5.3.1-8 comes first.
And I have g++ 4:5.3.1-1 on my system (amd64).
I did not notice that during the x32 chroot setup g++ 4:6-20160101-2 was 
installed.

So I confirm the bug, but it affects g++-6_6-20160205-1 and not g++-5_5.3.1-8.
Sorry for the confusion.

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

Bug#815543: [g++] errors in parsing templates

[Giulio Paci]

Package: g++
Version: 4:5.3.1-8
Severity: important

--- Please enter the report below this line. ---

Recently I updated phonetisaurus package and it failed to compile on a few 
architectures, where it used to compile (See
https://buildd.debian.org/status/package.php?p=phonetisaurus=experimental).

On hppa, x32 and sparc64 I obtain the following error:

"/usr/include/fst/interval-set.h: In member function 'bool 
fst::IntervalSet::Contains(const fst::IntervalSet&) const':
/usr/include/fst/interval-set.h:351:54: error: expected ')' before 'it1'
 } else if (it2->begin < it1->begin || it2->end > it1->end) {  // no C"

that seems a bug in g++.

According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 it also seems 
to be a recurrent bug, apparently solved upstream.

Bests,
Giulio

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.3.0-1-amd64

Debian Release: stretch/sid
  500 wheezy  repo.mongodb.org
  500 testing security.debian.org
  500 testing ftp.de.debian.org
  500 stable  toolbelt.heroku.com
  500 experimentalrepository.mivoq.it
1 experimentalftp.de.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

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#813810: ITP: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wnpp
Severity: wishlist
Owner: Giulio Paci <giuliop...@gmail.com>

* 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWtKWEAAoJEM7JlC23rbhvYgIP/3iams7dT6iLZvDi59M4UwSm
FcAc/2c4cPlzZYSa9RElrWLerkD3QhWswDERJdnQdIJL2mdR0l6GAOHAIT4fPnct
7fFNolfB3EpB7Txhks0pc3EagiCQOAsQXOPZMXkwCrDt9SV2aKhgLB3TA7BYPFSn
lY2udP558q6qM8HDYOysiMG4r2xRba7/gOXzSokEr+s+3+2hYvnky1VwJlAFChNg
mHvp3HiCJTmP52+mV7SC94hPW4m33ixP/yFdion+3w7hiNk+uyVWk0KzMiO/+c9Z
o2C0liIxVRwsm6OpAuYHH2kDmB0OW/LPMpbntKnuGaVwhzaDEjjhyKUEZdavbIoo
7yP9he9KyFlFum+xybC1pUndIqi9NxHrkRlPxtx8gBiOIqA7X4VoSyY909tmVcip
Fi23t0x/jq3ujC0f24ZwAsNIFmdHsPp9UXsHttMpn2g/sbtNZV+rueWrJcj9gcqH
5e4zNYNnefvCgg7B6G9cDOQ7ZZEvxZ+/ouLLzrZfxn4+8kUXWsldcuuyyRMtUGyg
+JpmV5Hs1H5ypNq6ABZApn+EH1vhc2DIJ79llpjVj9h19QGtrfUy+7AZzqsnPxML
yWG93efbNbJGrzk3yNvIP6urFfe1Cf7A78+4q13HWeYJOV3p0jwT1LlKAHoGyTv2
h0dLDO1hO7gJkZf4ylK/
=ECE+
-END PGP SIGNATURE-

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

[Giulio Paci]

Package: wnpp
Severity: wishlist
Owner: Giulio Paci <giuliop...@gmail.com>

* 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

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#813093: libirstlm-dev,libopenafs-dev: error when trying to install together

[Giulio Paci]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Andreas,
thank you for the bug report.

On 29/01/2016 15:10, Andreas Beckmann wrote:
> Package: libirstlm-dev,libopenafs-dev
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite

> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
> 
>   usr/include/timer.h
> 
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.

This bug as been already fixed in libirstlm-dev 5.80.03-1, however I think
it would be a good idea to fix it in libopenafs-dev as this file name is
very generic.

Bests,
Giulio.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWq3/AAAoJEM7JlC23rbhvlvgQAJ3j7emT2Cl4jlVYRQQCi8kX
O1KrMOrbXOwbr22YKQws8DNct0+GoTfknbEk99nrkMtdu9EWcMEbhxTsqilzrDtx
ABOpWrNjuKodDn/74v6Fj8Ndsv8XZnguNcfo9Zv9hb4XrT6BaHTefXP10wVkXFIh
hQg/wB9fg4XK6td1Ta9qgzA9AtxHtgytJI4WAkPadUBkMyfTpOHvl+oJYBfA10ZU
aeXe+0HOpWPyv1CjglRFToSYorfJCTQ5rv4JkaExGKyc0fgx8QUcMAn0D3TMN2ho
hYZa7o5ntVORdWP55dAIZiz2hH/gxrn5nS7J9nFRNvXMrydK6bi29JBDoWlaymRi
S7Vw6YG0wgMUgwifCIAcPvhbB7UNODPtSpkR8zlAxwaWTISeQmM/hqIooYwpnP6J
KrwQL05cOZkho75QBwtA6zAj2YU/M1hDjlE5L9Uo4pxiqExq2UWvJfXSEYgDyhOj
d1XyVjbES4XuR2Sip4FuBamK3P5zOuDQ6j20KwB9X1HNoeAbENKOxb9sDOO2BhXF
NQnDKDazCaLU6rrBT5Wvi4q38KTEJrs3gTFishJpA2MdM7lWeNF57Knnsy92VbMN
6nWHzTmiD2pm68EqNHxHqDgtEmxkPlhKWDc4npEvwfgqNRgehrZvB9/0zTxs+31G
5LNO/fm+zdT+9x39s41l
=MS8P
-END PGP SIGNATURE-

Bug#813093: libirstlm-dev,libopenafs-dev: error when trying to install together

[Giulio Paci]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 29/01/2016 19:30, Benjamin Kaduk wrote:
> On Fri, 29 Jan 2016, Giulio Paci wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Hi Andreas,
>>  thank you for the bug report.
>>
>> On 29/01/2016 15:10, Andreas Beckmann wrote:
>>> Package: libirstlm-dev,libopenafs-dev
>>> Severity: serious
>>> User: trei...@debian.org
>>> Usertags: edos-file-overwrite
>>
>>> Here is a list of files that are known to be shared by both packages
>>> (according to the Contents file for sid/amd64, which may be
>>> slightly out of sync):
>>>
>>>   usr/include/timer.h
>>>
>>> This bug is assigned to both packages. If you, the maintainers of
>>> the two packages in question, have agreed on which of the packages will
>>> resolve the problem please reassign the bug to that package. You may
>>> also register in the BTS that the other package is affected by the bug.
>>
>> This bug as been already fixed in libirstlm-dev 5.80.03-1, however I think
>> it would be a good idea to fix it in libopenafs-dev as this file name is
>> very generic.
> 
> Agreed, it is a very generic name (and the green-threads implementation it
> is from is not really something that anything ought to be using, at this
> point).
> 
> (Thank you for preemptively fixing this in libirstlm!)

You are welcome. BTW, the fixed version is libirstlm-dev 5.80.03-2.

Cheers,
Giulio.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWq7BKAAoJEM7JlC23rbhvAGsP/iMGrKY7g2xlMoEZazRhCV8f
mNxtHaR0Sa3njWlcTDGUaF7it4FTBi+ff0OTbXDEZCo3hoPKVVUoV/PwLHIeEAmT
UOCFzVetia/mFDP62ImvoexgXuRweCq4zKbLYINX5WrTxqm/p1Pyau0IFNXc9Abl
tDPVJRe8HwiBgjXS9BpwWqiWJxtgBqX+mNbl3SS+jLPlrWZgnHa9dYOCMPq7G5Cy
rXeeuF47EwLT8zJIcq7ncGkpNI+3rgC7ji7stKWEsbqcrP+PdAaybYgDFTC9ipn8
id6FwyuZFnH6nbg3sRKw61SKcja41+qRmKjp8U7q/gs3LhA0PITpdpZt96hjJeWd
v30/HMFO56kX5KW2DMbNGMhmMK1q4F2xAKeu0Y2+hw3K1uIxBj6JnE/T8W7DGS/g
lvooA38h9kumWEOnrw5J/xeXMblaXvT68Vu6LZJFIwlMsIoC17hyNXlbFesAQVGY
s9Z/JiKyRvbJvjcxRIwWzI1/5FlL7qIK5nq6l5M9c7PktJuYtbhgGIVqi/5jfvSD
B9rTLsH+4STnVOc9Muozd00MWnrHxSUUbAbyzGPsDGUYNMZx6zUJdzltIfGL4wwT
iT2rDH7zJIH1+6mOm3dVlox4cCVUQYVb2dUS67gSPMl6rXD0oVgHbofa4uLRKRDD
Ee2AS1+X9cJVUfHxU+1K
=JdL+
-END PGP SIGNATURE-

Bug#812742: libirstlm-dev and libduo-dev: error when trying to install together

[Giulio Paci]

Il 26/gen/2016 13:24, "Balint Reczey"  ha scritto:
>
> Control: tags -1 confirmed
>
> Hi Ralf,
>
> Thank you for the bug report.
>
> On Tue, 26 Jan 2016 10:06:07 +0100 Ralf Treinen  wrote:
> > Package: libduo-dev,libirstlm-dev
> > Version: libduo-dev/1.9.11-1+b1
> > Version: libirstlm-dev/5.80.03-1
> > Severity: serious
> > User: trei...@debian.org
> > Usertags: edos-file-overwrite
> >
> > Date: 2016-01-26
> > Architecture: amd64
> > Distribution: sid
> >
> > Hi,
> >
> > automatic installation tests of packages that share a file and at the
> > same time do not conflict by their package dependency relationships has
> > detected the following problem:
> >
> ...
>
> > dpkg: error processing archive
/var/cache/apt/archives/libduo-dev_1.9.11-1+b1_amd64.deb (--unpack):
> >  trying to overwrite '/usr/include/util.h', which is also in package
libirstlm-dev 5.80.03-1
> This is indeed a serious bug, the file's name is too generic.
> Maybe it is too generic for being in libduo-dev, too, but this is up to
> its maintainer.
>
> Moving all include files under /usr/include/irstlm/ seems to be the
> appropriate solution.

I agree. I just pushed the required changes to git repository.

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
>

Bug#790551: phonetisaurus: unmet dependencies error with phonetisaurus

[Giulio Paci]

Il 30/06/2015 07:39, ErikP ha scritto:
 I tried installing the packaged, and was told I have an unmet dependency on 
 python.  
 That's odd because I have python already installed..

How are you trying to install phonetisaurus-g2p? Can you please write the 
command sequence here and report relevant errors?

Thank you,
Giulio.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790551: phonetisaurus: unmet dependencies error with phonetisaurus

[Giulio Paci]

Hi again,

Il 01/07/2015 18:03, Erik P ha scritto:
 On Jul 1, 2015 2:08 AM, Giulio Paci giuliop...@gmail.com 
 mailto:giuliop...@gmail.com wrote:
 Il 30/06/2015 07:39, ErikP ha scritto:
  I tried installing the packaged, and was told I have an unmet 
 dependency on python.
  That's odd because I have python already installed..
 
 How are you trying to install phonetisaurus-g2p? Can you please write 
 the command sequence here and report relevant errors?

 No but I'll Google what this is and if it will work with jasper.

It is impossible to provide any help if it is not possible to 
reproduce/understand the issue.

What I was asking for are the steps to reproduce the issue. Did you download 
the package manually or using apt-get? Did you follow the instructions on 
jasper website?
What kind of error did you get?

Please, keep 790...@bugs.debian.org in CC, so that the issue will be updated 
with further information.

Bests,
Giulio.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768030: [htsengine] Different hts_engine versions are not compatible

[Giulio Paci]

Package: htsengine
Version: 1.08-1
Severity: wishlist

--- Please enter the report below this line. ---

Hi,
I noticed that the package htsengine is designed to provide the latest
version of the htsengine.

Unfortunately:
1) neither the hts_engine nor the libHTSEngine API are stable (i.e.:
they changes with every version);
2) there are TTS systems that supports more than one of these versions
(and it would be nice to package one of those systems, sooner or later);
3) I need more than one libHTSEngine API installed in my work pipeline.

Is it possible to have different packages for different htsengine
versions? (I personally need hts_engine 1.05 and later)
Is it possible to have this packages installed simultaneously? I think
this would be a great improvement.

By the way, is the soname of the libhtsengine library updated with every
API change in that library? (i.e.: with every version of the htsengine?)
If not this should be fixed.

Bests,
Giulio.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14-1-amd64

--- Package information. ---
Depends(Version) | Installed
-+-===
libc6 (= 2.3.4) |
libhtsengine1  (= 1.07) |


Package's Recommends field is empty.

Package's Suggests field is empty.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736433: phonetisaurus-calculateER fails to run phonetisaurus-g2p

[Giulio Paci]

Package: phonetisaurus
Version: 0.7.8-2
Severity: normal

phonetisaurus-calculateER fails to run hardcoded ../phonetisaurus-g2p
command.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.2geppetto (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages phonetisaurus depends on:
ii  libc6   2.17-97
ii  libfst0 1.3.2-1
ii  libgcc1 1:4.8.2-12
ii  libstdc++6  4.8.2-12
ii  python  2.7.5-5

phonetisaurus recommends no packages.

Versions of packages phonetisaurus suggests:
pn  flite none
ii  libfst-tools  1.3.3-1
ii  m2m-aligner   1.2-1
ii  mitlm 0.4.1-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734949: debian-maintainers: Please add Giulio Paci as a Debian Maintainer

[Giulio Paci]

Package: debian-maintainers
Severity: normal

Hi,
I will be using the subkey giuliop...@gmail.com for debian-related stuff.

cheers,
Giulio



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.2geppetto (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Comment: Add Giulio Paci giuliop...@gmail.com as a Debian Maintainer
Date: Sat, 11 Jan 2014 02:40:42 +0100
Action: import
Recommended-By: 
  Jakub Wilk jw...@debian.org
Agreement: 
  http://lists.debian.org/debian-newmaint/2014/01/msg00019.html
Advocates: 
  http://lists.debian.org/debian-newmaint/2014/01/msg00022.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.15 (GNU/Linux)
  
  mQINBE8P6asBEAC7PZQ1SjSnQnnCBhcFKbwFB42abgVj/pQRgIKNSE7P2Lth23Tj
  jctwBuO6TEbjr79JZ9tF2XWVKiGnD9d4jUvagp7AWLV5uCWFKpNtDyzpiXmgZTPa
  rFPWugOwmfocgFvLvJGAydp9O0O4YP+V8RLKrrz1y6VYVFOENw6078eiFt7rGR3t
  hcvA+gFrdO9kvN8y30yEb6o+Aa8ohl6CQZtLtXE4fk89VbHpt1FNX/tRJm4dMTwS
  l417t0sFWUYMp2dFpANprcXsu0iFWqgohKd+mSyLmgcAbYgKV0gY+A18vwtbTWw3
  2dNy8NGuGTQ/EYbc18Fie7Yk7zfyh710HHEZIBU76VeVF48G1O/p8gR60hZvTkHU
  g0pqogJe6harGv6QbtTI/PZLwzdrc4RD7mdgRwG/vREYrwjyfrYGC9jusX+zulD9
  ns1vexWwVa0kbtlk7VviDYZGzhcyGBRO3HtMFjDVpnu8q5fqbIasyZZqoUmS3WQG
  IESm7/LNBhq4QN1jizfzFsKaiMrdY29oUQarkPze44KT7syt77WceIJtSuTp7xlr
  wXhnw9Tb2BwsjOIGCO54rXHKrjXp2ObaHeaIO+83aPA3lYJdaFUWHm1hr0M0DKwp
  zUV7TPFDOfduuQ7rGBVjKnL6K34AuNQmecVId5jO4M58N4u0UoGISgyYOwARAQAB
  tCJHaXVsaW8gUGFjaSA8Z2l1bGlvLnBhY2lAbWl2b3EuaXQ+iQI9BBMBCgAnBQJS
  hCfVAhsDBQkJZgGABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEM7JlC23rbhv
  3DEP+gKFe9MkP5Gj2Rp8JOXn5b/eX2mTWkRaB9Hp+8RzccdZTU5chHYhIQvSrlp5
  DWxG+ij6sAT9GXZp3p8H1oYT3nmq3H9HgvS/RbFQyo8W5kmpBkMkSK2Ybt5BAceC
  A5an/iBlu4XMBypyQO65GvVTWwfyXnI+CAIQv+sr4XdRN5QhXFXXoWHd9N4n9yFJ
  sGeFn7PkPxS4Bt3gTdkJXfvAw06kqbPX7Qdvo0BQo9YHPylLgAdg/xXMF6nWGs27
  04fwmBA03K8yKCiZFmCupqgpkNcvwljhIJ6oYR8DJZwCcDxOKE/p2GnhiryN2P7C
  w7Bi6mr5Nt3XYcJ08ajrBE5n38+bcCEzvmWY2o65kLz7Z0yl2jL6HsJWPsmVh5ZO
  Klt2wqA/5ZA0au7bgPSLc99SV8ozknYPMFRnOY150xuichMzVvm4Al1UufWWv22V
  PhzNgwKdrrntvrDZZE6zMM2LNYqX1ByUPBL10T/0F3Dy9NBq1UbXXiVXPAophm2y
  AzZ74g3k4WADqNcpikLsOy0Fg3sHM1Oo9Q06RQdinRdzI/xACAddtgNmRLiEBF4y
  tWU8p0FtV4X4gPkv2GfFcB42NomZMHM/gishGq+emKqFRnsjYHeNf/yugiwfnAPb
  GHlCf3norFIR1YtGSLhWJgVJEVXAsnh7OkC03uawL0X/pXeTiQI9BBMBCgAnBQJS
  hCfPAhsDBQkJZgGABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEM7JlC23rbhv
  /8EP/iQEgvutpXI0fodfrm6wgATq0xfIHVbrWaZQCcRsLaelZ2jx6Gbd7Apv4sMk
  kwVv5TzisfBmGD9HRB83uQlkvYoOnldPoLvqE94+xSnueKVUpSts7RMTCA3cs1v5
  ModWVwTOz4zQG0/II/cdDErmDdVvnd13SFMr9b4u5S2Q9h+JoD5n4+Y0K/Sml8NU
  GE3CiFrsO7vaU+YN6UxDF5meOXZL0OxmThDb9VfF93VF0gCEUhI+HyUMk5+GiHux
  0MjWlyMb8GMFXFw3RAW/fJbIptjkbU7LR+vVw+K3GyN72xvVOmZaFZ0yt+Zv6eBV
  Wz/L8VA6wMf2lDCmmcwl5AR+E02mfiqO6L55YF9EMslM4R2zG/m0xf2TQcqYrBd3
  8Yqz+xtdId0s04F05bUzORRyUg0nzew0MA4YH0N/R9zd15mB4ny5aNrEU9tNpspV
  LBflpzDQBuo+asABRrUPkC6oSFmEwhHljKpDCmgWjAsUOBfhCDpS3mBNMGFCOj4r
  eoIG65Cn6ZRwD3WoA4oJebjor0KJTuZjenPelR7oCqKaCL8GlU0KJbtBjXQ6s0V/
  lktVcdG3ttzv0PzuSRx6ROrTjmpqHdgqzC7kxnqiWG78hZXEb3xPhi39KvFSbjn+
  X76jPxVVBHJjgEEpVn3pTocY6PY4vBi4o4XdOrvYmq+NfwRoiQIcBBABAgAGBQJS
  hKJxAAoJEDBVD3hx7wuoSVcQAIxuP0u5HcAjYHuHwB0Pnc5ORQQBxF5k3wthMvjl
  qeO2P/3Kgifgvog1gTZsBAA+XI9RBbm+8YJjBEkCR/clgflo4On1HhUjoHGj1OJX
  2Nf6ku+GcjXuHCBY1pwEYwudRZs7hvR9X6FhbUFc4ujau33iD2hNZIDzf+cATGDI
  NAFc5qzOYOS2t/hvhjLhsT5IhnxZm9kL9eFupKxFUG4iHDN2WezvvUmacc+xq8WD
  pG4kIe38Zbs9SEBZ5uDfHo+BcyBrxa4ybV8h49aNwsPmTZxxbjc+op6GV9u7wXHm
  5owTqm/GtJiPSTxhjG3EBkomRkZT5VW46Xf00I6GuzNy7wlhuNKux19B8focvS+J
  Tf6vADaJO+CgYAFAXsmt+V3HPmD0ux1B5ugJhzY8ZUx3I0aKEk25L5nYiQ5qj5m1
  +D65Gu+9Xi7cGdeX9azXjk682TU+6tw1ZsvwGkPpUUhey8UuMU65p6w1mxVhYFoY
  lJhK0KJXZc0xOCA4nAY3CfyEztL2bTHr7U161bS2smKRWoUAkEe3JfeAmlBZyGxe
  EgzvqrnjN+TA76Plmfbsg1ctbzzK+JQcHI0GFaEPYPbare4GhEh2ma5qG1NokNyS
  iDrAfVsL6x64mkhAAn74mPsBtoBEJBTxN4VGcprB/lvhHN0cw9IiwawIUAF0wecD
  iwKdiQIcBBABCAAGBQJShR9lAAoJEHRcR2bUys3/njYP/36uHUsRzENDa3BqYOtz
  C4AntStqZHcUOKFBdT3Mruhn4EI4dR8p8Bl2t7LH1y5VGnAJSOoPZz5LZ4o9Mzof
  ZAxnYkThCQuNGtev1Quvai85+A1x+aH0D+ueyCqsVcMxXlS06zUO9Uu/EO8JLHkS
  hvnk0vW3QWMn5f2XOtbpurvYAxpiVj4OpgB2EQm49L1QcBEYQ1z7DwJFkyGraU4h
  a3bBA2GdlrLzJfMEuPjPkUSXfOz4CerJnGqAjzqo3TG3ZEwNepk2DVDxqJDxBpxb
  EqYn2FK9DfPenjzTPHF8udzTobDsSQS230PaKFtKEnZx/8LhnjjGYEP49UPHrwtV
  qdwSTyvm4zpUiCdOe1CPprO/IYppHnc1P5Yx0JNkXOmlFU5Qtfg/qFvZ+DZiER/F
  B0DfuZkmj74HCmnTTa6SOwsIGqw7U46vIuNiDRs91U5u0LnsRuMiKA+WfU5E/c0o
  jyodq34p8ZkiJ65Sl8XkeXzlFG8UMuT/O2bRosN9xafVxo6E96SnGZbUTreNXQwm
  c008Qaq0ppPIrNaN4CFyOhPCoGk/QGVfnlsSASUW7D9y/JvYJ7MZ50mdg868FDVi
  UzSYQgxtQ5Bpb1FMwbAtIE/yRt6T9WBsPY6k13T40+4ALrWkEvXOxn6XUnb4rPaa
  QuIpy2b3HBHWR/MaKGQydv/iiQIcBBABAgAGBQJShKtRAAoJENpJWPYR4UnpHIAP
  /RvmU2g+j9YTTCFFxQ+M178tNmIiz3fLmUk/TiF97KGXmgIEiWF8r99t/G2+e6gP
  rhvaD70B8ZGTi8CTz3dclSjxyx/ggi8mUgdLzKgQFWcHltcprb2ahTpRtyysJS3o

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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#702882: f2c is simply not added to the linker flags

[Giulio Paci]

Il 19/dic/2013 09:34 Andreas Tille andr...@an3as.eu ha scritto:

 Hi,

 On Mon, Dec 09, 2013 at 06:16:41PM +0100, Gert Wollny wrote:
  here the configure script claims that f2c is added anyway:
 
 [AC_MSG_RESULT(not found, trying to use -lf2c anyway.)]
 
  but then it does this (and the patch doesn't touch that line):
 
 LDFLAGS=${LDFLAGS}
 
  which should read (just like the in the BLAS test below)
 
LDFLAGS=${LDFLAGS} -lf2c

Not needed to do explicitly because the patch fixes the test for libf2c.

 I tested the proposed ugly_fix.patch which leads to the following
 build log snippets:

 ...
 checking for gmp.h... yes
 checking for f77_alloc_ in -lf2c... no
 checking for f77_alloc in -lf2c... no
 checking for F77_ALLOC_ in -lf2c... no
 checking for F77_ALLOC in -lf2c... no
 checking for f_open in -lf2c... yes
 checking for daxpy_ in -lblas... yes
 checking for dlarnv_ in -llapack... yes
 ...
 ...
   Use internal F2C   -- no
 ...
 ...
 /bin/bash ../libtool --tag=CC   --mode=link gcc  -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-I/usr/include/libxml2  -Wl,-z,relro -lgmp -lblas -llapack -larpack -lglpk
- o libplfit.la  error.lo gss.lo kolmogorov.lo lbfgs.lo options.lo plfit.lo
zeta.lo  -larpack -llapack -lblas -lf2c
 ...
 ...
 dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libigraph0/usr/lib/x86_64-linux-gnu/libigraph.so.0.0.0 was not
linked against libf2c.so.2 (it uses none of the library's symbols)
 ...

This is probably true. There is no FORTRAN code in libigraph. Why linking
to f2c?
I did not investigate the problem further in March, and I still am not able
to allocate enough time to help on this issue now.

Bests,
Giulio.

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728833: transcriber: waveform is not correctly displayed

[Giulio Paci]

On 06/11/2013 03:50, Giulio Paci wrote:
 transcriber 1.5.1.1-8 is not able to display the signal waveform anymore (only
 a few samples are displayed).
 The audio file is played normally and wavesurfer is not affected by this 
 issue,
 so it is probably a rendering issue and not an I/O issue.
 The problem is probably related with the recent upgrade of the required tcl/tk
 version.

After investigation, apparently the issue is in using
TK_CONFIG_OPTION_SPECIFIED while it is not supported anymore with Tcl/Tk
8.5.

I am investigating how to fix src/wavfm.c and src/segmt.c accordingly,
but I currently have no idea about it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728833: transcriber: waveform is not correctly displayed

[Giulio Paci]

Package: transcriber
Version: 1.5.1.1-8
Severity: important

transcriber 1.5.1.1-8 is not able to display the signal waveform anymore (only
a few samples are displayed).
The audio file is played normally and wavesurfer is not affected by this issue,
so it is probably a rendering issue and not an I/O issue.
The problem is probably related with the recent upgrade of the required tcl/tk
version.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.2geppetto (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages transcriber depends on:
ii  libc6   2.17-93
ii  libfontconfig1  2.10.2-2
ii  libx11-62:1.6.1-1
ii  libxext62:1.3.2-1
ii  libxft2 2.3.1-1
ii  libxss1 1:1.2.2-1
ii  sox 14.4.1-3
ii  tcl-snack   2.2.10.20090623-dfsg-4
ii  tcl-tclex   1.2a1-16
ii  tcl8.5  8.5.14-2
ii  tk  8.5.0-2.1
ii  tk8.5   8.5.14-2

transcriber recommends no packages.

transcriber suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org