Bug#824121: python-nanomsg ready for review

2016-05-31 Thread Jonathon Love

hi mattia,


umh?  So, I read a bit the manpage, this was enough.
IMHO, you gave up way too early, and I really much don't like it.


well, thanks for your patience. i did think that i had possibly figured 
out the correct way to do it, but i wasn't sure. it can be hard to tell 
if you've done something correctly or not. the fact that i can't "undo" 
mistakes with git makes me reluctant too. but now you've got me started, 
i am learning how to work with git-dpm. hopefully my contributions in 
the future will compensate you for your time and frustration in this 
instance.


as per your feedback, i have

  - added a patch to enable the bindnow hardening
  - fixed all the lintian warnings
  - amended the copyright period to be 2013-2014

and i believe it is ready for the next round of review.

with thanks

jonathon



Bug#824121: python-nanomsg ready for review

2016-05-23 Thread Jonathon Love


On 23/05/2016 23:52, Julien Puydt wrote:

Hi,

On 23/05/2016 15:39, Jonathon Love wrote:

hi julien,

On 23/05/2016 23:16, Julien Puydt wrote:

Hi,

On 23/05/2016 14:19, Mattia Rizzolo wrote:

Hi Julien,

exactly the some days ago you hit this too:

On Mon, May 23, 2016 at 09:48:41PM +1000, Jonathon Love wrote:

hi, everything i can fix pretty easily, except:

Also, you did not use git-dpm, as mandate inside the DPMT:
https://wiki.debian.org/Python/GitPackaging


there are a lot of tutorials which explain how to start a repo from
scratch
using DPMT, but it's hard to know what to do with an established
repo. i
could easily solve this by nuking the repo and starting over, but
this is
frowned upon.


Mind sharing with Jonathon how you successfully solved it? :)

so do i start out be reverting all the commits after the original 
`gbp

import-orig blah.orig.tar.gz`, and then do all the DPMT stuff after
that?


that would be kind of ugly...


any advice here would be appreciated.


It's possible, not well documented maybe, but with some trials and
thoughts it can be done.



From memory, I used :

git-dpm record-new-upstream --allow-changes-in-debian-branch
--new-tarball-only 


if i run that, i get

 git-dpm: ERROR: Missing file debian/.git-dpm

do i need to do a `git-dpm init` first? i.e.

 git-dpm init ../python-nanomsg_1.0.orig.tar.gz

but then i've already told it where the tarball is.

any other pointers?

thanks for your help

jonathon



Put:
debianTag="debian/%e%v"
patchedTag="patched/%e%v"
upstreamTag="upstream/%e%u"
in debian/.git-dpm and see if that makes it happy...


so the issue is that that file doesn't exist ... but if i create it with 
those three lines in it, then:


git-dpm record-new-upstream --allow-changes-in-debian-branch 
--new-tarball-only 


doesn't do anything. my understanding is that you add those three lines 
*after* .git-dpm has been created.


so i'm still trying to figure out the right way to create it in this 
situation.


with thanks

jonathon



Bug#824121: python-nanomsg ready for review

2016-05-23 Thread Jonathon Love

hi julien,


On 23/05/2016 23:16, Julien Puydt wrote:

Hi,

On 23/05/2016 14:19, Mattia Rizzolo wrote:

Hi Julien,

exactly the some days ago you hit this too:

On Mon, May 23, 2016 at 09:48:41PM +1000, Jonathon Love wrote:

hi, everything i can fix pretty easily, except:

Also, you did not use git-dpm, as mandate inside the DPMT:
https://wiki.debian.org/Python/GitPackaging


there are a lot of tutorials which explain how to start a repo from
scratch
using DPMT, but it's hard to know what to do with an established
repo. i
could easily solve this by nuking the repo and starting over, but
this is
frowned upon.


Mind sharing with Jonathon how you successfully solved it? :)


so do i start out be reverting all the commits after the original `gbp
import-orig blah.orig.tar.gz`, and then do all the DPMT stuff after
that?


that would be kind of ugly...


any advice here would be appreciated.


It's possible, not well documented maybe, but with some trials and
thoughts it can be done.



From memory, I used :

git-dpm record-new-upstream --allow-changes-in-debian-branch
--new-tarball-only 


if i run that, i get

 git-dpm: ERROR: Missing file debian/.git-dpm

do i need to do a `git-dpm init` first? i.e.

 git-dpm init ../python-nanomsg_1.0.orig.tar.gz

but then i've already told it where the tarball is.

any other pointers?

thanks for your help

jonathon



Bug#824121: python-nanomsg ready for review

2016-05-23 Thread Jonathon Love

hi, everything i can fix pretty easily, except:

Also, you did not use git-dpm, as mandate inside the DPMT:
https://wiki.debian.org/Python/GitPackaging


there are a lot of tutorials which explain how to start a repo from 
scratch using DPMT, but it's hard to know what to do with an established 
repo. i could easily solve this by nuking the repo and starting over, 
but this is frowned upon.


so do i start out be reverting all the commits after the original `gbp 
import-orig blah.orig.tar.gz`, and then do all the DPMT stuff after that?


any advice here would be appreciated.

with thanks

jonathon



Bug#824121: python-nanomsg ready for review

2016-05-22 Thread Jonathon Love

hi,

the submitter of 776083 has let me take ownership of the ITP[1]

i have updated the uploader/maintainer fields, and committed the package to:

/git/python-modules/packaging/python-nanomsg.git

with thanks

jonathon

[1] https://bugs.debian.org/776083



Bug#823467: RFS: flatbuffers/1.3.0-2 [ITP]

2016-05-22 Thread Jonathon Love



When you upload your package with dput, you can use to -f option to
force the upload if the same version already exists on d-mentors.

ah! good tip!

i'm used to Ubuntu PPA's where you can't do that (i don't think... i 
think if you -f it rejects them).


OK, the package is now available from:

https://mentors.debian.net/debian/pool/main/f/flatbuffers/flatbuffers_1.3.0-1.dsc

with thanks

jonathon



Bug#823467: RFS: flatbuffers/1.3.0-2 [ITP]

2016-05-21 Thread Jonathon Love

hi andrey,



On Thu, May 05, 2016 at 11:17:27AM +1000, Jonathon Love wrote:

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

   dget -x 
https://mentors.debian.net/debian/pool/main/f/flatbuffers/flatbuffers_1.3.0-2.dsc

This gives 404.
https://mentors.debian.net/package/flatbuffers contains 1.3.0-5 instead.
Note that you shouldn't increase the debian version for pckages that were
not uploaded to Debian.



thanks for taking a look at my package. increasing the debian version is 
necessary when using d-mentors. if you make some changes/fixes, and 
upload with the same version number, it rejects it saying that it has 
already been uploaded. perhaps there is a workaround for this, but i 
don't know it.


i would prefer to be working out of a git repo than using d-mentors, 
perhaps you could request access for me to collab-maint, and i could set 
up a git repo there?


my debian username is jonathon-guest

with thanks

jonathon



Bug#823478: python3-protobuf3

2016-05-18 Thread Jonathon Love

hi,

so the advice i received regarding the name was that i must get it 
renamed upstream[1]. i don't think this will be possible because:


 - upstream is an established package, present in PYPI and macports
 - the developer is MIA

(additionally, the official Protocol Buffers 3 supports Python 3 [2] and 
should be coming to debian soon[3]. as the main point of this package 
was to allow the use of protocol buffers with Python 3, this reduces the 
need for this package).


hence, i propose to withdraw the package, the RFS and the ITP. also 
happy to proceed, the work is basically done, but i can't see a way to 
make it work.


with thanks

jonathon


[1] https://lists.debian.org/debian-mentors/2016/05/msg00462.html
[2] https://lists.debian.org/debian-mentors/2016/05/msg00491.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841



package name for what upstream calls protobuf3

2016-05-18 Thread Jonathon Love

hi,

i'm in the process of packaging protobuf3:

https://github.com/Pr0Ger/protobuf3

this is an implementation of protocol buffers 2 for python 3.

according to debian policy, this should be named python3-protobuf3, but 
i think this name isn't ideal, because it could be mistaken for:


a) an implementation of protocol buffers 3

b) the official google protocol buffers implementation

i'm proposing to call it:

python3-pr0ger-protobuf3

what should i call it?

with thanks

jonathon



Bug#823478: python3-protobuf3

2016-05-18 Thread Jonathon Love



umh, you force pushed everything, master, upstream and pristine-tar
branches.  WHY?  what did you do?
oh, sorry, i never intended for you to look at that repo, assuming you'd 
look at the debian-mentors one.

And still it doesn't build, if that was meant to fix it.
Without thinking of it I already overwrote the older files, so I can't
diff anymore :S
yeah, i've got it building on debian now, but i'm waiting for 
confirmation of what it should be called before pushing. i've asked on 
d-mentors.


sorry for the inconvenience, and thanks for your patience.

jonathon



Bug#823478: python3-protobuf3

2016-05-16 Thread Jonathon Love

hi matt,

thanks for the review, and sorry for the embarrassing "does not build" 
situation. i was packaging on ubuntu, and my experience has been that if 
it works there, it will work on debian - but apparently not, i'll be 
more careful in future.


i'm actually writing to ask your advice about the name of the package.

upstream is called protobuf3, but it's an implementation of protocol 
buffers 2 for python 3


i'm concerned that by calling it python3-protobuf3 people will think:

a) it is the "official" google protocol buffers

b) it is for protocol buffers version 3

¿what do you think about calling the package

python3-pr0ger-protobuf3

after the developer's nick:

https://github.com/Pr0Ger/protobuf3

with thanks

jonathon



Bug#824121: RFS: python-nanomsg/1.0-2 [ITP]

2016-05-12 Thread Jonathon Love

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-nanomsg"

 * Package name: python-nanomsg
   Version : 1.0-2
   Upstream Author : Tony Simpson
 * URL : https://github.com/tonysimpson/nanomsg-python
 * License : MIT
   Section : python

It builds the binary packages:

 python-nanomsg  - python wrapper for nanomsg (Python 2)
 python3-nanomsg - python wrapper for nanomsg (Python 3)

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

  https://mentors.debian.net/package/python-nanomsg


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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-nanomsg/python-nanomsg_1.0-2.dsc

More information about hello can be obtained from 
https://github.com/tonysimpson/nanomsg-python

  Regards,
   Jonathon Love



Bug#823478: RFS: python3-protobuf3/0.2.1-2 [ITP]

2016-05-04 Thread Jonathon Love

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python3-protobuf3"

 * Package name: python3-protobuf3
   Version : 0.2.1-2
   Upstream Author :Sergey Petrov 
 * URL : https://github.com/Pr0Ger/protobuf3
 * License : MIT
   Section : python

It builds the binary package:

  python3-protobuf3 - implementation of Google's Protocol Buffers for Python 3

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

https://mentors.debian.net/package/python3-protobuf3


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python3-protobuf3/python3-protobuf3_0.2.1-2.dsc

More information about hello can be obtained from 
https://github.com/Pr0Ger/protobuf3

with thanks
   Jonathon



Bug#823467: RFS: flatbuffers/1.3.0-2 [ITP]

2016-05-04 Thread Jonathon Love

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

  * Package name : flatbuffers
Version: 1.3.0-2
Upstream Author: Wouter van Oortmerssen
  * URL : http://google.github.io/flatbuffers/
  * License: Apache-V2
Section: libdevel

It builds the binary packages:

  flatbuffers-compiler - efficient cross platform serialization library
  libflatbuffers-dev - efficient cross platform serialization library
  libflatbuffers-java - efficient cross platform serialization library
  libjs-flatbuffers - efficient cross platform serialization library

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


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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/flatbuffers/flatbuffers_1.3.0-2.dsc


More information about flatbuffers can be obtained from 
http://google.github.io/flatbuffers/ and 
https://github.com/google/flatbuffers


with thanks

  Jonathon Love



looking for sponsor: flatbuffers

2016-05-03 Thread Jonathon Love

hi folks,

i've been packaging the flatbuffers project. i think it might be ready 
to go, and i'm looking for a sponsor.


i've pushed the work to:

/git/debian-science/packages/flatbuffers.git

(i normally work with debian-science, but this package isn't really 
science-y)


the flatbuffers project contains many subprojects which should form 
separate binary packages. my packaging so far produces:


 - libflatbuffers-dev

 - flatbuffers-compiler

 - libjs-flatbuffers

 - libflatbuffers-java

but there's also subprojects for go, C#, python, PHP, etc. which i 
haven't packaged and didn't really want to. hopefully that's ok.


i'm not completely sure i've done the right thing with the maven java 
builds. the pom.xml has sections requiring the plugins:


 - maven-source-plugin (version 2.3)

 - maven-javadoc-plugin (version 2.9.1)

so i've added these to the dependencies in d/control

however, these (older) versions don't exist in debian, and only newer 
ones (2.4, and 2.10.3). so i've patched pom.xml to use these newer 
versions, which works. but of course, this will *only* build with these 
versions, so i've fixed the dependency to require these versions.


from what i've read, maven requires you to specify a specific version, 
and doesn't allow wildcards or >= $version ... so i can't see a way 
around this.


could someone review this package and see if it's suitable for upload?

with thanks

jonathon




looking for sponsor: flatbuffers

2016-05-03 Thread Jonathon Love

hi folks,

i've been packaging the flatbuffers project. i think it might be ready 
to go, and i'm looking for a sponsor.


i've pushed the work to:

/git/debian-science/packages/flatbuffers.git

(i normally work with debian-science, but this package isn't really 
science-y)


the flatbuffers project contains many subprojects which should form 
separate binary packages. my packaging so far produces:


 - libflatbuffers-dev

 - flatbuffers-compiler

 - libjs-flatbuffers

 - libflatbuffers-java

but there's also subprojects for go, C#, python, PHP, etc. which i 
haven't packaged and didn't really want to. hopefully that's ok.


i'm not completely sure i've done the right thing with the maven java 
builds. the pom.xml has sections requiring the plugins:


 - maven-source-plugin (version 2.3)

 - maven-javadoc-plugin (version 2.9.1)

so i've added these to the dependencies in d/control

however, these (older) versions don't exist in debian, and only newer 
ones (2.4, and 2.10.3). so i've patched pom.xml to use these newer 
versions, which works. but of course, this will *only* build with these 
versions, so i've fixed the dependency to require these versions.


from what i've read, maven requires you to specify a specific version, 
and doesn't allow wildcards or >= $version ... so i can't see a way 
around this.


could someone review this package and see if it's suitable for upload?

with thanks

jonathon