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#816192: RFS: python-proselint/0.3.5-1 [ITP] -- A prose linter

[Jakub Wilk]

* Paul Wise , 2016-03-06, 16:59:
I can't find a copy of the BSD license grant in the upstream tarball at 
all, only in PKG-INFO and setup.py. I'm not sure this is good enough 
for ftp-master approval.


I'm pretty sure it isn't. Their reject FAQ[0] says:
If the upstream tarball does not include a copy of the license, 
debian/copyright must document when and how the license information was 
obtained (i.e. include "Downloaded by John Doe on 2008-12-24 from 
http://example.net/license; or reproduce email correspondence including 
some header) in addition to reproducing the license itself. In the past 
there were uploads where one couldn't find the license statement in the 
tarball or on the website from upstream, which is bad. 



[0] https://ftp-master.debian.org/REJECT-FAQ.html

--
Jakub Wilk

Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver

[Jose M Calhariz]

On 29/02/16 23:09, Mattia Rizzolo wrote:
> sorry, this took awfully long.
>
> On Fri, Feb 05, 2016 at 11:09:20PM +, Jose M Calhariz wrote:
>> Amanda have release a new upstream version.  My main sponsor is too
>> busy for helping me.  So I am searching for someone that can help
>> sponsor the new release.
> Ok, I can do it.
> Should I use the git repository?
Yes please.

> Just looking through cgit, I can ask you the following things:
>
> * https in Vcs-Git please

Done

> * standards-version to 3.9.7
Done

> * version restriction on tar can go away, and tar being essential:yes
>   the whole dep can go away
Done
> * are you sure the perl dep is needed?  ${perl:Depends} ought to do it
Done
> * guessing you are using git-buildpackage, why didn't you just
>   `gbp import-dsc` to import the NMU?

My changes are older than the NMU.  So I did not tried to import the NMU.

> * please push the tag for the upstream part
Done
> * you have a build-dep on debhelper version >= 9, but you use compat 5.
>   please bump the compat, after checking the differences in debhelper(7)
Done
> * the *.dirs files don't need to list directories for files installed by
>   other dh_* things, so I'm confident at least line 3,4,5 of
>   amanda-server.dirs are useless, haven't looked at the others

The debian/rules relies on cp and install to copy the files into the
directories listed in *.dirs
I don't like, I would prefer the format:
 mkdir $dir && cp $file $dir

What you recomend?

> * I'm not happy with the old style rules file, but guess I can't ask
>   that much in this case, and I can live well with it anyway :)

Thank you.  This package is being tested on my backup server for some
weeks.  I don't want
to make changes that may invalidate my tests.  The version 3.3.9 is all
ready available and I
can change the rules style for amanda 3.3.9.

>
> ↑ that's the kind of things I want to see changed for me to sponsor it.
> If you confirm I should look at the git repository and you're ok with me
> as a sponsor please confirm so (and fix the already reported problems,
> please ;))
>

This is for today.

Tomorrow I will look into "lintian -I --pedantic"

KInd regards
Jose M Calhariz




signature.asc
Description: OpenPGP digital signature

Bug#817074: RFS: guake/0.8.4-1

[Daniel Echeverry]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: guake
 * Version : 0.8.4-1
 * Upstream Author : Gaetan Semet 
 * URL :  http.//guake-project.org
 * License : GPL-2.0+
   Section : x11

  It builds those binary packages:

guake - Drop-down terminal for GNOME Desktop Environment

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

  http://mentors.debian.net/package/guake

  Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/g/guake/guake_0.8.4-1.dsc

  More information about hello can be obtained from http://www.guake-project.org

  Changes since the last upload:

  * New upstream release.
  * debian/control
+ Change homepage field. Closes: #812433
+ Bump Standards-Version 3.9.7 (no changes)
+ Use HTTPS in vcs-browser field
+ Use wrap-and-sort
  * debian/copyright
+ Change source field
+ Extend copyright holder years


 Regards,
 Daniel Echeverry

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#791463: Quick review

[Pali Rohár]

On Monday 07 March 2016 14:31:44 Andrew Shadura wrote:
> On 6 March 2016 at 21:16, Pali Rohár  wrote:
> >> > But should not be cleandir part of that --buildsystem=bmake? Or
> >> > why not?
> >> 
> >> You're actually very right in this, I'm going to implement that
> >> right now.
> > 
> > Now I tested bmake version 20160220-2 and looks like it is
> > working... Should I upload new version to mentors?
> 
> Please do.

Done. I uploaded last upstream version.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

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

[Giulio Paci]

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

Added a note about it.

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

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

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

> Do the leading numbers in patch names mean something?

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

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

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

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

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

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

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

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

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

I added zlib1g-dev dependency.

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

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

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

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

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

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

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

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

Dropped the -dbg package.

Bests,
Giulio

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

Bug#816065: marked as done (RFS: seq-el/1.11-1 [ITP] -- sequence manipulation functions for Emacs Lisp)

[Debian Bug Tracking System]

Your message dated Mon, 07 Mar 2016 16:34:49 +
with message-id 
and subject line closing RFS: seq-el/1.11-1 [ITP] -- sequence manipulation 
functions for Emacs Lisp
has caused the Debian Bug report #816065,
regarding RFS: seq-el/1.11-1 [ITP] -- sequence manipulation functions for Emacs 
Lisp
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
816065: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816065
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package seq-el.

This library provides sequence-manipulation functions that complement
basic functions provided by subr.el (which comes with Emacs).  It is a
useful library that a wide variety of Emacs Lisp addons depend on.

I am packaging seq-el as a dependency of flycheck, another ITP of mine.

* Package name: seq-el
  Version : 1.11-1
  Upstream Author : Nicolas Petton 
* URL : https://elpa.gnu.org/packages/seq.html
* License : GPL-3+
  Section : lisp

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/s/seq-el/seq-el_1.11-1.dsc

Or build it with gbp:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/pkg-emacsen/pkg/seq-el.git
cd seq-el
gbp buildpackage

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Package seq-el version 1.11-1 is in NEW now,
and the package at mentors is not newer (2016-03-06) than the package in NEW 
(2016-03-06),
so there is currently no package to sponsor.

https://ftp-master.debian.org/new/seq-el_1.11-1.html
https://mentors.debian.net/package/seq-el

Please remove the package from mentors or mark it "needs sponsor = no".
If for some reason you need to replace the package in NEW,
then you can upload an updated package to mentors
and feel free to reopen this RFS 816065 or open a new RFS.--- End Message ---

Bug#791463: Quick review

[Andrew Shadura]

On 6 March 2016 at 21:16, Pali Rohár  wrote:
>> > But should not be cleandir part of that --buildsystem=bmake? Or why
>> > not?
>>
>> You're actually very right in this, I'm going to implement that right
>> now.
>
> Now I tested bmake version 20160220-2 and looks like it is working...
> Should I upload new version to mentors?

Please do.

-- 
Cheers,
  Andrew

Bug#816611: RFS: yamllint/1.0.3-1 [ITP] -- A linter for YAML files

[Paul Wise]

On Mon, 2016-03-07 at 12:16 +0100, Adrien Vergé wrote:

> Good idea. I did this in my local package, should I upload it on
> mentors again? Or wait for the package to be published to unstable?
> (Sorry, first package on Debian.)

I would suggest that you make this and other upstream changes in the
upstream git repository and upload a new version to mentors when you
make a new release.

On that note, please file new RFS bugs for future uploads.


> Actually the branch on GitHub is temporary. I thought
> git://anonscm.debian.org/collab-maint/yamllint.git was going to be
> created once the package is uploaded, isn't it the case? If not,
> should I remove the Vcs-* tags?

collab-maint repos are only manually created, perhaps you were thinking
of dgit, but that is also manual creation.

https://wiki.debian.org/Teams/CollabMaint
https://browse.dgit.debian.org/

I suggest keeping the Vcs-* fields but pointing them at the place where
you intend to maintain the packaging, so either github or collab-maint.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#816611: RFS: yamllint/1.0.3-1 [ITP] -- A linter for YAML files

[Adrien Vergé]

2016-03-05 3:28 GMT+01:00 Paul Wise :
> There was one issue to fix, I've taken the liberty of doing that myself.

Thanks.

> Add a manual page, you can do that automatically using either sphinx
> and sphinxcontrib-autoprogram or python3-sphinx-argparse.

Good idea. I did this in my local package, should I upload it on
mentors again? Or wait for the package to be published to unstable?
(Sorry, first package on Debian.)

> The URLs in the Vcs-* fields are 404 (see duck output below), probably
> you need to point them at the right branch in the github repo.
>
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields
> https://github.com/adrienverge/yamllint/tree/packaging/

Actually the branch on GitHub is temporary. I thought
git://anonscm.debian.org/collab-maint/yamllint.git was going to be
created once the package is uploaded, isn't it the case? If not,
should I remove the Vcs-* tags?

Thanks again for your help.