Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

2017-06-12 Thread Sean Whitton
Hello,

On Sun, Jun 11 2017, Nicholas D Steeves wrote:

> I am looking for a sponsor for my package "rich-minority"
>
> Package name : rich-minority Version : 1.0.1-1

Here's a review of bc58ab0a49df6002e4e034cea8c1398fd7407322:

- why not just install README.org as it is?

- the file is not copyright Artur Malabarba.  It looks like he assigned
  copyright to the FSF

- your rationale for uploading to experimental applies to
  smart-mode-line, but why not upload rich-minority to unstable?  Is it
  similarly untested?  Maybe we should just wait a few weeks.

- it might be a good idea to mention diminish.el in the description

-- 
Sean Whitton


signature.asc
Description: PGP signature


Droping v5 extension to library names

2017-06-12 Thread Andreas Tille
Hi,

when libraries were build with gcc 5 'v5' was added to the soversion
inside the library name.  Should this extension be kept even if there is
a new soversion.  For instance for the package libbpp-core2v5 which has
now soversion=3.  Should the new package be named

libbpp-core3v5
or
libbpp-core3

?

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#864202: marked as done (RFS: mercurial-extension-utils/1.3.4-1)

2017-06-12 Thread Debian Bug Tracking System
Your message dated Mon, 12 Jun 2017 18:16:11 + (UTC)
with message-id <766003393.13688637.1497291371...@mail.yahoo.com>
and subject line Re: Bug#864202: RFS: mercurial-extension-utils/1.3.4-1
has caused the Debian Bug report #864202,
regarding RFS: mercurial-extension-utils/1.3.4-1
to be marked as done.

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

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


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

Dear mentors,

I am looking for a sponsor for my package "mercurial-extension-utils"

* Package name: mercurial-extension-utils
  Version : 1.3.4-1
  Upstream Author : Marcin Kasperski 
* URL : http://pypi.python.org/pypi/mercurial_extension_utils
* License : BSD-3-clause
  Section : python

It builds those binary packages:

  mercurial-extension-utils - Contains functions for writing Mercurial 
extensions.

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

http://mentors.debian.net/package/mercurial-extension-utils


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

  dget -x 
http://mentors.debian.net/debian/pool/main/m/mercurial-extension-utils/mercurial-extension-utils_1.3.4-1.dsc

More information about mercurial-extension-utils can be obtained from
http://pypi.python.org/pypi/mercurial_extension_utils

Changes since the last upload:

  * New upstream release.
  * Bump compat level to 10.


Regards,
 Christoph Mathys
--- End Message ---
--- Begin Message ---
Hi,

done
G.




Il Lunedì 5 Giugno 2017 10:45, Christoph Mathys  ha scritto:



Package: sponsorship-requests

Severity: normal


Dear mentors,


I am looking for a sponsor for my package "mercurial-extension-utils"


* Package name: mercurial-extension-utils

  Version : 1.3.4-1

  Upstream Author : Marcin Kasperski 

* URL : http://pypi.python.org/pypi/mercurial_extension_utils

* License : BSD-3-clause

  Section : python


It builds those binary packages:


  mercurial-extension-utils - Contains functions for writing Mercurial 
extensions.


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


http://mentors.debian.net/package/mercurial-extension-utils



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


  dget -x 
http://mentors.debian.net/debian/pool/main/m/mercurial-extension-utils/mercurial-extension-utils_1.3.4-1.dsc


More information about mercurial-extension-utils can be obtained from

http://pypi.python.org/pypi/mercurial_extension_utils


Changes since the last upload:


  * New upstream release.

  * Bump compat level to 10.



Regards,

Christoph Mathys--- End Message ---


Bug#864203: marked as done (RFS: mercurial-keyring/1.1.8-1)

2017-06-12 Thread Debian Bug Tracking System
Your message dated Mon, 12 Jun 2017 18:16:39 + (UTC)
with message-id <2117095245.13762763.1497291399...@mail.yahoo.com>
and subject line Re: Bug#864203: RFS: mercurial-keyring/1.1.8-1
has caused the Debian Bug report #864203,
regarding RFS: mercurial-keyring/1.1.8-1
to be marked as done.

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

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


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

Dear mentors,

I am looking for a sponsor for my package "mercurial-keyring"

* Package name: mercurial-keyring
  Version : 1.1.8-1
  Upstream Author : Marcin Kasperski 
* URL : http://pypi.python.org/pypi/mercurial_keyring
* License : BSD-3-clause
  Section : python

It builds those binary packages:

mercurial-keyring - Mercurial Keyring Extension

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

http://mentors.debian.net/package/mercurial-keyring


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

  dget -x 
http://mentors.debian.net/debian/pool/main/m/mercurial-keyring/mercurial-keyring_1.1.8-1.dsc

More information about mercurial-keyring can be obtained from
http://pypi.python.org/pypi/mercurial_keyring

Changes since the last upload:

  * New upstream release.
  * Bump compat to 10.

Regards,
Christoph Mathys
--- End Message ---
--- Begin Message ---
Hello, done!

G.--- End Message ---


Re: Droping v5 extension to library names

2017-06-12 Thread Mattia Rizzolo
On Mon, Jun 12, 2017 at 08:14:35PM +0200, Andreas Tille wrote:
> For instance for the package libbpp-core2v5 which has
> now soversion=3.  Should the new package be named
> 
> libbpp-core3v5

This no.

> or
> libbpp-core3
> ?

This one is right.



I think this was part of the announcement done back when the v5 suffix
where annouced by Matthias.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Re: Droping v5 extension to library names

2017-06-12 Thread Gianfranco Costamagna
Hi,

>when libraries were build with gcc 5 'v5' was added to the soversion
>inside the library name.  Should this extension be kept even if there is
>a new soversion.  For instance for the package libbpp-core2v5 which has
>now soversion=3.  Should the new package be named
>
>libbpp-core3v5
>or
>libbpp-core3


the latter.
and if you backport libbpp-core-3v5 to jessie-backport (so, with an old-ABI
libstdc++ or whatever), don't forget to rename it back to libpp-core-3)

G.



Bug#863251: marked as done (RFS: node-grunt-known-options/1.1.0-1~bpo8+1)

2017-06-12 Thread Debian Bug Tracking System
Your message dated Mon, 12 Jun 2017 18:21:09 + (UTC)
with message-id <1240051588.13689061.1497291669...@mail.yahoo.com>
and subject line Re: Bug#863251: RFS: node-grunt-known-options/1.1.0-1~bpo8+1
has caused the Debian Bug report #863251,
regarding RFS: node-grunt-known-options/1.1.0-1~bpo8+1
to be marked as done.

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

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


-- 
863251: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "node-grunt-known-options"

 * Package name: node-grunt-known-options
   Version : 1.1.0-1~bpo8+1
   Upstream Author : Grunt Development Team
 * URL : https://github.com/gruntjs/grunt-known-options
 * License : MIT
   Section : web

It builds those binary packages:

  node-grunt-known-options - known options used in Grunt

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


https://mentors.debian.net/package/node-grunt-known-options


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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/node-grunt-known-options/node-grunt-known-options_1.1.0-1~bpo8+1.dsc


Changes since the last upload:

* Rebuild for jessie-backports.

I would like to backport node-grunt-cli to Jessie and this dependency 
needs to be backported first.


Regards,
--- End Message ---
--- Begin Message ---
Hi,

done!

G.--- End Message ---


Bug#864680: RFS: budgie-desktop/10.3.1-2 -- bugfix release for the desktop environment Budgie Desktop

2017-06-12 Thread foss.freedom
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "budgie-desktop"

 * Package name: budgie-desktop
   Version : 10.3.1-2
   Upstream Author : i...@solus-project.com
 * URL : https://github.com/budgie-desktop/budgie-desktop
 * License : LGPL-2.1/GPL2.0
   Section : x11

  It builds those binary packages:

budgie-core - Core package for Budgie-Desktop
 budgie-core-dev - Development package for budgie-desktop
 budgie-desktop - Desktop package for budgie-desktop
 budgie-desktop-doc - documentation files for the budgie-desktop
 gir1.2-budgie-desktop-1.0 - GNOME introspection library for budgie-desktop
 libbudgie-plugin0 - Plugin library for budgie-desktop
 libbudgietheme0 - Theme library for budgie-desktop
 libraven0  - Raven library for budgie-desktop

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

  https://mentors.debian.net/package/budgie-desktop


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.3.1-2.dsc

Notes:

  from the previous upload #862371

Request to consider moving the man-pages to
a) .manpages
b) consider moving the manpages to budgie-desktop

I have - as requested - moved the dh_installman statements in
debian/rules to budgie-core.manpages

When building/testing with lintian, warnings were displayed when the
missing manpages were defined with the binary package budgie-desktop.
This is because the binary package budgie-core actually contains all
the built executables.  Thus I have left the man-pages within the
budgie-core package.

I suppose I could ignore the warning?  or maybe override the lintian
warning?  I would welcome your thoughts here.  For the moment I have
left the man-pages within budgie-core so that the whole build packages
are as lintian free as possible.

The two new patches here are bug-fixes available upstream.  The
"include-menubar-theme.patch" I have included because I would like to
update my other Debian package "budgie-indicator-applet" to utilise
this patch fix but need budgie-desktop to be accepted first [details
of the patch are included within the patch header in debian/patches].
In addition Ubuntu MATE most probably will be requesting sponsorship
of another package soon "vala-panel-appment" and one of the binaries
builds a budgie-desktop applet that will require this patch.

The second patch "0004" I have included here because I want to get
further feedback from testers if indeed this resolves memory leak
issues.

  Changes since the last upload:

* Bug-fix release
* Patches
- include-menubar-theme.patch
correctly style budgie applets that
use a GTK+ MenuBar
- 0004-wm-Purge-old-backgrounds-from-the-cache.patch
resolve memory leak when desktop wallpaper changes
* Packaging Changes:
- simplified debian/rules
manpages moved to budgie-core.manpages; each executable in
budgie-core now includes a manpage which enables users to
man the exe name and additionally resolves lintian issues.
make target and install methods moved to a more their more
appropriate targets, auto_build and auto_install respectively.
deleted erroneous override_dh_prep


  Regards,
   David Mohammed



Bug#864680: marked as done (RFS: budgie-desktop/10.3.1-2 -- bugfix release for the desktop environment Budgie Desktop)

2017-06-12 Thread Debian Bug Tracking System
Your message dated Mon, 12 Jun 2017 20:30:48 + (UTC)
with message-id <82309823.13941378.1497299448...@mail.yahoo.com>
and subject line Re: Bug#864680: RFS: budgie-desktop/10.3.1-2 -- bugfix release 
for the desktop environment Budgie Desktop
has caused the Debian Bug report #864680,
regarding RFS: budgie-desktop/10.3.1-2 -- bugfix release for the desktop 
environment Budgie Desktop
to be marked as done.

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

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


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

  Dear mentors,

  I am looking for a sponsor for my package "budgie-desktop"

 * Package name: budgie-desktop
   Version : 10.3.1-2
   Upstream Author : i...@solus-project.com
 * URL : https://github.com/budgie-desktop/budgie-desktop
 * License : LGPL-2.1/GPL2.0
   Section : x11

  It builds those binary packages:

budgie-core - Core package for Budgie-Desktop
 budgie-core-dev - Development package for budgie-desktop
 budgie-desktop - Desktop package for budgie-desktop
 budgie-desktop-doc - documentation files for the budgie-desktop
 gir1.2-budgie-desktop-1.0 - GNOME introspection library for budgie-desktop
 libbudgie-plugin0 - Plugin library for budgie-desktop
 libbudgietheme0 - Theme library for budgie-desktop
 libraven0  - Raven library for budgie-desktop

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

  https://mentors.debian.net/package/budgie-desktop


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.3.1-2.dsc

Notes:

  from the previous upload #862371

Request to consider moving the man-pages to
a) .manpages
b) consider moving the manpages to budgie-desktop

I have - as requested - moved the dh_installman statements in
debian/rules to budgie-core.manpages

When building/testing with lintian, warnings were displayed when the
missing manpages were defined with the binary package budgie-desktop.
This is because the binary package budgie-core actually contains all
the built executables.  Thus I have left the man-pages within the
budgie-core package.

I suppose I could ignore the warning?  or maybe override the lintian
warning?  I would welcome your thoughts here.  For the moment I have
left the man-pages within budgie-core so that the whole build packages
are as lintian free as possible.

The two new patches here are bug-fixes available upstream.  The
"include-menubar-theme.patch" I have included because I would like to
update my other Debian package "budgie-indicator-applet" to utilise
this patch fix but need budgie-desktop to be accepted first [details
of the patch are included within the patch header in debian/patches].
In addition Ubuntu MATE most probably will be requesting sponsorship
of another package soon "vala-panel-appment" and one of the binaries
builds a budgie-desktop applet that will require this patch.

The second patch "0004" I have included here because I want to get
further feedback from testers if indeed this resolves memory leak
issues.

  Changes since the last upload:

* Bug-fix release
* Patches
- include-menubar-theme.patch
correctly style budgie applets that
use a GTK+ MenuBar
- 0004-wm-Purge-old-backgrounds-from-the-cache.patch
resolve memory leak when desktop wallpaper changes
* Packaging Changes:
- simplified debian/rules
manpages moved to budgie-core.manpages; each executable in
budgie-core now includes a manpage which enables users to
man the exe name and additionally resolves lintian issues.
make target and install methods moved to a more their more
appropriate targets, auto_build and auto_install respectively.
deleted erroneous override_dh_prep


  Regards,
   David Mohammed
--- End Message ---
--- Begin Message ---
Hi,

>When building/testing with lintian, warnings were displayed when the
>missing manpages were defined with the binary package budgie-desktop.
>This is because the binary package budgie-core actually contains all
>the built executables.  Thus I have left the man-pages within the
>budgie-core package.


ack, sponsored!

G.--- End Message ---


Bug#864688: RFS: xtensor/0.10.4-1

2017-06-12 Thread Ghislain Vaillant
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: xtensor
  Version : 0.10.4-1
  Upstream Author : Johan Mabille, Sylvain Corlay and Wolf Vollprecht
* URL : http://quantstack.net/xtensor
* License : BSD
  Section : libs

One can check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/xtensor.git

Changes since the last upload:

  * New upstream version 0.10.4

Best regards,
Ghis



build-depends on a _source_ package ?

2017-06-12 Thread Benoît Rouits
Hello dear mentors,

This must be a frequently asked question over the years, sorry:

I built recently a binary package of a specific plugin for qtcreator,
on Debian Stretch, but this requires the source (package) of qtcreator
in order to build. As Debian Stretch has no qtcreator-dev, i had to
apt-get source qtcreator.

I don't know how to automate build dependency to a _source_ package,
since the -dev does not (or seems not to) exist, at least in
Stretch.

Is there a solution ? Should i file a bug on WNPP to ask for a
qtcreator-dev package in order to have qtcreator source installed in
/usr/src ?

Thank you for your advices,
 Benoît



signature.asc
Description: OpenPGP digital signature


Re: Droping v5 extension to library names

2017-06-12 Thread Rene Engelhard
Hi,

On Mon, Jun 12, 2017 at 08:14:35PM +0200, Andreas Tille wrote:
> when libraries were build with gcc 5 'v5' was added to the soversion
> inside the library name.  Should this extension be kept even if there is
> a new soversion.  For instance for the package libbpp-core2v5 which has
> now soversion=3.  Should the new package be named
> 
> libbpp-core3v5
> or
> libbpp-core3
> 
> ?

You can drop it.[1]

Regards,

Rene

[1] gcc 7 will change stuff AGAIN. No idea about what exactly is affected, but
I've already seen some cases. No idea about the suffix to-be-used then 
either.
Will probably be some time to come and hopefully with proper announcement 
etc.



Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

2017-06-12 Thread Nicholas D Steeves
On Mon, Jun 12, 2017 at 02:13:02PM +0100, Sean Whitton wrote:
> Hello,
> 
> On Sun, Jun 11 2017, Nicholas D Steeves wrote:
> 
> > I am looking for a sponsor for my package "rich-minority"
> >
> > Package name : rich-minority Version : 1.0.1-1
> 
> Here's a review of bc58ab0a49df6002e4e034cea8c1398fd7407322:
> 
> - why not just install README.org as it is?

My rationale is that in a worst-case scenario where I forget to
implement Policy 12.4 someone will file a bug like "Where is the
upstream README?"  Would it be better to ship README.org and file a
bug against the package myself?  I still don't have a plan for Policy
12.4, and am currently wondering if further conversion of README.html
to README using html2txt (if pandoc cannot do this) would be best,
because the expectation is that the upstream README found in
/usr/share/doc is a plain text file.

> - the file is not copyright Artur Malabarba.  It looks like he assigned
>   copyright to the FSF

So this?:

- Copyright: 2014, 2015 Free Software Foundation, Inc.
-2014-2016 Artur Malabarba 

+Copyright: 2014-2016 Free Software Foundation, Inc.
+ 

> - your rationale for uploading to experimental applies to
>   smart-mode-line, but why not upload rich-minority to unstable?  Is it
>   similarly untested?  Maybe we should just wait a few weeks.

If you'd prefer I'd be happy to wait a few weeks.  In terms of
worst-case scenario planning: If for some reason smart-mode-line
upstream didn't add emacs26 compatibility in time for Buster's freeze,
and I (or someone from pkg-emacsen) didn't have time to add it, then
should rich-minority still be part of Buster?

> - it might be a good idea to mention diminish.el in the description

How many lines can I dedicate to this?  By my count I need to
summarise the following in five lines, and the most salient additions
are the mention of diminish.el, plus compare/contrast by adding what I
suspect are the two most salient points.
  * "/missing/...quick and simple replacement functionality"
  * the addition of "It accepts *regexps* instead of [individual 
specifications]".

These two points seem contradictory to me.  Do you know how
diminish.el is more quick and simple?  Also, can I use your answer for
a patch against the upstream description, because I might not be the
only one who's not confused about this.  Failing that, I can open an
upstream issue/request for clarified description.

;; Comparison to Diminish
;; ──
;;
;;   Diminish is an established player in the mode-line world, who also
;;   handles the minor-modes list. What can rich-minority /offer in
;;   contrast/?
;;
;;   • rich-minority is more versatile:
;; 1. It accepts *regexps*, instead of having to specify each
;;minor-mode individually;
;; 2. It also offers a *whitelist* behaviour, in addition to the
;;blacklist;
;; 3. It supports *highlighting* specific minor-modes with completely
;;arbitrary text properties.
;;   • rich-minority takes a cleaner, functional approach. It doesn’t hack
;; into the `minor-mode-alist' variable.
;;
;;   What is rich-minority /missing/?
;;
;;   1. It doesn’t have a quick and simple replacement functionality yet.
;;  Although you can set the `display' property of a minor-mode to
;;  whatever string you want and that will function as a replacement.
;;   2. Its source comments lack [Will Mengarini’s poetry]. :-)


Thank you for the critique and pointers!
Cheers,
Nicholas


signature.asc
Description: Digital signature


pandoc example for implementing Policy 12.4

2017-06-12 Thread Nicholas D Steeves
Dear Mentors,

Would someone please point me to an example package that shows the
correct way to override or use a special
debian/package.convert-list-of-files-to-convert-to-html
debian/package.convert-list-of-files-to-convert-to-plain-text
debian/package.convert-list-of-files-to-info-pages
etc.
info/man pages and convert documentation out of markdown format.  I'm
trying to comply with Policy 12.4 regarding converting README.org to
README.html, because README.org is markdown.

I guess it's also arguable that README.html should be further
converted using html2text, if pandoc can't do that...

Also, I'd be happy to write documentation on how to implement Policy
12.4 after learning by example.  Of course, if someone has already
written such documentation, please point me there.

Please CC me in all replies.

Sincerely,
Nicholas


signature.asc
Description: Digital signature


Bug#864702: RFS: galternatives/0.13.6 [ITA]

2017-06-12 Thread Boyuan Yang
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org

Dear mentors and chinese-developers folks,

I am looking for a sponsor for adopted package "galternatives"

 * Package name: galternatives
   Version : 0.13.6
   Upstream Author : [not active anymore]
 * URL : [defunct]
 * License : GPL-1+
   Section : admin

It builds those binary package(s):
galternatives - graphical setup tool for the alternatives system

Unfortunately mentors.d.o upload is temporarily 403 here, so one can download 
the package with dget using:

http://debomatic-amd64.debian.net/debomatic/unstable/pool/
galternatives_0.13.6/galternatives_0.13.6.dsc

Or please use git repository on Alioth.d.o:

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

Changes since last upload:

galternatives (0.13.6) unstable; urgency=medium

  * Adopt package. (Closes: #856289)
  * Fix the bug that properties subwindow become blank.
(Closes: #325172)
  * Apply "wrap-and-sort -abst".
  * d/compat: bump to v10.
  * d/menu: drop obsoleted xpm file and menu file.
  * debian/control:
+ Bump Standards-Version to 3.9.8. (No changes needed)
+ Bump dependency to debhelper to 10~.
+ Write collab-maint url for Vcs-*.
  * d/copyright: rewrite with machine-readable format.
- Explicitly mark license as GPL-1+ since original declaration
  only said "GPL".
  * d/rules:
+ Fix grammar for "dh" tool.
  * translation:
+ Refresh translations.
+ Add Simplified Chinese translation.
  * add a .gitignore file for .mo files.
  * bump "galternatives" python package version to 0.13.6.
  * remove obsoleted line for "list-mos.sh" in setup.py.

Regards,
Boyuan Yang

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


Re: pandoc example for implementing Policy 12.4

2017-06-12 Thread Russ Allbery
Nicholas D Steeves  writes:

> Would someone please point me to an example package that shows the
> correct way to override or use a special
> debian/package.convert-list-of-files-to-convert-to-html
> debian/package.convert-list-of-files-to-convert-to-plain-text
> debian/package.convert-list-of-files-to-info-pages
> etc.
> info/man pages and convert documentation out of markdown format.  I'm
> trying to comply with Policy 12.4 regarding converting README.org to
> README.html, because README.org is markdown.

> I guess it's also arguable that README.html should be further
> converted using html2text, if pandoc can't do that...

So, I think it's entirely fine to just install README.org as-is as text
documentation, since that's part of the point of Markdown: to not require
any special formatting.  That satisfies Policy.

But if you *really* want to provide an HTML version for some reason,
multimarkdown < README.org > README.html does a pretty good job (probably
redirecting it to some path under the staging area for building the new
package).

BTW, are you sure that this is in Markdown?  org-mode is something else
that isn't necessarily Markdown

-- 
Russ Allbery (r...@debian.org)   



Re: build-depends on a _source_ package ?

2017-06-12 Thread Christian Seiler
Hi,

On 06/12/2017 11:05 PM, Benoît Rouits wrote:
> Is there a solution ? Should i file a bug on WNPP to ask for a
> qtcreator-dev package in order to have qtcreator source installed in
> /usr/src ?

Do you need the entire source of Qt Creator or just some header files?

In either case, you can only build-depend on binary packages, so that
you will need to ask the Qt Creator people to provide an additional
package for you.

If you only need header files, you should ask them to provide a
-dev package with the headers (and potentially .so libraries). If you
need the entire source tree, then you should ask them to provide a
-source package (see e.g. gcc-6-source, glibc-source, linux-source for
examples of this already in the archive) that puts the entire source
tree into /usr/src.

Note that you shouldn't open a bug on WNPP, but rather a bug on the
qtcreator package itself, severity wishlist, requesting this.

Hope that helps.

Regards,
Christian