Bug#845631: RFS: globjects/1.0.0-2

[Gianfranco Costamagna]

Hi,

>I am looking for a sponsor for my package "globjects"

thanks!

G.

Bug#844608: [Pkg-protobuf-devel] Bug#844608: Looking for sponsor for protobuf NMU

[lumin]

On Thu, 2016-11-24 at 20:39 +0100, László Böszörményi (GCS) wrote:
>  Your changes seem to be correct. I plan to upload the attached diff
> in some hours if you don't mind.

It is now present in unstable. However the buildd status seems bad.

ppc64el due to segfault during python2 test.
kfreebsd-* had never compiled protobuf since 3.x.x release.

armel,armhf,hppa,i386,mips,mipsel,powerpc,x32 failed during python3 test due to 
the same reason:

  Traceback (most recent call last):
File "/«PKGBUILDDIR»/python3/google/protobuf/internal/reflection_test.py", 
line 639, in testIntegerTypes
  TestGetAndDeserialize('optional_uint32', 1 << 31, long)
  NameError: name 'long' is not defined

There is no "long" type in python3, so this is an upstream
py2 -> py3 porting bug. See:

https://github.com/google/protobuf/issues/1504

I looked into protobuf's code at master branch and it seems to be solved:

https://github.com/google/protobuf/blob/master/python/google/protobuf/internal/reflection_test.py#L658-L659
https://github.com/google/protobuf/blob/master/python/google/protobuf/internal/reflection_test.py#L642-L645

Should we consider to cherry-pick the corresponding upstream commit to
Debian's protobuf 3.0.0 package or, to import protobuf 3.1.0
(maybe impossible due to transition freeze) ?

[1] https://buildd.debian.org/status/logs.php?pkg=protobuf=3.0.0-8
[2] https://github.com/google/protobuf/releases

Bug#845308: Sponsoring imagemagick/8:6.8.9.9-5+deb8u6

[Bastien Roucaries]

Can i add a newer patch fixing the last cve ?

Le 25 novembre 2016 17:30:54 GMT+01:00, Luciano Bello  a 
écrit :
>Hi,
>  I will sponsor imagemagick/8:6.8.9.9-5+deb8u6 and release the DSA.
>
>Thanks for you effort of keeping imagemagick secure!
>
>/luciano

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#845308: Sponsoring imagemagick/8:6.8.9.9-5+deb8u6

[Luciano Bello]

Hi,
  I will sponsor imagemagick/8:6.8.9.9-5+deb8u6 and release the DSA.

Thanks for you effort of keeping imagemagick secure!

/luciano

Bug#845308: Sponsoring imagemagick/8:6.8.9.9-5+deb8u6

[Gianfranco Costamagna]

control: owner -1 luci...@debian.org


>  I will sponsor imagemagick/8:6.8.9.9-5+deb8u6 and release the DSA.



thanks!


G.

Bug#845051: marked as done (RFS: freedroidrpg/0.16.1-1 [ITA])

[Debian Bug Tracking System]

Your message dated Fri, 25 Nov 2016 17:15:18 + (UTC)
with message-id <1575959642.885664.1480094118...@mail.yahoo.com>
and subject line Re: Bug#845051: RFS: freedroidrpg/0.16.1-1
has caused the Debian Bug report #845051,
regarding RFS: freedroidrpg/0.16.1-1 [ITA]
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.)


-- 
845051: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845051
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 "freedroidrpg"

 * Package name: freedroidrpg
   Version : 0.16.1-1
   Upstream Author : (long list -- see d/copyright)
 * URL : http://freedroid.org
 * License : GPL-2+
   Section : games

  It builds those binary packages:

freedroidrpg - Isometric RPG influenced by Paradroid
freedroidrpg-data - Data files for freedroidrpg

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


  https://mentors.debian.net/package/freedroidrpg


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/freedroidrpg/freedroidrpg_0.16.1-1.dsc


  I'm taking over an orphaned package, now it is packaged within the 
Debian Games Team git repository:

Vcs-Git: https://anonscm.debian.org/git/pkg-games/freedroidrpg.git
Vcs-Browser: https://anonscm.debian.org/git/pkg-games/freedroidrpg.git

  The last changelog entry reads:
freedroidrpg (0.16.1-1) unstable; urgency=medium

  * Updated d/watch to the new upstream.
  * Updated to new upstream release. (Closes: #799743)
+ The editor is now part of the game. (Closes: #460677)
+ Upstream fixed clang building. (Closes: #758161)
  * Added myself as uploader. (Closes: #826921)
  * Put Debian Games Team as maintainer.
  * Updated standards-version to 3.9.8.
  * Added Vcs-* fields.
  * Updated dh compat to 10.
  * Updated the following Debian patches:
+ 17_debianize.diff
+ 20_enter_keys.diff
+ 27_debug.diff.
  * Added new Debian patches:
+ 01_no_headless_check.diff.
+ 02_accept_mawk.diff.
+ 03_fix_desktop_file.diff.
+ 04_add_keywords_to_desktop_file.diff.
+ 05_fix_manpage.diff.
  * Rewrote debian/copyright, following copyright-format 1.0.

 -- Julien Puydt   Fri, 11 Nov 2016 14:15:08 
+0100



  Thanks,

Snark on #debian-games
--- End Message ---
--- Begin Message ---
Hi,

>I am looking for a sponsor for my package "freedroidrpg"


huge package! :)


Just a little nitpick/issue:

grep CC0 . -R
Binary file ./sound/music/Bleostrada.ogg matches
Binary file ./sound/effects/bot_sounds/voice_samples/51.ogg matches
Binary file ./graphics/droids/autogun/autogun_3.png matches
Binary file ./graphics/droids/420/420_2.png matches
Binary file ./graphics/droids/999/999_4.png matches
Binary file ./graphics/droids/hot_mama/hot_mama_1.png matches
Binary file ./graphics/droids/329/329_1.png matches
Binary file ./graphics/droids/123/123_3.png matches
Binary file ./graphics/droids/bartender/bartender_2.png matches
Binary file ./graphics/items/weapons/laser_pulse_cannon/inv_image.png matches
Binary file 
./graphics/tux_motion_parts/2h_heavy_melee/feet/iso_boots1/iso_boots1_1.png 
matches
Binary file 
./graphics/tux_motion_parts/2h_heavy_melee/torso/iso_robe/iso_robe_1.png matches
Binary file 
./graphics/tux_motion_parts/1hranged/shield/iso_heavy_shield/iso_heavy_shield_1.png
 matches
Binary file ./graphics/tux_motion_parts/1hranged/head/iso_helm1/iso_helm1_1.png 
matches
Binary file 
./graphics/tux_motion_parts/1hranged/torso/iso_armour1/iso_armour1_1.png matches
Binary file 
./graphics/tux_motion_parts/2hranged/feet/iso_boots1/iso_boots1_2.png matches
Binary file 
./graphics/tux_motion_parts/2hranged/weapon/iso_electro_laser_rifle/iso_electro_laser_rifle_2.png
 matches
Binary file ./graphics/floor_tiles/floor_tiles_atlas1.png matches
Binary file ./graphics/obstacles/obstacles_atlas2.png matches
./pkgs/freedesktop/freedroidrpg.appdata.xml:  
CC0-1.0

since the package is huge, and might FTBFS in some archs, lets keep this for a 
next upload
(and I have a good connection now, so the next upload will be source-only and 
without the orig tarball).

Also, autotools-dev is probably useless, but I didn't try to remove it.

cheers,

G.--- End Message ---

Re: Copyright for Autoconf stuff

[Gianfranco Costamagna]

Hi

>(autoconf specific copyrights)

they have special exceptions to be relicensed under another license.

So, if you don't account them specifically they will fall in the common
package license.
Somebody just don't care about them (I don't think it is source of reject by
ftpmasters).

I think mentioning them is worth the effort, but probably you can avoid it, even
if it is appreciate when copyright is the most "open" wrt single files.


G.

Bug#845614: RFS: acorn/4.0.3-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
>https://mentors.debian.net/debian/pool/main/a/acorn/acorn_4.0.3-1.dsc



http://debomatic-amd64.debian.net/distribution#unstable/acorn/4.0.3-1/buildlog

FTBFS

>(2) upstream moved forward very fast and uses rollup to compile itself, 
>but we don't have rollup yet, and rollup needs acorn (and itself!), so 
>I'm using my node-es6-module-transpiler and sed-patch things so they 
>work ; I could check running "acorn foo.js" works for most files in 
>/usr/lib/nodejs (some give errors, but can still be tokenized, so 
>nothing too worrying).
>
>The ultimate goal is to get rollup up and running, boostrapping it with 
>node-es6-module-transpiler. I'm not there yet...


ok, but it needs to build... what about building stages?

look e.g. to gcc bootstrapping
G.

Bug#845614: RFS: acorn/4.0.3-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi
(resending from the correct email)

>https://mentors.debian.net/debian/pool/main/a/acorn/acorn_4.0.3-1.dsc

http://debomatic-amd64.debian.net/distribution#unstable/acorn/4.0.3-1/buildlog

FTBFS


>(2) upstream moved forward very fast and uses rollup to compile itself,
>but we don't have rollup yet, and rollup needs acorn (and itself!), so
>I'm using my node-es6-module-transpiler and sed-patch things so they
>work ; I could check running "acorn foo.js" works for most files in
>/usr/lib/nodejs (some give errors, but can still be tokenized, so
>nothing too worrying).
>
>The ultimate goal is to get rollup up and running, boostrapping it with
>node-es6-module-transpiler. I'm not there yet...
ok, but it needs to build... what about building stages?

look e.g. to gcc bootstrapping, or compilers in general
(note: I don't have knowledge on this topic)


cheers,
G.

Re: Copyright for Autoconf stuff

[Russ Allbery]

wf...@niif.hu (Ferenc Wágner) writes:
> In #832941 Sean Whitton  writes:

>> 6. config.guess, config.sub, configure, configure.in, Makefile.in and
>> install-sh are not accounted for in d/copyright.

> The license and the copyright of these files is pretty much the same all
> the time (some details can depend on the date).  However, tracking this
> all properly in the copyright files of all packages using Autoconf takes
> a huge amount of work.  Is there really no way to redirect all that
> effort towards something productive?  For example by declaring at a
> central place that these files have the usual license and copyright
> unless specified otherwise in debian/copyright, and be done with them?

It's very widespread practice in the archive to not bother documenting the
copyright and license of the build system files that come from Autoconf
and Automake.  I'm sure people have various opinions about the merits of
that, but as long as nothing weird is happening here (upstream adding code
to those files under some weird license), I really doubt that ftp-master
will care, which is the metric that matters the most.  The licenses are
very well-understood and don't pose any interesting issues.

Package sponsors can of course have their own policies, but I'd upload
packages without that documentation, since I think it's a fair amount of
effort for very little gain.  (I have stanzas for those files in some,
although not all, of my packages, but only because I have a half-assed
script that semi-automates it, although not horribly well.)

For those who think it's important to document the licenses of these
files, I would encourage you to work on writing a well-tested and reliable
tool to automatically generate those stanzas (the notices are fairly
consistent and open for that sort of automation) rather than asking people
to do tedious and not very productive manual work.

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

Re: Writing outside of build dir

[Christian Seiler]

On 11/26/2016 01:59 AM, Ross Vandegrift wrote:
> On 11/11/2016 0826:45 AM, Christian Seiler wrote:
>> pbuilder sets the home directory of the pbuilder user to /nonexistent
>> to make sure that builds don't modify files in the home directory,
>> which is forbidden by Debian Policy (for good reason builds are not
>> supposed to change things outside the build directory).
> 
> Could you point me to this policy?  I'd like to learn more, but haven't
> been able to find it.

I just checked and it really isn't in there. OTOH, there have been
bug reports with severity serious about this issue since forever;
a quick search randomly gave me the following reports within 1
minute, and then I stopped looking:

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

My guess is that it probably never got added to policy because
autobuilders fail with similar errors as pbuilder does, so
packages that violate this FTBFS, which is an automatic RC bug,
regardless of policy. And probably also because most people
find this principle so obvious.

Btw. notable exception is /tmp (or $TMPDIR, if that's set), as
long as there is cleanup afterwards. Many compilers tend to use
/tmp for temporary files. (gcc does by default unless you
specify -pipe.)

> Two probably naive questions:
> 
> 1) Why? (I can imagine reasons, but don't want to assume that I know)

Well, because of side effects. Suppose you want to fix a bug in
a package you're using, and there is some patch already available
online, and you just want to rebuild the package with that patch
included, but you don't really understand all details of the
entire build system etc. of the package (even though you might
understand the patch itself) - what if the package then just
modifies configuration in your home directory? Or installs stuff
there? What if your home directory has limited space available
and you're building on a different partition - but then suddenly
the partition with your home directory is full just because of a
package build that has side effects.

There are tons of reasons why builds should be self-contained,
and I think this is something that should IMHO be very obvious.

Also, this is a good practice irrespective of Debian, upstream
packages should do the same in principle. (And most do.) Now in
the case of build systems that have a feature to automatically
download dependencies this is a bit more complicated (because
the user might want that feature), so I understand why upstream
might deviate from that principle in this specific case. [1]
But in general at least I see no reason for any build system to
not be self-contained within the source directory of the package.
(Technically, if the system supports out of tree builds, as
many traditional systems such as automake or cmake do, it should
even be contained in the build directory only and not modify the
source directory at all.)

> 2) Is there a common pattern for handling upstream tests that break this
> rule?  Maybe there's an alternative to disabling them?

If upstream tests do that, I would suggest sending a patch
upstream that fixes them, because especially for tests I
would consider this a bug.

That said, if tests just require stuff in the home directory 
you could set the HOME environment variable to a temporary
directory within the build tree before you run the tests, to
work around this kind of problem. Nevertheless I would consider
those tests buggy and would want to patch them.

If you could give a couple of examples of what exactly you're
thinking of, maybe my answer could be more specific.

Regards,
Christian

[1] But even there I dislike this. I don't think running a build
should install stuff. I could get behind a build system having a
separate command line command for downloading the dependencies
automatically that the user could explicitly call if required,
and maybe a combined command for doing both at the same time,
but I do think that a command to "just build, and fail if deps
not available" should be easily available in any sane build
system, for various reasons. (The famous "dissident test", but
even more trivial things such as being behind a metered
connection.)

Bug#845710: RFS: mongovi/1.0.0-1 [ITP]

[Tim Kuijsten]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: mongovi
  Version : 1.0.0-1
  Upstream Author : me
* URL : https://github.com/timkuijsten/mongovi
* License : ISC
  Section : database

It builds those binary packages:

  mongovi- Command line interface for MongoDB

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


https://mentors.debian.net/package/mongovi


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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mongovi/mongovi_1.0.0-1.dsc


Regards,

Tim

Writing outside of build dir (was: Re: Scala 2.10)

[Ross Vandegrift]

On 11/11/2016 0826:45 AM, Christian Seiler wrote:
> pbuilder sets the home directory of the pbuilder user to /nonexistent
> to make sure that builds don't modify files in the home directory,
> which is forbidden by Debian Policy (for good reason builds are not
> supposed to change things outside the build directory).

Could you point me to this policy?  I'd like to learn more, but haven't
been able to find it.

Two probably naive questions:

1) Why? (I can imagine reasons, but don't want to assume that I know)

2) Is there a common pattern for handling upstream tests that break this
rule?  Maybe there's an alternative to disabling them?

Thanks,
Ross

Re: Writing outside of build dir

[Johannes Schauer]

Hi!

Quoting Christian Seiler (2016-11-26 01:30:59)
> On 11/26/2016 01:59 AM, Ross Vandegrift wrote:
> > Could you point me to this policy?  I'd like to learn more, but haven't
> > been able to find it.
> I just checked and it really isn't in there.

Oh. This is odd. I just reported #845715 to rectify this situation.

> My guess is that it probably never got added to policy because autobuilders
> fail with similar errors as pbuilder does, so packages that violate this
> FTBFS, which is an automatic RC bug, regardless of policy.

More specifically, autobuilders use sbuild which also sets $HOME to
/sbuild-nonexistent for package builds. If the source package tries to create
that path it will fail because it lacks permissions to do so.

This practice of course doesn't catch source packages which will not write into
$HOME if it does not exist but will do so if it does. It would be interesting
to do an archive rebuild with $HOME set to a writable location and to record
which source packages still violate this rule.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#845308: Sponsoring imagemagick/8:6.8.9.9-5+deb8u6

[Luciano Bello]

On Friday, 25 November 2016 17:42:13 EST Bastien Roucaries wrote:
> Can i add a newer patch fixing the last cve ?

Do you think you can upload it for tomorrow? Let me unroll everything on this 
end (I already asked for a DSA id, but I think I can put it back). Let me know 
if you can upload to mentors asap.

Cheers, luciano

Re: Copyright for Autoconf stuff

[Paul Wise]

On Sat, Nov 26, 2016 at 3:51 AM, Russ Allbery wrote:

> For those who think it's important to document the licenses of these
> files, I would encourage you to work on writing a well-tested and reliable
> tool to automatically generate those stanzas (the notices are fairly
> consistent and open for that sort of automation) rather than asking people
> to do tedious and not very productive manual work.

There are various tools for this, FOSSology looks the most promising
but Kate Stewart hasn't had the chance to finish her packaging of it.

https://wiki.debian.org/CopyrightReviewTools

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#844608: [Pkg-protobuf-devel] Bug#844608: Looking for sponsor for protobuf NMU

[GCS]

Hi,

On Fri, Nov 25, 2016 at 4:05 PM, lumin  wrote:
> It is now present in unstable. However the buildd status seems bad.
 Yes, seen that. :(

> ppc64el due to segfault during python2 test.
 Do you know any reason why it may happen?

> kfreebsd-* had never compiled protobuf since 3.x.x release.
 That's bad. I'd like to support kFreeBSD for Stretch, but don't think
I'll have time to really look into it. :(

> armel,armhf,hppa,i386,mips,mipsel,powerpc,x32 failed during python3 test due 
> to the same reason:
>
>   Traceback (most recent call last):
> File 
> "/«PKGBUILDDIR»/python3/google/protobuf/internal/reflection_test.py", line 
> 639, in testIntegerTypes
>   TestGetAndDeserialize('optional_uint32', 1 << 31, long)
>   NameError: name 'long' is not defined
>
> There is no "long" type in python3, so this is an upstream
> py2 -> py3 porting bug. See:
>
> https://github.com/google/protobuf/issues/1504
 Found this, seems to be solvable. But next time I'll do test builds
on several architectures before upload.

> I looked into protobuf's code at master branch and it seems to be solved:
>
> https://github.com/google/protobuf/blob/master/python/google/protobuf/internal/reflection_test.py#L658-L659
> https://github.com/google/protobuf/blob/master/python/google/protobuf/internal/reflection_test.py#L642-L645
 This should be the way, seems to be a natural try this and if doesn't
work then go with the safe default.

> Should we consider to cherry-pick the corresponding upstream commit to
> Debian's protobuf 3.0.0 package or, to import protobuf 3.1.0
> (maybe impossible due to transition freeze) ?
 As I understand, small transitions are still possible, that doesn't
affect too many packages. But to be honest, the 3.0 transition was big
enough and still not finished (see the kFreeBSD build problems). I do
_not_ want to risk having more problems with 3.1 so close to the full
freeze.

Regards,
Laszlo/GCS
PS: please don't Cc me, I'm subscribed to the list.

Bug#845614: RFS: acorn/4.0.3-1

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: acorn
   Version : 4.0.3-1
   Upstream Author : (big list)
 * URL : https://github.com/ternjs/acorn
 * License : Expat
   Section : web

  It builds those binary packages:

node-acorn - ECMAScript parser for Node.js

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


  https://mentors.debian.net/package/acorn


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

dget -x 
https://mentors.debian.net/debian/pool/main/a/acorn/acorn_4.0.3-1.dsc


  It is packaged within the Debian Javascript Maintainers' git repository:
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/acorn.git
Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/acorn.git

Notice:

(1) the package was first made by Bas Couwenberg, uploaded, then pulled 
and abandoned -- I had just a (very obsolete) repository to start with ; 
so I set the priority as "normal" but considered "wishlist" too.


(2) upstream moved forward very fast and uses rollup to compile itself, 
but we don't have rollup yet, and rollup needs acorn (and itself!), so 
I'm using my node-es6-module-transpiler and sed-patch things so they 
work ; I could check running "acorn foo.js" works for most files in 
/usr/lib/nodejs (some give errors, but can still be tokenized, so 
nothing too worrying).


The ultimate goal is to get rollup up and running, boostrapping it with 
node-es6-module-transpiler. I'm not there yet...


Cheers,

Snark on #debian-js

Copyright for Autoconf stuff

[Ferenc Wágner]

In #832941 Sean Whitton  writes:

> 6. config.guess, config.sub, configure, configure.in, Makefile.in and
> install-sh are not accounted for in d/copyright.

Hi,

The license and the copyright of these files is pretty much the same all
the time (some details can depend on the date).  However, tracking this
all properly in the copyright files of all packages using Autoconf takes
a huge amount of work.  Is there really no way to redirect all that
effort towards something productive?  For example by declaring at a
central place that these files have the usual license and copyright
unless specified otherwise in debian/copyright, and be done with them?
-- 
Regards,
Feri

Re: Copyright for Autoconf stuff

[Ben Finney]

wf...@niif.hu (Ferenc Wágner) writes:

> The license and the copyright of these files is pretty much the same all
> the time (some details can depend on the date).

It's part of the package maintainer's job to confirm that's the case for
this specific package, and document it in ‘debian/copyright’ so others
can verify that work.

> However, tracking this all properly in the copyright files of all
> packages using Autoconf takes a huge amount of work.

Is anyone asking you to do it for “all packages using Autoconf”? I
missed that.

You can do it for this package and let the maintainers of other packages
do the work for those.

-- 
 \ “Capitalism has destroyed our belief in any effective power but |
  `\  that of self interest backed by force.” —George Bernard Shaw |
_o__)  |
Ben Finney

Bug#845469: RFS: ranger/1.7.2+git20161104-0.1 [NMU]

[Mateusz Łukasik]

On 23.11.2016 at 20:54, Gianfranco Costamagna wrote:

control: owner -1 !
control: tags -1 moreinfo


Hi Vern and Mateusz,


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


too much changes without an ack from the Maintainer (in cc)

   * Non-maintainer upload.
   * Merged lastest upstream git version. (Closes: #829114)
   * debian/patches:
 - Refresh 0002-make-sensible-decisions-on-which-pager-and-editor.patch.
 - Drop 0003-honour-TMPDIR-environment-variable.patch - included upstream.
 - Rename 0004-closes-772351-thanks-Raphael-Geissert.patch to
   0003-closes-772351-thanks-Raphael-Geissert.patch.
   * debian/control:
 - Updated Standard-version to 3.9.8.
 - Move sudo from Recommends to Suggests. (Closes: #771803)
   * Bump debhelper version to 10.
   * Add debian/lintian-overrides.


Vern, are them ok for you?
Do you plan to do a maintainer upload?


G.



I contacted with him about half year ago but without answer. This is my 
reason of NMU.


--
 .''`.  Mateusz Łukasik
: :' :  http://mati75.eu
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#840424: RFS: verilog-mode

[Kiwamu Okabe]

Dear Sean,

On Sun, Nov 20, 2016 at 5:15 AM, Sean Whitton  wrote:
> Thank you for your work to bring this new package to Debian!  As I said,
> I can't sponsor the upload, but I hope this more detailed review is
> useful to you.

Of course, your precisive review is very useful for me. Thanks.

> I've split it into two sections: things that I would consider must-fixes
> before an upload to Debian, and suggested improvements.  The latter
> aren't strictly necessary, but they would help demonstrate to a
> potential sponsor that you are committed to maintaining this package in
> Debian.

OK.

> Must fixes
> ==
>
> 1. The line "Only support emacs and xemacs" doesn't make sense (what
> else would you be supporting?).  What were you trying to say?

Fixed. It's my simple mistake. I should say "Support emacs and xemacs."

> 2. There is a Lintian error:
>
> E: verilog-mode: info-document-missing-dir-section 
> usr/share/info/verilog.info.gz

You are right. I miss it out. It's fixed by
debian/patches/fix-dircategory.patch.
The patch is pull-requested to upstream:

https://github.com/veripool/verilog-mode/pull/13

> 3. Some files are not GPL-3+.  For example,
> tests/auto_delete_whitespace.v.  Please check every file's copyright
> status and detail in d/copyright.

The debian/copyright is updated.

> 4. The README is useless to an end user who has already installed the
> package, so you shouldn't be installing it -- it could be confusing.

Fixed.

> 5. You've missed some steps of the Emacs policy.[1]  For example, you
> are missing a emacsen compat level.  Please check the policy carefully.
>
> [1] https://www.debian.org/doc/packaging-manuals/debian-emacs-policy

I added "verilog-mode.emacsen-compat" file.
And I think that there are no other violation.

> Suggestions
> ===
>
> 1. It would be best to build-depend on emacs25, not emacs24.  emacs24
> might be removed from stretch.

Fixed.

> 2. At debhelper compat 10, you can probably delete
> debian/verilog-mode.dirs.

You are right. It's removed from git repo.

> 3. You are generating ChangeLog.txt but not installing it.  You can use
> dh_installchangelogs(1).

I think it's not useful.

```
$ make ChangeLog.txt
./make_log.pl
Unknown host nasuno.
$ cat ChangeLog.txt
$ make ChangeLog
perl makechangelog --git verilog-mode.el > ChangeLog
$ cat ChangeLog
-*- Change-Log -*-



* verilog-mode.el:

==
```

> 4. How about installing verilog-lex.el as an example?  See
> dh_installexamples(1).  Or possibly somewhere else.

Sorry. I can't understand why it becomes as example,
because I'm not a expert for both Emacs and Verilog.

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

Bug#845469: RFS: ranger/1.7.2+git20161104-0.1 [NMU]

[Gianfranco Costamagna]

hi,

>I contacted with him about half year ago but without answer. This is my 
>reason of NMU.



ok but you still:
- have to restrict changes to a minimum necessary set (e.g. no bumping of
stuff)
- have to provide a debdiff on the bugs you close with what you want to be
sponsored, and tag it patch/pending
- explain why you are not packaging 1.7.2 but 1.7.2+something.

For NMU stable releases are somewhat appreciated, unless you have reasons
for having a snapshot (also cherry-picks of particular upstream commits
are fine).

and please explain why the new release is useful to Debian (new features? bugs 
fixed?)

according to upstream changelog it seems really about just bugfixes, so it 
should be fine)

G.

Bug#845631: RFS: globjects/1.0.0-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: globjects
  Version : 1.0.0-2
  Upstream Author : CG Internals
* URL : http://globjects.org/
* License : Expat
  Section : libs

It builds those binary packages:

  globjects-doc - documentation for globjects
  libglobjects-dev - development files for globjects
  libglobjects1 - cross-platform C++ wrapper for OpenGL API objects

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


  https://mentors.debian.net/package/globjects

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/globjects/globjects_1.0.0-2.dsc


Successful build on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/globjects/1.0.0-2/buildlog

Changes since the last upload:

  * Fix packaging testsuite failure.

Regards,
Ghislain Vaillant