[Python-modules-team] Bug#647210: How many ...
Probably just qwt. IIRC last time I updated python-qt4, qwt didn't like it either. I believe qwt does a runtime check and aborts as you describe if the version doesn't match what it was compiled again. I don't think this is actually a python-qt4 bug, but a feature of qwt. I will be traveling and only have intermittent Internet access for the next several days, so if that proves not to be the case, additional investigations/NMUs if needed welcome. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#619096: PyQt/QsciScintilla Breakage
It's being addressed. See #647210. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#648085: Bug#648085: python-qt4: wrong dependency to libqtwebkit4
On 11/08/2011 04:48 PM, Picca Frédéric-Emmanuel wrote: ... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647695 It seems to me that there is an incompatibility between python-qt4 (4.8.3-4, 4.8.6-2) and libqtwebkit 2.1.0~2011week09-3 And that the right dependency of python-qt4 should be at least (>= 2.1.0~2011week13-2) so in your opinion, am I right ? and what is for you the right way to solve this issue ? ... My guess is a Qt webkit bug. Can you provide a reduced test case that demonstrates the problem? ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#653293: Caused by new sip4
I can confirm the bug, but it's a byproduct of the new sip4. Downgrading to the sip4 in Testing produces a successful build. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#653293: Needs newer PyQt4
Upstream says this Sip4 version only works with PyQt4 4.9, so I'll leave this RC bug open against Sip4 to keep the new version out of Testing until we can get PyQt4 (python-qt4) updated. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#653567: Bug#653567: python3-pyqt4 fails to install
I believe I see what my mistake was. Thanks, Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#558389: Bug#558389: Package fails to install
Already fixed. Your PPA is out of date. If you have problems with an Ubuntu PPA, please deal with the PPA owner and not the Debian BTS. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Orphaned python modules
On Tuesday, January 03, 2012 08:22:35 PM Michael Gilbert wrote: > Hi, > > I noticed that there are quite a few python modules (pyglew, daap, > pyxine, pycg, dhm, etc.) that are currently under maintenance by this > team on the orphaned package list: > http://qa.debian.org/orphaned.html > > I was going to do a QA upload for one of the packages, but it struck > me as wrong to take the it away from your oversight without asking. > Did you really mean to give these packages up for adoption, or did you > just want to remove Sandro from the uploaders list? > > Please CC me on replies as I'm not subscribed to this list. Per policy 3.3 there needs to be a human in uploaders if the team is maintainer, so absent a volunteer for that, I think QA uploads are appropriate. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#659356: Patch source
Did you get the patch directly from upstream or is it in their latest snapshot? Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#628199: Probably fixed via rebuild
The relevant packages have been rebuilt several times since this bug was filed and I can't reproduce the error in either python2.6, 2.7, or 3.2. I believe it's resolved. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Packages renaming erroneous process
On Saturday, February 18, 2012 09:39:55 AM Aleksey Midenkov wrote: > Please, when renaming packages don't forget to add conflict with older > name. I am not the first time stumbling upon 'trying to overwrite ... > which is also in package' error with python packages. That were on > upgrades from 2.5 to 2.6. And that continues on upgrade 2.6 to 2.7. > Please, add some rule to your business workflow process. I'm not very > sure is it Debian or Ubuntu responsible for that particular errors. > But that would be good to mention everywhere. Thank you! > > Current problems were noticed on following upgrades: > > python-sip4 -> python-sip The last time python-sip4 was a real (non-transitional package) was in Lenny, so no conflicts/breaks should be needed for wheezy. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#661854: Forwarded to upstream mailing list
signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#535759: Needs to be robust
I think that such a method would be fragile. I don't think a solution that requires maintainers to manually review code from new upstream releases to adjust dependencies is adequate. To do such a thing we'd need a tools to search the code and generate proper dependencies. I didn't think much on design though. I'm open to suggestions. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#664743: storm: Watch file no longer works
Package: storm Version: 0.19-1 Severity: minor Tags: patch Launchpad recently dropped http:// file downloads, so Storm's watch file stopped working. Patch to fix attached. diff -Nru storm-0.19/debian/changelog storm-0.19/debian/changelog --- storm-0.19/debian/changelog 2011-11-13 19:24:03.0 -0500 +++ storm-0.19/debian/changelog 2012-03-20 09:54:11.0 -0400 @@ -1,3 +1,9 @@ +storm (0.19-2) unstable; urgency=low + + * Fixed watch file to work with Launchpad again + + -- Scott Kitterman Tue, 20 Mar 2012 09:53:49 -0400 + storm (0.19-1) unstable; urgency=low * New upstream release. diff -Nru storm-0.19/debian/watch storm-0.19/debian/watch --- storm-0.19/debian/watch 2010-07-28 19:30:39.0 -0400 +++ storm-0.19/debian/watch 2012-03-20 09:54:31.0 -0400 @@ -1,2 +1,2 @@ version=3 -https://launchpad.net/storm/+download http://launchpad.net/storm/trunk/.*/storm-(.*)\.tar\.bz2 +https://launchpad.net/storm/+download https://launchpad.net/storm/trunk/.*/storm-(.*)\.tar\.bz2 ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#667910: Forwarded
Sent to the PyQt development list. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#667910: Fixed upstream
This should be fixed as of tonight's upstream snapshot and will be in the next python-qt4 release. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#657211: Steps to reproduce
Please provide the exact steps you used to run this demo so I can try to reproduce the problem. Thanks, Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#657211: Steps to reproduce
On Saturday, April 28, 2012 01:41:41 PM Yann Dirson wrote: ... > Looking at /usr/share/doc/python-qt4-doc/examples/README, no exact > command to run the examples is given, but the hint about > examples/demos/qtdemo led me to launch: > > /usr/share/doc/python-qt4-doc/examples/demos/qtdemo/qtdemo.py > > and from there, select "Qt declarative examples" and "Corkboards". > Still happens on today's wheezy. Thanks. Got it figured out. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#671371: python3-pyqt4: Segfault for simpe canvas view program
The examples are meant to be run from examples/demos/qtdemo/qtdemo.py. It's not been ported to python3 yet, so there's not a good way to do this as provided from upstream. If I run graphicsview/anchorlayout.py with python2.7 I also get a segmentation fault, so there is something worth looking into here. I'm not sure if it's python/python3 or PyQt at fault though. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#619096: Next steps
Since the problem is triggered by the Qt version changing, it's not clear to me how to catch this automatically. I'll see what I can do about this case. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#619096: Rebuilds queued
Queued binnmus for qscintilla2 which should deal with this. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#671548: python-qt4 4.9.1-2 broke hgview
I believe this will be fixed by the qscintilla2 binNMU I had done today. Please check if you still have this problem after updating it. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#671605: RE : Bug#671605: Acknowledgement (python-qt4 broke python-guiqwt)
On Saturday, May 05, 2012 11:07:29 AM PICCA Frédéric-Emmanuel wrote: ... > so a binNMU of pyqwt5 should be enought ... Scheduled. Please let me know in the bug if that solves it for you. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#672108: python-qt4: segfault when passing a QRect to QWidget::update()
If you could provide a reduced test case I can use to replicate this and report it upstream, I'll work with them to see what we can do. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#671919: Bug#671919: python-sip: segfault in python-sip in use with calibre
Can you rebuild calibre and see if that fixes it? ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#672312: Bug#672312: pyqt4-dev-tools: segfault when using pyuic4
Please provide a minimal test case I can use to confirm the bug and discuss it with upstream. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#672312: Bug#672312: Bug#672312: pyqt4-dev-tools: segfault when using pyuic4
On Thursday, May 10, 2012 05:28:56 AM B.Cordier wrote: > I've attached a simple .ui file, you just need to run : > > pyuic4 test.ui -o test.py > > It should return a segfault. No segfault here on i386. Are you on amd64? Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#672494: Bug#672494: python-qt4: Python plasmoids causes plasma-desktop to crash -> KDE is unusable
This will probably be fixed by a pykde4 rebuild, but first akonadi, kde4libs and kdepimlibs need to be rebuilt. This is in progress today. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#672312: Bug#672312: Bug#672312: pyqt4-dev-tools: segfault when using pyuic4
On Friday, May 11, 2012 02:58:35 AM B.Cordier wrote: > /usr/lib/python2.7/dist-packages/PyKDE4/kdeui.so PyKDE4 is known to be broken at the moment. It needs to be rebuilt after akonadi, kde4libs, and kdepimlibs (which are in progress). Once that's done, then we'll see if there's still a problem. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#671919: binNMUs for sip4 scheduled
Please test again 4.13.2-1+b1 after it is built. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#672312: Bug#672312: Bug#672312: pyqt4-dev-tools: segfault when using pyuic4
PyKDE is reported to be working now, so please retry and see if the problem still appears. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#673925: Needs python-opengl ported to python3
For Python, we have python-qt4-gl. It depends on python-opengl. Python- opengl is not ported to Python 3 yet, so there's no way to support PyQt4/QtOpenGL yet. We'll support it when the dependencies are available (python3-opengl) and it's part of what upstream ships. I imagine it'll be supported, but I've no idea the timing since it's dependent on developments outside Debian. BTW, the package name will be python3-pyqt4.qtopengl when it's available. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#673925: Needs python-opengl ported to python3
The dependency relationship predates my work on the package, so I've assumed it's correct. Perhaps it was a some point and it's not now. Next time I update the package, I can see if I can build this module for Python 3. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#676536: Patch sent upstream
Just for the record, reported upstream with patch. See http://pyyaml.org/ticket/247 Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#679819: Bug#679819: Dropping Provides field broke depending software (python-avogadro)
The Avogadro dependency is incorrect and should be fixed. Depends: python2.7, python-qt4 will do what you want. Since, if Avogadro needs 2.7, you need to depend on it directly, also depending on python2.7-qt4 is redundant. Scott K P.S. Due to a multi-day power outage all I've got to work from is my phone. Apologies in advance if my reply seems curt.___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#679819: Dropping Provides field broke depending software (python-avogadro)
That's a bug in the policy I failed to notice. It should be restricted to
packages that build modules only for the non-default version of Python which
Avogadro doesn't. One or the other package needs to be changed. I agree with
that.
python-avogadro is the only package in the archive that depends on python2.7-
qt4. I think it makes more sense to fix it there than in python-qt4 and depend
on a bug in poilcy, but since that's what it says, I'll fix it in python-qt4 if
you prefer.
Note that XS-Python-Version: current is long deprecated and has never been
supported by dh_python2, so that part of your package isn't doing anything.
Here's all that's needed:
diff -Nru avogadro-1.0.3/debian/changelog avogadro-1.0.3/debian/changelog
--- avogadro-1.0.3/debian/changelog 2012-06-06 16:55:16.0 -0400
+++ avogadro-1.0.3/debian/changelog 2012-07-01 20:10:16.0 -0400
@@ -1,3 +1,11 @@
+avogadro (1.0.3-6) unstable; urgency=low
+
+ * Drop semi-obsolete use of version specify python packages to restore
+installability (python-qt4 stopped providing one of the required packages
+(Closes: #679819)
+
+ -- ... Sun, 01 Jul 2012 20:08:53 -0400
+
avogadro (1.0.3-5) unstable; urgency=low
* debian/control (Uploaders): Removed Jordan Mantha. Thanks for your work.
diff -Nru avogadro-1.0.3/debian/control avogadro-1.0.3/debian/control
--- avogadro-1.0.3/debian/control 2012-06-06 16:50:23.0 -0400
+++ avogadro-1.0.3/debian/control 2012-07-01 20:08:49.0 -0400
@@ -99,6 +99,9 @@
Priority: extra
XB-Python-Version: ${python:Versions}
Depends: ${misc:Depends},
+ python-numpy,
+ python-qt4,
+ python-sip,
${pyavo:Depends},
${python:Depends},
${shlibs:Depends},
diff -Nru avogadro-1.0.3/debian/rules avogadro-1.0.3/debian/rules
--- avogadro-1.0.3/debian/rules 2012-05-04 10:42:44.0 -0400
+++ avogadro-1.0.3/debian/rules 2012-07-01 20:07:32.0 -0400
@@ -31,6 +31,3 @@
dh_numpy -ppython-avogadro
dh_sip
-override_dh_gencontrol:
- dh_gencontrol -- -V'pyavo:Depends=python$(PYTHON_VERSION)-numpy,
python$(PYTHON_VERSION)-qt4, python$(PYTHON_VERSION)-sip'
-
You'll find that it makes absolutely no difference about what packages are
pulled in when it's installed. If you'd be willing to fix it this way, I'll
take on talking to the release team about it.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#679819: Dropping Provides field broke depending software (python-avogadro)
On Wednesday, July 04, 2012 10:19:34 PM Daniel Leidert wrote: ... > If the policy is not correct, it should be fixed after Wheezy release. > I'd appreciate a pointer from your site, when you start the discussion. ... After the Wheezy release having the provides will be entirely superfluous since there will very quickly only be python2.7 supported. The post-Wheezy policy fix will be very easy. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#679819: Dropping Provides field broke depending software (python-avogadro)
I can. Thanks for the second opinion. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#679819: Bug#679819: Dropping Provides field broke depending software (python-avogadro)
sip4 will cause you the same problem. I'll take care of that too. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#679819: Bug#679819: Dropping Provides field broke depending software (python-avogadro)
On Thursday, July 05, 2012 07:59:19 AM Scott Kitterman wrote: > sip4 will cause you the same problem. I'll take care of that too. Actually that's wrong. Sip4 is fine. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#680837: Fix on the way
I have a patch from upstream that I'm testing. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#681583: Uploading NMU
Uploading directly since this is over a week with no response from the maintainer. NMU diff is identical to the last patch attached except for unstable/UNRELEASED. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#681583: Ignore the last message
That was meant to go to a different bug. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#682623: Bug#682623: uicilibris: FTBFS: /bin/sh: 1: pyuic4: not found
Looks like a dh_python3 bug that mistakenly rewrote that shebang. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#683108: Bug#683108: ipython: python3 shebangs
On Saturday, July 28, 2012 06:00:19 PM Yaroslav Halchenko wrote: > my guess is that it needs overrides for dh_python* calls like I did > recently for cython: > > override_dh_python2: > dh_python2 -pcython > > override_dh_python3: > dh_python3 -pcython3 > Yes. Something like that should work. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#702445: segfault when calling PyQt4.QtGui.QIcon.themeSearchPaths()
>From upstream: > Almost certainly a user error/Qt "feature". Try creating a QApplication > instance first. Please try this and report back if you are still having a problem. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Uploads/Rebuilds for sip4 update
The following packages depend on a version of sip-api and will need to be rebuilt/updated once sip4 is uploaded to unstable as part of getting the addition of python3.3 sorted. DD list is attached (I've only included uploaders in this direct email for packages that aren't team maintained. python-avogadro (avogadro) - binNMU python-ball (ball) - boost related FTBFS #707205 python-ballview (ball) - boost related FTBFS #707205 calibre-bin (calibre) - binNMU after python-qt4 python-kde4 (pykde4) - source uploade needed for python3.3 after python-qt4 python-qwt3d-qt4 (pyqwt3d) - binNMU after python-qt4 python-qwt5-qt4 (pyqwt5) - binNMU after python-qt4 python-qt4 - source upload needed for python3.3 python-qscintilla2 (qscintilla2) - binNMU after python-qt4 serna - FTBFS sfworks/xpath/impl3/Tokenizer.cxx:33:33: fatal error: xpath/xpathParser.hpp: No such file or directory veusz-helpers (veusz) - binNMU after python-qt4 veusz-helpers-dbg (veusz) - binNMU after python-qt4 The serna FTBFS in my test is the only one I couldn't replicate with current sip4. I plan on coordinating this with the release team to get the binNMUs scheduled and dealing with fixing python-qt4/pykde4. I'm not sure what to do about serna. Scott KAndreas Hildebrandt ball (U) Bernd Zeimetz python-qt4 (U) Daniel Leidert (dale) avogadro (U) Debian Med Packaging Team ball Debian Python Modules Team pyqwt3d (U) pyqwt5 (U) python-qt4 qscintilla2 Debian Qt/KDE Maintainers pykde4 Debichem Team avogadro Gudjon I. Gudjonsson pyqwt3d pyqwt5 qscintilla2 (U) Jeremy Sanders veusz (U) Joachim Breitner serna-free Martin Pitt calibre (U) Mathieu Malaterre serna-free (U) Michael Banck avogadro (U) Michael Casadevall python-qt4 (U) Michael Meskes pykde4 (U) Miriam Ruiz calibre Modestas Vainius pykde4 (U) Python Applications Packaging Team veusz Scott Kitterman python-qt4 (U) qscintilla2 (U) Sune Vuorela pykde4 (U) Torsten Marek python-qt4 (U) qscintilla2 (U) signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#707157: python-qt4: FTBFS: configure.py: error: '/usr/lib/python3.3/config' is not a directory
Waiting on the release team to approve a sip4 transition (#707239). ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#709138: Bug report contains non-free content and cannot be processed
On Tuesday, May 21, 2013 12:16:19 PM Jakub Wilk wrote: > Hi Scott! > > What do you mean by "non-free content"? The reporter specified the bug report was covered by non-free license. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Bug#709138: Bug report contains non-free content and cannot be processed
On Tuesday, May 21, 2013 03:30:06 PM Daniel Kahn Gillmor wrote: > On 05/21/2013 03:15 PM, Clint Byrum wrote: > > On 2013-05-21 09:59, Jakub Wilk wrote: > >> * Scott Kitterman , 2013-05-21, 06:20: > >>>> What do you mean by "non-free content"? > >>> > >>> The reporter specified the bug report was covered by non-free license. > >> > >> Oh come on. Sure, it's silly to "release" a bug report under a > >> non-free license. But if we suddenly start caring about bug report > >> licences, then we might as well shut down the whole BTS, as the vast > >> majority of submissions don't come with any license at all. > > > > I am not a laywer, but this is my opinion. Under most definitions of > > copyright, a bug report's copyright belongs to its author. We host them > > in the BTS at their request, so I don't believe we need any further > > license. However if a poster asked to have their material removed, I > > think we'd be obligated to remove it. > > For clarity: the original poster of #709138 asked no such thing; the > poster merely asserted a CC BY-NC license in the .sig of their e-mail. No, they said, "My quotes in this email licensed under ..." I read that as anything they typed. That said, I agree there's no obligation to remove. If they didn't want it published in the BTS, then they shouldn't have sent it there. > Despite the fact that i find the NC clause troublingly vague (and > undoubtably non-dfsg-free), CC BY-NC is clearly no worse than the > overwhelming majority of bug reports which come with no license > information at all. > > Debian does not demand that bug reports themselves be DFSG-free, and > closing a bug report due to non-DFSG-free licensing of the bug report > itself seems silly to me. Don't we want to fix bugs? how can we do > that if we don't know about or acknowledge them? I think this sort of thing is obnoxious and annoying and what I did is point out behavior inconsistent with our values. Marking the report closed does not also require forgetting about the issue raised. Love the bug, not the bug report. > let's support our users and appreciate them when they report problems; > this is how debian gets better. Yes, but ... I think obnoxiousness in bug reports should not be ignored either. > Thank you Jakub for identifying the technical problem that needed fixing > here. :) Agreed (and in case you're wondering, I did plan to actually look at it later in the week - I felt I took on that responsibility when I closed the bug - Jakub saved me the work and I appreciate it). Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Bug#709138: Bug report contains non-free content and cannot be processed
On Wednesday, May 22, 2013 12:57:45 AM Daniel Kahn Gillmor wrote: > On 05/21/2013 10:23 PM, Scott Kitterman wrote: > > On Tuesday, May 21, 2013 03:30:06 PM Daniel Kahn Gillmor wrote: > >> For clarity: the original poster of #709138 asked no such thing; the > >> poster merely asserted a CC BY-NC license in the .sig of their e-mail. > > > > No, they said, "My quotes in this email licensed under ..." I read that as > > anything they typed. > > I don't think we're actually in disagreement on these factual matters, > so i am not sure what your "No," is about. I guess I misread then. I thought you were saying they only asserted the license against the .sig. > > I think this sort of thing is obnoxious and annoying and what I did is > > point out behavior inconsistent with our values. Marking the report > > closed does not also require forgetting about the issue raised. Love the > > bug, not the bug report. > > i'm sorry, but i think you are mistaken about the nature of the BTS. > > http://www.debian.org/Bugs/Developer#closing clearly says: > > Debian bug reports should be closed when the problem is fixed. Problems > in packages can only be considered fixed once a package that includes > the bug fix enters the Debian archive. > > This criterion was not met. The bug report should not have been closed. I can agree with this. > > Yes, but ... I think obnoxiousness in bug reports should not be ignored > > either. > > Sure, and if you had politely pointed the bug reporter to one of the > many places where reasonable people have taken apart the CC NC clause, > and explained why it might not be effective at promoting the freedoms we > all want to see expanded, that would have been a perfectly reasonable > response. I don't know how to explain my feelings about this in a way that wouldn't be escalatory, which I don't think is needed. I agree closing the bug wasn't the best way to deal with it. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#709400: Not a serious bug
hppa is no longer an official Debian architecture, si this is not an RC bug. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#711457: python-qt4: insufficient build-depends
It was introduced in 3.2.3-8. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#515634: Unable to replicate Debian Bug report #515634 (python-yaml: YAML loader complains about non-unique anchors)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515634 With python-yaml 3.09-1 I am unable to reproduce this problem. I'm not sure if I have set up the test case correctly. Can you still reproduce this error? Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Debian Sagemath dependencies
"RS Chakravarti" wrote: >Dear maintainers, > > > >Sagemath depends on python-processing > >which is in Lenny (i386) > >but not in Squeeze or Sid. > > > >Also, it depends on python-2.5 > >but not on 2.6. > > > >Upgrading python removes sagemath. > > > >If possible please fix these problems. > What this needs is a newer version of sagemath packaged. This is a major job that, last I heard, the maintainer did not have time for. If you are interested in the package, you might consider contacting him and asking to help. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#589349: Try removing .pyc files
I can't reproduce this either. A quick survey of Google results seems to indicate this can be a sign of a corrupted .pyc file. I'd recommend removing the .pyc files in /usr/lib/python2.6/dist-packages/yaml and then try again. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#591652: Rebuild will fix, but not yet
Rebuilding with the current dh_python3 will fix this, but there's no point in binNMU since a sourceful upload is needed to fix 591957. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#582313: Wishlist due to improved clamav ABI stability
Now that clamav is maintaining API/ABI stability, this should be much more maintainable through the full release cycle. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#605365: Bug#605365: Bug#605365: pyopenssl: Use dh_python2 instead of dh_pysupport
On Monday, November 29, 2010 09:42:55 am Daniel Holbach wrote: > On 29.11.2010 15:17, Sandro Tosi wrote: > >> * Rebuild with Python2.7. > > > > In Debian we would have scheduled a binNMU and get done with it, so > > there's nothing in the package to be done. > > In Ubuntu we don't have binNMUs. We need to do source uploads for rebuilds. > Yes, but a simple no change rebuild (0.10-1build1) would have been sufficient in this case and accomplished what a binNMU in Debian would have done. > >> * debian/rules: change dh_pysupport to dh_python2. > >> * debian/control: Removed python-support from Build-Depends. > > > > what's the point of this change? > > The way I understood > http://www.mail-archive.com/debian-pyt...@lists.debian.org/msg06566.html > was that the idea was to move away from dh_pysupport in favour of > dh_python2. > > As pyopenssl needed a rebuild in Ubuntu in order to give us OpenSSL for > 2.7 (I needed it for a papyon build), I thought I'd make the change in > the same upload and forward the changes to you. In general, this is the plan, but it's really up to package maintainers to decide when and if to make the move. > >> We thought you might be interested in doing the same. > > > > "we" as in? why not discussing it with us BEFORE apply a useless diff > > diverging from debian? > > "we" as in the default piece of text that "submittodebian" provides. > > I'm not sure you intended it this way, but your answer comes across as > quite a bit agitated. Please take my word for it that I only had the > best intentions. > > As I said: to me it looked like a straight-forward thing to get things > in the Ubuntu archive into a build-able state again. I'm sorry if I > misunderstood things. (I still don't understand what exactly what about > my change was wrong.) Daniel, I'm sure you were just trying to do the right thing by the change and by forwarding it to Debian, but I think it is inappropriate to make fundamental changes in a package build system without coordinating with Debian in advance and I don't understand why you did it in this case? It was completely unnecessary to solve the problem you were dealing with. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#558389: Bug#558389: What's up?
Squeeze is frozen and won't be updated before release. I do aim to have Python 3 support available for PyQt in Unstable soon after it releases. signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#622154: Additional considerations for updating pyopenssl
I can't actually test this in Debian due to this bug, but it looks like once it's fixed there's a python2.7 compatibility issue that will need to be addressed (fortunately with patch): https://bugs.launchpad.net/pyopenssl/+bug/686804 signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
Re: [Python-modules-team] matplotlib in experimental
On Wednesday, May 04, 2011 09:55:15 AM Sandro Tosi wrote: ... > probably numpy was not rebuilt to support python 2.7 yet. ... It was: http://packages.debian.org/sid/python-numpy Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
Re: [Python-modules-team] [Openstack] Nova not building on SID with python2.7
On Thursday, May 26, 2011 09:07:23 AM Thomas Goirand wrote: > This doesn't work like this in Debian: I do not own > the pyopenssl package, so I need to wait until the > pkg-python-modules team does it. I can send a patch > against the package, and if it takes more than a > week or 2 without an upload, then I can NMU (non > maintainer upload) in the delayed queue. But I wont > just fix like that, that would be considered as > rude to not work with current maintainers. Please see #622154. The package is team maintained by the DPMT and there's an open RC bug for quite some time. This package is quite ripe for a 0 day NMU or a team upload by any DPMT member. No need to wait based on fear of being rude to maintainers. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#638209: Options
There's a new version of qscintilla2 that I hadn't packaged yet (waiting for the python-dbus transition to finish) that properly bumps the soname/version to 6.1.0. I'll rebuild the packages that build-depend on libqscintilla2-dev. It looks like the relevant pacakges are: monkeystudio ovito juffed serna-free salome tora universalindentgui smokeqt Except salome doesn't look buildable at the moment, so I'll skip that one. Since upstream has already moved to 6.1.0, we could just bump the soversion locally and wait on the transition to the new version. We could just binNMU the above packages now and call that good enough. I don't think reverting the qscintilla2 update is a good way to go, but since this will cause a transition, I'll get advice from the release team before proceeding. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#638209: Progress on rebuild testing
I rebuilt monkeystudio ovito juffed serna-free tora universalindentgui smokeqt (skipping salome as previously mentioned) with the newest qscintilla2 from upstream. serna-free FTBFS for other reasons and is RC buggy (55) so I won't consider it further. ovito juffed tora universalindentgui smokeqt all build fine with the new qscintilla2. monkeystudio FTBFS as is, but there's a two line fix in the upstream svn to fix it (tested that it builds with the fix). ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#638209: Additional package checks
kscope FTBFS due to 631779, but gets to that stage with the new qscintilla2, so is probably fine. smokekde builds fine. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#636777: New version uploaded
Would you please check and see if 4.12.4 I just uploaded to Unstable works any better for you. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#712669: Bug#712669: New API version does not work with old one
Should have this fixed today. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#712669: Info received ( Bug#712669: New API version does not work with old one)
Fixed sip is uploaded. This will take some other package updates/rebuilds before it's resolved, however. No need to file more bugs. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#712669: Info received ( Bug#712669: New API version does not work with old one)
On Tuesday, June 18, 2013 05:04:50 PM Scott Kitterman wrote: > Fixed sip is uploaded. This will take some other package updates/rebuilds > before it's resolved, however. No need to file more bugs. Rebuilds are done for the more popular architectures. For some of the slower ones it'll be a bit yet. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] pyqt5_5.0-1_i386.changes REJECTED
Maintainer request - package is misbuilt due to a dh_python3 bug. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#718733: python-qt4: FTBFS on hppa -- 4.10.2-2
On Sunday, August 04, 2013 17:31:30 you wrote: > Package: python-qt4 > Version: 4.10.2-1 > Severity: serious > Justification: fails to build from source (but built successfully in the > past) FTBFS on ports isn't a serious bug. The problem is that python and python3 are behind on hppa, not a bug in this package. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#718733: python-qt4: FTBFS on hppa -- 4.10.2-2
On Monday, August 05, 2013 19:14:33 John David Anglin wrote: > On 4-Aug-13, at 8:04 PM, Scott Kitterman wrote: > > FTBFS on ports isn't a serious bug. The problem is that python and > > python3 > > are behind on hppa, not a bug in this package. > > Updating python and python3 fixes build. Perhaps dependencies might > be updated. In DPMT svn for the next upload. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#718900: python3-numpy: .so files missing on kFreeBSD
On Tuesday, August 06, 2013 14:35:18 you wrote: > The kFreeBSD python3-numpy packages somehow lack .so files, making > them unusable and causing matplotlib to FTBFS: Also pandas, pyfits, and python-scipy. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#718900: python3-numpy: .so files missing on kFreeBSD
On Friday, August 09, 2013 10:26:05 Scott Kitterman wrote: > On Tuesday, August 06, 2013 14:35:18 you wrote: > > The kFreeBSD python3-numpy packages somehow lack .so files, making > > them unusable and causing matplotlib to FTBFS: > Also pandas, pyfits, and python-scipy. python-astropy too. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#719770: python3-pyfits and python3-astropy-legacy: error when trying to install together
On Thursday, August 15, 2013 08:27:33 you wrote: > Package: python3-astropy-legacy,python3-pyfits > Version: python3-astropy-legacy/0.2.4-2 > Version: python3-pyfits/1:3.1.2-1+b1 > Severity: serious > User: trei...@debian.org > Usertags: edos-file-overwrite. > .. > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > /usr/lib/python3/dist-packages/pyfits/__init__.py In python-astropy-legacy this was resolved by adding a conflicts so the packages aren't co-installable. I think that's the miminal solution for python3-astropy-legacy, but even better would be for astropy to use the system provided pyfits. I don't think this can be reasonably resolved in the pyfits package, so I'm going to close the bug against it. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#719770: Oops. Wrong Bug
Sorry about that - I sent the done to the wrong bug. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#718900: python3-numpy: .so files missing on kFreeBSD
On Tuesday, August 27, 2013 15:13:39 Ansgar Burchardt wrote: > Hi, > > "Aaron M. Ucko" writes: > > The kFreeBSD python3-numpy packages somehow lack .so files, making > > > them unusable and causing matplotlib to FTBFS: > As this came up on #-mentors just now: > > I suspect the problem is the following line in d/rules: > > rm debian/python3-numpy/usr/lib/python3*/*-packages/*/*/*.cpython-*d*.so > > This probably should match *.cpython-3?d*, but also matches > *.cpython-33m-* on kfreebsd as the operating system name is included > later (which includes a "d" in the case of kfreebsd). Yes. That was it. Thanks, Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#697348: Patch to correct this bug
On Saturday, August 31, 2013 16:25:16 Jerome Kieffer wrote: > Dear Debian Python Modules Team, > > Could you please have python-qt4 recompiled for Debian6-Squeeze including > this patch to fix bug #697348. Are you sure that's right? That code in the Wheezy version of python-qt4 is: if bg_i18n is not None: # This should be handled properly in case the problem arises # elsewhere as well. try: # We are compiling the .ui file. bg_name = bg_i18n.string except AttributeError: # We are loading the .ui file. bg_name = bg_i18n Your patch is a bit different: if bg_i18n is not None: -bg_name = bg_i18n.string +try: +bg_name = bg_i18n.string +except AttributeError: +bg_name = str(bg_i18n) I don't know that the extra str() matters, but I think it's better to match upstream's change unless there's a good reason not to. Could you please check that it works for you without the str()? Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#697348: Patch to correct this bug
On Saturday, August 31, 2013 21:36:29 Jerome Kieffer wrote: > On Sat, 31 Aug 2013 10:47:18 -0400 > > Scott Kitterman wrote: > > On Saturday, August 31, 2013 16:25:16 Jerome Kieffer wrote: > > > Dear Debian Python Modules Team, > > > > > > Could you please have python-qt4 recompiled for Debian6-Squeeze > > > including > > > this patch to fix bug #697348. > > > > Are you sure that's right? > > At least I am sure it fixes this bug. Maybe the "str" is double shouting. > It looks like the bg_i18n lost this "string" attribute recently. > > The patch I sent you is in production on many computers for 6 months. > > > I don't know that the extra str() matters, but I think it's better to > > match > > upstream's change unless there's a good reason not to. Could you please > > check that it works for you without the str()? > > I just recompiled everything and it works without the str. Thanks. I do want to follow upstream as closely as possible here, just of the off chance the stray str() somehow causes a problem for someone else. I'd prepared the update for upload and asked the Debian release team for permission to upload it. This process can be tracked in Bug#721462. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#697348: Warrants serious
In the maintainer's opinion due to breaking other applications. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#697348: Fix Uploaded
The fix has been approved by the release team, so I've uploaded it. It will be available once they've accept it. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] [Openstack-devel] ITP: python-gear -- python-gear: pure python async library to interact with, gearman
Julien Danjou wrote: >On Tue, Oct 01 2013, Thomas Goirand wrote: > >> Could you please maintain this package using Git? It'd be nice, since >> that's an OpenStack stuff, and that everything there is maintained >using >> Git. If there is still resistance in the Python Module team, then you >> can use collab-maint. Your thoughts? > >This is not OpenStack related at all, there's no reason to limit its >maintenance to the OpenStack team. >I don't think the Python module team aims to switch to Git, so >collab-maint would be a good choice if git is retained. Last time we discussed this, we identified some things that needed to be resolved before we could switch. The problem isn't resistance, but that the magic some people seem to be waiting for to do the work is being slow. Anyone who wants to switch to git should work on switching. I'm not planning to work on it myself because I don't care which we use. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#727555: pykde4 needs rebuilding most likely
If this is still a problem, it's pykde4 needing to be rebuilt with the new sip. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Comments regarding pyqt5_5.2+dfsg-2_i386.changes
On January 31, 2014 6:42:51 AM EST, Thorsten Alteholz wrote: >Dear Maintainer, > >there are two lintian errors in your new examples-package: > > lintian check for pyqt5-examples_5.2+dfsg-2_all.deb >E: pyqt5-examples: changelog-file-not-compressed changelog >E: pyqt5-examples: changelog-file-not-compressed changelog.Debian > >Are these intentional? > > Thorsten No. Please accept and we'll fix in the next upload. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#725848: Bug#725848: (no subject)
On Tuesday, June 03, 2014 16:43:22 Barry Warsaw wrote: > Switching to --user by default is being actively discussed upstream: > > https://github.com/pypa/pip/issues/1668 > > In the meantime, I plan on updating the manpage to describe --user and any > other missing options. Can you go ahead and make --user default in Debian and document that as well? Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#750813: pyzmq: FTBFS on kfreebsd* and mips*
Source: pyzmq Version: 14.3.0-1 Severity: serious Justification: fails to build from source (but built successfully in the past) The current pymzq upload FTBFS on the mentioned architectures. The mips* failures are different than the kfreebsd* failures. This package is part of the transition to remove python3.3 from the archive. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#751343: python-tornado: FTBFS on mips due to test failure
Source: python-tornado Version: 3.2.0-1 Severity: serious Justification: fails to build from source (but built successfully in the past) While rebuilding your package on mips as part of the python3.3 removal transition, the following test failure (and FTBFS) ocurred: # python3 tests only in autopkgtest because I'm lazy set -e && for pyvers in 2.7; do \ PYTHONPATH=/«PKGBUILDDIR» python$pyvers ./tornado/test/runtests.py; \ done ...sss..s.Fsss...sssss...s.s...ssss...s.s... == FAIL: test_multi_performance (tornado.test.gen_test.GenEngineTest) -- Traceback (most recent call last): File "/«PKGBUILDDIR»/tornado/testing.py", line 427, in wrapper functools.partial(f, self), timeout=timeout) File "/«PKGBUILDDIR»/tornado/ioloop.py", line 389, in run_sync return future_cell[0].result() File "/«PKGBUILDDIR»/tornado/concurrent.py", line 129, in result raise_exc_info(self.__exc_info) File "/«PKGBUILDDIR»/tornado/stack_context.py", line 302, in wrapped ret = fn(*args, **kwargs) File "/«PKGBUILDDIR»/tornado/gen.py", line 574, in inner self.set_result(key, result) File "/«PKGBUILDDIR»/tornado/gen.py", line 500, in set_result self.run() File "/«PKGBUILDDIR»/tornado/gen.py", line 531, in run yielded = self.gen.send(next) File "/«PKGBUILDDIR»/tornado/test/gen_test.py", line 327, in test_multi_performance self.assertLess(end - start, 1.0) AssertionError: 1.4046919345855713 not less than 1.0 -- Ran 739 tests in 42.257s FAILED (failures=1, skipped=76) Some tests were skipped because: PEP 380 not available, futures module not present, mock package not present, needs fix, pycares module not present, pycurl module not present, ssl.SSLContext not present, tornado.speedups module not present, twisted module not present [E 140611 20:26:50 testing:611] FAIL make[1]: *** [override_dh_auto_test] Error 1 debian/rules:31: recipe for target 'override_dh_auto_test' failed make[1]: Leaving directory '/«PKGBUILDDIR»' make: *** [build-arch] Error 2 debian/rules:9: recipe for target 'build-arch' failed dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#751531: libqt5scintilla2-dev: qmake features file seems to be installed in the wrong location
On Friday, June 13, 2014 21:47:55 Torsten Paul wrote: > Package: libqt5scintilla2-dev > Version: 2.8.1-4 > Severity: important > > The features file is installed in > /usr/share/qt5/mkspecs/features/qscintilla2.prf but qmake seems to only > read from /usr/lib/x86_64-linux-gnu/qt5/mkspecs/features. This causes qmake > not to see the file with just "qmake CONFIG+=qscintilla2" > > In addition the rename of -lqscintilla2 to -lqt5scintilla2 for Qt5 is only > active in case "debug" is not defined. In case the project uses > CONFIG+=debug, the wrong library name is used. Thanks for the feedback. I'm not actually using it for Qt5 and the .prf file is new in 2.8.1 and later in any case, so it's great to have someone who is that can test it. The install location is where the upstream build system puts it, but that doesn't make it right. There is currently an upload in unstable that needs to get to jessie/testing before I upload again to fix this, but I ought to be able to fix it next week. Scott K signature.asc Description: This is a digitally signed message part. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#751531: libqt5scintilla2-dev: qmake features file seems to be installed in the wrong location
Yes. It's fine to keep them all in one bug. Translations aren't architecture specific so I'd guess the current location for the Qt5 translation is fine ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#751531: libqt5scintilla2-dev: qmake features file seems to be installed in the wrong location
On Tuesday, June 17, 2014 19:02:32 Torsten Paul wrote: > Hi! > > It looks like that affects also the header files. Using the installed > Qt/qmake, they are searched in /usr/include/x86_64-linux-gnu/qt5 but the > dev package installs the Qsci headers in /usr/include/qt5. > > Using "QMAKEFEATURES=/usr/share/qt5/mkspecs/features qmake" picks up the > prf file, but compilation failes when using includes like > > > Is it ok to leave the 3 topics in a single bug report? > > * location of the prf file > * location of the header files > * wrong library name for Qt5 if debug is enabled In 2_2.8.2+dfsg-2 that arrived in Testing today the header file location should already be fixed. Please check. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#751531: Bug#751531: closed by Scott Kitterman (Bug#751531: fixed in qscintilla2 2.8.2+dfsg-3)
Excellent. Thanks for both the detailed report and testing. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Bug#751343: Bug#751343: python-tornado: FTBFS on mips due to test failure
On Friday, June 20, 2014 16:55:29 Julian Taylor wrote: > in svn I have disabled all performance relevant tests which includes > this one. Upstream has a convinient switch for that for the CI. its > currently waiting for sponsoring. Looking at it. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] On team maintainership of DPMT (PAPT) packages
On Sun, 9 Mar 2008 17:34:05 +0100 "Sandro Tosi" <[EMAIL PROTECTED]>
wrote:
>Hi all,
>I'd like to report here my feelings about the current way to maintain
>package in our repositories (DPMT and PAPT).
>
>As of now, policy[1] states that:
>
> Thus if you bring some packages into the team, you can keep your
> name in the Maintainer field. You will receive bug reports and
> handle your package as usual except that other team members may help
> from time to time and/or take over when you're too busy.
>
> If you put the team in the Maintainer field, the package will be
> handled completely by the team and every member is invited to work
> on any outstanding issue.
>
>I personally feel this is not the way a team should work. If I inject
>a package in the team, I think the team should be the maintainer, and
>every people that do "important" work on the package can add
>{him,her}self to Uploaders.
Then you are free to do that.
>If you're in the Uploaders fields, the package will appear in personal
>DDPO page too, so bugs can be noticed there (I hope this should reduce
>oppositions about bugs notification).
>
>The things I'd like to change, inspired from perl group policy [2]
>(don't kill me for this ;), are the following:
>
>* everyone that inject a package in the team repository have to set
>Maintaner to the team (adding {him,her}self to Uploaders)
I have the team as Maintainer for some of my packages and myself for others
depending on how interested I am in making sure I have control over the
package (I consider the ability to make this choice a feature of the
current policy). If the policy is changed, I will reluctantly withdraw
these packages from the team (with the possible exception of pyspf because
I didn't bring that to the team.
>* everyone interested in actively taking part to team packages
>mainteinership, must subscribe to alioth mailing list[3], where bug
>reports and other messages about packages arrive
I thought this was required already, but how would you enforce it?
>Maybe this way, would allow more people with "spot spare time" (I
>mean, some hours in random situation, not every day) to collaborate,
>attracting eventually new guys to the team.
That or give people working on team packages more time per package because
there
will be fewer packages to worry about.
>I know I'm in the team since few months, and not being a DD hides me
>from different kind of problems and point-of-views, but those are my
>feelings, so please come join and discuss about this and every other
>problems currently affecting the team.
IANADD either. I don't think that should stop you from suggesting
improvement.
If there's a problem we should work on it's making sure Python policy is
kept up to date and maintained. There was some discussion about bring
Python policy maintenance into DPMT. I think this should be further
considered.
Scott K
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
Re: [Python-modules-team] PyOpenSSL compile situation on hppa
On Tue, 8 Apr 2008 18:17:29 +0200 "Sandro Tosi" <[EMAIL PROTECTED]> wrote: >Dear HPPA admin, > >> I'd like to know what is the situation about PyOpenSSL compilation on >> hppa port machine. The package version 0.6-5 was uploaded on >> 2008-03-08 and, as of now, no build attempt was made on hppa[1]. I've got a package (not Python related) in similar circumstances. I understand that hppa has in general fallen behind. I believe they're getting/have recently gotten some new hardware so there's hope they'll catch up. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Security issue in python-dns
Python-dns is used by python-spf and python-formencode. I wanted to let you know that python-dns has problems with respect to the current DNS cache issue. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490217 for details. Python-dns upstream is going to do a release that will at least provide TID randomization. It's his position though that since python-dns opens a new socket for each request, it's the OS job to randomize the port. 2.6.24 will do this, but the Etch kernel will not. So, after upstream is done, I think Lenny/Sid will be OK, but Etch will still not have port randomization. I know nothing about python-formencode's usage of python-dns. Does this present a security risk? Scott K Maintainer for python-dns and python-spf ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Security issue in python-dns - update
Python-dns is used by python-spf and python-formencode. I wanted to let you know that python-dns has problems with respect to the current DNS cache issue. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490217 for details. Python-dns upstream has now agreed to provide both TID randomization and source port randomization. I've uploaded 2.3.1-4 based on their current CVS that partially addresses TID randomization (details in the bug). Scott K Maintainer for python-dns and python-spf pgpOvaskaEhsq.pgp Description: PGP signature ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] [Bug 335914] Re: Cannot install; depends on python 2.6 or less but 2.6.1 is installed
Please don't assign bugs to Debian teams such as DPMT. ** Changed in: python-xml (Ubuntu) Assignee: Debian Python Modules Team (python-modules-team) => (unassigned) -- Cannot install; depends on python 2.6 or less but 2.6.1 is installed https://bugs.launchpad.net/bugs/335914 You received this bug notification because you are a bug assignee. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
Re: [Python-modules-team] python-yaml: can it be priority optional?
On Mon, 23 Mar 2009 10:04:45 + Jonathan Wiltshire wrote: >Hi, > >python-yaml seems to be a priority: extra package, and I have a >package dependent on it which is priority: optional. Before I change the >priority, is there any reason python-yaml can't become optional instead? > >(please keep me in CC, and if you'd rather I file a bug that's no >problem.) > It's extra because (and only because) it depends on libyaml whic is extra. If you get libyaml moved to optional, I've no problem moving pyyaml back to optional. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
Re: [Python-modules-team] python-yaml: can it be priority optional?
On Monday 23 March 2009 13:33, Jonathan Wiltshire wrote: > On Mon, Mar 23, 2009 at 06:24:43AM -0400, Scott Kitterman wrote: > > It's extra because (and only because) it depends on libyaml whic is > > extra. If you get libyaml moved to optional, I've no problem moving > > pyyaml back to optional. > > I've been in touch with Anders Kaseorg, libyaml's maintainer, and his > next release is going to put it into optional. So, if you don't mind > doing the same, that makes the whole tree nice and consistent. > That's no problem at all. It was optional before it depended on libyaml and I see no reason for it not to be again. Scott K ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
