Re: create Debian Source from GIT repository without tag

[Andrey Rahmatullin]

On Mon, Aug 15, 2016 at 04:53:59PM -0700, Sean Whitton wrote:
> One thing I've done is added a tag corresponding to upstream part of the
> version in my Debian changelog entry.  Then gbp can generate the tarball
> for me.
Sure, but Jerome didn't say he was using gbp.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#834245: RFS: arasan/19.0.1-1 [ITP] -- a strong chess engine using xboard

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Dear Michael,

Thank you for packaging this interesting-looking software for Debian.  I
can't sponsor the upload, but I hope this review is useful to you.

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.

=== Must-fixes / clarifications

1. The upstream author distributes the source code under the MIT
license, but places restrictions on distributing the binary builds
available from his website.  I think you need to confirm that none of
the files in your package are bit-for-bit identical to any files that
can be downloaded from his website.  It might be best to ask
debian-legal about it.

2. The debian/copyright file doesn't fill all the requirements given in
Debian Policy section 12.5.  It's highly recommended you use the
"machine-readable" copyright format:


3. You seem to be embedding at least one other project: src/syzygy looks
to be a library.  This needs to be packaged separately.

4. The content in debian/changelog is not appropriate.  It should
contain a single entry, saying "Initial release (Closes: #771057)."  The
information in your changelog should be split between
/usr/share/doc/arasan/README.Debian and patch headers.

5. You shouldn't install the whole doc/ directory.  You are installing
the upstream changelog twice, installation instructions, and some
licenses for components that

=== Suggested improvements

1. I'd be very grateful if you'd put your packaging in a git
repository.  That allows me to more easily track changes you've made in
response to my comments in this review.

2. In your debian/rules file, you do not use the dh sequencer.  Since
you are not doing anything non-standard, you could probably use a rules
file that is less than 5 lines long.  Please look into that (dh(1) would
be a good place to start).

3. Upstream are on version 19.1.0 now.  You could upgrade from 19.0.1.

4. In the patch header for remove-arasanx-suffix.patch, isn't it for
running a multi-arch system not a multi-user system?

5. Why are you installing /usr/share/arasan/README?  That's not the
place for a README.

6. Would it make sense to run upstream's test suite during the package
build, to check everything is working?

7. Have you considered packaging the Syzygy tablebase for Debian (if
it's free software)?

The "must-fixes" are quite serious, so I'll end my review here.  If you
can deal with the above I'll probably be able to find some more things
you can improve :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: which license to use

[Paul Wise]

On Tue, Aug 16, 2016 at 9:26 AM, Gustavo S. L. wrote:

> I'm packing the gifshuffle software.
> source:http://www.darkside.com.au/gifshuffle/ almost all files appear
> to be public domain. but to do it: egrep -sriA25 --with-filename
> '(public dom|copyright)' I found a file mentioning the gif.

It appears that the only mention of the public domain is on the
website. This may be good enough for the Debian FTP team, but it would
be best to have upstream add a license grant.

Please be aware that gif.c references giftoppm and its license, so be
sure to include that in debian/copyright.

> after reading this article I was afraid:
> https://www.gnu.org/philosophy/gif.html

You may have missed the header and the footnote, which say that all
the GIF patents are expired after 2006 and that we are well clear of
any legal threat from the GIF patents.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

which license to use

[Gustavo S. L.]

I'm packing the gifshuffle software.
source:http://www.darkside.com.au/gifshuffle/ almost all files appear
to be public domain. but to do it: egrep -sriA25 --with-filename
'(public dom|copyright)' I found a file mentioning the gif. I wonder
how I proceed in this case. after reading this article I was afraid:
https://www.gnu.org/philosophy/gif.html

thanks

-- 
Gustavo Soares de Lima
Logicus Tecnologia de Informação e Comunicação

Re: create Debian Source from GIT repository without tag

[Sean Whitton]

Hello,

On Mon, Aug 15, 2016 at 09:24:01PM +0500, Andrey Rahmatullin wrote:
> > Do you have a example or a wiki in mind ?
> Um. git archive  | xz > foo.tar.xz, I guess.

One thing I've done is added a tag corresponding to upstream part of the
version in my Debian changelog entry.  Then gbp can generate the tarball
for me.

For example, support I'm packaging 0~git.abc123d.  This version number
might be used because I'm basing my packaging on upstream git commit
whose hash is uniquely identified by the string 'abc123d'.  I would add
a tag '0_abc123d' (since gbp replaces '~' with '_' in tags due to git
restrictions).  Then `gbp buildpackage` would generate the tarball as
needed.

Just calling `git archive` yourself is fine.  The only advantage of the
method I just described is that it's easier to remember/document for
future releases -- create the tag, and let gbp do the rest.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: create Debian Source from GIT repository without tag

[Jerome BENOIT]

Hi,

On 15/08/16 17:46, Andrew Shadura wrote:
> On 15 August 2016 at 17:24, Andrey Rahmatullin  wrote:
>> On Mon, Aug 15, 2016 at 04:58:32PM +0100, Jerome BENOIT wrote:
> So I am considering to create a Debian Source from the GIT repository.
> Unfortunately, the GIT repository contains no tags, so uscan(1) seems
> not be useful here. I have already submitted a ticket to the upstream
> maintainer [3], but he seems to be very busy.  Meanwhile, I want to step
> forward.
>
> What is the best way to create a Debian Source from the upstream GIT 
> repository ?
 git archive would be enough, you don't need uscan for that.
 You can't have a debian/watch in this case, of course.

>>>
>>> Do you have a example or a wiki in mind ?
>> Um. git archive  | xz > foo.tar.xz, I guess.
> 
> I did attempt to automate such tasks a couple of time for
> Ajenti-related packages (I haven't finished packaging Ajenti itself —
> any takers by the way?): python-catcher, python-exconsole,
> python-reconfigure (have a look at debian/rules:get-orig-source).
> 
The three of them have a d/wath file .


Jerome

Re: create Debian Source from GIT repository without tag

[gregor herrmann]

On Mon, 15 Aug 2016 16:58:32 +0100, Jerome BENOIT wrote:

> >> What is the best way to create a Debian Source from the upstream GIT 
> >> repository ?
> > git archive would be enough, you don't need uscan for that.
> > You can't have a debian/watch in this case, of course.
> Do you have a example or a wiki in mind ?

If you want to check what other Debian packages do,
codesearch.debian.net often helps:

https://codesearch.debian.net/search?q=git-archive+path%3Adebian%2F=1


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tom Waits: America


signature.asc
Description: Digital Signature

Bug#834424: RFS: r-bioc-rbgl/1.48.1+dfsg-1 [ITP]

[Andreas Tille]

Hi Christopher,

On Mon, Aug 15, 2016 at 03:14:01PM +0100, Christopher Hoskin wrote:
>   I am looking for a sponsor for my package "r-bioc-rbgl"

I'd happily sponsor any BioConductor package 
 
>   It builds those binary packages:
> 
> r-bioc-rbgl - R interface to the graph algorithms contained in the BOOST 
> library
> 
>   To access further information about this package, please visit the 
> following URL:
> 
>   https://mentors.debian.net/package/r-bioc-rbgl

I must admit that I'd exclusively sponsor from a team version control
system (Git or SVN).  Please inject the packaging into Debian Med VCS as
described in the Debian Med policy[1].  I've just added you to the
Debian Med team so you have commit permissions.

Thanks for working on the BioConductor package

 Andreas. 

[1] https://debian-med.alioth.debian.org/docs/policy.html

-- 
http://fam-tille.de

Bug#828978: RFS: install-mimic/0.2.0-1 (ITP)

[Peter Pentchev]

On Wed, Jun 29, 2016 at 05:12:24PM +0300, Peter Pentchev wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my new package "install-mimic".
> It's a tool that I've found useful time and again when installing
> an updated version of a file and not wanting to bother with all
> the owner, group, and mode parameters to install(1).

Mmm, anyone? :)

> * Package name: install-mimic
>   Version : 0.2.0-1
>   Upstream Author : Peter Pentchev 
> * URL : https://devel.ringlet.net/misc/install-mimic/
> * License : BSD-2-clause
>   Language: C
>   Section : sysutils
>   ITP : https://bugs.debian.org/828913
> 
> It builds a single binary package that has been built using sbuild and
> tested with Lintian, cme, and autopkgtest:
> 
> install-mimic - overwrite files and preserve their ownership
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/install-mimic
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/i/install-mimic/install-mimic_0.2.0-1.dsc
> 
> More information about install-mimic can be obtained from
> https://devel.ringlet.net/misc/install-mimic/

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#834433: RFS: id3/1.0.0-1 [ITA] (adopt, adopt upstream, fix bugs, refresh packaging)

[Peter Pentchev]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for adopting the "id3" package:

* Package name: id3
  Version : 1.0.0-1
  Upstream Author : Peter Pentchev 
* URL : https://devel.ringlet.net/audio/id3/
* License : GPL-2+
  Section : sound

It builds a single binary package that has been tested with Lintian, sbuild,
cme, and most of the programs in check-all-the-things:

  id3   - Editor for ID3 tags

Please note that the *.dsc file also contains a reference to an upstream
signature, id3_1.0.0.orig.tar.gz.asc; it would be nice to have that
included in the final upload once we get to that point.

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/i/id3/id3_1.0.0-1.dsc

More information about id3 can be obtained from 
https://devel.ringlet.net/audio/id3/

Changes since the last upload:

id3 (1.0.0-1) unstable; urgency=medium

  * New maintainer.  Closes: #770258
  * Declare compliance with Debian Policy 3.9.8 with no changes.
  * Point the Vcs-* fields to the new collab-maint Git repository and
switch to the HTTPS scheme.
  * Point to the new upstream at devel.ringlet.net in the control,
copyright, and watch files.
  * Convert the copyright file to version 1.0 of the machine-readable
copyright file format and add my debian/* copyright notice.
  * Convert the watch file to format version 4, use pgpmode=auto, and
add the devel.ringlet.net signing key.
  * Turn on all the build hardening options.
  * New upstream release:
- drop all the Debian patches, incorporated upstream
- drop the "no upstream changelog" Lintian override
- pass the empty STRIP variable to the upstream build
- add my upstream copyright notice
  * Add Multi-Arch: foreign to the binary package.
  * Add the debian/upstream/metadata file.
  * Bump the debhelper compatibility level to 10 and override the Lintian
debhelper version warning.

 -- Peter Pentchev   Mon, 15 Aug 2016 17:50:16 +0300

Thanks in advance for your time and attention!

G'luck,
Peter

-- System Information:
Debian Release: stretch/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Re: create Debian Source from GIT repository without tag

[Andrey Rahmatullin]

On Mon, Aug 15, 2016 at 04:58:32PM +0100, Jerome BENOIT wrote:
> >> So I am considering to create a Debian Source from the GIT repository.
> >> Unfortunately, the GIT repository contains no tags, so uscan(1) seems
> >> not be useful here. I have already submitted a ticket to the upstream
> >> maintainer [3], but he seems to be very busy.  Meanwhile, I want to step
> >> forward.
> >>
> >> What is the best way to create a Debian Source from the upstream GIT 
> >> repository ?
> > git archive would be enough, you don't need uscan for that.
> > You can't have a debian/watch in this case, of course.
> > 
> 
> Do you have a example or a wiki in mind ?
Um. git archive  | xz > foo.tar.xz, I guess.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: create Debian Source from GIT repository without tag

[Jerome BENOIT]

Hello Andrey,

thanks for your prompt reply.

On 15/08/16 16:43, Andrey Rahmatullin wrote:
> On Mon, Aug 15, 2016 at 04:19:03PM +0100, Jerome BENOIT wrote:
>> it appears that for one of my pacage, libgap-sage not to mention it [1],
>> the upstream source tarbal does not contain the required material to be not
>> rejected by ftpmaster [2]. 
> Your link doesn't seem to support that.

The answer from Ben Finney does, given that the upstream source ball
contains only the transformed source files (neither the original nor
the scripts used to transformed them),

https://lists.debian.org/debian-legal/2016/08/msg7.html

> 
> 
>> So I am considering to create a Debian Source from the GIT repository.
>> Unfortunately, the GIT repository contains no tags, so uscan(1) seems
>> not be useful here. I have already submitted a ticket to the upstream
>> maintainer [3], but he seems to be very busy.  Meanwhile, I want to step
>> forward.
>>
>> What is the best way to create a Debian Source from the upstream GIT 
>> repository ?
> git archive would be enough, you don't need uscan for that.
> You can't have a debian/watch in this case, of course.
> 

Do you have a example or a wiki in mind ?

Thanks in advance,
Jerome

create Debian Source from GIT repository without tag

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Forum,

it appears that for one of my pacage, libgap-sage not to mention it [1],
the upstream source tarbal does not contain the required material to be not
rejected by ftpmaster [2]. So I am considering to create a Debian Source
from the GIT repository. Unfortunately, the GIT repository contains no tags,
so uscan(1) seems not be useful here. I have already submitted a ticket to
the upstream maintainer [3], but he seems to be very busy.
Meanwhile, I want to step forward.

What is the best way to create a Debian Source from the upstream GIT repository 
?

Any hint and any (good) example is wellcome.

Thanks in advance,
Jerome


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833406
[2] https://lists.debian.org/debian-legal/2016/08/msg6.html
[3] https://bitbucket.org/vbraun/libgap/issues/14
- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJXsdv+AAoJED+SGaZ/NsaLqyIf+wTyHg7e49zH1SWPzEhI7QF0
fbmgtlWIx2he/qEFCaMCERpDuR3SzltVuhJHm4C8pmGk58uJur3Tfttz6H5m4cR4
qBUNXWMH3Xeigulx30gAIC6vKPoIaIKumhldqZpoOVvgNHplBXmZRsUGwa/+l8M1
Z3zh730VPEyHmG3foRpri7FQCUS2PQW+7GDUTt8hiEbYxErzp+zIVQdAQ1pzw7U+
JkKd31bmDGwKqC1In2dOk4/JnubEyZmmaKY8px/ptzrEUGOKwF/7Q95CChywmvzQ
r4wvcZttorl6me3Uea6Fi/iwfgcqs0I+g4wC7DzdwrBIxJe/kurt3Htj8EErEvIr
z8LHK7m4tPKF1iwTEIyieW1mczRz+lOwf8Ou9PyWBO5ZEHZC7R5jx/goW4lTZ9rv
Jl9HtgcjgdDLEwbTEHlZrNpOmkF3vPVNIP0KyQvDi6uwzScQD2q89sbcSK+YsMgU
ca3BtcKu6Sse71szNYEI5r7ANeLOg/4DcfT3ILiUPVskJPJq/agD5CYwCC10EBsv
oDnqWdBBDrJc1G0Brnul0qrzSiG3XR8HHRppXaatiLdBHKHUzP6PUykbSFl3AQ1G
Cm/oa1MrtOlFO5xE/Jh/HCIZshMEWPNA6K0eqWD0dI03T5WiRvILGSJ0Tdaa7k+7
eCD9XJo9ChdJNh+tgOhAWA1ljudBLzrEY/V7eRfVW2JXsnPYTiuPPkXKOLQVib/5
5jMaLVah30EGKY2agqOwtT3l6QnKW6PTkM46bWGJ6YgCIL8R8MDNrKfTfqae+Xle
9kbK3EqW60kFMF3XxjAkpWPnMIR21VN/X0iEDdkebzmJLLN7uf4AVJJP2DW6/RDG
9Httz7/c/Z2vFyakWMYdfGBClo2kKqmw4SNjhUQrfXGBt5CuFy3STTgH2I69cD8U
UK0jfNJA0o+arKb/7j0Y6cwlWrOZ0W5YHyGQdH2MJ7doExEncpk9429V0vskTGsg
mGq6sTn7RoJFCHp0YTdTRnYy1QgDYuPs53spJZffSvttNdyzkVYkb1WMWow7ix5K
pSyGO3iHnLRPGgs8Dno1REz/AteJczyF6nJr+KbUX5d+qE+jXpqww/V92BDh8/8L
U65k19+6IIG3pZzqk0wtTnS/yMEuYGFP9NiECeQIGX0jDln5CaBRwyvKnPDYsbYW
QGTMKEhuyStuVEIjUZpTU93XX6sCVhP9tvhKQv6W43IvInbuKNONOTonyFoc5eze
QBtE2fecv2rIY/FWP5cNE6RwQhrRIeyUhpZrz30X5u1GHR7Ush9BQZyB/fbCu607
ls5e7nJTcyu3+7i60CTQNtIGkXbW16wu/3igrx591ibXJzil1csOSxKTfYAUM08=
=Bf9+
-END PGP SIGNATURE-

Re: create Debian Source from GIT repository without tag

[Andrey Rahmatullin]

On Mon, Aug 15, 2016 at 04:19:03PM +0100, Jerome BENOIT wrote:
> it appears that for one of my pacage, libgap-sage not to mention it [1],
> the upstream source tarbal does not contain the required material to be not
> rejected by ftpmaster [2]. 
Your link doesn't seem to support that.


> So I am considering to create a Debian Source from the GIT repository.
> Unfortunately, the GIT repository contains no tags, so uscan(1) seems
> not be useful here. I have already submitted a ticket to the upstream
> maintainer [3], but he seems to be very busy.  Meanwhile, I want to step
> forward.
> 
> What is the best way to create a Debian Source from the upstream GIT 
> repository ?
git archive would be enough, you don't need uscan for that.
You can't have a debian/watch in this case, of course.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

create Debian Source from GIT repository without tag

[Jerome BENOIT]

Hello Forum,

it appears that for one of my pacage, libgap-sage not to mention it [1],
the upstream source tarbal does not contain the required material to be not
rejected by ftpmaster [2]. So I am considering to create a Debian Source
from the GIT repository. Unfortunately, the GIT repository contains no tags,
so uscan(1) seems not be useful here. I have already submitted a ticket to
the upstream maintainer [3], but he seems to be very busy.
Meanwhile, I want to step forward.

What is the best way to create a Debian Source from the upstream GIT repository 
?

Any hint and any (good) example is wellcome.

Thanks in advance,
Jerome


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833406
[2] https://lists.debian.org/debian-legal/2016/08/msg6.html
[3] https://bitbucket.org/vbraun/libgap/issues/14

Bug#834429: RFS: arrayfire/3.3.2+dfsg1-4

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: arrayfire
  Version : 3.3.2+dfsg1-4
  Upstream Author : ArrayFire
* URL : http://arrayfire.com/
* License : BSD
  Section : science

It builds those binary packages:

  libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
  libarrayfire-cpu3 - High performance library for parallel computing 
(CPU backend)

  libarrayfire-dev - Common development files for ArrayFire
  libarrayfire-doc - Common documentation and examples for ArrayFire
  libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL 
backend)
  libarrayfire-opencl3 - High performance library for parallel 
computing (OpenCL backend)
  libarrayfire-unified-dev - Development files for ArrayFire (unified 
backend)
  libarrayfire-unified3 - High performance library for parallel 
computing (unified backend)


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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.2+dfsg1-4.dsc


Changes since the last upload:

  * Build with compute library from Boost 1.61.
  * d/rules: disable build of examples.
  * d/rules: remove superfluous nocheck guards.

Regards,
Ghislain Vaillant

Bug#834424: RFS: r-bioc-rbgl/1.48.1+dfsg-1 [ITP]

[Christopher Hoskin]

Package: sponsorship-requests
Severity: wishlist


Dear mentors,

  I am looking for a sponsor for my package "r-bioc-rbgl"

 * Package name: r-bioc-rbgl
   Version : 1.48.1+dfsg-1
   Upstream Author : Vince Carey , Li Long 
, R. Gentleman 
 * URL : 
http://www.bioconductor.org/packages/release/bioc/html/RBGL.html
 * License : Artistic-2.0
   Section : gnu-r

  It builds those binary packages:

r-bioc-rbgl - R interface to the graph algorithms contained in the BOOST 
library

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

  https://mentors.debian.net/package/r-bioc-rbgl

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

dget -x 
https://mentors.debian.net/debian/pool/main/r/r-bioc-rbgl/r-bioc-rbgl_1.48.1+dfsg-1.dsc

  More information about RBGL can be obtained from 
http://www.bioconductor.org/packages/release/bioc/html/RBGL.html.

  The ITP is Bug#834398.

  Thank you.

  Christopher Hoskin

Re: gcc-6 and sip help (bug 812138)

[Christian Seiler]

On 08/15/2016 12:43 PM, Gudjon I. Gudjonsson wrote:
> This fails to compile with the following message:
> 
> make[2]: Entering directory '/home/gudjon/nb/pyqwt3d/
> pyqwt3d-0.1.7~cvs20090625/build/py2.7-qt4/configure/OpenGL_Qt4'
> g++ -c -g -O2 -fstack-protector-strong -Wformat -Werror=format-security  -
> Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -O2 -Wall -W -D_REENTRANT -DNDEBUG -
> DGL2PS_HAVE_ZLIB -DHAS_NUMPY -DQT_NO_DEBUG -DQT_OPENGL_LIB -I. -I/usr/include/
> qwtplot3d-qt4 -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/
> numpy/core/include -I/usr/include/qt4/Qt -I/usr/share/qt4/mkspecs/default -I/
> usr/include/qt4/QtOpenGL -I/usr/include/qt4 -I/usr/X11R6/include -o 
> sipOpenGLcmodule.o sipOpenGLcmodule.cpp
> sipOpenGLcmodule.cpp:4445:1: error: narrowing conversion of ‘4294967295u’ 
> from 
> ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
>  };

Beginning with gcc 5, when using the newest C++ standard, narrowing
conversions of constants are an error:

https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
   (search for "-Wnarrowing")
https://gcc.gnu.org/wiki/FAQ#Why_does_GCC_not_give_an_error_for_some_narrowing_conversions_within_list-initializations_as_required_by_C.2B-.2B-11_.28-Wnarrowing.29_.3F

Starting with gcc 6, the default C++ standard the compiler uses is
now gnu++14 (i.e. C++14 + GNU extensions). IIRC the default standard
the compiler assumed previously was still C++98. (I may be wrong
though.)

Now obviously, the problem is with the original sip file: int is
simply the wrong data type for these constants. You should use
unsigned int instead.

However, it appears that only two constants are affected here, and
the error message is actually quite misleading about the position
of the error, because sip creates a large data structure, and the
position where the error is thrown is at the end of the definition
of the data structure. If you investigate the constants that are
defined in that data structure further though, you'll realize that
only two are actually >= 0x8000, i.e. don't fit in a signed int
anymore.

Those are:

GL_CLIENT_ALL_ATTRIB_BITS
GL_ALL_ATTRIB_BITS

which both are defined as 0x in GL/gl.h, to indicate that
all bits (that fit into 32bit int[0]) are meant.

The proper fix would probably be to replace all int constants with
unsigned int constants, but that has two issues:

 - sip doesn't appear to make a difference between int and unsigned
   int (it uses int internally), so that doesn't actually help

 - you don't want to touch the entire source file
   (ok, you could touch only those two constants, but that would
   be asymmetric)

You could probably resort to long long as a data type (long is not
sufficient on 32bit platfors), but that's really not a good idea
IMHO.

The easiest solution is probably to add -Wno-narrowing to the
compiler flags. Now due to the fact that how your pacakge build
works [1], you actually have to add 

  --extra-cxxflags="-Wno-narrowing"

to the configure.py invocation in debian/rules (for example you can
put it before --extra-libs=...). That disables the compiler
diagnostic and makes the package compile again. I just tried that
and it does build the package. [2]

However, and this was actually also a bug in the previous version
of the package, the two constants are defined "wrongly" in Python:

>>> import PyQt4.Qwt3D.OpenGL
>>> PyQt4.Qwt3D.OpenGL.GL_CLIENT_ALL_ATTRIB_BITS
-1
>>> PyQt4.Qwt3D.OpenGL.GL_ALL_ATTRIB_BITS
-1

(Should be 4294967295, if they really were unsigned.)

It's not terribly problematic, because using those constants with
a bitwise AND in python will result in the correct answer:

>>> PyQt4.Qwt3D.OpenGL.GL_ALL_ATTRIB_BITS & PyQt4.Qwt3D.OpenGL.GL_2D == 
>>> PyQt4.Qwt3D.OpenGL.GL_2D
True

But a really proper fix for this would entail:

 - file a bug against sip to support unsigned int properly
 - once that's fixed, remove the -Wno-narrowing against in your
   package and use unsigned int for all of the constants, not a
   signed int (at least for those constants that are obviously
   meant to be used in a bit field context)

Hope that helps.

Regards,
Christian

[0] Which in theory is not completely portable, because int could
be larger or smaller than 32 bits (though in practice it isn't
on any arch Debian supports), the right way to define a
constant for "all bits in an unsigned int" would be to use
#define CONSTANT_NAME (~0u)
However, that's probably something one should tell OpenGL
upstream, because it's there that that constant is defined in
that way.

[1] Btw. the entire CFLAGS = logic in debian/rules you can drop,
because a) you're compiling C++ code, so CXXFLAGS would be
relevant and b) the way python builds its modules is that it
always uses the compiler and flags that python itself was
compiled with (and it's non-trivial to override that), so
even CXXFLAGS would likely have no effect at all.

[2] There's a reason for this 

gcc-6 and sip help (bug 812138)

[Gudjon I. Gudjonsson]

Hi list

I am trying to fix a sip/gcc-6 related bug in package pyqwt3d but I don't know 
how.

OpeGL_mod.sip contains

const int GL_2D;
const int GL_3D;
const int GL_3D_COLOR;


which is converted to

sipOpenGLcmodule.cpp which contains:

static sipIntInstanceDef intInstances[] = {
{sipName_GL_2D, GL_2D},
{sipName_GL_2_BYTES, GL_2_BYTES},
{sipName_GL_3D, GL_3D},
..
{0, 0}
};

This fails to compile with the following message:

make[2]: Entering directory '/home/gudjon/nb/pyqwt3d/
pyqwt3d-0.1.7~cvs20090625/build/py2.7-qt4/configure/OpenGL_Qt4'
g++ -c -g -O2 -fstack-protector-strong -Wformat -Werror=format-security  -
Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -O2 -Wall -W -D_REENTRANT -DNDEBUG -
DGL2PS_HAVE_ZLIB -DHAS_NUMPY -DQT_NO_DEBUG -DQT_OPENGL_LIB -I. -I/usr/include/
qwtplot3d-qt4 -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/
numpy/core/include -I/usr/include/qt4/Qt -I/usr/share/qt4/mkspecs/default -I/
usr/include/qt4/QtOpenGL -I/usr/include/qt4 -I/usr/X11R6/include -o 
sipOpenGLcmodule.o sipOpenGLcmodule.cpp
sipOpenGLcmodule.cpp:4445:1: error: narrowing conversion of ‘4294967295u’ from 
‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
 };


sipIntInstanceDef is defined in:
/usr/include/python2.7/sip.h

typedef struct _sipIntInstanceDef {
/* The int name. */
const char *ii_name;

/* The int value. */
int ii_val;
} sipIntInstanceDef;


But some of the OpenGL parameters are out of range for int.


Does anyone have a clue on how to fix this?

Regards
Gudjon

Bug#834288: marked as done (RFS: dblatex/0.3.8-1)

[Debian Bug Tracking System]

Your message dated Mon, 15 Aug 2016 06:35:25 +
with message-id <20160815063525.ga2...@master.debian.org>
and subject line RFS: dblatex/0.3.8-1
has caused the Debian Bug report #834288,
regarding RFS: dblatex/0.3.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.)


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

 Package name: dblatex
 Version : 0.3.8-1
 Upstream Author : Benoît Guillon 
 URL : http://dblatex.sourceforge.net/
 License : GPL V2+
 Section : text

It builds those binary packages:

  dblatex - Produces DVI, PostScript, PDF documents from DocBook sources
  dblatex-doc - Documentation for dblatex

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dblatex/dblatex_0.3.8-1.dsc

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

Changes since the last upload:

  * New upstream release
  * Drop a temporary lintian override regarding a copyright file spelling error
as it has been fixed upstream.
  * Standards-Version: 3.9.8
+ Move documentation and examples to separate package dblatex-doc.
  * Actualize debian/watch.

Regards, Andreas Hoenen
-- 
Andreas Hoenen 
GPG: 1024D/B888D2CE
 A4A6 E8B5 593A E89B 496B
 82F0 728D 8B7E B888 D2CE


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
I took the liberty of replacing "actualize" by "update" and uploading the
package as the rest of the package was imho good.--- End Message ---