Re: RFS: python-keyring 1.4-1
On Mon, Jun 17, 2013 at 10:53 PM, Sebastian Ramacher wrote: > On 2013-06-14 14:55:58, Dmitry Shachnev wrote: >> On Wed, Jun 12, 2013 at 2:34 AM, Sebastian Ramacher >> wrote: >> > I'd put the script in /usr/share/doc/python-keyring or >> > /usr/share/python-keyring. There's no need to put it in /usr/bin. >> >> It's now in /usr/share/python-keyring. > > I think lines 48 and 49 can be removed too. As I said on IRC, if we drop these lines, removing of crypted_password won't be saved. >> > What's the status of all the other tests? Many tests are skipped because >> > of missing dependencies. >> >> Gnome-keyring-daemon refuses to run in xvfb. As I do not know other >> Secret Service implementations, it's currently impossible to test >> GNOME and Secret Service backends (libsecret's upstream testsuite has >> some code for mocking Secret Service, but I didn't yet have time to >> test it). > > If we can't run them reliably I'd rather see them disabled. These tests either succeed or are skipped — i.e. do not affect the build. Why should we disable them? >> Python-fs is too old in Debian (python-keyring needs at least 0.4), so >> this test can't be run also. > > What about the gdata tests? Gdata is a Google backend, so these tests do nothing when you don't have an internet connection. Also (with my python-gdata maintainer hat on), I would avoid adding any new (build-)dependencies on it because it's mostly dead and unmaintained code. > It currently FTBFS twice in a row: > | dpkg-source: info: local changes detected, the modified files are: > | python-keyring-1.4/keyring.egg-info/PKG-INFO > | python-keyring-1.4/keyring.egg-info/SOURCES.txt > | python-keyring-1.4/keyring.egg-info/dependency_links.txt > | python-keyring-1.4/keyring.egg-info/entry_points.txt > | python-keyring-1.4/keyring.egg-info/requires.txt > | python-keyring-1.4/keyring.egg-info/top_level.txt Fixed by removing keyring.egg-info in clean target. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakimphu2fg_p8sy3-_wgtfplq_jjqp7rdjbnucxytd9c3by...@mail.gmail.com
Re: RFS: python-keyring 1.4-1
On 2013-06-18 18:21:27, Dmitry Shachnev wrote: > >> > What's the status of all the other tests? Many tests are skipped because > >> > of missing dependencies. > >> > >> Gnome-keyring-daemon refuses to run in xvfb. As I do not know other > >> Secret Service implementations, it's currently impossible to test > >> GNOME and Secret Service backends (libsecret's upstream testsuite has > >> some code for mocking Secret Service, but I didn't yet have time to > >> test it). > > > > If we can't run them reliably I'd rather see them disabled. > > These tests either succeed or are skipped — i.e. do not affect the > build. Why should we disable them? Because they cause the package to FTBFS if python-secretstorage is installed and there's no gnome-keyring or dbus session available. > >> Python-fs is too old in Debian (python-keyring needs at least 0.4), so > >> this test can't be run also. > > > > What about the gdata tests? > > Gdata is a Google backend, so these tests do nothing when you don't > have an internet connection. Also (with my python-gdata maintainer hat > on), I would avoid adding any new (build-)dependencies on it because > it's mostly dead and unmaintained code. Fine with me then. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Re: RFS: python-keyring 1.4-1
On Jun 18, 2013 7:33 PM, "Sebastian Ramacher" wrote: > > On 2013-06-18 18:21:27, Dmitry Shachnev wrote: > > >> > What's the status of all the other tests? Many tests are skipped because > > >> > of missing dependencies. > > >> > > >> Gnome-keyring-daemon refuses to run in xvfb. As I do not know other > > >> Secret Service implementations, it's currently impossible to test > > >> GNOME and Secret Service backends (libsecret's upstream testsuite has > > >> some code for mocking Secret Service, but I didn't yet have time to > > >> test it). > > > > > > If we can't run them reliably I'd rather see them disabled. > > > > These tests either succeed or are skipped — i.e. do not affect the > > build. Why should we disable them? > > Because they cause the package to FTBFS if python-secretstorage is > installed and there's no gnome-keyring or dbus session available. I've fixed this in upstream SecretStorage and added a temporary patch to python-keyring to workaround this failure. -- Dmitry Shachnev
Recommend package not yet in Debian
Hello, I am packaging Pybik 1.1 that uses python3-pyicu. python3-pyicu is in Ubuntu, but not in Debian (bug #671361). What should i do? 1. Just "Recommends: python3-pyicu" and rely the package is coming sometime 2. "Recommends: python3-pyicu" and target experimental 3. This way: http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ 4. ??? Vcs-Svn: svn://anonscm.debian.org/python-apps/packages/pybik/trunk/ Vcs-Browser: http://anonscm.debian.org/viewvc/python-apps/packages/pybik/trunk/ Thanks, B.C. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51c0a25d.50...@gmx.de
Re: Recommend package not yet in Debian
On Tue, Jun 18, 2013 at 08:09:33PM +0200, B. Clausius wrote: > I am packaging Pybik 1.1 that uses python3-pyicu. python3-pyicu is in > Ubuntu, but not in Debian (bug #671361). What should i do? > 1. Just "Recommends: python3-pyicu" and rely the package is coming sometime > 2. "Recommends: python3-pyicu" and target experimental Packages in main cannot recommend packages not in main even if you target experimental. -- WBR, wRAR signature.asc Description: Digital signature
Re: Recommend package not yet in Debian
* B. Clausius , 2013-06-18, 20:09: 1. Just "Recommends: python3-pyicu" and rely the package is coming sometime I've been doing this for my packages (with s/pyicu/$somethingelse/ of course). 2. "Recommends: python3-pyicu" and target experimental This should work, too. 3. This way: http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ I don't see how is that better that 1 or 2. It hides the problem rather than fixing it. 4. ??? Ping the maintainer? #671361 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130618183149.ga6...@jwilk.net
Re: Recommend package not yet in Debian
* Jakub Wilk , 2013-06-18, 20:31: 1. Just "Recommends: python3-pyicu" and rely the package is coming sometime I've been doing this for my packages (with s/pyicu/$somethingelse/ of course). Though that works only if you can predict the package name. And I believe the Ubuntu's choice of package name is wrong: http://bugs.debian.org/671361#21 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130618184500.ga7...@jwilk.net
Re: Recommend package not yet in Debian
On 2013-06-18, B. Clausius wrote: > Hello, > > I am packaging Pybik 1.1 that uses python3-pyicu. python3-pyicu is in > Ubuntu, but not in Debian (bug #671361). What should i do? > 1. Just "Recommends: python3-pyicu" and rely the package is coming sometime Do you plan on ensuring the package is coming soon? if yes, I would go for that option, even if it is shortly introducing policy violations. /Sune -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnks19ua.j8.nos...@sshway.ssh.pusling.com
Re: how could I help?
* Stéphane Blondon , 2013-06-15, 12:40: I want to change my way of contributing to Debian. I wonder if I could help the debian-python. Some ideas: * Adopt a package: http://wnpp-by-tags.alioth.debian.org/tags/implemented-in/python.html (But note that maintaining packages you don't use is usually a bad idea!) * Provide patches for these bugs: http://udd.debian.org/cgi-bin/python_bugs.cgi (Not necessarily all of them at once. ;P) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130618220630.ga4...@jwilk.net
Re: Joining Python Modules Packaging Team
On 9 June 2013 08:56, Jakub Wilk wrote: > python-django-tables2 > python-django-filters > python-ajax-select > Out of curiosity, why python-ajax-select and not, python-django-ajax-select? -- Brian May
django-tables package
Hello, Can I please get somebody to review my django-tables package before I upload to Debian? I copied the updates from my django-filter package. Code is at http://anonscm.debian.org/viewvc/python-modules/packages/django-tables/trunk/debian/ using: http://ftp.de.debian.org/debian/pool/main/d/django-tables/django-tables_0.13.0.orig.tar.gz As far as I can tell it should be OK to me, although a bit nervous about the following build messages from Sphinx: loading intersphinx inventory from http://docs.python.org/dev/objects.inv... loading intersphinx inventory from http://docs.djangoproject.com/en/dev/_objects/... Seems to suggest that it is getting files from external locations during the build. If this is a problem, how do I fix it? Thanks -- Brian May
Re: django-tables package
On Wednesday, June 19, 2013 01:57:47 PM Brian May wrote: > Hello, > > Can I please get somebody to review my django-tables package before I > upload to Debian? > > I copied the updates from my django-filter package. > > Code is at > > http://anonscm.debian.org/viewvc/python-modules/packages/django-tables/trunk > /debian/ > > using: > > http://ftp.de.debian.org/debian/pool/main/d/django-tables/django-tables_0.13 > .0.orig.tar.gz > > As far as I can tell it should be OK to me, although a bit nervous about > the following build messages from Sphinx: > > loading intersphinx inventory from http://docs.python.org/dev/objects.inv... This one can be found in /usr/share/doc/python*/html/objects.inv > loading intersphinx inventory from > http://docs.djangoproject.com/en/dev/_objects/... > > Seems to suggest that it is getting files from external locations during > the build. If this is a problem, how do I fix it? Patch to use the installed copy. I had to do this once before. Not sure where to find the django one. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1531446.dVsG21l3ky@scott-latitude-e6320
Re: django-tables package
On 19 June 2013 14:33, Scott Kitterman wrote: > Patch to use the installed copy. I had to do this once before. > How do I do this? I don't see any references to objects.inv in the upstream source code for django-filter, and I am not really sure what these files are used for. -- Brian May
Re: python3.3 status
Here's a further update on packages pertaining to the 3.3 transition: boost1.49 Fixed flufl.bounce builds now that zope.interface is updated hivex FTBFS fixed, dependencies fixed, nothing further to do. libguestfs - No longer FTBFS on amd64, but does on i386, #710545, now builds for all python3 versions > nuitka FTBFS unrepoducible > pyepr builds successfully, but puts dbg extensions into wrong package: > #708011 pyside Fixed, needs python3.3 as default to migrate to testing, needs shiboken fixed on mipsel. > > python-astropy Builds fine, but doesn't actually put the python3 build in > a binary, no impact on the transition python-cffi - Built against 3.2/3.3 - nothing further to do. python-csb - Builds now, nothing further to do. > python-scipy FTBFS with new Cython/Numpy: #707315 Needs new, new cython > which is ready in svn python-stem Builds now, but has other issues unrelated to transition python-wadllib - Builds now > pytango - Shouldn't have been removed from the list, FTBFS on s390 - #711761 yapsy - builds now, nothing further to do. zope.interface - Uploaded zope.exceptions - Uploaded zope.component - Uploaded > > morse-simulator - Builds, but depends are FUBAR: #712014 > All of the red in > http://release.debian.org/transitions/html/python3.3.html > is due to open bugs. The binNMUs that could be done after python-numpy was > uploaded are done except those blocked by bugs. It would still be worth > doing some investigation of the unknown packages to see if they are > generating dependencies correctly. > Here's the other unknown packages: > boost1.53 - builds, but doesn't generate python related depends right > file - No effect on the transition #709269 > liblouis - Shouldn't be part of the transition, build-dep is wrong #712076 > libsigrokdecode - #709406 marked pending since May 28, can ignore > postgresql-9.1 - Only depends on libpython3.2. Will need NMU after 3.3 is > default. I think this should have an interpreter dependency as well, but > didn't file a bug as I'm not sure. I would appreciate it if someone would > have a look. > pycxx - Will need sourceful update after python3.3 is default > pymongo - If it was packaged properly, it would need a binNMU, but it's not, > so it's not an issue for the transition, #712112. sqlalchemy - Builds fine, no action needed for transition, ideally would build- dep on python3-all subunit - No action needed for transition, but multiple bugs need dealing with, #708077, #709540, and #712203 yafaray - FTBFS fixed. Only supports default python3, so it will need binNMU after python3.3 is default. shiboken - back on the list after FTBFS on mipsel - blocking pyside build > znc > magics++ - No python3 content in the binaries, no effect on transition > pygrib - Doesn't actually build python3 packages yet, no effect on > transition. > uwsgi - uwsgi-plugin-python3 only depends on libpython3.2 (and also 3.3 when > rebuilt). Like postgresql-9.1, I think this should probably have a python3 > dependency. It'd be nice if someone could have a look. I've marked the things that I think block python3.3 as default a blocking the transition bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708536 Is there anything there that shouldn't be a blocker? I think scipy is the biggest issue and that apparently needs cython updated first. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1431099.aGNH6O39L1@scott-latitude-e6320
Re: django-tables package
On Wednesday, June 19, 2013 02:47:44 PM Brian May wrote: > On 19 June 2013 14:33, Scott Kitterman wrote: > > Patch to use the installed copy. I had to do this once before. > > How do I do this? I don't see any references to objects.inv in the > upstream source code for django-filter, and I am not really sure what these > files are used for. This is what I came up with when I ran into this before: http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=20272 Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50803022.xiFY0qMhcc@scott-latitude-e6320
Re: python3.3 status
Dnia 2013-06-19, śro o godzinie 00:53 -0400, Scott Kitterman pisze: [ cut ] > I've marked the things that I think block python3.3 as default a blocking the > transition bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708536 > pyopencl package fixing FTBFS #711926 (which block #708536) is in NEW now. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
