Re: warning: symbol PyLong_FromUnsignedLong...
Paul, On Wed, Apr 11, 2012 at 11:52 PM, Paul Wise p...@debian.org wrote: On Wed, Apr 11, 2012 at 11:43 PM, Mathieu Malaterre wrote: I am trying to remove the remaining warnings from the gdcm/python package. They can be seen here: That is pretty normal for plugins on Linux; the symbols are provided by the program that loads the plugins and the plugins do not reference where they get those symbols from. I am trying to remove the annoying 'todo' section of the gdcm package page: http://packages.qa.debian.org/g/gdcm.html If this was a lintian false positive, one would use *.lintian-overrides file. However in this case I did not know what I need to do. Since every single python module suffer from this, I thought there would be something very simple. Regards, -M -- 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/ca+7wusxfy3kmf2igtzxas+8gpb+v512pi3n0xsay3ryomn0...@mail.gmail.com
Re: warning: symbol PyLong_FromUnsignedLong...
On Thu, Apr 12, 2012 at 3:04 PM, Mathieu Malaterre wrote: I am trying to remove the annoying 'todo' section of the gdcm package page: http://packages.qa.debian.org/g/gdcm.html If this was a lintian false positive, one would use *.lintian-overrides file. However in this case I did not know what I need to do. Since every single python module suffer from this, I thought there would be something very simple. Based on my reading of dlopen(3) and the output of objdump -T /usr/bin/python, dpkg-shlibdeps needs to look for defined symbols in executables too. Since there is no way to know exactly which binary a symbol is supposed to be supplied by (no SONAMEs in binaries), this will be a bit tricky to get right. If you want to implement this, good luck! -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6escv1r8vlg_megdbrf3gv_ikg5dcovdjg7p75yspo...@mail.gmail.com
Re: pythonX.Y maintenance team
On Tue, Apr 03, 2012 at 10:36:58AM +0200, Stefano Zacchiroli wrote:
Allow me be blunt then: do we have volunteers to maintain the pythonX.Y
packages? Can those volunteers manifest themselves on this list?
So, ~10 days later this call, we've two volunteers: Sandro and Barry. If
no one else show up, I'll relay the information to the tech-ctte bug log
mentioning that, if they want to have an explicit team in their ballot,
the two of them volunteered.
Anyone else?
Also, it would be appropriate to know what participants to this list
(including the volunteers) think of such a potential maintenance team
for pythonX.Y. Given the history of the underlying conflict, I would
prefer to receive comments about that publicly. But I do understand it
might be socially awkward to do so for those who would prefer a
different team. So if you *really* don't feel like commenting publicly,
feel free to do so in private mail to me. I'll then simply anonymize and
aggregate the feedback, if any. (If you've better options on how to
solicit comments, I'm all ears as well.)
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: pythonX.Y maintenance team
Il 03 aprile 2012 10:36, Stefano Zacchiroli lea...@debian.org ha scritto: If you volunteered in #573745 already, and you're still available, please reiterate your availability here. I'm willing to help too, but I would limit by doing grunt work such as bug triaging and cleanup. I know this kind of work could also be performed as an outsider, that's why I want to clearly state this to help getting to a decision. -- 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/cadk7b0o8roxzqa-ie4qt9v8qjc2nb-dryg5pna2fh6a6stx...@mail.gmail.com
Re: warning: symbol PyLong_FromUnsignedLong...
* Mathieu Malaterre ma...@debian.org, 2012-04-11, 17:43: [CC me please] [done] dpkg-shlibdeps: warning: debian/python-gdcm/usr/lib/python2.7/dist-packages/_gdcmswig.so contains an unresolvable reference to symbol PyObject_IsTrue: it's probably a plugin. dpkg-shlibdeps: warning: 86 other similar warnings have been skipped (use -v to see them all). This one is easy. _gdcmswig.so has a SONAME. This is unusual (and almost always unnecessary) for Python extension modules and confuses dpkg-shlibdeps. Quoting the manual page: “The indicated symbol has not been found in the libraries linked with the binary. The binary is most likely a plugin and the symbol is probably provided by the program that loads this plugin. In theory a plugin doesn't have any SONAME but this binary does have one and as such it could not be clearly identified as such. However the fact that the binary is stored in a non-public directory is a strong indication that's it's not a normal shared library.” Get rid of the SONAME and they'll go away. dpkg-shlibdeps: warning: Can't extract name and version from library name `libKitware.mummy.Runtime.Unmanaged.so' dpkg-shlibdeps: warning: Can't extract name and version from library name `libKitware.mummy.Runtime.Unmanaged.so' I suppose these are about CLI stuff, not about Python stuff. dpkg-shlibdeps: warning: symbol PyLong_FromUnsignedLong used by debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of the libraries. dpkg-shlibdeps: warning: symbol Py_InitModule4 used by debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of the libraries. What is the purpose of this library? I see that package-name-doesnt-match-sonames and shlib-without-versioned-soname were overridden without a comment. It doesn't directly address your problem, but: - If it's a general-purposed library that is supposed to be used by other packages, then it should be versioned, put into a package with versioned name, and linked to all the libraries it uses symbols from. - Otherwise, it should be moved to a private directory. -- 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/20120412102053.ga8...@jwilk.net
Re: warning: symbol PyLong_FromUnsignedLong...
* Mathieu Malaterre ma...@debian.org, 2012-04-12, 09:04: I am trying to remove the annoying 'todo' section of the gdcm package page: http://packages.qa.debian.org/g/gdcm.html If this was a lintian false positive, one would use *.lintian-overrides file. However in this case I did not know what I need to do. Build log checks is a tool with great potential, but IMO adding it to PTS was premature. Since every single python module suffer from this, I thought there would be something very simple. No, most of Python extension modules don't suffer from it. -- 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/20120412102346.gb8...@jwilk.net
Re: warning: symbol PyLong_FromUnsignedLong...
Jakub, On Thu, Apr 12, 2012 at 12:20 PM, Jakub Wilk jw...@debian.org wrote: * Mathieu Malaterre ma...@debian.org, 2012-04-11, 17:43: dpkg-shlibdeps: warning: debian/python-gdcm/usr/lib/python2.7/dist-packages/_gdcmswig.so contains an unresolvable reference to symbol PyObject_IsTrue: it's probably a plugin. dpkg-shlibdeps: warning: 86 other similar warnings have been skipped (use -v to see them all). This one is easy. _gdcmswig.so has a SONAME. This is unusual (and almost always unnecessary) for Python extension modules and confuses dpkg-shlibdeps. Quoting the manual page: “The indicated symbol has not been found in the libraries linked with the binary. The binary is most likely a plugin and the symbol is probably provided by the program that loads this plugin. In theory a plugin doesn't have any SONAME but this binary does have one and as such it could not be clearly identified as such. However the fact that the binary is stored in a non-public directory is a strong indication that's it's not a normal shared library.” Get rid of the SONAME and they'll go away. D'oh ! I was not looking at the right error message. Thanks for spotting this ! dpkg-shlibdeps: warning: Can't extract name and version from library name `libKitware.mummy.Runtime.Unmanaged.so' dpkg-shlibdeps: warning: Can't extract name and version from library name `libKitware.mummy.Runtime.Unmanaged.so' I suppose these are about CLI stuff, not about Python stuff. This is a different issue (or maybe exactly the same). Anyway I'll deal with it ASAP. dpkg-shlibdeps: warning: symbol PyLong_FromUnsignedLong used by debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of the libraries. dpkg-shlibdeps: warning: symbol Py_InitModule4 used by debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of the libraries. What is the purpose of this library? I see that package-name-doesnt-match-sonames and shlib-without-versioned-soname were overridden without a comment. It doesn't directly address your problem, but: - If it's a general-purposed library that is supposed to be used by other packages, then it should be versioned, put into a package with versioned name, and linked to all the libraries it uses symbols from. - Otherwise, it should be moved to a private directory. The real issue is about SONAME -hopefully- I can then cleanup this file. thanks much ! -- 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/CA+7wUswfW=hkgj12t59hrt6jr_f1lln8vnypogcmr8mvh...@mail.gmail.com
Re: warning: symbol PyLong_FromUnsignedLong...
On Thu, Apr 12, 2012 at 12:23 PM, Jakub Wilk jw...@debian.org wrote:
* Mathieu Malaterre ma...@debian.org, 2012-04-12, 09:04:
I am trying to remove the annoying 'todo' section of the gdcm package
page:
http://packages.qa.debian.org/g/gdcm.html
If this was a lintian false positive, one would use *.lintian-overrides
file. However in this case I did not know what I need to do.
Build log checks is a tool with great potential, but IMO adding it to PTS
was premature.
Since every single python module suffer from this, I thought there would
be something very simple.
No, most of Python extension modules don't suffer from it.
I am not pointing finger at anyone, but this issue is present in other package.
$ find /usr/lib/pyshared/python2.6/ -name \*.so -exec readelf -d {} \;
| grep SONAME | wc
73 3655333
After all this is a great that it was added to PTS :)
--
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/CA+7wUswE1CNsV2ugASVOLN_PF=_u915S_Q=_kcyct3l2k1e...@mail.gmail.com
Re: How do I add support for python3 to my package?
Hi Paul, On Apr 12, 2012, at 02:09 AM, Paul Elliott wrote: A recent review of my package asked me to consider making a python3 version. Excellent! One more down the road to Python 3 world domination. :) But the response below says that is difficult. It is several months old, has this changed? I think it's not so hard, and you should definitely do it. It's true that the tools need to catch up to Python 3, but I think most packages can be adapted to include python3-* versions without too much trouble. You might find this wiki page helpful: http://wiki.debian.org/Python/LibraryStyleGuide The other problem is that the package is an extension and there is currently no python3 program to test it. Should packagers create a python3 extension even if there is no way to test it? It might be a chicken and egg problem. I'm not sure what you mean by no python3 program to test it. You can and should create the Python 3 extension modules. `apt-get install python3` should do the trick, right? Cheers, -Barry signature.asc Description: PGP signature
Re: pythonX.Y maintenance team
On Thursday, April 12, 2012 11:25:07 AM Stefano Zacchiroli wrote: On Tue, Apr 03, 2012 at 10:36:58AM +0200, Stefano Zacchiroli wrote: Allow me be blunt then: do we have volunteers to maintain the pythonX.Y packages? Can those volunteers manifest themselves on this list? So, ~10 days later this call, we've two volunteers: Sandro and Barry. If no one else show up, I'll relay the information to the tech-ctte bug log mentioning that, if they want to have an explicit team in their ballot, the two of them volunteered. Anyone else? I'm not volunteering because I don't think I'm qualified. Also, it would be appropriate to know what participants to this list (including the volunteers) think of such a potential maintenance team for pythonX.Y. Given the history of the underlying conflict, I would prefer to receive comments about that publicly. But I do understand it might be socially awkward to do so for those who would prefer a different team. So if you *really* don't feel like commenting publicly, feel free to do so in private mail to me. I'll then simply anonymize and aggregate the feedback, if any. (If you've better options on how to solicit comments, I'm all ears as well.) I will be direct. doko and morph do not get along with each other. This has been true (IIRC) since before I started participating in Debian. There is no reasonable basis for believing this is going to change. I don't know who's fault it is (and I don't care - don't bother to engage me in a discussion on the topic). I have seen both of them have enough socially unpleasant interactions with other people that I suspect there is blame enough to go around. I don't think that the *-defaults packages and the interpreter packages fundamentally require the same maintainer, but I expect it to be problematic to have different teams maintain them if each team has the other as a member as they are both strong personalities. So far, the solicitation has been for co-maintainers with morph. I think it would only be fair to make a similar call for co-maintainers with doko. Despite the language in the original tech ctte bug, I don't think morph and doko on the same team is a realistic possibility. I agree with the goal of the bug. I think it's important to have multiple maintainers on packages as important as the python interpreter packages. I'm glad I'm not the one that has to figure out how to manage that. Scott K signature.asc Description: This is a digitally signed message part.
Re: pythonX.Y maintenance team
On Thu, Apr 12, 2012 at 10:13:02AM -0400, Scott Kitterman wrote:
I will be direct.
Thanks! I really appreciate.
So far, the solicitation has been for co-maintainers with morph. I think it
would only be fair to make a similar call for co-maintainers with doko.
... but hold right there :-) If that is what you perceived from what _I_
wrote, I should make clear that it was not my intention. The first call
for volunteers I've sent on this list was meant to be neutral. I really
wanted to know who is *potentially* interested to co-maintain pythonX.Y
in *some* team.
I've never meant to imply forced co-maintenance among all the people
who volunteer, let alone co-maintenance specifically with someone. In my
intention, a broad call for volunteers was just a first step before a
second one during which incompatibilities among the people who
volunteered should have been identified (I didn't make that explicit
before simply because that step might be unneeded --- e.g. if a single
person had volunteered :-P).
So, if anyone did not volunteer due to the fact that others did, please
reconsider.
Similarly, it would be helpful to do what Scott has just done:
clarifying what the incompatibilities among the (potential) volunteers
are.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: How do I add support for python3 to my package?
On Thursday, April 12, 2012 08:30:41 AM Barry Warsaw wrote: Hi Paul, I'm not sure what you mean by no python3 program to test it. You can and should create the Python 3 extension modules. `apt-get install python3` should do the trick, right? I mean that I have python 2 programs that use this extension module. So I can check that the python 2 extension works. But I don't have any python 3 programs that use the python3 extension module. Under these conditions should I create a python 3 extension, without knowing if it works? Cheers, -Barry -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: How do I add support for python3 to my package?
On Apr 12, 2012, at 10:09 AM, Paul Elliott wrote: On Thursday, April 12, 2012 08:30:41 AM Barry Warsaw wrote: Hi Paul, I'm not sure what you mean by no python3 program to test it. You can and should create the Python 3 extension modules. `apt-get install python3` should do the trick, right? I mean that I have python 2 programs that use this extension module. So I can check that the python 2 extension works. But I don't have any python 3 programs that use the python3 extension module. Under these conditions should I create a python 3 extension, without knowing if it works? Does the package itself have a test suite? If so, try enabling that for both Python 2 and 3 (using the hints in that wiki page). If not, then as long as the extension imports, I think it's worth building. You can't get bug reports on broken modules if the module doesn't exist. :) -Barry signature.asc Description: PGP signature
Re: warning: symbol PyLong_FromUnsignedLong...
* Mathieu Malaterre ma...@debian.org, 2012-04-12, 12:32:
Since every single python module suffer from this, I thought there
would be something very simple.
No, most of Python extension modules don't suffer from it.
I am not pointing finger at anyone, but this issue is present in other
package.
$ find /usr/lib/pyshared/python2.6/ -name \*.so -exec readelf -d {} \;
| grep SONAME | wc
73 3655333
After all this is a great that it was added to PTS :)
The latest lintian4python (0+20120412) will emit a pedantic tag for
such packages.
BTW, does anybody know how to stop libtool from adding SONAME? I would
expect that -module -avoid-version does that, but it's not the case.
Or, alternatively: is there a way to remove SONAME from an existing
library?
--
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/20120412174256.ga6...@jwilk.net
Re: pythonX.Y maintenance team
On Thu, Apr 12, 2012 at 16:13, Scott Kitterman deb...@kitterman.com wrote: I don't think that the *-defaults packages and the interpreter packages fundamentally require the same maintainer, but I expect it to be problematic to have different teams maintain them if each team has the other as a member as they are both strong personalities. could you please elaborate a bit? what is the problem you see? *-defaults define the policy and the default version of python, while python* is just the interpreter packages (big packages, but not even *that* complicated; f.e. the most scary point, problems on weird archs, is currently delegated to porters). I don't even see that much collaboration needed here (not that it would hurt), so I'd like to hear your doubts. So far, the solicitation has been for co-maintainers with morph. I think it would only be fair to make a similar call for co-maintainers with doko. Stefano already explained to you, but that would have been fair if doko had asked for it. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/cab4xwxydipdro2nxi7ludten4rfg9qrjhkdjbffg6lt_xwp...@mail.gmail.com
Re: pythonX.Y maintenance team
On Thursday, April 12, 2012 09:12:23 PM Sandro Tosi wrote: On Thu, Apr 12, 2012 at 16:13, Scott Kitterman deb...@kitterman.com wrote: I don't think that the *-defaults packages and the interpreter packages fundamentally require the same maintainer, but I expect it to be problematic to have different teams maintain them if each team has the other as a member as they are both strong personalities. could you please elaborate a bit? what is the problem you see? *-defaults define the policy and the default version of python, while python* is just the interpreter packages (big packages, but not even *that* complicated; f.e. the most scary point, problems on weird archs, is currently delegated to porters). I don't even see that much collaboration needed here (not that it would hurt), so I'd like to hear your doubts. The most controversial decisions (as I see it) the the Debian Python community have been around when to introduce new versions, when the switch defaults, and when to drop old versions. These decisions need an understanding between the maintainers of the interpreter packages and the maintainers of the defaults packages. The Python policy (that is in python-defaults) defines some of the requirements for the interpreter packages. I haven't seen a lot of controversy around this, but it is another point where there would have to be some consensus. I'm not saying such things can't be solved, but if there are two teams they need to work together. Scott K signature.asc Description: This is a digitally signed message part.
Re: pythonX.Y maintenance team
On Thu, Apr 12, 2012 at 16:36, Stefano Zacchiroli lea...@debian.org wrote: clarifying what the incompatibilities among the (potential) volunteers are. From my side, I don't think i'll have problems working with Barry, but I honestly have to say we had few occasions to work together (that I can remember, there was some interactions for his flufl.* packages, but then he decided to go with another sponsor). My only fear is (are you surprised?) that Barry is a Canonical employee, and that usually means there are different priorities when working for Debian over Ubuntu. I can't say it's a good or a bad sign, but it's a red flag to me (to be investigated). To give a (fresh) example and what I meant above, you can try to answer this provocative question: Why Ubuntu has Python 2.7.3 since more than 2 days (even before it was publicly announced) while Debian is still stuck with a RC, FingTBFS on 4 archs version? But on the bright side, is a really authoritative figure in the CPython project, and it was always kinda nice talking with him. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/cab4xwxxd7e4x6aqv1o6k8ebfahal3rooeusu8nrsueyjd8a...@mail.gmail.com
Re: pythonX.Y maintenance team
On Thursday, April 12, 2012 10:20:04 PM Sandro Tosi wrote: To give a (fresh) example and what I meant above, you can try to answer this provocative question: Why Ubuntu has Python 2.7.3 since more than 2 days (even before it was publicly announced) while Debian is still stuck with a RC, FingTBFS on 4 archs version? Probably because Ubuntu is a day before final freeze for a release. I virtually always upload stuff to Debian first where I'm the Debian maintainer for a package, but there are legitimate reasons why in some cases that's not the best way to go about it. We all get busy with $DAYJOB every now and then and that's OK. I think complaining about two days is a very minor thing. Scott K signature.asc Description: This is a digitally signed message part.
Re: pythonX.Y maintenance team
On Thu, Apr 12, 2012 at 22:50, Scott Kitterman deb...@kitterman.com wrote: On Thursday, April 12, 2012 10:20:04 PM Sandro Tosi wrote: To give a (fresh) example and what I meant above, you can try to answer this provocative question: Why Ubuntu has Python 2.7.3 since more than 2 days (even before it was publicly announced) while Debian is still stuck with a RC, FingTBFS on 4 archs version? Probably because Ubuntu is a day before final freeze for a release. I virtually always upload stuff to Debian first where I'm the Debian maintainer for a package, but there are legitimate reasons why in some cases that's not the best way to go about it. exactly my point as in that usually means there are different priorities when working for Debian over Ubuntu We all get busy with $DAYJOB every now and then and that's OK. funny how in this case the dayjob overlaps the hobby, so I guess one could have achieved the best for both distro with minimal effort (as the changelog for previous syncs suggest) but decided to just go with one only. cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/cab4xwxy11dmxmuebazyyex0t8de0butnaux2kjjfp0pwh_y...@mail.gmail.com
Re: pythonX.Y maintenance team
On Thursday, April 12, 2012 11:04:33 PM Sandro Tosi wrote: On Thu, Apr 12, 2012 at 22:50, Scott Kitterman deb...@kitterman.com wrote: On Thursday, April 12, 2012 10:20:04 PM Sandro Tosi wrote: To give a (fresh) example and what I meant above, you can try to answer this provocative question: Why Ubuntu has Python 2.7.3 since more than 2 days (even before it was publicly announced) while Debian is still stuck with a RC, FingTBFS on 4 archs version? Probably because Ubuntu is a day before final freeze for a release. I virtually always upload stuff to Debian first where I'm the Debian maintainer for a package, but there are legitimate reasons why in some cases that's not the best way to go about it. exactly my point as in that usually means there are different priorities when working for Debian over Ubuntu We all get busy with $DAYJOB every now and then and that's OK. funny how in this case the dayjob overlaps the hobby, so I guess one could have achieved the best for both distro with minimal effort (as the changelog for previous syncs suggest) but decided to just go with one only. It's not that simple. Depending on the timing of various processes in Debian/Ubuntu there can be a substantial (as much as a day) delay from Debian upload to when a package can be synced into Ubuntu. When you're only two or three days from a freeze, that can be unacceptable. FWIW, I saw him discussing it on #debian-release at least briefly today. BTW, it is just this kind of nitpicking that I think would make a *defaults team with doko and an interpreter team with you problematic. Scott K signature.asc Description: This is a digitally signed message part.
