[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Looking for sponsor: python-llfuse



OoO En  ce début de soirée du  lundi 13 juin 2011,  vers 21:50, Nikolaus
Rath <Nikolaus@rath.org> disait :

>> debian/changelog:
>> 
>> This is a bit unusual to  describe non change related things here, but I
>> am fine with it.

> That was in response to Jacob's request. I'm fine to put it somewhere
> else (or not document it at all) :-).

Keep it here, it will be useful for FTP masters as well.

>> I don't think that python-all-dbg and python3-all-dbg will be needed
>> to build the package.

> To build the debug versions, I'm calling python-dbg setup.py (so I need
> python-*-dbg). Is that the wrong thing to do?

I was not aware that this was the way to do it.

> Done. I used  http://dep.debian.net/deps/dep5/ as the 
> <VERSIONED_FORMAT_URL>, because it says that the format is now fixed. Is
> that correct? Some other packages used URLs like
> http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?op=file&rev=135,
> but these just give 400s now.

Yes, that's fine.

>> Also, you  say that python-llfuse is  licensed with LGPL 3.  There is no
>> such  mention in  the upstream  package. Only  "LGPL". As  upstream, you
>> should add a LICENSE file to clarify this.

> Done as well. Should I release a new version with just the LICENSE file
> added, or can this wait for a regular update (without delaying the
> debian package)?

It can wait.

>> The python3-llfuse-dbg  does not contain  debug symbols. Only  the debug
>> version of the library (llfuse.cpython-32dmu.so).

> I'm a bit at a loss here. For some reason, dh_strip puts the
> python3-llfuse debugging symbols into the python-llfuse-dbg directory:


> $ dh_strip -v -a -ppython-llfuse --dbg-package=python-llfuse-dbg
> [...]
> 	install -d debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages
> 	objcopy --only-keep-debug
> debian/python3-llfuse/usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
> debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
> 	chmod 644
> debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
> 	strip --remove-section=.comment --remove-section=.note
> --strip-unneeded
> debian/python3-llfuse/usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
> 	objcopy --add-gnu-debuglink
> debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
> debian/python3-llfuse/usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
> 	objcopy --only-keep-debug
> debian/python3-llfuse-dbg/usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
> debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
> 	chmod 644
> debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
> 	strip --remove-section=.comment --remove-section=.note
> --strip-unneeded
> debian/python3-llfuse-dbg/usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
> 	objcopy --add-gnu-debuglink
> 	debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
> 	debian/python3-llfuse-dbg/usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so

> Shouldn't this command only work on the python-llfuse package?

The "-a" means "all arch packages". I suppose that you should not use it
with "-p".

>>> The .c files are now regenerated in debian/rules. I am not regenerating
>>> the documentation yet. I understood that this is nice to have but not
>>> required, so I wanted to wait until the Sphinx 1.1 hits the archive.
>>> When that has happened, it's just a matter of uncommenting one line in
>>> debian/rules.
>> 
>> I was also a bit surprised that  so many DD did agree to not rebuild the
>> documentation. I would prefer that  the documentation is rebuilt. Why do
>> you need Sphinx 1.1?

> Sphinx 1.0 cannot extract the function signature for extension modules,
> Sphinx 1.1 can (by parsing the first line of the docstring). llfuse does
> some postprocessing on these docstrings (to remove C type declarations),
> so using Sphinx 1.0 doesn't just silently omit the signatures, but
> aborts with an error because of missing hooks for signature
> postprocessing.

> Discussion:
> https://bitbucket.org/birkenfeld/sphinx/issue/564

> Relevant changesets:
> https://bitbucket.org/birkenfeld/sphinx/changeset/de340a6098c7
> https://bitbucket.org/birkenfeld/sphinx/changeset/a8b0ef275438


> I also added a sphinx wishlist bug to backport this feature (Bug
> #630409).

OK to wait for Sphinx 1.1 (or for the resolution of bug #630409).
-- 
Vincent Bernat ☯ http://www.luffy.cx

 /*
  * For moronic filesystems that do not allow holes in file.
  * We may have to extend the file.
  */
	2.4.0-test2 /usr/src/linux/fs/buffer.c

Attachment: pgpc634mRHent.pgp
Description: PGP signature


Reply to: