Re: dropping top patch with git-dpm
Brian May writes: > brian@prune:~/tree/debian/python-modules/django-guardian$ git-dpm > update-patches > grep: warning: GREP_OPTIONS is deprecated; please use an alias or script > grep: warning: GREP_OPTIONS is deprecated; please use an alias or script > git-dpm: Calling merge-patched-into-debian first... > git-dpm: ERROR: cowardly refusing to update patched to already merged > version!. Use --allow-revert to override! Ok, so as I expected, integrating a new upstream release resolved this issue for me. git-dpm import-new-upstream left me in the patched directory, and I was able to drop the last patch and then run git-dpm update-patches. Something to watch out for however. -- Brian May
Re: dropping top patch with git-dpm
On Apr 04, 2016, at 05:33 PM, Brian May wrote: >Ok, so as I expected, integrating a new upstream release resolved this >issue for me. git-dpm import-new-upstream left me in the patched >directory, and I was able to drop the last patch and then run git-dpm >update-patches. When it works, it's magic. ;) On the rare occasion where I've had to do it manually, I don't use reset. I checkout-patched then rebase -i upstream and drop the commit. I don't know if that's effectively the same thing as what you've done, and ISTR that it doesn't always work, but I know that it sometimes does . -Barry
Re: dropping top patch with git-dpm
Hi Brian, On Mon, Apr 04, 2016 at 04:35:52PM +1000, Brian May wrote: > Seems this isn't as easy as I hoped. > > brian@prune:~/tree/debian/python-modules/django-guardian$ git-dpm > checkout-patched > grep: warning: GREP_OPTIONS is deprecated; please use an alias or script > grep: warning: GREP_OPTIONS is deprecated; please use an alias or script > Updating outdated 'patched'... > Switched to branch 'patched' > You are now in branch 'patched' > brian@prune:~/tree/debian/python-modules/django-guardian$ git reset --hard > HEAD\^ > HEAD is now at 2e72565 Remove nonlocal image for Travis-ci. > brian@prune:~/tree/debian/python-modules/django-guardian$ git-dpm > update-patches > grep: warning: GREP_OPTIONS is deprecated; please use an alias or script > grep: warning: GREP_OPTIONS is deprecated; please use an alias or script > git-dpm: Calling merge-patched-into-debian first... > git-dpm: ERROR: cowardly refusing to update patched to already merged > version!. Use --allow-revert to override! This message suggests you to use --allow-revert — I believe it's what you need. From the manpage: --allow-revert Usually reverting to an old state of the patched branch is not allowed, to avoid mistakes (like having only pulled the Debian branch and forgot to run checkout-patched). This option changes that so you can for example drop the last patch in your stack. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#820001: ITP: asynctest -- unittest extension to test code using asyncio
Package: wnpp Version: N/A; reported 2016-04-04 Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org Package name: asynctest Version: 0.6.0 Upstream Author: Martin Richard URL: https://github.com/Martiusweb/asynctest License: Apache 2 Description: unittest extension to test code using asyncio The package asynctest is built on top of the standard unittest module and cuts down boilerplate code when testing libraries for asyncio. -- Ezequiel Alfie
Upstream has split a package in two -> new Debian package?
Hi! I'm the package maintainer of mercurial-keyring, a keyring extension for mercurial. Upstream has split some of the functionality of mercurial-keyring into a separate python library and pip package (mercurial_extension_utils). Do I need to create and upload a new package for this library? Or is there another way? I doubt that this library will get a second user, but you never know... For reference: https://pypi.python.org/pypi/mercurial_extension_utils https://pypi.python.org/pypi/mercurial_keyring Thanks. Christoph
Re: Packaging Grip
Hi, The Style Guide for Packaging Python Libraries[1] states that in cases like this, one should package the library for both Python 2 and 3, creating a third package that contains the executable. As this package is indeed intended to be used as a CLI application (as its description says), I've followed the examples found in packages like python-django and tox and: - Didn't used the application layout which stores files in "/usr/share/", as it has modules that needs to be imported later; - Removed the entry point script that is automatically created; - Added a custom and simple script[2] that imports and calls Grip's main function; - Ended up with a single package called "grip". As I said, I didn't invented this and followed the practices that are being used by bigger Python packages. I'm entirely open about discussing those decisions with my future sponsor in the RFS that I'll be filling later today. Regards, Tiago. [1]: https://wiki.debian.org/Python/LibraryStyleGuide#Executables_and_library_packages [2]: https://github.com/myhro/deb-grip/blob/0fc1143/debian/bin/grip -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Bug#820019: RFP: python-sframe -- scalable tabular (SFrame, SArray) and graph (SGraph) data-structures built for out-of-core data analysis.
Package: wnpp
Severity: wishlist
* Package name: python-sframe
Version : 1.8.4
Upstream Author : Dato, Inc.
* URL : https://github.com/dato-code/SFrame
* License : BSD
Programming Lang: C++, Python
Description : scalable tabular (SFrame, SArray) and graph (SGraph)
data-structures built for out-of-core data analysis.
The SFrame package provides the complete implementation of:
* SFrame
* SArray
* SGraph
* The C++ SDK surface area (gl_sframe, gl_sarray, gl_sgraph)
The SFrame contains the open source components GraphLab Create from Dato.
For more details on GraphLab Create (including documentation and tutorials)
see http://dato.com.
Some of the key features of this package are.
* A scalable column compressed disk-backed dataframe optimized for machine
learning and data science needs.
* Designed for both tabular (SFrame, SArray) as well as graph data (SGraph)
* Support for strictly typed columns (int, float, str, datetime), weakly
typed columns (schema free lists, dictionaries) as well as specialized types
such as Image.
* Uniform support for missing data.
* Query optimization and Lazy evaluation.
* A C++ API (gl_sarray, gl_sframe, gl_sgraph) with direct native access via
the C++ SDK.
* A Python API (SArray, SFrame, SGraph) with an indirect access via an
interprocess layer.
Since I am interested in this package, I am willing to help co-maintain it
(as soon as I orphan some packages of mine), especially if some other more
experienced module packager is willing to guide me through some of the
process of having a hybrid module like this one.
Also, since this package is very similar in spirit to Pandas, I'm including
the pandas mantainers as CC, in case they are interested here.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#820029: RFS: grip/4.1.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "grip" * Package name: grip Version : 4.1.0-1 Upstream Author : Joe Esposito * URL : https://github.com/joeyespo/grip * License : MIT Section : utils It builds those binary packages: grip - Preview GitHub Markdown files like Readme locally To access further information about this package, please visit the following URL: http://mentors.debian.net/package/grip Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/grip/grip_4.1.0-1.dsc - This package depends on "python-path-and-address" (RFS #819773[1]), which is not on the archive yet. It would be awesome if the sponsor could help me with both RFS bugs. Tests are commented out in "debian/rules" because they depend on a newer version of "python-responses". I've filled a bug (#820020[2]) which is now pending (thanks Ondrej Novy!). This can be fixed as soon as the updated package hits unstable. Decisions made about packaging layout (Python application vs. Python library) have been clarified on the "debian-python" mailing list[3]. I also would like to thanks Gustavo Panizzo, who gave me permission[4] to take over his ITP. Regards, Tiago. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819773 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820020 [3]: https://lists.debian.org/debian-python/2016/04/msg00017.html [4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611#17 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Upstream has split a package in two -> new Debian package?
Christoph Mathys writes: > I'm the package maintainer of mercurial-keyring, a keyring extension > for mercurial. Thank you for maintaining this in Debian. > Upstream has split some of the functionality of mercurial-keyring into > a separate python library and pip package (mercurial_extension_utils). That seems to imply there will be separate releases and versions for ‘mercurial_extension_utils’. Is that correct? > Do I need to create and upload a new package for this library? Or is > there another way? If the source is managed and released separately, with distinct release schedule and versions, yes there should be separate Debian packages for that. -- \ “If nature has made any one thing less susceptible than all | `\others of exclusive property, it is the action of the thinking | _o__) power called an idea” —Thomas Jefferson, 1813-08-13 | Ben Finney
Re: Upstream has split a package in two -> new Debian package?
On 05.04.2016 03:51, Ben Finney wrote: Christoph Mathys writes: Upstream has split some of the functionality of mercurial-keyring into a separate python library and pip package (mercurial_extension_utils). That seems to imply there will be separate releases and versions for ‘mercurial_extension_utils’. Is that correct? Yes, this is the case. If the source is managed and released separately, with distinct release schedule and versions, yes there should be separate Debian packages for that. OK. Thanks for the clear and quick response! Christoph
