Re: Review of firefox-branding-iceweasel

[Charles Plessy]

Le Tue, Apr 19, 2016 at 01:46:46PM -0700, Sean Whitton a écrit :
> 
> "Every package must be accompanied by a verbatim copy of its copyright
> information and distribution license in the file
> /usr/share/doc/package/copyright."
> 
> It then makes an *exception* to this verbatim rule:
> 
> "Packages distributed under the Apache license (version 2.0), the
> Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
> (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should
> refer to the corresponding files under /usr/share/common-licenses,
> rather than quoting them in the copyright file."
> 
> Since you are not using /usr/share/common-licenses, your package doesn't
> fall under this exception and so you need to include it in your
> d/copyright file.

Hi all,

actually, the MPL-2 will be added to /user/share/common-licenses when a Policy
Editor will find time to make it happen.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768292

So I suggest that it is fine to be forward-compatible with the future Policy :)

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 20.04.2016 um 00:53 schrieb Ben Finney:
> On 19-Apr-2016, Markus Koschany wrote:
>> thanks for your update. There are only a few things left before we can
>> upload the package.
> 
> Thank you for working with me on this.
> 
>> My main concern is the adventure-common binary package because I
>> don't believe that shipping advent.dat with an extra package is very
>> useful at the moment.
> 
> Would you decline to upload on that basis? I appreciate you don't
> think there's a benefit, but is there any appreciable harm from having
> the ‘adventure-common’ package?
> 
>> I think it is cool to have a modern Python3 version but it would be
>> rather boring to have identical versions that simply reuse the same
>> story from advent.dat.
> 
> My thinking is that the Python 3 package is rather idiosyncratic, and
> that I'd like to make it clear the common files are available for
> different ports from the original Fortran program.
> 
> I'm not going to insist, but I'd like to know whether you think this
> structure is harmful, or only that this isn't the style you would
> choose.

I think the word harmful is a bit too strong but I don't think that your
current approach is beneficial either. The rationale for providing
multiple binary packages is that users should be able to install a
subset of an application and save some disk space. In this case they
always have to install both packages because otherwise the game would be
broken. It would be a different case if they already had a choice and
could choose between different variants.

Games often provide a significant amount of data and media files and
then it really makes sense to split off the data into some arch:all
-data or -common package when the architecture dependent data is small
compared to the arch-indep part. It would have been extremely wasteful,
if I hadn't done that for freeorion. (C++ game, -data package ~150 MB)
but in your case the game is already arch:all instead of arch:any and
adventure-common is even smaller than colossal-cave-adventure. So
another variable must be taken into account: metadata. Every binary
package in Debian's archive produces metadata and _every_ user has to
fetch this information, for instance with apt when doing a daily update.
In your case the performance penalty (even when it's rather small) is
greater than the advantage of having a separate -common package which
could be reused for a potential and not yet packaged adventure variant.

And last but not least the ftp team once rejected an extra -doc package
for the game njam because it was very small and insisted to merge it
into the -data package. The funny part is that my sponsor back then
thought it was a good idea, so the situation was kind of reversed.

I wouldn't decline to upload but you should take this wall of text into
consideration. In my opinion you can always split the package later when
a potential port might require it.

[...]
>> and that we use cgit for better performance.
> 
> Recently, the default browser on Alioth was switched to Cgit. So,
> at  the Cgit
> browser is presented.

Indeed they redirect all requests now. I don't know if that comes with a
performance penalty though. I wonder why we need two fields, Vcs-Browser
and Vcs-Git, if they are identical...

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Seeking Sponsors for my package - roadfighter

[Paul Wise]

On Mon, 2016-04-18 at 01:15 -0300, Carlos Donizete Froes wrote:

> I would like to help in this case.

Only make changes by sending upstream patches and getting them to
release new versions. If they don't respond you can include the patches
in the debian/patches/ directory.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Re: Bug#821270: RFS: firefox-branding-iceweasel/0.3.0 [ITP] -- Preserves Iceweasel branding for new Firefox packages

[Adam Borowski]

On Wed, Apr 20, 2016 at 10:42:04AM +0800, Paul Wise wrote:
> On Mon, 2016-04-18 at 14:31 +, nord-stream wrote:
> 
> > Technically a Firefox extension cannot change this. It's a .desktop
> > file's job, I assume. But can we replace a .desktop file from another
> > package? Adding extra files to be installed also complicates rules a
> > lot.
> 
> I think this would have to be handled in the iceweasel package:

Alternatively, you can dpkg-divert the .desktop file.  Just remember to
undivert it back when the extension is being removed.

-- 
A tit a day keeps the vet away.

Re: Review of firefox-branding-iceweasel

[Sean Whitton]

Hello,

On Wed, Apr 20, 2016 at 10:47:05AM +0800, Paul Wise wrote:
> On Wed, Apr 20, 2016 at 4:46 AM, Sean Whitton wrote:
> 
> > Yes, it should definitely be xul-ext-iceweasel-branding -- that's
> > pkg-mozext policy for anything that appears in about:addons.  dh_xul-ext
> > assumes that your package is called xul-ext-foo, and it will generate a
> > Provides: entry for firefox-foo.
> 
> The package name was suggested by Mozilla folks:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

As far as I can see the person making that suggestion is not a part of
the pkg-mozext team, though.  And it's in the (draft) group policy:
https://wiki.debian.org/Mozilla/ExtensionsPolicy

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Review of firefox-branding-iceweasel

[Paul Wise]

On Wed, Apr 20, 2016 at 4:46 AM, Sean Whitton wrote:

> Yes, it should definitely be xul-ext-iceweasel-branding -- that's
> pkg-mozext policy for anything that appears in about:addons.  dh_xul-ext
> assumes that your package is called xul-ext-foo, and it will generate a
> Provides: entry for firefox-foo.

The package name was suggested by Mozilla folks:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

> How about adding a new file /usr/share/applications/iceweasel.desktop
> that launches firefox with the old icon?  This would make this extension
> conflict with iceweasel, but I think that would be okay so long as you
> added a Conflicts: line in d/control.

I think it would be best to handle this in the iceweasel package instead.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#821270: RFS: firefox-branding-iceweasel/0.3.0 [ITP] -- Preserves Iceweasel branding for new Firefox packages

[Paul Wise]

On Mon, 2016-04-18 at 14:31 +, nord-stream wrote:

> Technically a Firefox extension cannot change this. It's a .desktop
> file's job, I assume. But can we replace a .desktop file from another
> package? Adding extra files to be installed also complicates rules a
> lot.

I think this would have to be handled in the iceweasel package:

pabs@chianamo ~ $ dpkg -L iceweasel 
/.
/usr
/usr/bin
/usr/share
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/iceweasel
/usr/share/applications
/usr/share/applications/iceweasel.desktop
/usr/share/doc
/usr/share/doc/iceweasel
/usr/share/doc/iceweasel/copyright
/usr/share/doc/iceweasel/MPL-1.1.gz
/usr/share/doc/iceweasel/MPL-2.0.gz
/usr/share/doc/iceweasel/changelog.Debian.gz
/usr/bin/iceweasel
pabs@chianamo ~ $ grep -i exec /usr/share/applications/iceweasel.desktop
Exec=firefox-esr %u
pabs@chianamo ~ $ grep -i icon /usr/share/applications/iceweasel.desktop
Icon=firefox-esr
pabs@chianamo ~ $ ls -l /usr/bin/iceweasel
lrwxrwxrwx 1 root root 30 Apr 13 10:13 /usr/bin/iceweasel -> 
../lib/firefox-esr/firefox-esr*

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

On 19-Apr-2016, Markus Koschany wrote:
> thanks for your update. There are only a few things left before we can
> upload the package.

Thank you for working with me on this.

> My main concern is the adventure-common binary package because I
> don't believe that shipping advent.dat with an extra package is very
> useful at the moment.

Would you decline to upload on that basis? I appreciate you don't
think there's a benefit, but is there any appreciable harm from having
the ‘adventure-common’ package?

> I think it is cool to have a modern Python3 version but it would be
> rather boring to have identical versions that simply reuse the same
> story from advent.dat.

My thinking is that the Python 3 package is rather idiosyncratic, and
that I'd like to make it clear the common files are available for
different ports from the original Fortran program.

I'm not going to insist, but I'd like to know whether you think this
structure is harmful, or only that this isn't the style you would
choose.


> colossal-cave-adventure.desktop: error: (will be fatal in the future):
> value "colossal-cave-adventure.png" for key "Icon" in group "Desktop
> Entry" is an icon name with an extension, but there should be no
> extension as described in the Icon Theme Specification if the value is
> not an absolute path

I didn't see that part of the specification, thank you.

> Please change the Vcs fields […] so that the name of the git
> repository is identical to the source package name

Okay. The name ‘pkg-python-adventure’ was originally chosen because
the repository had only the Debian packaging, like other ‘pkg-foo’
repositories. I will re-name it now that the repository also contains
the upstream code.

> and that we use cgit for better performance.

Recently, the default browser on Alioth was switched to Cgit. So,
at  the Cgit
browser is presented.

> There is a authoritative list of virtual package names (yeah,
> bureaucracy in Debian is wonderful)
> 
> https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
> 
> Please follow the procedure outlined in this text file

Great, I didn't know that existed :-) I will follow that procedure.

-- 
 \“I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__) Friday. That way you still have the weekend.” —Steven Wright |
Ben Finney 


signature.asc
Description: PGP signature

Bug#817949: RFS: niceshaper/1.2.2-1 [ITP]

[Mariusz Jedwabny]

Hello,

I've just uploaded 1.2.2-2 version.

Changes since the last upload:

niceshaper (1.2.2-2) unstable; urgency=low

  * Move iptables from Depends to Recommends.
  * debian/copyright: point out that src/libnetlink.* is GPL-2+ (not GPL-2).
  * Bump Standards-Version to 3.9.8, no changes needed.

 -- Mariusz Jedwabny   Sun, 17 Apr 2016 20:59:23 +0200


On 15.04.2016 15:29, Gianfranco Costamagna wrote:

Hi again,


niceshaper (1.2.2-1) unstable; urgency=low


*one* single entry.
niceshaper (1.2.2-1) unstable; urgency=low


* Initial foo release closes: bar

signature.

that's all.


This signature is already there in the changelog, it was added to 
initial 1.0.0-2 version.


now it seems to be 3.9.8 :)


True:)

Bumped.



I would like, at least for now, to stay with exactly GPLv2 - without
option of v2.2 or v3.x or whatever.


licensecheck * -r |grep GPL |grep -v debian

src/libnetlink.h: *No copyright* GPL (v2 or later)
src/libnetlink.cc: *No copyright* GPL (v2 or later)


so your sources are wrong.
(at least they are missing from copyright file)




I've added paragraph about src/libnetlink.* files to debian/copyright, 
to inform that these are licensed under GPL-2+

and who are the authors.

Just to explain. These two files are originated from iproute2, wrapped 
into a C++ class by another author and, at the end,

adapted to NiceShaper needs by me.
Unfortunately, there was never "Copyright" clause in these files, only 
GPL-2+ license header text and Author fields.

There is still no such clause in original iproute2 source.
So, I hope I made the best what I could.

Regards
Mariusz Jedwabny

Bug#821260: RFS: python-adventure/1.4-1 [ITP], Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Hello Ben,

thanks for your update. There are only a few things left before we can
upload the package. My main concern is the adventure-common binary
package because I don't believe that shipping advent.dat with an extra
package is very useful at the moment. As a compromise I offer you help
in resolving future issues with possibly other adventure variants in
Debian. However I expect that they will a) just ship the file with their
own package and b) it is rather unlikely that we will see another
implementation of the original adventure game in Debian. I think it is
cool to have a modern Python3 version but it would be rather boring to
have identical versions that simply reuse the same story from advent.dat.

Please fix

colossal-cave-adventure.desktop: (found with desktop-file-validate)

colossal-cave-adventure.desktop: error: (will be fatal in the future):
value "colossal-cave-adventure.png" for key "Icon" in group "Desktop
Entry" is an icon name with an extension, but there should be no
extension as described in the Icon Theme Specification if the value is
not an absolute path

Please change the Vcs fields from:

Vcs-Git:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

Vcs-Browser:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

to

Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-adventure.git
Vcs-Browser:
https://anonscm.debian.org/cgit/collab-maint/python-adventure.git

so that the name of the git repository is identical to the source
package name and that we use cgit for better performance. Please push
the package to collab-maint next time and I will work and upload from there.

Last but not least:

There is a authoritative list of virtual package names (yeah,
bureaucracy in Debian is wonderful)

https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

Please follow the procedure outlined in this text file and post to
debian-devel and CC this RFS bug report. Personally I have no objections
against using the adventure name but it is polite to inform fellow DDs too.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: Review of firefox-branding-iceweasel

[Sean Whitton]

Hello,

On Tue, Apr 19, 2016 at 02:51:35PM +, nord-stream wrote:
> I thought of creating packages named firefox-branding-iceweasel,
> thunderbird-branding-icedove, etc. I am aware of the naming convention,
> but these extensions are not much like extensions but just branding
> packages. (In fact it Provides: xul-ext-iceweasel-branding.)
> Is that naming mandatory? I also found many of xul-ext-* packages do not
> include a single XUL file. (Neither does firefox-branding-iceweasel.)
> More discussion at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

Yes, it should definitely be xul-ext-iceweasel-branding -- that's
pkg-mozext policy for anything that appears in about:addons.  dh_xul-ext
assumes that your package is called xul-ext-foo, and it will generate a
Provides: entry for firefox-foo.

> > - don't install the MPL-* files using debian/docs.  Instead, include
> > the full license text in debian/copyright.
> 
> firefox-esr package seems to do this. Do you mean that it is not
> appropriate for a branding package?

I'm pretty sure that firefox-esr is wrong to do that.  Policy 12.5 says:

"Every package must be accompanied by a verbatim copy of its copyright
information and distribution license in the file
/usr/share/doc/package/copyright."

It then makes an *exception* to this verbatim rule:

"Packages distributed under the Apache license (version 2.0), the
Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
(versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should
refer to the corresponding files under /usr/share/common-licenses,
rather than quoting them in the copyright file."

Since you are not using /usr/share/common-licenses, your package doesn't
fall under this exception and so you need to include it in your
d/copyright file.

Further the machine-readacble copyright specification says "... this
field should either include the full text of the license(s) or include a
pointer to the license file under /usr/share/common-licenses."

> > - on my machine, the package doesn't change the application icon --
> >   see the top of the attached screenshot.  Maybe you can't fix that,
> >   though.
> 
> Not possible with an extension. Doable with a .desktop file, I think.

How about adding a new file /usr/share/applications/iceweasel.desktop
that launches firefox with the old icon?  This would make this extension
conflict with iceweasel, but I think that would be okay so long as you
added a Conflicts: line in d/control.

> The complex part of Makefile is from Iceweasel package. Although most
> extensions' Makefiles just pack files into .xpi, it generates files from
> source files. This tiny override just saved me of hours of studying more
> about customizing dh_xul-ext.

Indeed: most of your Makefile complexity is unavoidable.

However, some reasons why it would be good if you avoided the override:

- it makes it easier for team members working on dh_xul-ext to know
  whether some change they are working on will break this package; and

- more generally, it makes it easier for team members to work on your
  package if files have the standard layout (that's the point of team
  maintenance).

It's not just about a short debian/rules: it makes your package more
standardised overall which is a good thing for your project :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Workaround for "Architecture: any [!armel !armhf]" in debian/control

[Joachim Reichel]

Hi,

background: on armel and armhf Qt is using OpenGL ES, but my package cgal does
not support OpenGL ES (yet). The OpenGL functionality is only needed for some
demos and their support library which are already in separate binary packages.
Therefore I just want to not build the OpenGL-related binary packages on armel
and armhf.

But how can I do that? Putting "Architecture: any [!armel !armhf]" in
debian/control is not supported:

dpkg-source: error: architecture any only allowed on its own (list for package
libcgal-qt5-11 is 'any')

Do I really need to expand the architecture list manually? Why is it supported
in Build-Depends etc., but not in Architecture?

Joachim

Bug#821837: RFS: openresolv/3.8.0-1 [ITA] - - management framework for resolv.conf

[Junior Santos]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: openresolv
   Version : 3.8.0-1
   Upstream Author : Roy Marples 
 * URL : http://roy.marples.name/projects/openresolv/home
 * License : BSD-2-clause
   Section : net

  It builds those binary packages:

openresolv - management framework for resolv.conf

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

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


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

dget -x 
http://mentors.debian.net/debian/pool/main/o/openresolv/openresolv_3.8.0-1.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

* New upstream release
- Fix doesn't work with multiple domains in search,
  they are concatenated. (Closes: #817841)
  * New Maintainer (Closes: #770083)
  * d/patches
- Update resolvconf.8.in-spell
  * d/copyright
- Update copyright



  Regards,
   J.S.Júnior


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Review of firefox-branding-iceweasel

[Gianfranco Costamagna]

Hi,
(just answering the alioth part)
https://qa.debian.org/developer.php?login=pkg-mozext-maintain...@lists.alioth.debian.org
this should be the maintainer

and the account has to be created on alioth.d.o, and then join the group
https://alioth.debian.org/projects/pkg-mozext

cheers,

G.




Il Martedì 19 Aprile 2016 16:51, nord-stream  ha 
scritto:
On 18/04/16 20:20, Sean Whitton wrote:
> The package is mostly fine.  Here are some points:
>
> - binary package name should be xul-ext-iceweasel-branding or similar

I thought of creating packages named firefox-branding-iceweasel,
thunderbird-branding-icedove, etc. I am aware of the naming convention,
but these extensions are not much like extensions but just branding
packages. (In fact it Provides: xul-ext-iceweasel-branding.)
Is that naming mandatory? I also found many of xul-ext-* packages do not
include a single XUL file. (Neither does firefox-branding-iceweasel.)
More discussion at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

> - is it possible to generalise this to restore both icedove and
>   iceweasel branding in one binary package?  (icedove will soon become
>   thunderbird)

It may be possible, but many people use one and not another, so one
binary package may not be desirable. One source package may be a good
idea, though.

> - don't install the MPL-* files using debian/docs.  Instead, include 
>   the full license text in debian/copyright.

firefox-esr package seems to do this. Do you mean that it is not
appropriate for a branding package?

> - as Gianfranco suggested, this should be team maintained.  Your name
>   should be in the Uploaders: field in debian/control, and Maintainer:
>   should be the Mozilla extensions packaging team.  You should upload
>   the git repository to the Mozilla extensions team section of alioth.

That seems right. Please tell me more.

>   Do you have an alioth account?

I don't. What does it mean? I'm willing to do what's needed.

> - the long description is not, IMO, appropriate.  You should include
>   the history of the package in the README.markdown, and just give a
>   terse description of what it does in the long description (or at
>   least in the first paragraph of the long description)

I'll consider this point later.

> - on my machine, the package doesn't change the application icon --
>   see the top of the attached screenshot.  Maybe you can't fix that,
>   though.

Not possible with an extension. Doable with a .desktop file, I think.

On 19/04/16 02:18, Sean Whitton wrote:
> I just took a closer look at your debian/rules file.  You don't need the
> boilerplate.  This is enough:

Done. Will upload later.


> However, since this is a native package, would you consider editing your
> Makefile so that dh_xul-ext can do your whole build for you?  Take a
> look at the source package y-u-no-validate.  It uses this main Makefile
> target:
> 
> ,
> | %:
> | dh $@ --with xul-ext --buildsystem=xul_ext --sourcedirectory=src
> `
> 
> There is an override, but it's just something minor.  This works because
> the source code is organised in a standard way, but your code seems to
> be organised in a non-standard way which is why you need a complex
> Makefile and dh overrides.

The complex part of Makefile is from Iceweasel package. Although most
extensions' Makefiles just pack files into .xpi, it generates files from
source files. This tiny override just saved me of hours of studying more
about customizing dh_xul-ext.

Thank you for reviewing,

--
nord-stream

Re: Review of firefox-branding-iceweasel

[nord-stream]

On 18/04/16 20:20, Sean Whitton wrote:
> The package is mostly fine.  Here are some points:
>
> - binary package name should be xul-ext-iceweasel-branding or similar

I thought of creating packages named firefox-branding-iceweasel,
thunderbird-branding-icedove, etc. I am aware of the naming convention,
but these extensions are not much like extensions but just branding
packages. (In fact it Provides: xul-ext-iceweasel-branding.)
Is that naming mandatory? I also found many of xul-ext-* packages do not
include a single XUL file. (Neither does firefox-branding-iceweasel.)
More discussion at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

> - is it possible to generalise this to restore both icedove and
>   iceweasel branding in one binary package?  (icedove will soon become
>   thunderbird)

It may be possible, but many people use one and not another, so one
binary package may not be desirable. One source package may be a good
idea, though.

> - don't install the MPL-* files using debian/docs.  Instead, include 
>   the full license text in debian/copyright.

firefox-esr package seems to do this. Do you mean that it is not
appropriate for a branding package?

> - as Gianfranco suggested, this should be team maintained.  Your name
>   should be in the Uploaders: field in debian/control, and Maintainer:
>   should be the Mozilla extensions packaging team.  You should upload
>   the git repository to the Mozilla extensions team section of alioth.

That seems right. Please tell me more.

>   Do you have an alioth account?

I don't. What does it mean? I'm willing to do what's needed.

> - the long description is not, IMO, appropriate.  You should include
>   the history of the package in the README.markdown, and just give a
>   terse description of what it does in the long description (or at
>   least in the first paragraph of the long description)

I'll consider this point later.

> - on my machine, the package doesn't change the application icon --
>   see the top of the attached screenshot.  Maybe you can't fix that,
>   though.

Not possible with an extension. Doable with a .desktop file, I think.

On 19/04/16 02:18, Sean Whitton wrote:
> I just took a closer look at your debian/rules file.  You don't need the
> boilerplate.  This is enough:

Done. Will upload later.

> However, since this is a native package, would you consider editing your
> Makefile so that dh_xul-ext can do your whole build for you?  Take a
> look at the source package y-u-no-validate.  It uses this main Makefile
> target:
> 
> ,
> | %:
> | dh $@ --with xul-ext --buildsystem=xul_ext --sourcedirectory=src
> `
> 
> There is an override, but it's just something minor.  This works because
> the source code is organised in a standard way, but your code seems to
> be organised in a non-standard way which is why you need a complex
> Makefile and dh overrides.

The complex part of Makefile is from Iceweasel package. Although most
extensions' Makefiles just pack files into .xpi, it generates files from
source files. This tiny override just saved me of hours of studying more
about customizing dh_xul-ext.

Thank you for reviewing,

--
nord-stream



signature.asc
Description: OpenPGP digital signature

Re: Bug#821270: RFS: firefox-branding-iceweasel/0.3.0 [ITP] -- Preserves Iceweasel branding for new Firefox packages

[nord-stream]

Fixed in Git. I will upload the new package with other proposed changes
soon.

On 18/04/16 18:47, Ben Finney wrote:
> nord-stream  writes:
> 
>> It builds those binary packages:
>>
>>   firefox-branding-iceweasel - Preserves Iceweasel branding for new Firefox 
>> packages
> 
> Please change the description synopsis, to conform to the Developer's
> Reference §6.2.2.
> 
> That entails that it should not be a sentence itself, but a phrase
> describing what the package *is*.
> 
> The synopsis “” should make sense when inserted into a
> sentence of the form “The package  installs .”.
> 
> So a proper sentence is not appropriate as the “”.
> 
> I suggest:
> 
> branding for Firefox to apply Iceweasel name and images
> 

--
nord-stream




signature.asc
Description: OpenPGP digital signature

Bug#821171: RFS: growl-for-linux/0.8.1-2 [ITP]

[dai]

On Sat, Apr 16, 2016 at 06:05:03PM +0900, HAYASHI Kentaro wrote:
> * Package name: growl-for-linux
>   Version : 0.8.1-2

It seems that upstream author already uploads this package into Ubuntu,
Do you talk him about uploading this package into Debian?

>   * debian/copyright
> - Rewrited to machine-readable debian/copyright

typo: Rewrited 

You can use aspell or ispell for spell check.

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc

>   * debian/rules
> - Fixed non-empty-dependency_libs-in-la-file lintian warning
> - Added hardening flags (+all,-pie)
> - Drop deprecated libtweets subscriber

"Drop" is only present tense. Others are past tense.

debian/control:

> Growl For Linux provides four kind of display styles - ballon, fog,

typo: ballon
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#821762: marked as done (RFS: ublock-origin/1.6.8+dfsg-1 -- general-purpose lightweight ads, malware, trackers blocker)

[Debian Bug Tracking System]

Your message dated Tue, 19 Apr 2016 09:46:47 + (UTC)
with message-id <392879146.4869563.1461059207271.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#821762: RFS: ublock-origin/1.6.8+dfsg-1 -- 
general-purpose lightweight ads, malware, trackers blocker
has caused the Debian Bug report #821762,
regarding RFS: ublock-origin/1.6.8+dfsg-1 -- general-purpose lightweight ads, 
malware, trackers blocker
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.)


-- 
821762: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821762
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 an update to ublock-origin.

* Package name: ublock-origin
  Version : 1.6.8+dfsg-1
  Upstream Author : Raymond Hill
* URL : https://github.com/gorhill/uBlock
* License : GPL-3+
  Section : web

Changes since the last upload:

  * Package new upstream release.
  * Explicitly include copyright for Raymond Hill.
  * Updates for upstream's repository reorganisation:
- Patch tools/make-assets.sh
- Update debian/clean-dfsg.sh
- Update debian/copyright
- Explain changes README.source.
  * Bump standards version to 3.9.8 (no changes required).

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/u/ublock-origin/ublock-origin_1.6.8+dfsg-1.dsc

Or build it with gbp:

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

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Hi, sponsoring soon!

G.




Il Martedì 19 Aprile 2016 5:45, Sean Whitton  ha 
scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an update to ublock-origin.

* Package name: ublock-origin
  Version : 1.6.8+dfsg-1
  Upstream Author : Raymond Hill
* URL : https://github.com/gorhill/uBlock
* License : GPL-3+
  Section : web

Changes since the last upload:

  * Package new upstream release.
  * Explicitly include copyright for Raymond Hill.
  * Updates for upstream's repository reorganisation:
- Patch tools/make-assets.sh
- Update debian/clean-dfsg.sh
- Update debian/copyright
- Explain changes README.source.
  * Bump standards version to 3.9.8 (no changes required).

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/u/ublock-origin/ublock-origin_1.6.8+dfsg-1.dsc

Or build it with gbp:

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

Thanks.

-- 
Sean Whitton--- End Message ---

Bug#819395: RFS: stormlib-listfiles/2015-04-20-1 [ITP]

[Gianfranco Costamagna]

Hi,


>There is no more info about it just as it is public domain, no more
>license texts... What to write into paragraph then??


everything is a license, and public domain is a license too.
https://codesearch.debian.net/results/License:%20public-domain/page_0

G.

Bug#819395: RFS: stormlib-listfiles/2015-04-20-1 [ITP]

[Pali Rohár]

On Monday 18 April 2016 22:32:14 Gianfranco Costamagna wrote:
> Still a copyright issue
> 
> W missing-license-paragraph-in-dep5-copyright
> public-domain (paragraph at line 17)

There is no more info about it just as it is public domain, no more
license texts... What to write into paragraph then??

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