Bug#815799: RFS: kateperlcheck/1.7-1 [put in ITP ]

[Dmitry Bogatov]

I am no DD, so I would not be able to sponsor. But here is review:

> Dear mentors,
>
>   I am looking for a sponsor for my package "kateperlcheck"
>
>  * Package name: kateperlcheck
>Version : 1.7-1
>Upstream Author : dirk Lindner  
>  * URL : http://kate.lindnerei.de/
>  * License : gpl
>Section : editors

d/control:

> Section: kde
Maybe devel?

> Build-Depends: debhelper (>= 8.0.0), cmake
debhelper (>= 9), please

> Standards-Version: 3.9.4
3.9.7, please

> #Vcs-Git: git://git.debian.org/collab-maint/kateperlcheck.git
> #Vcs-Browser: 
http://git.debian.org/?p=collab-maint/kateperlcheck.git;a=summary
Why commented out?

> Package: kateperlcheck
> Architecture: i386
Architecture 'any', please

Did you used sbuild or pbuilder? Seems dependencies are incomplete, since
configuration fails on my box, complaining about missing `FindKDE4.cmake`.

> E source-is-missing
> kateperlcheck/CMakeFiles/2.8.12.2/CMakeDetermineCompilerABI_C.bin
> kateperlcheck/CMakeFiles/2.8.12.2/CMakeDetermineCompilerABI_CXX.bin
> kateperlcheck/CMakeFiles/2.8.12.2/CompilerIdC/a.out
> kateperlcheck/CMakeFiles/2.8.12.2/CompilerIdCXX/a.out

CMakeFiles are binary files, and lintian rightfully asks where is
their source.  Correct approach is to NOT have them in tarball in
first place, they are generated by `cmake'. Since you are upstream,
you can easily fix it, otherwise you would be interested in
Files-Excluded.

I do not use KDE, so I can't check the usefulness of your package.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#816004: RFS: [ITP] python-nameparser/0.3.11-1

[Dmitry Bogatov]

[2016-02-26 15:34] Edward Betts 
>
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-nameparser"
> 
>  * Package name: python-nameparser
>Version : 0.3.11
>Upstream Author : Derek Gulbranson 
>  * URL : https://github.com/derek73/python-nameparser
>  * License : LGPL-2.1+
>Section : python

[I am no DD]

In Description: of python3-nameparser last line:

   This package contains fuzzywuzzy for Python3.
 ^^
   What is that?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

[RFS] eoconv -- convert text files between various Esperanto encodings

[Dmitry Bogatov]

Package: sponsorship-request
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "eoconv". I already filed RFS
several weeks ago, this is just bump (not sure, if it is good practice)

* Package name: eoconv
  Version : 1.4-1
  Upstream Author : Tristan Miller 
* Url : http://en.nothingisreal.com/wiki/Eoconv
* Licenses: GPL-3+
  Section : text

convert text files between various Esperanto encodings
 Esperanto is written in an alphabet of 28 letters. However,
 only 22 of these letters can be found in the standard ASCII
 character set. The remaining six -- `c', `g', `h', `j', and
 `s' with circumflex, and `u' with breve -- are not available
 in ASCII. Various encoding systems have been developed to
 represent Esperanto text in printed and typed text.  eoconv
 program converts between them.

It builds those binary packages:

eoconv -- convert text files between various Esperanto encodings

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

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

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

http://mentors.debian.net/debian/pool/main/e/eoconv/eoconv_1.4-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/eoconv.git

More information about eoconv can be obtained from 
http://en.nothingisreal.com/wiki/Eoconv

Changes since last upload:

  * Initial release (Closes: #809817)

Regards,
  Dmitry Bogatov

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

RFS: fgetty/0.7-0.1 [NMU] -- very small, efficient, console-only getty

[Dmitry Bogatov]

Package: sponsorship-request
Severity: normal

Dear mentors,

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

* Package name: fgetty
  Version : 0.7-0.1
  Upstream Author : Felix von Leitner 
* Url : https://www.fefe.de/fgetty
* Licenses: GPL-2+
  Section : admin

It builds those binary packages:

fgetty -- very small, efficient, console-only getty and login

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

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

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

http://mentors.debian.net/debian/pool/main/f/fgetty/fgetty_0.7-0.1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/fgetty.git

More information about fgetty can be obtained from https://www.fefe.de/fgetty

Changes since last upload:

  * Non-maintainer upload.
  * New upstream release
  * Add watch file with GPG key verification
  * Add source/format to follow v3.0 source package format
  * Use debhelper instead of custom debian/rules
  * Drop checkpassword-pam. Upstream does not support it, and once written,
but is not maintained anymore. Averaged desktop setup should not
need anyway.
  * Remove outdated README.Debian
  * Reformat debian/copyright to follow DEP-5
  * Link checkpassword with gnu libc (Closes: #563335) with hardening
  * Add lintian overrides about static build and lack of dependencies
  * Write manpage for login1 and login2
  * New standards version -- 3.9.7 (No changes needed)

Regards,
  Dmitry Bogatov

Re: Bug#816363: RFS: fgetty/0.7-0.1 [NMU] -- very small, efficient, console-only getty

[Dmitry Bogatov]

[2016-03-01 13:28] Mattia Rizzolo 
> please DON'T CC debian-mentors (or anybody, for what metters) while
> filing bugs to sub...@bugs.debian.org.  The CCed people will receive an
> email from you without the bug number, and will be unable to follow-up
> correctly.  In this particular case you also risked a double email,
> since debian-mentors receive bugs against sponsorship-request.
> And you mistyped the pseudo-package name, missing the trailing s.

Sorry about it.

> On Tue, Mar 01, 2016 at 02:51:51AM -0500, Dmitry Bogatov wrote:
> > Changes since last upload:
> >=20
> >   * Non-maintainer upload.
> >   * New upstream release
> >   * Add watch file with GPG key verification
> >   * Add source/format to follow v3.0 source package format
> >   * Use debhelper instead of custom debian/rules
> >   * Drop checkpassword-pam. Upstream does not support it, and once writte=
> n,
> > but is not maintained anymore. Averaged desktop setup should not
> > need anyway.
> >   * Remove outdated README.Debian
> >   * Reformat debian/copyright to follow DEP-5
> >   * Link checkpassword with gnu libc (Closes: #563335) with hardening
> >   * Add lintian overrides about static build and lack of dependencies
> >   * Write manpage for login1 and login2
> >   * New standards version -- 3.9.7 (No changes needed)
> 
> This is way way way too much for a NMU.
> A NMU should fix bugs and be minimal; see
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu

So it would be okay to have NMU with several lintian errors and heap of
warnings?

> Though that package is actually unmaintained, and don't see an upload
> since 9+ years.
> Considering that pape is MIA but tends to (slowly) reply to mails [0],
> please try to contact him (better as a follow-up of this RFS) and see
> what he has to say.

Before starting to work I tried to contact him. No reply since 8th
Feb. Would it be polite to take maintainership?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#816433: RFS: complexity/1.5+dfsg-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: complexity
  Version : 1.5+dfsg-1
  Upstream Author : Bruce Korb 
* Url : https://gnu.org/software/complexity
* Licenses: GFLD-1.2+, GPL-3+
  Section : devel

It builds those binary packages:

complexity -- tool for analyzing the complexity of C program functions
complexity-doc -- tool for analyzing the complexity of C program 
(documentation)

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

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

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


http://mentors.debian.net/debian/pool/main/c/complexity/complexity_1.5+dfsg-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/complexity.git

More information about complexity can be obtained from 
https://gnu.org/software/complexity

Changes since last upload:

  * New upstream release, which fix issues with non-Unix line endings
(Closes: #816244)
  * Standards version bump -- 3.9.7 (No changes needed)

Regards,
  Dmitry Bogatov

Packaging fork

[Dmitry Bogatov]

Hello!

I am interested in packaging [mmh](

Bug#817118: RFS: complexity/1.5+dfsg-1~bpo8+1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: complexity
  Version : 1.5+dfsg-1~bpo8+1
  Upstream Author : Bruce Korb 
* Url : https://gnu.org/software/complexity
* Licenses: GFLD-1.2+, GPL-3+
  Section : devel

It builds those binary packages:

complexity -- tool for analyzing the complexity of C program functions
complexity-doc -- tool for analyzing the complexity of C program 
(documentation)

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

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

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


http://mentors.debian.net/debian/pool/main/c/complexity/complexity_1.5+dfsg-1~bpo8+1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/complexity.git

More information about complexity can be obtained from 
https://gnu.org/software/complexity

Changes since last upload:

  * Rebuild for jessie-backports.

Regards,
  Dmitry Bogatov

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Dmitry Bogatov]

[2016-03-06 19:48] Nikos Tsipinakis 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "newsbeuter"
> 
> * Package name: newsbeuter
>   Version : 2.9-1
>   Upstream Author : Andreas Krennmair 
> * URL : https://github.com/akrennmair/newsbeuter
> * License : MIT
>   Section : net
>
> It builds those binary packages:
>
>newsbeuter - text mode rss feed reader with podcast support
>newsbeuter-dbg - debugging symbols for newsbeuter

[NO DD, can't sponsor]

There is nice tool `check-all-the-things'. It reveals

 * loads of spelling errors in po/
 * wrong formatting of your email (email is formatted this way: Name 
,
   your formatting in patches/podbeuter-segfault-fix misses <> symbols)
 * installation instruction (README) should not find way into binary package

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#817213: RFS: fgetty/0.7-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: fgetty
  Version : 0.7-1
  Upstream Author : Felix von Leitner 
* Url : https://www.fefe.de/fgetty
* Licenses: GPL-2+
  Section : admin

I take maintainership with acknowlegement of previous maintainer
(Gerrit Pape).

It builds those binary packages:

fgetty -- very small, efficient, console-only getty and login

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

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

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

http://mentors.debian.net/debian/pool/main/f/fgetty/fgetty_0.7-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/fgetty.git

More information about fgetty can be obtained from https://www.fefe.de/fgetty

Changes since last upload:

  * New maintainer
  * New upstream release
  * Add watch file with GPG key verification
  * Add source/format to follow v3.0 source package format
  * Use debhelper instead of custom debian/rules
  * Drop checkpassword-pam. Upstream does not support it, and once written,
but is not maintained anymore. Averaged desktop setup should not
need anyway.
  * Remove outdated README.Debian
  * Reformat debian/copyright to follow DEP-5
  * Link checkpassword with gnu libc (Closes: #563335) with hardening
  * Add lintian overrides about static build and lack of dependencies
  * Write manpage for login1 and login2
  * New standards version -- 3.9.7 (No changes needed)

Regards,
  Dmitry Bogatov

Bug#816363: RFS: fgetty/0.7-0.1 [NMU] -- very small, efficient, console-only getty

[Dmitry Bogatov]

> 1) I see you dropped patches, but they aren't applied upstream.
> fgetty-login.diff
> ro-dev.diff

I knew what I did, but feel free to disagree with my reasoning.

fgetty-login.diff essentially just renames /bin/login1 to /bin/fgetty-login.
I find it confusing, when binaries are renamed. Either way, /bin/login{1,2}
are never invoked directly, so I considered installing them into /lib/fgetty.
It would eliminate need in manpage, which is barely useful. WDYT?

ro-dev.diff demotes chown/chmod error, if it is caused by read-only
/dev. I do not understand why anyone would want it, /dev is rw by
default Debian installation. Yes, just tried, `getty' from util-linux
issues warning, not error in case of ro /dev, but can anyone explain me
why it is good thing?

> please explain, and comment on changelog.
>
> (the cvs diff I suspect is fully applied, right?)

Right.

> 2) +export DEB_BUILD_OPTIONS =3D noautodbgsym
> why?

3 of 4 binaries are statically linked with no debug information.  So
the only debug symbols for checkpassword(1). Since `$(wc -l
checkpassword.c) = 93` I see little use of debug package.

> as a general note, please try to be more verbose in your work (changelog,=
>  comments in rules file), to save time to your sponsor, and to make the c=
> ommunity aware of your intentions.
> I can't understand if your changes above are something you did by mistake=
> , or intentionally, in any case, some more verbosity doesn't hurt too muc=
> h :)

Sure. Will do better next time.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#816363: RFS: fgetty/0.7-0.1 [NMU] -- very small, efficient, console-only getty

[Dmitry Bogatov]

Uploaded new version on mentors.

> >I knew what I did, but feel free to disagree with my reasoning.
> >
> >fgetty-login.diff essentially just renames /bin/login1 to /bin/fgetty-login.
>  >are never invoked directly, so I considered installing them into /lib/fgetty.
> >It would eliminate need in manpage, which is barely useful. WDYT?

Installed `login1' and `login2' into /lib/fgetty/. Looks nice to
me. Dropped manpage.

> > Yes, just tried, `getty' from util-linux
> >issues warning, not error in case of ro /dev, but can anyone explain me
> >why it is good thing?

> it might not be the same on Debian derivatives, on chroots, on
> minimal installations, on raspbian and so on.  in my opinion this
> one is still needed (and should be upstreamed).
>
> I never had to mount /dev in ro, but I tried in a chroot and it seems 
> possible.
>
> Some particular installations might have this, for security or whatever else.
>
> How do you feel about reverting?

I am not fond of maintaining code for some strage setup, not
supported by upstream. I tried to search web, and I found no information
about read-only /dev. Read-only /, /etc/, /usr -- sure, but not /dev.

Adding Pape in CC, he should be able clarify issue. I will revert, if
someone bug an report about his read-only /dev.

> >3 of 4 binaries are statically linked with no debug information.  So
> >the only debug symbols for checkpassword(1). Since `$(wc -l
> >checkpassword.c) = 93` I see little use of debug package.
> ok, but shouldn't the new system provide "empty" debug packages then, or
> maybe even better, understand and don't provide them?

Probably. But it is question to debhelper team. I can't remove "empty"
debug ELF's manually, since their name are some hashes.

> >Sure. Will do better next time.

I documented my position on ro-dev.diff and debug packages in changelog.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#814064: [RFS] eoconv -- convert text files between various Esperanto encodings

[Dmitry Bogatov]

> control:
> std-version is 3.9.7
Fixed.

> rules: no upstream makefile is sad.
> makedocs? not run?
Forgot it. Fixed.

New version on mentors.

What do you think about NEWS, AUTHORS and THANKS?

I doubt NEWS is of any use, AUTHORS is mirrored in d/copyright,
but I think it would be fair for end-user to know who to thank.
Maybe just install it under /usr/share/doc/eoconv?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#814064: [RFS] eoconv -- convert text files between various Esperanto encodings

[Dmitry Bogatov]

> >Too fast. I improved d/rules and installed THANKS file. New revision
> >in on mentors. I do not expect new release anytime soon, so probably
> >it worth reject previous version and upload new one. Sad to bother
> >FTP-masters.


> I asked that on irc a few seconds ago :)
> >Sorry for misunderstanding, but can you please upload only after I
> >explicitly express that I finished work?

> sorry for my misunderstanding, I have issues with internet
> connection, so I have to speed up things.

> anyway, I'll upload then this one when the previous one gets rejected, and in
> case it gets processed before, I'll bump to -2 and reupload, is it ok?
Sure. Hope we will process with -1.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#820203: RFS: cdist/4.0.0~pre3-2 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: cdist
  Version : 4.0.0~pre3-2
  Upstream Author : Nico Schottelius 
* Url : http://www.nico.schottelius.org/software/cdist/
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

cdist -- Usable Configuration Management System

I have issues, that package builds find via `dpkg-buildpackage',
but when build with `sbuild' one of manpages get executable bit,
classified as error by lintian. Suggestions are welcome.

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

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

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

http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.0.0~pre3-2.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git

More information about cdist can be obtained from 
http://www.nico.schottelius.org/software/cdist/

Changes since last upload:

  * Bump standards version to 3.9.7 (no changes needed)
  * Do not hardcode python version dependency (Closes: #802784)
  * Replace insecure git:// uri in Vcs-Git field with secure https://
  * Fix spelling errors in manpages

Regards,
  Dmitry Bogatov

Bug#820234: RFS: cligh/0.2-4 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: cligh
  Version : 0.2-4
  Upstream Author : Christopher M. Brannon 
* Url : http://the-brannons.com/software/cligh.html
* Licenses: BSD-3-clause, GPL-3+
  Section : vcs

It builds those binary packages:

cligh -- Command-line interface to GitHub

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

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

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

http://mentors.debian.net/debian/pool/main/c/cligh/cligh_0.2-4.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git

More information about cligh can be obtained from 
http://the-brannons.com/software/cligh.html

Changes since last upload:

  * Change section from python to vcs (Closes: #811127)
  * Bump standards version (no changes needed)
  * Change insecure git:// uri in Vcs-Git field to secure https://
  * Check GPG signature

Regards,
  Dmitry Bogatov

Bug#820234: RFS: cligh/0.2-4 ITP

[Dmitry Bogatov]

> >Vcs-Browser: 
> >https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git
> >Vcs-Git: https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git
> please note: std-version is 3.9.8 now.

Fixed. New version on mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#820348: RFS: fgetty/0.7-1~bpo8+1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: fgetty
  Version : 0.7-1~bpo8+1
  Upstream Author : Felix von Leitner 
* Url : https://www.fefe.de/fgetty
* Licenses: GPL-2+
  Section : admin

It builds those binary packages:

fgetty -- very small, efficient, console-only getty and login

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

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

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

http://mentors.debian.net/debian/pool/main/f/fgetty/fgetty_0.7-1~bpo8+1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/fgetty.git

More information about fgetty can be obtained from https://www.fefe.de/fgetty

Changes since last upload:

  * Rebuild for jessie-backports.

Regards,
  Dmitry Bogatov

Packaging mmh (fork of nmh)

[Dmitry Bogatov]

[CC nmh maintainer]

Hello!

I am packaging mmh (http://marmaro.de/prog/mmh), which is fork of
nmh. Both of them are mail user agents.

nmh installs it's binaries (~20) into /usr/bin/nmh. Now I try to
do the same, and install mmh's binaries into /usr/bin/mmh, but
Lintian complain about FHS violation. The only allowed
subdir of /usr/bin is /usr/bin/mh.

Installing mmh into /usr/bin/mh would be impolite to `nmh', since
`mh' is historical name, like `vi'.

So I consider using alternatives mechanism. Unfortunately,
`mmh' and `nmh' are not totally equivalent -- mmh has lesser
count of commands. I think about alternatives not for binaries,
but for whole directories:

/usr/bin/mh -> /usr/lib/nmh | /usr/lib/mmh
/etc/mh -> /etc/nmh | /etc/mmh
...

Is it allowed? Is it good solution? And what to do with man pages?
For example, both provides `scan(1)', but only `nmh' has `mhshow(1)'.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Packaging mmh (fork of nmh)

[Dmitry Bogatov]

[2016-04-10 17:15] Jakub Wilk 
>
> * Wookey , 2016-04-10, 15:49:
> >>nmh installs it's binaries (~20) into /usr/bin/nmh.
>
> Actually it installs to /usr/bin/mh, ...

Sorry, my memory served me bad.

> >Are nmh and mmh intended to be co-installable? I presume that you want
> >one or the other, so making them conflict like MTAs would make sense.
>
> Conveniently, nmh already has Conflicts+Replaces+Provides for virtual
> package "mh". It would make sense to add the same C+R+P to mmh.

Ideally, they should be *co-installable*. This is wish (just a wish)
of mmh upstream and probably the right thing to do. I had to state it
more explicitly.

So, it is okay to use alternatives to manage /usr/bin/mh symlink (I
will need your cooperation, Jakub), but what about manpages?

Creating alternative for every manpage is too complicated. Is possible
to somehow create subdirectory /usr/share/man/man1/mh and have it
availiable to man? Seems, it will require rehashing of manpages database
every alternatives switch, though.

In general, any ideas how make them co-installable without too much pain
and FHS violation?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Packaging mmh (fork of nmh)

[Dmitry Bogatov]

> >So, it is okay to use alternatives to manage /usr/bin/mh symlink (I 
> >will need your cooperation, Jakub)
> I think you're confusing me with someone else...

Sorry again. With your statement about nmh content I thought, that
you are nmh maintainer.

> >, but what about manpages?
> >
> >Creating alternative for every manpage is too complicated.
>
> It's just a bunch of extra slave links. I doesn't look complicated to
> me.

It would be confusing, that `man scan' can refer to mmh, but `man mhshow'
to nmh, since such command is absent in `mmh'.

> >Is possible to somehow create subdirectory /usr/share/man/man1/mh and
> >have it availiable to man?
>
> I don't think so.

What about custom hooks, triggered on every alternative change?

> What you could do is to put the manpages into a different section[0], so
> that mmh's manpage files don't conflict with nmh's ones. But then it
> wouldn't be guaranteed that, say, "man mhl" will give the manpage
> corresponding to /usr/bin/mh/mhl.

It is terrible confusing. Only if I alternatives could affect section
resolution order...

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#820938: RFS: complexity/1.9+dfsg-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: complexity
  Version : 1.9+dfsg-1
  Upstream Author : Bruce Korb 
* Url : https://gnu.org/software/complexity
* Licenses: GPL-3+, GFLD-1.2+
  Section : devel

It builds those binary packages:

complexity -- tool for analyzing the complexity of C program functions
complexity-doc -- tool for analyzing the complexity of C program 
(documentation)

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

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

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


http://mentors.debian.net/debian/pool/main/c/complexity/complexity_1.9+dfsg-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git

More information about complexity can be obtained from 
https://gnu.org/software/complexity

Changes since last upload:

  * New upstream release
  * Change insecure git:// uri into secure https:// in Vcs-Git
field

Regards,
  Dmitry Bogatov

Bug#821907: RFS: fbless/0.2.3-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: fbless
  Version : 0.2.3-1
  Upstream Author : Con Radchenko 
* Url : https://github.com/matimatik/fbless
* Licenses: GPL-2+
  Section : text

It builds those binary packages:

fbless -- terminal fiction book reader

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

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

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

http://mentors.debian.net/debian/pool/main/f/fbless/fbless_0.2.3-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/fbless.git

More information about fbless can be obtained from 
https://github.com/matimatik/fbless

Changes since last upload:

  * Initial release (Closes: #821903)

Regards,
  Dmitry Bogatov

Bug#822856: RFS: dvtm/0.15-0.1 NMU

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: dvtm
  Version : 0.15-0.1
  Upstream Author : Marc Andre Tanner 
* Url : http://www.brain-dump.org/projects/dvtm
* Licenses: MIT/X
  Section : utils

I want to make NMU, since request to package new version is more then
270 days old and `dvtm-0.15' have features I miss in 0.12.  Maintainer
and Uploader are in CC. I am ready to take over package, if current
maintainer (Albin Tonnerre) is too busy.

It builds those binary packages:

dvtm -- Tiling window management for the console

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

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

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

http://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-0.1.dsc

Alternatively, you can access package debian/ directory via git from URL:

Sorry, git repository is not availiable

More information about dvtm can be obtained from 
http://www.brain-dump.org/projects/dvtm

Changes since last upload:

  * Non-maintainer upload.
  * New upstream release (Closes: #793472)
  * Bump debhelper compat level (9 -> 10), and add lintian override
about wrong versioned debhelper dependency
  * Replace patch about stripping and PREFIX with environment variables,
exported from debian/rules.
  * Adjust debian/docs to match upstream, renamed README to README.md
  * Convert debian/changelog into DEP-5 format
  * Remove `config.h' at clean stage
  * Bump standards version to 3.9.8 (no changes needed)
  * Enable hardening
  * Make copymode work out-of-box in most cases
  * Export every available command for fifo scripting

Regards,
  Dmitry Bogatov

Bug#822856: RFS: dvtm/0.15-0.1 NMU

[Dmitry Bogatov]

> >  * Bump debhelper compat level (9 -> 10),
> Compat level 10 is an experimental feature. NMUs is not a place to make
> experiments.
>
> >  * Convert debian/changelog into DEP-5 format
>
> ITYM debian/copyright, but this is not appropriate for an NMU either.
Will fix it.

> >  * Bump standards version to 3.9.8 (no changes needed)
> Ditto.

> maybe we can also start a MIA process?

I do not want to put a pressure on anyone, but if it is the only way
to make big changes to package, let's do it.

BTW, is it some rule of thumb, how many days of no response to
please-package-new-upstream-version-bug should pass before considering
NMU/MIA?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#822856: RFS: dvtm/0.15-0.1 NMU

[Dmitry Bogatov]

> >I do not want to put a pressure on anyone, but if it is the only way
> >to make big changes to package, let's do it.
> I could understand that, but
> 1) lets avoid experimental features
> 2) lets try to keep changes minimal.

Okay, I can agree that compat 10 is unnecessery. But still someone
someday will have to do it.

> I mean, a package refactor might be acceptable if the current
> packaging is broken/unmaintainable, not just for fun

Sorry, can't locate any just-for-fun changes beside compat 10.

> (avoding compat level 10 will remove a lot of the diff, and

Is it imperative to revert it?

> (BTW I would also apreciate you opening important bugs for your
> changes, e.g.  "please add hardening" please avoid STRIPPING of
> binaries and then propose a patch for them.

Okay, I will do it this next time.

> STRIP is something new in this release, so you can avoid a bug)

Sorry, can't understand this sentence. Do you advice aganist usage of
STRIP variable?

> >BTW, is it some rule of thumb, how many days of no response to
> >please-package-new-upstream-version-bug should pass before considering
> >NMU/MIA?

> Since you opened the "please update version bug" [1] one year ago, I
> propose you to bump the severity to important, and then wait some
> little more time.

Bumped severity.

> I'll for sure put the upload in deferred/15, so the maintainers will
> have time to react (adding the time you will need to prepare a good
> package :) )

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#823292: RFS: dh-haskell/0.2 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-haskell"

* Package name: dh-haskell
  Version : 0.2
  Upstream Author : Dmitry Bogatov 
* Url : 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-haskell.git
* Licenses: GPL-3+
  Section : devel

It builds those binary packages:

dh-haskell -- debhelper add-on for packaging software written in Haskell

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

http://mentors.debian.net/package/dh-haskell

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

http://mentors.debian.net/debian/pool/main/d/dh-haskell/dh-haskell_0.2.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/dh-haskell.git

More information about dh-haskell can be obtained from 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-haskell.git

Changes since last upload:

  * Correctly handle packages without library. (Closes: #820406)
Patch is inspired by one, provided by Neil Mayhew.
  * Fix handling of multiple flags, returned by `dpkg-buildflags'.
(Closes: #822947) Patch provided by Colin Watson (cjwat...@ubuntu.com).
  * Bump standards version to 3.9.8 (no changes needed)
  * Fix debian/copyright syntax
  * Use secure uri in Vcs-Git field
  * Fix spelling errors
  * Fix wrong links in debian/control

Regards,
  Dmitry Bogatov

Bug#822856: RFS: dvtm/0.15-0.1 NMU

[Dmitry Bogatov]

> >Is it imperative to revert it?
> if you want a speedy NMU yes, if you want to wait some months no, we can let
> MIA team ping the maintainer, and then take over the package.

It already waited for almost year. I think we are not in a hurry. So I
would rather wait for MIA.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#821907: RFS: fbless/0.2.3-1 ITP

[Dmitry Bogatov]

> Please rename README to README.ru, preferably upstream.

dh_install'ed

> Please consider using hyphenation data from hyphen-* packages.

dh_linktree'ed

Please, review once more.

Bug#824411: RFS: stterm/0.6-0.1 NMU

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: stterm
  Version : 0.6-0.1
  Upstream Author : Christoph Lohmann <2...@r-36.net>
* Url : http://st.suckless.org
* Licenses: GPL-2+, MIT
  Section : x11

It builds those binary packages:

stterm -- suckless tools simple terminal for windowed system

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

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

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

http://mentors.debian.net/debian/pool/main/s/stterm/stterm_0.6-0.1.dsc

Alternatively, you can access package debian/ directory via git from URL:

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

More information about stterm can be obtained from http://st.suckless.org

Changes since last upload:

  * Non-maintainer upload.
  * New upstream upload (Closes: #820376)
  * Update debian/watch
  * Refresh patches

Regards,
  Dmitry Bogatov

Bug#821907: RFS: fbless/0.2.3-1 ITP

[Dmitry Bogatov]

> > > Please rename README to README.ru, preferably upstream.
> >=20
> > dh_install'ed
> >=20
> > > Please consider using hyphenation data from hyphen-* packages.
> >=20
> > dh_linktree'ed
> >=20
> > Please, review once more.
> Please build this in a clean sid chroot.
>
> dpkg-query: no path found matching pattern /usr/share/hyphen/hyph_es_ANY.dic
> dh_linktree: error: dpkg --search -- /usr/share/hyphen/hyph_de_DE.dic /usr/=
> share/hyphen/hyph_en_US.dic /usr/share/hyphen/hyph_es_ANY.dic /usr/share/hy=
> phen/hyph_fr.dic /usr/share/hyphen/hyph_it_IT.dic /usr/share/hyphen/hyph_ru=
> _RU.dic /usr/share/hyphen/hyph_uk_UA.dic gave error exit status 1

Fixed and rebuilt. New version is on mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

cdist: TeX in sid

[Dmitry Bogatov]

Hello!

When building cdist-4.0.0, I encountered listed error with sbuild.
Seems it is issues with TeX, not with my package. Any suggestions?

How read this '/tmp/fmtutils.C8RsuPiw' file, for example?

Processing triggers for tex-common (6.05) ...
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... 
fmtutil failed. Output has been stored in
/tmp/fmtutil.C8RsuPiw
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 subprocess installed post-installation script returned error exit 
status 1
dpkg: dependency problems prevent configuration of 
texlive-generic-recommended:
 texlive-generic-recommended depends on tex-common (>= 6); however:
  Package tex-common is not configured yet.

dpkg: error processing package texlive-generic-recommended 
(--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of 
texlive-fonts-recommended:
 texlive-fonts-recommended depends on tex-common (>= 6); however:
  Package tex-common is not configured yet.

dpkg: error processing package texlive-fonts-recommended (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of texlive-htmlxml:
 texlive-htmlxml depends on texlive-generic-recommended (>= 2016); 
however:
  Package texlive-generic-recommended is not configured yet.
 texlive-htmlxml depends on texlive-fonts-recommended (>= 2016); 
however:
  Package texlive-fonts-recommended is not configured yet.
 texlive-htmlxml depends on tex-common (>= 6); however:
  Package tex-common is not configured yet.

dpkg: error processing package texlive-htmlxml (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of jadetex:
 jadetex depends on texlive-htmlxml; however:
  Package texlive-htmlxml is not configured yet.

dpkg: error processing package jadetex (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of docbook-utils:
 docbook-utils depends on jadetex; however:
  Package jadetex is not configured yet.
  Package texlive-htmlxml which provides jadetex is not configured yet.

dpkg: error processing package docbook-utils (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of 
sbuild-build-depends-cdist-dummy:
 sbuild-build-depends-cdist-dummy depends on docbook-utils; however:
  Package docbook-utils is not configured yet.

dpkg: error processing package sbuild-build-depends-cdist-dummy 
(--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of texlive-latex-base:
 texlive-latex-base depends on tex-common (>= 6); however:
  Package tex-common is not configured yet.

dpkg: error processing package texlive-latex-base (--configure):
 dependency problems - leaving unconfigured
Processing triggers for systemd (229-6) ...
Processing triggers for libc-bin (2.22-9) ...
Errors were encountered while processing:
 tex-common
 texlive-generic-recommended
 texlive-fonts-recommended
 texlive-htmlxml
 jadetex
 docbook-utils
 sbuild-build-depends-cdist-dummy
 texlive-latex-base

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#825230: RFS: cdist/4.0.0-1

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: cdist
  Version : 4.0.0-1
  Upstream Author : Nico Schottelius 
* Url : http://www.nico.schottelius.org/software/cdist/
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

cdist -- Usable Configuration Management System

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

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

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

http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.0.0-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git

More information about cdist can be obtained from 
http://www.nico.schottelius.org/software/cdist/

Changes since last upload:

  * New upstream release
  * Refresh spelling patches
  * Improve machine-readability of debian/copyright
  * Disable building html documentation
  * Bump standards version to 3.9.8 (no changes needed)

Regards,
  Dmitry Bogatov

Bug#822856: Another try for dvtm?

[Dmitry Bogatov]

> Hi Dmitry, due to the partial orphaning of the package in #824284,
> are you interested in this package, and starting to maintain it properly?

Last version is on mentors. I think it is okay to upload, the only thing
I am not sure is about close-multiple-bug syntax.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#822856: Another try for dvtm?

[Dmitry Bogatov]

> Hi, still missing a build-dependency on libncurses5-dev
>
> the package just FTBFS
> http://debomatic-amd64.debian.net/distribution#unstable/dvtm/0.15-1/buildlog
> If it is ok for you I can add it, sign and upload.

Yes, proceed, please. My bad. Some time ago I installed ghc into blessed image,
and did not noticed, that it pulls libncurses5-dev.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#825509: RFS: cdist/4.0.0-2 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: cdist
  Version : 4.0.0-2
  Upstream Author : Nico Schottelius 
* Url : http://www.nico.schottelius.org/software/cdist/
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

cdist -- Usable Configuration Management System

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

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

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

http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.0.0-2.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git

More information about cdist can be obtained from 
http://www.nico.schottelius.org/software/cdist/

Changes since last upload:

  * patches/ensure-reproducible-build.patch: ensure deterministic file
processing order.  Thanks to Chris Lamb .
(Closes: #825406)

Regards,
  Dmitry Bogatov

Bug#825509: RFS: cdist/4.0.0-2 ITP

[Dmitry Bogatov]

> the rationale is:
> what you have on git is different from what is in unstable.
>
> I had to change UNRELEASED to unstable
> and to change the timestamp of the -1 version
> https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git/commit/?id=3D=
> 3527e379aad6e7d2621652b308676e000e7f866b
>
> you seem to have changed it, but the package has been sponsored in unstable=
>  without that change
>
> (BTW having it on deferred/4 has two meanings: let you the time to answer, =
> and give time to the current package to migrate
> in testing. I don't think a reproducible build fix is worth a delay for the=
>  testing transition, specially if the package is 3/5 days old :) )

Sorry, my bad. Now I understand, that I uploaded on mentors 4.0.0-2
again UNRELEASED. Please, reject current and grab new from mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

dh_install globbing

[Dmitry Bogatov]

Hello!

I want dh_install to install according following globbing:

src/doc/*[a-z].html /usr/share/doc/runit/html

(There is also html pages in form foo.1.html, which duplicate man
pages. I do not want to install them.)

But it does not work -- nothing is installed. dh_install(1) does not
specify glob rules, but plain star (src/doc/*.html) works. Is it
possible accomplish what I want, or I should add override and remove
unwanted pages after?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: dh_install globbing

[Dmitry Bogatov]

> * Dmitry Bogatov , 2016-05-30, 18:27:
> >I want dh_install to install according following globbing:
> >
> > src/doc/*[a-z].html /usr/share/doc/runit/html
> >
> >(There is also html pages in form foo.1.html, which duplicate man=20
> >pages. I do not want to install them.)
> >
> >But it does not work -- nothing is installed. dh_install(1) does not=20
> >specify glob rules, but plain star (src/doc/*.html) works.
> 
> The rules are documented in debhelper(1) manpage: =E2=80=9Cyou can use st=
> andard=20
> shell wildcard characters (? and * and [..] character classes) in the=20
> [config] files=E2=80=9D.
> 
> Even if [] wasn't supported, in compat >=3D5 dh_install is supposed to=20
> fail if wildcard expands to nothing.
> 
> Can you show us the source package, so that we can see what's going on?

Sure.

  $ git clone -b demonstrate 
https://anonscm.debian.org/cgit/users/kaction-guest/runit.git/

Glob in 'runit.install'. Try to build package, and notice, that no
html files installed at all.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: dh_install globbing

[Dmitry Bogatov]

> * Dmitry Bogatov , 2016-05-31, 13:15:
> >  $ git clone -b demonstrate 
> > https://anonscm.debian.org/cgit/users/kaction-guest/runit.git/
> >
> >Glob in 'runit.install'. Try to build package, and notice, that no html 
> >files installed at all.
> 
> I can't reproduce it here:
> 
> $ grep -B1 html debian/*.install
> #!/usr/bin/dh-exec
> ${RUNIT}/doc/*[a-z].html /usr/share/doc/runit/html
> 
> $ dpkg-buildpackage && dpkg -c ../runit_2.1.2-4_amd64.deb | grep /html/
> ...

I upgraded dh-exec from jessie to sid, and it started to work. Strange, there
were no NEWS.

Thanks for your help!

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: dh_install globbing

[Dmitry Bogatov]

> >I upgraded dh-exec from jessie to sid, and it started to work.
>
> This is probably #801516.
>
> Anyway, if replaced "${RUNIT}" with "runit-*" in the *.install file, you
> wouldn't need dh-exec at all.

In some cases I need renaming feature, but thank you for advice.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Helping maintain debian packages

[Dmitry Bogatov]

> I have created a debian package
> https://packagecloud.io/waghanza/plunder/packages/debian/jessie/phantomjs_2.1.1_amd64.deb

Phantomjs is good. But as I remember it, that upstream release
contains some bundled library, and do not support linking with system one.

About documentation, apt-get install debian-policy developers-reference

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#826266: RFS: dvtm/0.15-1~bpo8+1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: dvtm
  Version : 0.15-1~bpo8+1
  Upstream Author : Marc Andre Tanner 
* Url : http://www.brain-dump.org/projects/dvtm
* Licenses: MIT/X
  Section : utils

It builds those binary packages:

dvtm -- Tiling window management for the console

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

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

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

http://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-1~bpo8+1.dsc

Alternatively, you can access package debian/ directory via git from URL:

Sorry, git repository is not availiable

More information about dvtm can be obtained from 
http://www.brain-dump.org/projects/dvtm

Changes since last upload:

  * Rebuild for jessie-backports.

Regards,
  Dmitry Bogatov

Bug#826266: RFS: dvtm/0.15-1~bpo8+1 ITP

[Dmitry Bogatov]

> >http://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-1~bpo8+1.dsc
> 404

Sorry. Should work now.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Importing ubuntu package

[Dmitry Bogatov]

Hello!

What is common practice about adopting ubuntu packages? I want to
adopt ubuntu `btpd' package, but it already have it's changelog. I
think it would be impolite to just discard it. What is recommended way
to follow Debian policy and still make a credit to previous
maintainer?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827043: RFS: gdbm/1.12-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: gdbm
  Version : 1.12-1
  Upstream Author : bug-g...@gnu.org
* Url : http://directory.fsf.org/project/gdbm/
* Licenses: GPL-3+, GFDL-1.3+
  Section : libs

It builds those binary packages:

libgdbm4 -- GNU dbm database routines (runtime version)
libgdbm-dev -- GNU dbm database routines (development files)
gdbmtool -- GNU dbm database routines (command line tools)

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

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

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

http://mentors.debian.net/debian/pool/main/g/gdbm/gdbm_1.12-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/gdbm.git

More information about gdbm can be obtained from 
http://directory.fsf.org/project/gdbm/

Changes since last upload:

  * New maintainer (Closes: #826639)
  * New upstream release
  * Update debian/watch
  - use HTTP over FTP protocol. FTP have some issues with Tor.
  - check GPG signature
  * New binary package libgdbm4 over libgdbm3 due upstream changing ABI.
  * Bump debhelper compat level from 7 to 9
  * Migrate debian/rules to `dh' sequencer
  * Bump standards version to 3.9.8
  * Remove obsolete README.source -- package no longer uses dpatch,
it now uses quilt
  * Refresh patches and format them according dep3
- 01_texinfo-usr-local.patch: upstream moved texinfo manual under doc/
  * Drop no longer needed patches
 - 02_zero-headers.patch: code seems to be correct as-is,
   no bug reference is present in patch
 - 03-Makefile.in.patch: upstream now uses Automake
 - 04_fix-gdbm-compat-linking.patch: compatibility with ancient (pre-2.0)
   libtool is not needed anymore.
 - 05_handle-short-read.patch: implemented upstream
 - 06_manpage-cleanup.patch: hyphen issues fixed upstream
 - 07-link-flags.patch: upstream now uses Automake
 - 08-651521-libtool-mode-install.patch: upstream now uses Automake
 - 08-709905-gdbm.texinfo.patch: fixed upstream
  * Remove mainainer scripts that called 'ldconfig', which is called by
dpkg trigger.
  * Reformat debian/copyright according dep5
  * New binary package 'gdbtool' for command line utilities, provided by
upstream.
  * Enable hardening
  * Fix spelling in manual pages
  * Replace direct pre-dependency on multiarch-support with ${misc:Pre-Depends}
  * Regenerate 'symbols' file
  * Add Vcs-* fields in debian/control

Regards,
  Dmitry Bogatov

Bug#827043: RFS: gdbm/1.12-1 ITP

[Dmitry Bogatov]

> I am not a DD and thus cannot sponsor your package, but here are a few
> remarks.

Thank you for review.

> Your debian/changelog file is actually missing the entry of the last
> upload (1.8.3-14), please incorporate it.  That version already included
> a few of your changes, plus there is a patch for bug #774394 which your
> package seems to be missing.

My bad. I should put 'apt-get update' into cron.

> >   * New maintainer (Closes: #826639)
> Please send a message to that bug that you would like to adopt the
> package, and retitle the bug accordingly.

Sent it. Seems I can't include control into message to
826...@bugs.debian.org

> >   * New upstream release
> Closes: #682239
> Probably there are a few other bugs which are fixed by the new upstream
> release, e.g. #340479 - since version 1.9, gdbm has large file support.
> Please take a look at them, there are not too many.

I considered some of them. Other require more prolonged
experimentation on my side and communication with upstream. I am not
aganist to defer them to -2 revision.

> >   * Update debian/watch
> >   - use HTTP over FTP protocol. FTP have some issues with Tor.
> >   - check GPG signature
> >   * New binary package libgdbm4 over libgdbm3 due upstream changing ABI.
> This means that the upload should go to experimental first, and then you
> have to start a transition, see
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions.

New concept for me. Will read.

> >   * Bump debhelper compat level from 7 to 9
> Already done in 1.8.3-14.
Removed changelog entry

> >   * Migrate debian/rules to `dh' sequencer
> 
> The old package (besides not using debhelper for most things) had a few
> idiosyncrasies, such as the one mentioned in #589761.  Hopefully none of
> those are needed anymore, but you should at least look at them.  Also,
> you get a fix for bug #436944 for free. :-)
Marked as closed

> >   * Bump standards version to 3.9.8
> Already done in 1.8.3-14.
Removed changelog entry

> >   * Remove mainainer scripts that called 'ldconfig', which is called by
> > dpkg trigger.
> Ditto.
Removed changelog entry

> >   * Replace direct pre-dependency on multiarch-support with 
> > ${misc:Pre-Depends}
> Ditto.
Removed changelog entry

> I guess it would be useful to ship the NEWS and NOTE-WARNING files in
> the libgdbm4 package.  The latter is probably quite important on 32-bit
> architectures.
Shipped with devel package.

New version in on mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827089: RFS: dh-runit/0.1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-runit"

* Package name: dh-runit
  Version : 0.1
  Upstream Author : Dmitry Bogatov 
* Url : 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

dh-runit -- debhelper add-on to handle runit runscripts

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

http://mentors.debian.net/package/dh-runit

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

http://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_0.1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git

More information about dh-runit can be obtained from 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git

Changes since last upload:

  * Initial release (Closes: #826771)

Regards,
  Dmitry Bogatov

Bug#827090: RFS: runit/2.1.2-4 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: runit
  Version : 2.1.2-4
  Upstream Author : Gerrit Pape 
* Url : http://smarden.org/runit/
* Licenses: BSD-3-clause
  Section : admin

It builds those binary packages:

runit -- system-wide service supervision
runit-systemd -- system-wide service supervision (systemd integration)
getty-run -- runscripts to supervise getty processes
runit-init -- system-wide service supervision (as init system)

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

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

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

http://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-4.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/runit.git

More information about runit can be obtained from http://smarden.org/runit/

Changes since last upload:

  * New maintainer
  * Bump standards version to 3.9.8 (no changes needed)
  * Write watch file
  * Change source format from implicit `1.0' to explicit `3.0(quilt)'.
  - patches from debian/patches are applied automatically
  - `dpkg-buildpackage' no longer complains about files under
`debian/.git'.
  * Convert patches to quilt format.
  - Remove manual patches application
  - Rename `debian/diff' to `debian/patches'
  - Generate `patches/series' file
  * Use makefile snippets provided by `dpkg' over manual assignments.
  * Convert 'debian/copyright' to dep5 format
  * Convert packaging to debhelper
  * New binary package 'runit-init', that provides /sbin/init replacement
out-of-box. This package have reduced priority 'extra', since it
conflicts with other initialization systems.
  * Add Vcs-Browser and Vcs-Git fields into 'debian/control'
  * Patch '${RUNIT}/etc/2' and install it instead of providing separate
version as 'debian/2'
  * Remove unused 'examples/start-stop-daemon' script.
  * Utilize 'dh_bash-completion' to install bash completion snippet
  * Utilitze 'dh_systemd' to install systemd service file into new binary
package 'runit-systemd'.
  * Delete runsvdir-start symbolic link. Note is left in NEWS file
  * Rename runit.NEWS.Debian to runit.NEWS to be installed by debhelper
  * Remove scripting in runit's maintainer scripts to adjust /etc/inittab.
It will be provided as separate package.
  * Make buildsystem respect dpkg-buildflags.
  * Enable hardening
  * Register documentation with doc-base (Policy 9.10)
  * Move communication files under /run to work with read-only /etc
  * Move getty runscripts into separate binary package
  * Emulalate sysv runlevel 5 by default.

Regards,
  Dmitry Bogatov

Bug#827089: RFS: dh-runit/0.1 ITP

[Dmitry Bogatov]

> while I did some work on runit package a while ago, I'm not sure about
> how you want the packages to use your new shiny dh call?
> how do you plan to notify them about it?
> do you plan to open a lot of bugs for packages exposing a runit script?

First of all, runit supports (as policy requires) support for running
/etc/init.d/scripts, so there is no need to make haste. Yes, I plan to
open bugs with patches to provide `runscripts'. As long as there is no
runscript is provided, runit can use init.d script.

dh_runit is now needed by 'getty-run', that now is built
from runit source package.

> I admit, I'm not a fan of too-many-init-systems-to-support, and runit
> is not so far one of the most used...

Sure. As-is in archives it requires determination to migrate on it, so
no surprise. And, as was discussed in upstart RM thread, popularity is
poor metric, when you compare any init system with systemd, which is
installed by default (ugh) and sysvinit, compatibility with which is
mandated by policy.

> but a debhelper script is always something appreciated that can
> simplify things...

Again, dh_runit is dependency of runit now. I would put it into runit
source package, but it would create chicken-and-egg problem.

> another question: I see a lot of activity on git, so you need to
> freeze at some point, and tag the "release", otherwise the sponsor
> won't know when you are ready to go.

If I am correct, master is same as version on mentors. If you insist,
I can make 'release' tag, but I prefer to tag things when they reach
Archives.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827090: RFS: runit/2.1.2-4 ITP

[Dmitry Bogatov]

> +  * New maintainer
> did Gerrit asked for help?
> stepping in as maintainer needs an RFH or Orphan package.
> (well, Gerrit was fine on giving up some packages IIRC)

Gerrit gave up fgetty (which I picked up), so I think he will be okay
with this. But explicit is better then implicit.

> compat level 10 not mentioned in changelog

Fixed

> explicit `3.0(quilt)'.

Strange. Version in git have (and always had) space.

> +  * Remove scripting in runit's maintainer scripts to adjust /etc/inittab.
> +It will be provided as separate package.

My bad. Forgot about it. Will take some time.

> + is probably necessery.
> typo

Fixed.

> https://launchpad.net/ubuntu/+source/runit/2.1.2-3ubuntu1
> what about the Ubuntu delta?

I see no use of them, sorry.

> 7) we should wait for dh-runit to be accepted, so please remove moreinfo tag 
> once
> done

dh-runit accepted into unstable. Removed tag.

> 8) I can't test until all the required build dependencies are in
> place, so expect a runtime-review on the next run.

You will have to rebuild 'init' helper yourself for now, since it
depends on systemd|sysv-core|upstart, but not on runit-init(sure),
which conflicts with all above.

> BTW, for an init system I really would like to see Gerrit acking the
> changes, specially because he is also the  upstream developer.

Yes, it would be great. To be honest, I lost hope to upstream some of
my patches, since upstream git is dead, and all we have it tarball.

Please review everything you can. I will implement running under sysv
in a week or so.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827090: RFS: runit/2.1.2-4 ITP

[Dmitry Bogatov]

> On Mon, Jun 13, 2016 at 10:18:04PM +0300, Dmitry Bogatov wrote:
> > > +  * New maintainer
> > > did Gerrit asked for help?
> > > stepping in as maintainer needs an RFH or Orphan package.
> > > (well, Gerrit was fine on giving up some packages IIRC)
> >
> > Gerrit gave up fgetty (which I picked up), so I think he will be okay
> > with this. But explicit is better then implicit.
>
> Hi Gianfranco, Dmitry,
>
> actually I'm not okay with anyone taking over the runit packge.  And I
> don't see why runit needs an update in Debian.  The few bugs are known
> and can be worked around if necessary.

Well, in current state, runit is not init system and using it is
rather complicated -- sysadmin have to manually copy files from
/usr/share/doc/ into /etc. It writes files under /etc, which may be
read-only. Using it under sysv control means that getty is not runit
service. It provides only tty5 runscript.

My changes addresses all of above to provide something, that would
work out-of-box. Would you be interested in taking them?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827090: RFS: runit/2.1.2-4 ITP

[Dmitry Bogatov]

> I've been there, done that.  Many years ago, if interested search
> history for the runit-init package.  Today I don't think runit is the
> right choice for integrating as init system into Debian.

Would you be so kind to be more verbose/provide link? What is wrong for
runit provide init?

> Take a look at s6, nosh, or perp maybe?

I saw them. Not impressed. There is some features from s6 worth
adopting, but I still prefer runit.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827685: RFS: elpa-undo-tree/0.6.4-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "elpa-undo-tree"

* Package name: elpa-undo-tree
  Version : 0.6.4-1
  Upstream Author : Toby Cubitt 
* Url : http://www.dr-qubit.org/git/undo-tree.git
* Licenses: GPL-3+
  Section : lisp

It builds those binary packages:

elpa-undo-tree -- Emacs minor mode for handling undo history as tree

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

http://mentors.debian.net/package/elpa-undo-tree

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


http://mentors.debian.net/debian/pool/main/e/elpa-undo-tree/elpa-undo-tree_0.6.4-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/paredit-el.git

More information about elpa-undo-tree can be obtained from 
http://www.dr-qubit.org/git/undo-tree.git

Changes since last upload:

  * Initial release. (Closes: #827679)

Regards,
  Dmitry Bogatov

Bug#827685: RFS: elpa-undo-tree/0.6.4-1 ITP

[Dmitry Bogatov]

> 1. The /source/ package name should actually be undo-tree not
>elpa-undo-tree (team convention to use upstream's name).  Probably
>not worth changing now, but you should be aware of this for packaging
>other addons (you mentioned you wanted to package evil).

Ok. In self-protection can point on elpa-paredit source package.

> 2. Is there some reason you packaged version 0.6.4?  0.6.6 is available.

$ git tag | grep 0.6.6
[empty]

> 3. The homepage in d/control is wrong:
>http://www.dr-qubit.org/git/undo-tree.git is just a git repository,
>not a webpage.  It should be
> (my script
>got this mostly right!).
>I've gone ahead and fixed this in the team repo.

Thanks.

> 4. Please apply a PGP-signed tag to the correct commit in the team
>repo.  Then it will appear correctly on PET.[1]

You mean, I should gpg-tag 'a9e75' as debian/0.6.4-1?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827765: RFS: gdbm/1.12-2 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: gdbm
  Version : 1.12-2
  Upstream Author : bug-g...@gnu.org
* Url : http://directory.fsf.org/project/gdbm/
* Licenses: GFDL-1.3+, GPL-3+
  Section : libs

It builds those binary packages:

libgdbm4 -- GNU dbm database routines (runtime version)
libgdbm-dev -- GNU dbm database routines (development files)
gdbmtool -- GNU dbm database routines (command line tools)
libgdbm-compat4 -- GNU dbm database routines (legacy support runtime 
version)
libgdbm-compat-dev -- GNU dbm database routines (legacy support development 
files)

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

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

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

http://mentors.debian.net/debian/pool/main/g/gdbm/gdbm_1.12-2.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/gdbm.git

More information about gdbm can be obtained from 
http://directory.fsf.org/project/gdbm/

Changes since last upload:

  * Install localization into libgdbm4 binary package
  * Install info manual into libgdbm-dev binary package
  * Separate dbm and ndbm compat layer into separate package

Regards,
  Dmitry Bogatov

Bug#827685: RFS: elpa-undo-tree/0.6.4-1 ITP

[Dmitry Bogatov]

> > > 2. Is there some reason you packaged version 0.6.4?  0.6.6 is
> > > available.
> >=20
> > $ git tag | grep 0.6.6
> > [empty]
> Hmm, nevermind, not sure where I thought I'd found 0.6.8.

There is Version: 0.6.6 header in elisp file in upstream master.
But there is no corresponding tag. I packaged according tags.

> > > 4. Please apply a PGP-signed tag to the correct commit in the team
> > >repo.  Then it will appear correctly on PET.[1]
> >=20
> > You mean, I should gpg-tag 'a9e75' as debian/0.6.4-1?
> Yes, that would be useful.

Done.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: evil
  Version : 1.2.12-1
  Upstream Author : Vegard Øye 
* Url : https://bitbucket.org/lyro/evil/wiki/Home
* Licenses: GFDL-1.3+, GPL-3+
  Section : lisp

It builds those binary packages:

elpa-evil -- extensible vi layer for Emacs

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

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

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

http://mentors.debian.net/debian/pool/main/e/evil/evil_1.2.12-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/evil.git

More information about evil can be obtained from 
https://bitbucket.org/lyro/evil/wiki/Home

Changes since last upload:

  * Initial release. (Closes: #827897)

Regards,
  Dmitry Bogatov

Bug#827913: RFS: goto-chg/1.6-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "goto-chg"

* Package name: goto-chg
  Version : 1.6-1
  Upstream Author : David Andersson 
* Url : https://www.emacswiki.org/emacs/goto-chg.el
* Licenses: GPL-2+
  Section : lisp

It builds those binary packages:

elpa-goto-chg -- navigate the point of the most recent edit in the buffer

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

http://mentors.debian.net/package/goto-chg

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

http://mentors.debian.net/debian/pool/main/g/goto-chg/goto-chg_1.6-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/goto-chg.git

More information about goto-chg can be obtained from 
https://www.emacswiki.org/emacs/goto-chg.el

Changes since last upload:

  * Initial release. (Closes: #827910)

Regards,
  Dmitry Bogatov

Proposing patch for packages, affected by transition

[Dmitry Bogatov]

Hello!

Recently, I took over gdbm package and got new version into
experimental. Now I work on fixing reverse dependencies FTBFS.

Given I have patch for one of rdependency (camldbm, namely). What now?
Should I ask maintainer to apply it and make upload into experimental?
Or something else?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Proposing patch for packages, affected by transition

[Dmitry Bogatov]

> >Recently, I took over gdbm package and got new version into
> >experimental. Now I work on fixing reverse dependencies FTBFS.
> >
> >Given I have patch for one of rdependency (camldbm, namely). What now?
> >Should I ask maintainer to apply it and make upload into experimental?
> >Or something else?
>
> open bugs against the affected packages, severity important, tags patch
> and mention that it will become RC when the transition starts.

Okay. But if they apply this patch right now, package will not build
aganist unstable.  Is it okay?

> Do you have a wider view about how many packages are affected by
> rebuild issues?

Yes.

FAIL camldbm_1.0-2.dsc -- patch ready
FAIL courier_0.73.1-1.6.dsc
FAIL freeradius_2.2.8+dfsg-0.1.dsc
FAIL ifmail_2.14tx8.10-22.dsc
FAIL nis_3.17-34.dsc
FAIL ntop_5.0.1+dfsg1-2.1.dsc
FAIL ocsigenserver_2.4.0-1.dsc
FAIL perdition_2.1-2.dsc
FAIL python3-stdlib-extensions_3.4.2-1.dsc
FAIL qsf_1.2.7-1.dsc
FAIL ruby2.1_2.1.5-2+deb8u2.dsc
FAIL ruby2.3_2.3.1-5.dsc
FAIL sortmail_2.4-2.dsc

> the -2 version should make probably all of them build correctly if
> I'm not wrong.

No. -2 version separated modern and compat interface into different
binaries packages, so some packages at least need add build-depends:
libgdbm-compat-dev.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Proposing patch for packages, affected by transition

[Dmitry Bogatov]

> >Okay. But if they apply this patch right now, package will not build
> >aganist unstable.  Is it okay?
> just mention that in the bug report, this will allow me/you to NMU when the 
> transition starts

Okay.

> >FAIL camldbm_1.0-2.dsc -- patch ready
> >FAIL courier_0.73.1-1.6.dsc
> >FAIL freeradius_2.2.8+dfsg-0.1.dsc
> >FAIL ifmail_2.14tx8.10-22.dsc
> >FAIL nis_3.17-34.dsc
> >FAIL ntop_5.0.1+dfsg1-2.1.dsc
> >FAIL ocsigenserver_2.4.0-1.dsc
> >FAIL perdition_2.1-2.dsc
> >FAIL python3-stdlib-extensions_3.4.2-1.dsc
> >FAIL qsf_1.2.7-1.dsc
> >FAIL ruby2.1_2.1.5-2+deb8u2.dsc
> >FAIL ruby2.3_2.3.1-5.dsc
> >FAIL sortmail_2.4-2.dsc
> >
> >No. -2 version separated modern and compat interface into different
> >binaries packages, so some packages at least need add build-depends:
> 
> >libgdbm-compat-dev.
> 
> if adding an additional build dependency works, I'm ok with a bug filing
> (maybe send a mail to -devel, because this sounds like an MBF)
> 
> BTW since there are >10 packages to patch, what about make the new library 
> depend explictly
> on the old one?

I would better not. calmdbm patch is not such trivial -- it was more
serious. I will do it one-by-one.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#827913: RFS: goto-chg/1.6-1 ITP

[Dmitry Bogatov]

> 1. The long description is not grammatical English.  I appreciate you're
>not a native speaker, so I fixed it for you in the team git
>repository.

Thanks.

> 2. I noticed with all of your packages that I reviewed that there is no
>trailing newline at the end of your files.  My Emacs keeps trying to
>add it... is there some reason for this?  Obviously not a blocker for
>sponsorship.

Bad habit. Sorry.

> 3. Any particular reason you are using gz and not xz compression in
>gbp.conf?  Also, it might be a good idea to check the tarball into
>git with pristine-tar so that a sponsor has exactly the same one (I
>generated my own for testing).

None. Just cut-and-yank from paredit package.

> 4. Please add a d/watch file.

Need help with it. No idea how to track versions on Emacs wiki.

> 5. You could extract the upstream changelog from goto-chg.el and install
>it.

Done.

> 6. I don't think the copy of the code on the Emacs Wiki counts as a
>"Homepage".  It's the correct thing to put in Source: field of
>d/copyright, but I don't think it should go in d/control.

Done.

We probably need to make emacsen policy more... verbose.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827913: RFS: goto-chg/1.6-1 ITP

[Dmitry Bogatov]

> Enjoy:
>
> ;; require a buffer to have a final newline
> (setq require-final-newline 'visit-save)

Nice. Thanks.

> > > 3. Any particular reason you are using gz and not xz compression in
> > > gbp.conf?  Also, it might be a good idea to check the tarball into
> > > git with pristine-tar so that a sponsor has exactly the same one (I
> > > generated my own for testing).
> >=20
> > None. Just cut-and-yank from paredit package.
> Okay.  I'd be grateful if you could use dh-make-elpa and report bugs,
> although it's having trouble with gbp.conf right now I think.

No idea why, but dh-make-elpa (seems to violate debhelper naming
convention) works when invoken from /bin/bash, but complains about
package versions, when invoked from my shell of choice, rc.

Just wild suggestion, seems it assumes, that `getenv("PWD") == getcwd()'.
It is not.

> > > 4. Please add a d/watch file.
> >=20
> > Need help with it. No idea how to track versions on Emacs wiki.
>
> Ah, yes.  I don't think it can be done because I don't think uscan can
> extract the version from the contents of the file: it needs the URL of
> the wiki page to change with each version and that's not going to
> happen.  I think we have to abandon this goal.

> > We probably need to make emacsen policy more... verbose.
> I agree.  Please feel free to edit the team ikiwiki.

Adding note about xz is on my todo list.

Also, about source package naming. What about emacs-foo? elpa-foo
reveals implementation detail, and just foo introduce
inconsistences/collisions. Let's settle this before upload.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827913: RFS: goto-chg/1.6-1 ITP

[Dmitry Bogatov]

[moved discussion to debian-emacsen. Please, keep me in cc if you
want me to reply]

> > No idea why, but dh-make-elpa (seems to violate debhelper naming
> > convention)
> It does?

My bad. debhelper claims dh_* namespace. But I would find just make-elpa
more intuitive.

> > Adding note about xz is on my todo list.
> >=20
> > Also, about source package naming. What about emacs-foo? elpa-foo
> > reveals implementation detail, and just foo introduce
> > inconsistences/collisions. Let's settle this before upload.
>
> Our current convention is to use the upstream package name for the
> source package name, unless the word is very common and the Emacs
> package is very minor, in which case we use the emacs- prefix.
>
> Are you suggesting we always use the emacs- prefix?  I don't see why we
> would need to do that.  goto-chg is fine in this case.

Because what is minor package or what is very common is subjective?
For example, I would consider 'powerline' neither minor, neither very
common, but, unfortunately, vim team considered same and plain
'powerline' source package name is already occupied.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#828029: RFS: surf/0.7-2~bpo8+1

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for backporting package "surf" with
acknowledgement of Reiner Herrmann 

* Package name: surf
  Version : 0.7-2~bpo8+1
  Upstream Author : Reiner Herrmann 
* Url : http://surf.suckless.org
* Licenses: MIT
  Section : web

It builds those binary packages:

surf -- Simple web browser by suckless community

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

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

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

http://mentors.debian.net/debian/pool/main/s/surf/surf_0.7-2~bpo8+1.dsc

Alternatively, you can access package debian/ directory via git from URL:

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

More information about surf can be obtained from http://surf.suckless.org

Changes since last upload:

  * Rebuild for jessie-backports.

Regards,
  Dmitry Bogatov

Bug#828030: RFS: gdbm/1.12-3

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: gdbm
  Version : 1.12-3
  Upstream Author : bug-g...@gnu.org
* Url : https://gnu.org/software/gdbm
* Licenses: GPL-3+, GFDL-1.3+
  Section : libs

It builds those binary packages:

libgdbm4 -- GNU dbm database routines (runtime version)
libgdbm-l10n -- GNU dbm database routines (translation files)
libgdbm-dev -- GNU dbm database routines (development files)
gdbmtool -- GNU dbm database routines (command line tools)
libgdbm-compat4 -- GNU dbm database routines (legacy support runtime 
version)
libgdbm-compat-dev -- GNU dbm database routines (legacy support development 
files)

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

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

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

http://mentors.debian.net/debian/pool/main/g/gdbm/gdbm_1.12-3.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/gdbm.git

More information about gdbm can be obtained from https://gnu.org/software/gdbm

Changes since last upload:

  * Separate translation files (/usr/share/locale/*) into new binary
package 'libgdbm-l10n' to comply with Policy §8.2 (Closes: #828005)
  * Update homepage link from directory.fsf.org to gnu.org

Regards,
  Dmitry Bogatov

Bug#828030: RFS: gdbm/1.12-3

[Dmitry Bogatov]

> On 2016-06-24 00:19 -0400, Dmitry Bogatov wrote:
> 
> > I am looking for a sponsor for my package "gdbm"
> >
> > Changes since last upload:
> >
> >   * Separate translation files (/usr/share/locale/*) into new binary
> > package 'libgdbm-l10n' to comply with Policy =A78.2 (Closes: #828005)
> Thanks for the fast reaction to that bug report. :-)  There seem to be a
> few minor problems.
>
> Since you are moving files between packages, libgdbm-l10n needs a
> versioned Replaces on libgdbm4 to avoid file conflicts on upgrades.
> Actually the same holds for libgdbm-dev, in 1.12-2 you moved files from
> libgdbm4 to it.

Fixed. But please review carefully.

> The libgdbm-l10n package is "Architecture: all", but libgdbm4 has a
> "Suggests: libgdbm-l10n (=3D ${binary:Version})".  If you want to specify
> a version at all, it should be ${source:Version} instead.

Fixed.

> The package description of libgdbm-l10n says "This package provides
> translations for error messages, generated by library routines".  This
> does not seem to be accurate, it also contains messages from gdbmtool.
> That's why I suggested the package name gdbm-l10n in #828005.

Reworded. Native speaker review is welcome.

New version is on mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#828030: RFS: gdbm/1.12-3

[Dmitry Bogatov]

> The changes in debian/control look good to me, but your changelog says
> you added Breaks when it's actually Replaces.
>
> There is one change in 1.8.3-14 which you have not incorporated, namely
> making libgdbm-dev "Multi-Arch: same".  Please check whether the files
> outside of /usr/lib are identical across architectures and re-add the
> Multi-Arch field if they are.

Fixed. New version on mentors.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827913: RFS: goto-chg/1.6-1 ITP

[Dmitry Bogatov]

> >hash: 73310900c65c7d56fb639868ed574424e9fdbec8
> ERR:
> goto-chg (1.6-1) unstable; urgency=low
> Source: goto-chg-el

Ah, my bad. I am really sorry.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

1. How about using the source package name "emacs-evil"?  I've been
   doing this for my packages where upstream's name is a very generic
   word (e.g. emacs-buttercup), but maybe evil is a significant enough
   package that it can just be "evil", I'm not sure.  Your judgement.

Renamed as evil-el

2. In d/copyright, I think you need to specify copyright years for the
   copyright holders.  Just their names is not enough, since on a desert
   island ~60 years from now with no newer versions of evil available
   for download, the code would become public domain :)  (well, I guess
   the old version of the code would be public domain on the mainland too)

Unfortunately, upstream maintains only list of contributors. So seems
best thing we can do is to count 60 years from last debian upload.

3. Any particular reason you are using gz and not xz compression in
   gbp.conf?  Also, it might be a good idea to check the tarball into
   git with pristine-tar so that a sponsor has exactly the same one (I
   generated my own for testing).

No. Moved to xz.

4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
   the tests for you, though you'll probably need to give it some hints.
   See dh_elpa_test(1) for how to do this: basically, raise to compat
   level 10 and then set DH_ELPA_TEST_* env vars.

Tests want tty on stdin. Added note and disabled tests. Any good
ideas, how to run them in background?

5. Please add a d/watch.

Problem. Mercurial upstream repository, and tarballs are named not
after version, but after hashes. I fail to extract anything useful
from this page: [1]

[1] https://bitbucket.org/lyro/evil/downloads

PS. Your email formatting is amazing. Thank you.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> The function `evil-mode' doesn't seem to be properly autoloaded.
> I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> evil-mode is not available.  However, if I type M-x describe-function
> RET evil-mode RET it works.  Something is going wrong with the
> autoloading.

I think I fixed it. Please, check.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> * Dmitry Bogatov , 2016-06-27, 17:32:
> >Mercurial upstream repository, and tarballs are named not after 
> >version, but after hashes. I fail to extract anything useful from this 
> >page: [1]
> >
> >[1] https://bitbucket.org/lyro/evil/downloads

> This seems to work for me:
> version=3
> https://bitbucket.org/lyro/evil/downloads .*/get/([0-9.]+)[.]tar[.]gz

Thanks a lot. Pushed.

In general, do we have any script, that automates process of writing
watch files? Every time I need to write watch file for github, I
copy-and-paste from comments in /usr/bin/uscan.

If not, it may be useful addition to devscripts.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> On Mon, Jun 27, 2016 at 05:32:32PM +0300, Dmitry Bogatov wrote:
> > 2. In d/copyright, I think you need to specify copyright years for the
> > copyright holders.  Just their names is not enough, since on a desert
> > island ~60 years from now with no newer versions of evil available for
> > download, the code would become public domain :) (well, I guess the
> > old version of the code would be public domain on the mainland too)
> > 
> > Unfortunately, upstream maintains only list of contributors. So seems
> > best thing we can do is to count 60 years from last debian upload.
> 
> I'm not sure whether this is likely to be acceptable to the ftp-masters
> or not.  Perhaps someone more experienced on debian-mentors can chime
> in.

Gianfranco, your opinion?

> > > 3. Any particular reason you are using gz and not xz compression in
> > >gbp.conf?  Also, it might be a good idea to check the tarball into
> > >git with pristine-tar so that a sponsor has exactly the same one (I
> > >generated my own for testing).
> > No. Moved to xz.
> I still don't see a pristine-tar branch :)

Do not understand. I alread have tarball content, as I downloaded
it at 'upstream/1.2.12'. What more we need?

> > 4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
> >the tests for you, though you'll probably need to give it some hints.
> >See dh_elpa_test(1) for how to do this: basically, raise to compat
> >level 10 and then set DH_ELPA_TEST_* env vars.
> > 
> > Tests want tty on stdin. Added note and disabled tests. Any good
> > ideas, how to run them in background?

> It's unlikely that the tty issue is the problem: ERT tests are supposed
> to be runnable in batch mode.  Although perhaps evil is different.

> First, though, we need to fix your dh_elpa_test usage.  You don't need
> DH_ELPA_TEST_ERT_EVAL: dh_elpa_test will automatically load that file
> because it contains ERT test definitions.  Instead, you need to use
> DH_ELPA_TEST_ERT_HELPER to call `evil-test-initialise' as upstream's
> Makefile does.

Here is script, that does same as dh_elpa_test:

emacs -batch -Q -L . --eval "(require 'evil)" -l package \
  --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" \
  --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa-src\")" \
  -f package-initialize \
  -L . \
  -l evil-tests.el \
  -l lib/ert.el \
  -L lib \
  -f evil-tests-initialize

It reports 22 failures. If I replace -batch with -nw, all tests
passes. So seems tty is really needed, but I do not understand why.

> > 5. Please add a d/watch.
> > 
> > Problem. Mercurial upstream repository, and tarballs are named not
> > after version, but after hashes. I fail to extract anything useful
> > from this page: [1]
> > 
> > [1] https://bitbucket.org/lyro/evil/downloads
> Ah.  Seems that we're out of luck: uscan can't do Mercurial tags.

Jakub Wilk found solution. Now we have another way to
get tarball.

> > > The function `evil-mode' doesn't seem to be properly autoloaded.
> > > I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> > > evil-mode is not available.  However, if I type M-x describe-function
> > > RET evil-mode RET it works.  Something is going wrong with the
> > > autoloading.
> >
> > I think I fixed it. Please, check.
>
> It seems it wasn't enough.  If I move my .emacs.d out of the way and
> then run it, and M-x evil-mode, I get this:
>
> Error in post-command-hook (evil-repeat-post-hook): (void-function 
> evil-repeat-post-hook)
> Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
> evil-repeat-pre-hook)

Patched it. Check again.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "elisp-slime-nav-el"

* Package name: elisp-slime-nav-el
  Version : 0.9-1
  Upstream Author : Steve Purcell 
* Url : https://github.com/purcell/elisp-slime-nav
* Licenses: GPL-3+
  Section : lisp

It builds those binary packages:

elpa-elisp-slime-nav -- Emacs extension that provide Emacs Lisp code 
navigation

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

http://mentors.debian.net/package/elisp-slime-nav-el

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


http://mentors.debian.net/debian/pool/main/e/elisp-slime-nav-el/elisp-slime-nav-el_0.9-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/elisp-slime-nav.git

More information about elisp-slime-nav-el can be obtained from 
https://github.com/purcell/elisp-slime-nav

Changes since last upload:

  * Initial release (Closes: #828885)

Regards,
  Dmitry Bogatov

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Dmitry Bogatov]

> 1) The links listed on the Vcs-* fields are not valid, so perhaps you
> may want to (a) push your git repo temporarily at another URL, or (b)
> create the repo under collab-maint/ and push your things there.

Thanks. Fixed.

> 2) It seems you forgot to set the distribution to 'unstable' on your
> debian/changelog file.

Correct. Fixed.

> 3) Any reason why you're using debhelper version 10?  It's still
> experimental, so you probably should be using version 9.

Compat 10 is default for emacs packages. dh_elpa_test(1).

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> Try removing the call to dh_auto_build from your override_dh_auto_build.
> It's doing a bunch of byte compilation that is unnecessary because
> dh-elpa will do that later on.

Removed. Nice hint, cut build time.

> On Tue, Jun 28, 2016 at 02:01:41PM +0300, Dmitry Bogatov wrote:
> > In general, do we have any script, that automates process of writing
> > watch files? Every time I need to write watch file for github, I
> > copy-and-paste from comments in /usr/bin/uscan.
>
> There is the uscan manpage, rather than looking at the code, which you
> might consider slightly better.

Okay. Probably worth make some scripting.

> > Do not understand. I alread have tarball content, as I downloaded
> > it at 'upstream/1.2.12'. What more we need?
>
> It just means that your tarball will be different from the one that
> actually gets uploaded by the DD who sponsors the RFS.  Hopefully it is
> not materially different (just timestamps etc.) but I think that
> settings in ~/.gbp.conf could mean a materially different tarball gets
> generated on the DD's machine.  It's a nice safety check if we can check
> out your tarball from the pristine-tar branch.  But not a big deal and
> certainly doesn't block sponsorship.

Ah, found it. Should be there.

> > Here is script, that does same as dh_elpa_test:
> > [...]
> > It reports 22 failures. If I replace -batch with -nw, all tests
> > passes. So seems tty is really needed, but I do not understand why.
>
> This is not what dh_elpa_test is actually running ;)

Well, I was not explicit enough.

> In the worst case, if we can confirm that some of tests really do
> require a tty (it would be good to figure out why -- maybe ask
> upstream?), you can add a patch disabling those tests in particular.

Simple. Replace in upstream Makefile -nw with -batch and get 22 failures.
So I think we should accept it -- no tests for us.

> Nice work.  Have you forwarded the fix upstream?

Too much trouble. To fix it upstream, they have to deal with either:

 * evil-mode is autoloaded, but not as interactive. Status-quo. Usually
   it is okay, since evil-mode is enabled once in .emacs and forever.
 * evil-mode is autoloaded, interactive, but without sane description.
   Ugly.
 * evil mode is autoloaded, interactive and with sane description. Ugliness
   in code.
 * move definition of evil-mode from evil-core.el to evil.el. Ugly code.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Dmitry Bogatov]

> Thanks for your response.  I think this package is almost ready.  Please
> add Forwarded: headers to the patches based on our discussion.

Is it any wat to get best of 'gbp pq' and dep3?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> It would be great if you could make the evil test suite run by using
> dtach.  You won't be able to use dh_elpa_test directly -- maybe you
> could use
> 
> override_dh_elpa_test:
> dtach --foo --bar -- dh_elpa_test
> 
> or just drop to compat level 9 and use override_dh_auto_test.

I elaborated this solution and pushed to master. Following is true:

 * `make test < /dev/null' fails
 * `dpkg-buildpackage -us -uc < /dev/null' is success now. (see 16d89)
 * 'dtach' uses pty(7)
 * default configuration of pbuilder do not provide possibility to allocate
   pty

So, question is whether it is possible to allocate pty on Debian build farm.

> > > Nice work.  Have you forwarded the fix upstream?
> > Too much trouble. To fix it upstream, they have to deal with either:
> >  * evil mode is autoloaded, interactive and with sane description. Ugliness
> >in code.

> Do you know whether the problem if Debian-specific, or if it also arises
> when installing evil from MELPA?

On MELPA everything is smooth.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> > > > > Nice work.  Have you forwarded the fix upstream?
> > > > Too much trouble. To fix it upstream, they have to deal with either:
> > > >  * evil mode is autoloaded, interactive and with sane description. 
> > > > Ugliness
> > > >in code.
> >
> > > Do you know whether the problem if Debian-specific, or if it also arises
> > > when installing evil from MELPA?
> >
> > On MELPA everything is smooth.
>
> Are you sure about this?  I tested myself, and the same problem occurs:
> M-x evil-mode doesn't work, although M-x describe-function evil-mode does.

Yes, I do.

> I consider this an upstream bug.  Although most users will call
> `evil-mode' in their init file, one of the reasons for using the
> package.el packaging format is that a user can just do `M-x
> package-install evil RET M-x evil-mode RET' to quickly try out a new
> mode without doing any config.
>
> Since we have fixed this bug in the Debian package, we ought to forward
> our work upstream.  Since we fixed it by some code in d/rules, we can't
> just send a patch they can apply.  So I suggest that you file an
> upstream bug report, explain what you did to fix the problem for the
> Debian package, and put a link to that bug report in the Forwarded:
> header of the patch and also as a comment in d/rules.

Can you please report upstream yourself? I can't reproduce bug via MELPA.
See:

 * If I build without my patch, the following autoload form will appear in
   evil-autoloads.el

(autoload 'evil-mode "evil")

   Note the lack of third and forth arguments, description and
   interactive markers.

 * With my patch, and before sed, we have following autoload:

(autoload 'evil-mode "evil-core" "\
Toggle Evil-Local mode in all buffers.
With prefix ARG, enable Evil mode if ARG is positive;
otherwise, disable it.  If called from Lisp, enable the mode if
ARG is omitted or nil.

Evil-Local mode is enabled in all buffers where
`evil-initialize' would do it.
See `evil-local-mode' for more information on Evil-Local mode.

\(fn &optional ARG)" t nil)

   Note that "evil-core" is autoloaded -- file where evil-mode is defined,
   but not while evil suite.

 * And here is autoload from my
   ~/.emacs.d/elpa/evil-20160227.711/evil-autoloads.el:

(autoload 'evil-mode "evil" "\
Toggle Evil-Local mode in all buffers.
With prefix ARG, enable Evil mode if ARG is positive;
otherwise, disable it.  If called from Lisp, enable the mode if
ARG is omitted or nil.

Evil-Local mode is enabled in all buffers where
`evil-initialize' would do it.
See `evil-local-mode' for more information on Evil-Local mode.

\(fn &optional ARG)" t nil)

   Everything is perfect. #'evil-mode autoloads whole evil suite.

> Another thing :)  I don't think you need to invoke find(1) in d/rules.
> You can just do something like this:
>
> sed -i 's#foo..' 
> debian/elpa-evil/usr/share/emacs/site-lisp/elpa-src/evil-*/evil-autoloads.el
>
> That's more explicit and easier to understand.

Done.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Dmitry Bogatov]

> > > Thanks for your response.  I think this package is almost ready.  Please
> > > add Forwarded: headers to the patches based on our discussion.
> > Is it any wat to get best of 'gbp pq' and dep3?
> I generally resort to using quilt :(

Added Forwarded: header at bootom of description. It works. If I add it at top,
it will be lost during patch->commit->patch conversion.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#829208: RFS: evil-paredit-el/0.0.2-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "evil-paredit-el"

* Package name: evil-paredit-el
  Version : 0.0.2-1
  Upstream Author : Roman Gonzalez 
* Url : https://github.com/roman/evil-paredit
* Licenses: MIT
  Section : lisp

It builds those binary packages:

elpa-evil-paredit -- emacs extension, integrating evil and paredit

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

http://mentors.debian.net/package/evil-paredit-el

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


http://mentors.debian.net/debian/pool/main/e/evil-paredit-el/evil-paredit-el_0.0.2-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-paredit-el.git

More information about evil-paredit-el can be obtained from 
https://github.com/roman/evil-paredit

Changes since last upload:

  * Initial release (Closes: #829207)

Regards,
  Dmitry Bogatov

Bug#829208: RFS: evil-paredit-el/0.0.2-1 ITP

[Dmitry Bogatov]

> 1. In d/copyright, the license should be called "Expat" not "MIT" since
>"MIT" is ambiguous between several different licenses.

Is it true? AFAIC, there are 3 versions of BSD (2,3,4 clauses) and only
one MIT.

> 2. evil-paredit.el declares a dependency on paredit version "25beta".
>But we have version 24 in Debian.[1]  Have you tested that it works with
>paredit 24?  I have noticed that the current generation of Elisp
>hackers declare dependencies newer than they actually need so maybe
>we are in luck.

Relaxed dependency. Works for me.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

pause command line utility

[Dmitry Bogatov]

Hello!

I need pause utility to keep gpg-agent in foreground:
gpg-agent --use-standard-socket --daemon ./pause

Something like following C program:

#include 

int main (void)
{
return pause();
}

Is there any standard utility for it?

`apt-file find pause' returns only 'pauseme', something related to Tk
window manager. Web search also did not helped. Neither did `dpkg -L
coreutils'.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#829208: RFS: evil-paredit-el/0.0.2-1 ITP

[Dmitry Bogatov]

> > Relaxed dependency. Works for me.
> I had at upstream's commit history and it seems that they have added
> compatibility code so that it works with various versions of paredit.

Which commit?

> You should definitely forward the dependency relaxation upstream: they
> shouldn't be declaring so tight a dependency if they have the
> compatibility code.

It is not problem for MELPA, melpa ships 25beta. Who would benefit
from forwarding?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#829208: RFS: evil-paredit-el/0.0.2-1 ITP

[Dmitry Bogatov]

> >> 1. In d/copyright, the license should be called "Expat" not "MIT" since
> >>"MIT" is ambiguous between several different licenses.
> >
> > Is it true? AFAIC, there are 3 versions of BSD (2,3,4 clauses) and only
> > one MIT.

> Debian uses Expat instead of MIT.  There are unfortunately many "MIT
> licenses" and the interpretation is ambiguous:
> [...]

Yes, you are correct. Fixed debian/copyright.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: pause command line utility

[Dmitry Bogatov]

> > I need pause utility to keep gpg-agent in foreground:
> > gpg-agent --use-standard-socket --daemon ./pause
> >=20
> > Something like following C program:
> >=20
> > #include 
> >=20
> > int main (void)
> > {
> > return pause();
> > }
> >=20
> > Is there any standard utility for it?
>
> I expect tail -f /dev/null to be close enough in behavior to
> pause(3), even though it does something else internally.

Brilliant! Thank you.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: pause command line utility

[Dmitry Bogatov]

> >I expect tail -f /dev/null to be close enough in behavior to
> >pause(3), even though it does something else internally.

> yes, indeed even if it might be not the best in efficiency [1]
> somebody suggested "sleep inf" or "sleep infinity".

Also great. But some implementations of sleep do not support floating
number.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#829208: [PATCH] evil-paredit: relax dependency on paredit

[Dmitry Bogatov]

Hello!

I am now packaging your library evil-paredit for Debain. It declares
dependency on paredit "25beta", but

 * paredit-25beta upstream consider it unstable and advices aganist beeing 
packaged
 * seems evil-paredit works fine with paredit-24
 * seems commits 86d8ab33c, 6eea8638a explicitly add support for older versions 
of paredit

So, please consider patch inlined, that relaxes depedency on paredit till 24.

Also, git-tag'ing releases greatly simplify my work, consider making more tags.

From: Dmitry Bogatov 
Date: Sat, 2 Jul 2016 03:01:58 +0300
Subject: Relax dependency on paredit

25beta advices aganist distribution by APT, but 24 is good enough.
Forwarded: yes
---
 evil-paredit.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/evil-paredit.el b/evil-paredit.el
index 0df87be..99bbe01 100644
--- a/evil-paredit.el
+++ b/evil-paredit.el
@@ -14,7 +14,7 @@

 ;; URL: https://github.com/roman/evil-paredit

-;; Package-Requires: ((evil "1.0.9") (paredit "25beta"))
+;; Package-Requires: ((evil "1.0.9") (paredit "24"))

 ;;; Code:

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#829208: RFS: evil-paredit-el/0.0.2-1 ITP

[Dmitry Bogatov]

> >In my view evil-paredit-el is ready to be uploaded, bar `dch -r`.

Sorry, was out-of-networking. Done 'debchange -r' and pushed as 8d9c4d3.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

libgdbm transition

[Dmitry Bogatov]

Hello!

Some time ago I made gdbm_1.12-3 into experimental, and since it is 
incompatible with
gdbm-1.8 (new soname, separated compat library) I rebuilt all reverse 
depedencies.
Here is my report:

FAIL camldbm_1.0-2.dsc | PATCH
FAIL courier_0.73.1-1.6.dsc
FAIL freeradius_2.2.8+dfsg-0.1.dsc | PATCH
FAIL ifmail_2.14tx8.10-22.dsc | PATCH
FAIL nis_3.17-34.dsc | FTPFS pre-history debhelper
FAIL ntop_5.0.1+dfsg1-2.1.dsc | FTBFS issues with rrd
FAIL ocsigenserver_2.4.0-1.dsc | FTPFS issues with FindLib
FAIL perdition_2.1-2.dsc | PATCH
FAIL python3-stdlib-extensions_3.4.2-1.dsc | FTBFS purely virtual
FAIL qsf_1.2.7-1.dsc | PATCH
FAIL ruby2.3_2.3.1-5.dsc | FTBFS testsuite
FAIL sortmail_2.4-2.dsc | PATCH

Some comments:

  * PATCH means I managed to write patch to make things build. Sometimes it was 
unrelated
to gdbm, but simple enough for me.
  * courier_0.73 fails, but it does not matter, since courier_0.76.1 successes.
  * FTBFS means it fails to build due issues, unrelated to gdbm and I failed to 
make it build
or estimated required work as too huge.

It looks as MBF, but I would like someone more experienced to give advice. 
Also, I am really
surprised by number of FTBFS packages (not due my libgdbm changes). We do not 
have automation
to rebuild packages and file FTBFS bugs, do we?

Below is boring, but pleasant list:

SUCCESS am-utils_6.2+rc20110530-3.2.dsc
SUCCESS avahi_0.6.32~rc+dfsg-1.dsc
SUCCESS clisp_2.49-10.dsc
SUCCESS courier-authlib_0.66.1-1.dsc
SUCCESS courier_0.76.1-3.dsc
SUCCESS couriergrey_0.3.2-5.dsc
SUCCESS elk_3.99.8-4.dsc
SUCCESS fpc_3.0.0+dfsg-6.dsc
SUCCESS freebsd-glue_0.2.22.dsc
SUCCESS fsvs_1.2.6-3.dsc
SUCCESS gauche_0.9.4-6.dsc
SUCCESS gdbm_1.8.3-14.dsc
SUCCESS gnarwl_3.6.dfsg-6.2.dsc
SUCCESS gnu-smalltalk_3.2.5-1.dsc
SUCCESS jwhois_4.0-2.1.dsc
SUCCESS librep_0.92.5-3.dsc
SUCCESS lighttpd_1.4.39-1.dsc
SUCCESS magicrescue_1.1.9-2.dsc
SUCCESS maildrop_2.8.3-0.1.dsc
SUCCESS man-db_2.7.5-1.dsc
SUCCESS metview_4.6.5-4.dsc
SUCCESS mit-scheme_9.1.1-5.dsc
SUCCESS modem-manager-gui_0.0.18-3.dsc
SUCCESS openipmi_2.0.21-1.2.dsc
SUCCESS pam-shield_0.9.6-1.2.dsc
SUCCESS perl_5.22.2-1.dsc
SUCCESS pike7.8_7.8.866-3.dsc
SUCCESS pike8.0_8.0.240-1.dsc
SUCCESS pypy_5.3.1+dfsg-1.dsc
SUCCESS python-stdlib-extensions_2.7.8-2.dsc
SUCCESS sjeng_11.2-8.dsc
SUCCESS slgdbm_1.7.1-4.dsc

Just in case, all patched are attached to this email.

--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io
diff -Nru camldbm-1.0/debian/control camldbm-1.0/debian/control
--- camldbm-1.0/debian/control	2013-12-08 00:08:13.0 +0400
+++ camldbm-1.0/debian/control	2016-06-23 11:59:49.0 +0300
@@ -7,6 +7,7 @@
 Build-Depends:
  debhelper (>= 9),
  libgdbm-dev,
+ libgdbm-compat-dev,
  ocaml-nox,
  ocaml-findlib,
  dh-ocaml
diff -Nru camldbm-1.0/debian/patches/0002-fix-configure-script.patch camldbm-1.0/debian/patches/0002-fix-configure-script.patch
--- camldbm-1.0/debian/patches/0002-fix-configure-script.patch	1970-01-01 03:00:00.0 +0300
+++ camldbm-1.0/debian/patches/0002-fix-configure-script.patch	2016-06-23 11:59:37.0 +0300
@@ -0,0 +1,17 @@
+Description: Fix configure script
+ Script used spoiled $? variable, instead of saved value.
+Author: Dmitry Bogatov 
+Last-Update: 2016-06-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/configure
 b/configure
+@@ -35,7 +35,7 @@ hasgot() {
+   ${CC:-cc} -I$1 -o hasgot.exe hasgot.c $3 $4
+   res=$?
+   rm -f hasgot.c hasgot.exe
+-  return $?
++  return $res
+ }
+ 
+ dbm_include="not found"
diff -Nru camldbm-1.0/debian/patches/series camldbm-1.0/debian/patches/series
--- camldbm-1.0/debian/patches/series	2013-12-08 00:08:29.0 +0400
+++ camldbm-1.0/debian/patches/series	2016-06-23 11:57:58.0 +0300
@@ -1 +1,2 @@
 0001-Improve-Makefile.patch
+0002-fix-configure-script.patch
diff -Nru freeradius-2.2.8+dfsg/debian/control freeradius-2.2.8+dfsg/debian/control
--- freeradius-2.2.8+dfsg/debian/control	2015-09-14 17:38:37.0 +0300
+++ freeradius-2.2.8+dfsg/debian/control	2016-06-23 12:57:35.0 +0300
@@ -8,6 +8,7 @@
  libpam0g-dev,
  libmysqlclient-dev,
  libgdbm-dev,
+ libgdbm-compat-dev,
  libldap2-dev,
  libsasl2-dev,
  libiodbc2-dev,
diff -Nru ifmail-2.14tx8.10/debian/control ifmail-2.14tx8.10/debian/control
--- ifmail-2.14tx8.10/debian/control	2014-07-25 03:38:56.0 +0400
+++ ifmail-2.14tx8.10/debian/control	2016-06-27 10:00:18.0 +0300
@@ -2,7 +2,7 @@
 Section: comm
 Priority: extra
 Maintainer: Marco d'Itri 
-Build-Depends: debhelper (>> 9), gettext, libgdbm-dev, bi

Bug#831370: RFS: dh-runit/0.3

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-runit"

* Package name: dh-runit
  Version : 0.3
  Upstream Author : Dmitry Bogatov 
* Url : 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

dh-runit -- debhelper add-on to handle runit runscripts

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

http://mentors.debian.net/package/dh-runit

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

dget -x 
http://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_0.3.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git

More information about dh-runit can be obtained from 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-runit.git

Changes since last upload:

  * Support for `runlevels'. Now, runscripts are installed for
`runlevel' default, but system adminstrator can create more.

Regards,
  Dmitry Bogatov

Re: Bug#831370: RFS: dh-runit/0.3

[Dmitry Bogatov]

> how are runit features like disabled services (via the "down" file, for
> the case that a service should be visible to runit but not started by
> default)

At bootup (entering stage 2, more correct), every service in /etc/service is 
started.
/etc/service contains symbolic links to /etc/sv/, so if you do not want 
service
to be started at boot, just remove symlink. After boot, you can bring service 
down
via 'sv down '.

You can have arbitrary amount of 'runlevels' -- predefined sets of
services you want to run. See runsvchdir(8).

> log services handled?

Every service process is expected to write logging on it's stdout, which is 
piped
to log/run script. Usually, it invokes `svlogd'. `dh-runit' do not handle 
creating
log directory yet, since so far all it users are tty's, which do not log.

Was my response helpful, or I misunderstood your question?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827090: RFS: runit/2.1.2-4 ITP

[Dmitry Bogatov]

> it appears that it's time for me to let the runit package go, so, hereby
> my acknowledgement to you to adopt the Debian runit package as new
> maintainer.  I'm positively surprised that after all these years
> somebody still is motivated to bring runit integration into Debian
> forward.  It would be wrong to stop that, although I personally prefer
> to simply have my working runit package on my Debian systems, and not
> change the running systems.

With Gerrit's acknowledgement and dh-runit_0.3 in unstable, I ask for
futher review (package uploaded on mentors).

$ dget -ux https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-4.dsc

For what it worth, it boots my system several weeks already.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: Bug#831370: RFS: dh-runit/0.3

[Dmitry Bogatov]

> My question was if log/run is automatically picked up if it exists, or
> needs to be installed with an additional command.

What is done:

 * If you have following line in your PACKAGE.runit

enable debian/runscript-directory PACKAGE

   you will have debian/runscript-directory recursively installed as
   /etc/sv/PACKAGE.  As such, if debian/runscript-directory/log/run
   exists, so will /etc/sv/PACKAGE/log/run.

What is not done:

 * symbolic link /etc/sv/PACKAGE/log/run/main -> /var/log/runit/PACKAGE
   should be created
 * /var/log/runit/PACKAGE should be created
 * trivial 'log/run' script with 'exec svlogd -vv main' content should
   be created automatically, unless already provided by package.

I plan to introduce missing functionality when:

 * runit is actually uploaded to unstable
 * runit-init is actually installable (currently it indirectly
   conflicts with 'init' metapackage)
 * I propose -run patch for package , which need logging.
   (AFAIK, getty does not need logging. At least, fgetty does not.)

If you want to start working on adding runscripts right now, and need
missing functionality, just ask, and I will add it.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#831763: RFS: cdist/4.2.1-1

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: cdist
  Version : 4.2.1-1
  Upstream Author : Nico Schottelius 
* Url : http://www.nico.schottelius.org/software/cdist/
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

cdist -- Usable Configuration Management System
cdist-doc -- Usable Configuration Management System (html documentatin)

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

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

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

dget -x http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.2.1-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git

More information about cdist can be obtained from 
http://www.nico.schottelius.org/software/cdist/

Changes since last upload:

  * New upstream release
  * Refresh patch 'do-not-assume-git-checkout.patch'
  * Removed patches:
- fix-more-spelling-errors.patch: applied upstream
- disable-building-html.patch: no longer needed, since now upstream
  generates html via sphinx
- ensure-reproducible-build.patch: applied upstream
  * New patch: fix-docs-man-Makefile.patch
  * Update debian/watch, check GPG signature
  * Update debian/rules:
  + take advantage of /usr/shake/dpkg/default.mk instead of manual
invocation of 'dpkg-parsechangelog'
  + .gitignore file no longer installed, drop fix
  + remove no longer generated files from clean target
  * Use pybuild debhelper build system
  * Introduce new binary package 'cdist-doc', which contain html
documentation.

Regards,
  Dmitry Bogatov

Bug#831763: RFS: cdist/4.2.1-1

[Dmitry Bogatov]

> E404
Sorry. Forgot. Fixed.

> missing copyrights:
> e.g.
> # 2016 Darko Poljak (darko.poljak at gmail.com)
> # 2015-2016 Steven Armstrong (steven-cdist at armstrong.cc)
Fixed.


> some licenses seems to be GPL-3 only :(
> +Copyright \(C) 2012,2016 Jake Guffey. Free use of this software is
> +granted under the terms of the GNU General Public License version 3 (GPLv3).

Someone forgot or later clause, other copied. Wrote in 'debian/copyright'
about GPLv3-only manpages. Upstream is willing to fix issue.

> W: cdist-doc: wrong-section-according-to-package-name cdist-doc => doc

Fixed.

> I: cdist-doc: possible-documentation-but-no-doc-base-registration

Installed.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#831841: RFS: stterm/0.6-1~bpo8+1

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: stterm
  Version : 0.6-1~bpo8+1
  Upstream Author : Christoph Lohmann (irc __20h__) <2...@r-36.net>
* Url : http://st.suckless.org
* Licenses: MIT, GPL-2+
  Section : x11

It builds those binary packages:

stterm -- suckless tools simple terminal for windowed system

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

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

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

dget -x 
http://mentors.debian.net/debian/pool/main/s/stterm/stterm_0.6-1~bpo8+1.dsc

Alternatively, you can access package debian/ directory via git from URL:

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

More information about stterm can be obtained from http://st.suckless.org

Changes since last upload:

  * Rebuild for jessie-backports.

Regards,
  Dmitry Bogatov

Re: Dealing with "duplicate-font-file" lintian warning

[Dmitry Bogatov]

> I'm updating the "grip" package (bug #832000[1]), which resulted in
> the following lintian warning:
>
> W: grip: duplicate-font-file
> usr/share/grip/grip/static/octicons/octicons.ttf also in
> fonts-octicons
>
> Is there a helper to deal with this kind of issue? Like the
> "sphinxdoc"[2] one, which automatically replaces embedded JS files to
> their respective links? Or should I manually declare a dependency on
> "octions" package and symlink the correspondent font files[3] (as
> there's also other files besides the ".tff")?

`apt-get install dh-linktree`. Usage is simple, documentation is good,
but you can take a look as example at cdist_4.2.1-1.

Unfortunately, dh-linktree is not magic, and you have manually
specify, what you want to replace with symlinks.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#832246: RFS: cligh/0.2-5

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: cligh
  Version : 0.2-5
  Upstream Author : Christopher M. Brannon 
* Url : http://the-brannons.com/software/cligh.html
* Licenses: GPL-3+, BSD-3-clause
  Section : utils

It builds those binary packages:

cligh -- Command-line interface to GitHub

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

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

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

dget -x http://mentors.debian.net/debian/pool/main/c/cligh/cligh_0.2-5.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/cligh.git

More information about cligh can be obtained from 
http://the-brannons.com/software/cligh.html

Changes since last upload:

  * Change section to 'utils'

Regards,
  Dmitry Bogatov