Bug#824121: python-nanomsg ready for review
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
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
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
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
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]
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]
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
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
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
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
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]
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]
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]
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
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
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