Re: Updating python-jsmin
On Tue, Jan 12, 2016 at 02:40:46AM +, Mattia Rizzolo wrote: > On Tue, Jan 12, 2016 at 10:18:43AM +0800, gustavo panizzo (gfa) wrote: > > Hello > > > > anybody willing to sponsor the upload? > > > > git.debian.org:/git/collab-maint/python-jsmin.git > > > > thanks! > > I can do it, but what should I use as a orig tarball? what I get out of > uscan (from pypi) has sha256sum > 8e7f19bc2cc467bccd02322dc0a6065d06a038e311f2531af1a33b410afea081 > Please consider following a git format with packagin branch Usually I generate the orig.tar.gz from git tags myself (gbp will do it for you) and upload that. if the pkg needs a -2 release I base on that, I never used pristine-tar > (debian/unstable in your case and that's ok) + upstream branch + > pristine-tar. according to debian/gbp.conf there should be master > branch, but maybe you didn't push it? nop, accidentaly i didn't upload it > > btw, from that tarball you miss .travis.yml so I can't get the source > built. another good reason not to use tarballs from pip, its not the first time I see that. > > also, please consider fixing unused-file-paragraph-in-dep5-copyright > (you need to swap the paragraphs; in dep5 order matters). ohhh, excelent catch, I never found a solution for that error, thank you > and also please consider using https in Vcs-Browser. > (but I won't hold on those 2 if you say you don't want to bother) I will switch to https I just pushed the changes, could you upload? you will need to force as I changed the tag and I merged over the branch from alioth but the end result is fine thanks! > > > So, I'm up, but you need to give me an upstream tarball. > > > keybase: http://keybase.io/gfa > the key used to sign the tags on that repo is not the same as the one in > keybase, btw. doesn't really help. (063A6583 is the one used, 9F6C6333 > the one on keybase) > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > more about me: http://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: http://keybase.io/gfa
Re: upgrading setuptools in virtualenv leaves behind version 5.5.1
Andrey Rahmatullin writes: >> Problem is some packages will pickup pkg_resources from >> setuptools-5.5.1-py2.py3-none-any.whl instead of the new version I just >> thought I installed. > I don't see where did you install the new version. Sorry, somehow I managed to stuff up the copy and paste. I actually run "pip install -U setuptools" as below. brian@prune:~$ rm -rf /tmp/virtual/ brian@prune:~$ virtualenv /tmp/virtual Running virtualenv with interpreter /home/brian/.pyenv/shims/python2 New python executable in /tmp/virtual/bin/python2 Also creating executable in /tmp/virtual/bin/python Installing setuptools, pip...done. brian@prune:~$ . /tmp/virtual/bin/activate (virtual)brian@prune:~$ pip install -U setuptools Downloading/unpacking setuptools from https://pypi.python.org/packages/3.5/s/setuptools/setuptools-19.2-py2.py3-none-any.whl#md5=7bdac510b6bc1675a2a149eb3f81af77 Downloading setuptools-19.2-py2.py3-none-any.whl (463kB): 463kB downloaded Installing collected packages: setuptools Found existing installation: setuptools 5.5.1 Uninstalling setuptools: Successfully uninstalled setuptools Successfully installed setuptools Cleaning up... (virtual)brian@prune:~$ ls -l /tmp/virtual/lib/python-wheels/setuptools-5.5.1-py2.py3-none-any.whl -rw--- 1 brian brian 229854 Jan 14 08:31 /tmp/virtual/lib/python-wheels/setuptools-5.5.1-py2.py3-none-any.whl -- Brian May
Re: transition: python3-defaults (python3.5 as default python3) - status update
On 13/01/16 14:02, Scott Kitterman wrote: > On Wednesday, January 06, 2016 03:39:15 PM you wrote: >> b. Remove pygpgme from Testing. It has rdepends so it would kill off a few >> other packages as well: ... >> bmap-tools: bmap-tools It turns out I can drop pygpgme to a Recommends on this one: it's only conditionally imported, and if you obtained the bmap image from a trusted source (or have verified its signature manually, or it doesn't have one at all), you don't need pygpgme. I'll upload that later today. S
Re: transition: python3-defaults (python3.5 as default python3) - status update
On Wednesday, January 06, 2016 03:39:15 PM you wrote: ... > 1. pygpgme is FTBFS due to test failures (#797776). There has been no > response from the maintainers and I have been unable to determine the > source of the failures. I do not believe it is python3 version related (the > package builds with python3.5 on Ubuntu). I see two possible options: > > a. NMU to disable tests so it can be rebuilt with python3.5 support > (without at least this python3-gpgme will be totally broken once python3.5 > is default) > > b. Remove pygpgme from Testing. It has rdepends so it would kill off a few > other packages as well: > > Checking reverse dependencies... > # Broken Depends: > alot: alot > assword: assword > bmap-tools: bmap-tools > nautilus-dropbox/non-free: nautilus-dropbox [amd64 i386] > > # Broken Build-Depends: > assword: python-gpgme Discussing this before we started the transition with pochu, he indicated "b" was the preferred RT option. I did try and binNMU it again to make sure and as expected, it failed, so these packages will need to be removed from testing. > 2. Elektra is FTBFS due to unrelated test failures (#810069). The impact > of this is that python3-elektra will become uninstallable. It has no > rdepends. Presumably elektra could be temporarily removed from testing. > > 3. Geis is FTBFS for reasons unrelated to python3 (#810071). Similarly, > python3-geis will become uninstallable. Geis does have one external > rdepend, libgrip (which has no rdepends). I don't see a reason they > couldn't be temporarily removed from testing. Both these magically fixed themselves, so are no longer an issue. > 4. Pandas FTBFS on some archs (#790024 and #790025). It's a leaf package, > so it could either be partially or fully removed. This will need removal. > 5. Cython3 not currently working [3]. This appears to be due to a change > in python3.5. It affects borgbackup and s3ql only. As these are rather > late in the transition, we could probably go ahead while this is getting > sorted. These are both leaf applications that would become temporarily > uninstallable. We believe we have identified the problematic python3.5 > commit (it's also in the next python3.4 release, so it's not inherently a > transition issue) and are working with upstream to evaluate the correctness > of the change and if as a result cython needs to be changed. python3.5 has been fixed. We're still waiting for the fixed python3.5 to build on mips and a few ports archs, but the binNMUs of borgbackup and s3ql have otherwise been successful. With a little more buildd time, I expect these issues will be fully resolved. > I have test built (as of this writing libreoffice is still building) all the > unknown/bad packages that need rebuilding for this transition as well as > reviewing all the unknown packages. Due to the number of unknowns, I have > created a pad to track the status of the transition [2]. LO is mostly rebuilt, but depending on which builder and when it's picked up for mips, it may take long enough to delay things a bit. There are a few other builds I'm waiting on to finish, but everything's been uploaded/scheduled so modulo the issues above, we should be finished this week. Scott K
Re: upgrading setuptools in virtualenv leaves behind version 5.5.1
On Wed, Jan 13, 2016 at 06:43:31PM +1100, Brian May wrote: > Running virtualenv with interpreter /tmp/bbb/bin/python2 Huh? > Using real prefix '/usr' > New python executable in /tmp/virtual/bin/python2 > Also creating executable in /tmp/virtual/bin/python > Installing setuptools, pip...done. > brian@prune:~$ . /tmp/virtual/bin/activate > (virtual)brian@prune:~$ ls -l > /tmp/virtual/lib/python-wheels/setuptools-5.5.1-py2.py3-none-any.whl > -rw--- 1 brian brian 229854 Jan 13 18:34 > /tmp/virtual/lib/python-wheels/setuptools-5.5.1-py2.py3-none-any.whl > > So the old version of setuptools is still there. It's the version installed by virtualenv, from the python-setuptools-whl package. > Problem is some packages will pickup pkg_resources from > setuptools-5.5.1-py2.py3-none-any.whl instead of the new version I just > thought I installed. I don't see where did you install the new version. -- WBR, wRAR
