Re: warning: symbol PyLong_FromUnsignedLong...
On Thu, Apr 12, 2012 at 7:42 PM, Jakub Wilk jw...@debian.org wrote:
* 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 365 5333
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.
Cool !
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.
Same question for cmake [1]. I am tempted to simply fill a bug against
cmake/debian package. CMake supports the notion of module, but still
add the -Wl,-soname switch to those.
Or, alternatively: is there a way to remove SONAME from an existing library?
I have been searching for such tool also. I found chrpath which use
the low level read_elf() API to manipulate .so, but I could not find
anything else.
-M
[1] http://www.cmake.org/pipermail/cmake/2012-April/049874.html
--
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+7wusy5dsvwsp0cnabbjpuedq7a13ks8gi-rf3q_0e-ybk...@mail.gmail.com
Re: pythonX.Y maintenance team
On Friday, April 13, 2012 08:37:26 AM Sandro Tosi wrote: On Thu, Apr 12, 2012 at 23:35, Scott Kitterman deb...@kitterman.com wrote: 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. I see; another point for having Debian maintainers whose main interest is making Debian the best distro. That or people in Debian with just a slight bit of perspective that it's not the only thing that matters. There are good and valid reasons to upload to Ubuntu first. There are times when people get busy with work. There are also times when the only 'solution' available is a short term hack that's needed for Ubuntu's time based release schedule that isn't appropriate to Debian's approach of doing things right and releasing when ready. I'm not saying that there have never been delays that weren't ideal, but I think in this case you're trying to make a point out of a small matter. FWIW, I saw him discussing it on #debian-release at least briefly today. well, he was asked (sorry, I don't have that line of log here) when python will start building again, and the only reply was doko jcristau, sure, just disabling the tests ... but please ask port maintainers as well. I now got some feedback from kfreebsd porters (still on the line of http://packages.qa.debian.org/p/python2.7/news/20120405T171854Z.html where FTBFS are delegated to porters but without notifying them first) but he was also pointed out that: pinotree doko: i guess the one to ask, as maintainer of said source, should be you then nothing else; not exactly a discussion, but oh well 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. Yes. It wasn't a great interaction and the package should be fixed, but it's also not quite the same thing as ignoring Debian. non sequitur: it doesn't show how python*-default - pythonX.Y interactions would be problematic, only that, IMO, pythonX.Y is poorly maintained in Debian, since nothing has changed on that side. I think a good interaction between the two teams would be needed and I don't think with you on one team and doko on the other it would happen. I may be completely wrong about that, but that's what I think. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2841496.GRyXvWAYjS@scott-latitude-e6320
Re: pythonX.Y maintenance team
* Stefano Zacchiroli lea...@debian.org, 2012-04-12, 11:25: 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 hereby volunteer to take over maintainership of pythonX.Y packages. However, if I were to maintain them, I would do this myself, without any co-maintainers. (At least formally and initially: I'm certainly going to ask you for help with certain boring^W tasks. And I don't vow to never seek co-maintainers in the future.) That said, I don't believe that forcibly changing the maintainer of Python interpreter packages is the correct course of action. I'm not personally happy with the way they are maintainer, but it's not nearly as bad as to justify such action. -- Jakub Wilk signature.asc Description: Digital signature
Re: warning: symbol PyLong_FromUnsignedLong...
* Mathieu Malaterre ma...@debian.org, 2012-04-13, 13:11:
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.
Same question for cmake [1]. I am tempted to simply fill a bug against
cmake/debian package. CMake supports the notion of module, but still
add the -Wl,-soname switch to those.
I used to maintain a Python+cmake package and I didn't find any sane way
do to that. I ended up with sed-editing link.txt files, something like
this:
find -name 'link.txt' -exec sed -i \
-e 's/ -Wl,-soname,[^ ]\+ / /' \
{} +
Or, alternatively: is there a way to remove SONAME from an existing
library?
I have been searching for such tool also. I found chrpath which use the
low level read_elf() API to manipulate .so, but I could not find
anything else.
Turning chrpath codebase into a tool to edit/remove SONAMEs shouldn't be
very difficult. I'm not sure it's worth effort, though.
Another way to approach this problem would be to write a wrapper for gcc
that filters out spurious -Wl,-soname,... arguments.
--
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/20120413203715.ga8...@jwilk.net
