Re: Taking over maintainership of gringotts
On Tue, Jul 24, 2012 at 12:05:59AM +0200, Jose G. López wrote: Arno Töll wrote: but it certainly won't hurt. Not too many people care about that flag (you know, even less than about RFS bugs). Thanks Arno, but since Bart seems to be reviewing these packages, I suppose he will sponsor them. Other sponsors are welcome to review and upload these packages at any time without talking to me. Bart, I made the changes requested in your comments but I'm not sure if I have to re-upload the packages bumping a new revision 1.2.10.-2 or I keep them on revision -1. I suggest to replace gringotts at mentors with the same number 1.2.10-1. Another doubt is with bug #633167. It belongs to gringotts source package but whit the split I can't close it in libgringotts. I think we'll have to close it manually, won't we? You can simply use Closes: #633167 in debian/changelog of the package with the fix. I see that gringotts 1.2.10~pre3-1 has Merge libgringotts source package in debian/changelog. You seem to be undoing that now. Intentional ? Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120724060947.gb2...@master.debian.org
Help needed in gcc-4.7 - cython issue
Hi, I did run into some trouble with a fresh package which is prepared in SVN at Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/python-biom-format/trunk/ You can obtain the source via `uscan --force-download` or `make -f debian/rules get-orig-source` . The package builds nicely when leaving out cython as Build-Depends but upstream recommended strongly to use cython which results in trying to build a C++ file which unfortunately fails when using gcc-4.7. I stripped down the command line which fails to the minimum and here is the comparison between gcc-4.7 and gcc-4.6 $ gcc-4.7 -I/usr/include/python2.6 -c python-code/support-code/_sparsemat.cpp -std=c++0x python-code/support-code/_sparsemat.cpp: In function ‘void __Pyx_RaiseArgtupleInvalid(const char*, int, Py_ssize_t, Py_ssize_t, Py_ssize_t)’: python-code/support-code/_sparsemat.cpp:5164:95: error: unable to find string literal operator ‘operator PY_FORMAT_SIZE_T’ python-code/support-code/_sparsemat.cpp: In function ‘void __Pyx_RaiseNeedMoreValuesError(Py_ssize_t)’: python-code/support-code/_sparsemat.cpp:5424:52: error: unable to find string literal operator ‘operator PY_FORMAT_SIZE_T’ python-code/support-code/_sparsemat.cpp: In function ‘void __Pyx_RaiseTooManyValuesError(Py_ssize_t)’: python-code/support-code/_sparsemat.cpp:5430:73: error: unable to find string literal operator ‘operator PY_FORMAT_SIZE_T’ $ gcc-4.6 -I/usr/include/python2.6 -c python-code/support-code/_sparsemat.cpp -std=c++0x I did some giggling and noticed that the error above occured in some threads were some solution was promised with cython 0.16. So I also tried cython from experimental and can confirm that the problem above remains identical - so cython 0.16 does not seem to be the solution. However, in some way I would like to blame cython for the problem anyway because the problematic lines do seem to be injected by the cython preprocessing (the file python-code/support-code/_sparsemat.cpp is automatically created when calling python setup.py ... unfortunately I have no idea about cython internals). In other words: The problem might be relevant also for other packages using cython in connection with gcc-4.7. Any hint how to fix this would be welcome. Kind regards Andras. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120724070230.gc14...@an3as.eu
Help needed with dh_python2 and dh_python3
Hi all
I have a package that installs a few Python scripts and utility modules
which are compatible with both, python2 and python3. The build system
does not use distutils, it just copies the files into
/usr/share/pyshared/module/.
Now, I figured it would be as easy as
* adding a build-dependency on python and python3
* adding X-Python-Versino and X-Python3-Version tags
* adding ${python:Depends} and ${python3:Depends} to the respective
binary packages dependencies
* invoking the dh sequencer with the option --with=python2,python3
That, however, only seems to give the desired results for python2; the
files in /usr/share/pyshared/module are sym-linked to
/usr/lib/python2.7/dist-packages/module. Although, in the build log I
do see that dh_python3 is being invoked, it simply doesn't seem to have
any effect.
Manually invoking dh_python3 then errors out that it detected python2
and that I should call dh_python2 instead.
Anybody got a clue as to what I'm doing wrong here? Do I need to add an
extra binary python3-foo package?
Michael
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500e59b7.60...@gmail.com
Re: Help needed with dh_python2 and dh_python3
On Tue, Jul 24, 2012 at 1:15 AM, Michael Wild them...@gmail.com wrote: [snip] Anybody got a clue as to what I'm doing wrong here? Do I need to add an extra binary python3-foo package? As far as I'm aware, yes, you have to add an extra binary in debian/control if you want to build both python2 and python3 packages for foo. See [1] for an example that is fairly straight-to-the-point. Regards, Vincent [1] http://wiki.debian.org/Python/LibraryStyleGuide -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tdr7xkj_prakuk+nabnek6zz4yf0ab5cnspe7ydbey...@mail.gmail.com
Re: Help needed in gcc-4.7 - cython issue
Hi, On 24/07/12 09:02, Andreas Tille wrote: $ gcc-4.7 -I/usr/include/python2.6 -c python-code/support-code/_sparsemat.cpp -std=c++0x python-code/support-code/_sparsemat.cpp: In function ‘void __Pyx_RaiseArgtupleInvalid(const char*, int, Py_ssize_t, Py_ssize_t, Py_ssize_t)’: python-code/support-code/_sparsemat.cpp:5164:95: error: unable to find string literal operator ‘operator PY_FORMAT_SIZE_T’ python-code/support-code/_sparsemat.cpp: In function ‘void __Pyx_RaiseNeedMoreValuesError(Py_ssize_t)’: python-code/support-code/_sparsemat.cpp:5424:52: error: unable to find string literal operator ‘operator PY_FORMAT_SIZE_T’ python-code/support-code/_sparsemat.cpp: In function ‘void __Pyx_RaiseTooManyValuesError(Py_ssize_t)’: python-code/support-code/_sparsemat.cpp:5430:73: error: unable to find string literal operator ‘operator PY_FORMAT_SIZE_T’ $ gcc-4.6 -I/usr/include/python2.6 -c python-code/support-code/_sparsemat.cpp -std=c++0x I did some giggling and noticed that the error above occured in some threads were some solution was promised with cython 0.16. So I also tried cython from experimental and can confirm that the problem above remains identical - so cython 0.16 does not seem to be the solution. As it seems, the fix has been merged after the 0.16 release. The patch to solve this in cython can be found at [1]. Until this is fixed one can try to add spaces between PY_FORMAT_SIZE_T and the quotation marks in the file generated by cython. Kind regards [1] https://github.com/cython/cython/pull/109 -- Sebastian Ramacher signature.asc Description: OpenPGP digital signature
Re: Help needed with dh_python2 and dh_python3
Hi Michael (2012.07.24_10:15:51_+0200)
I have a package that installs a few Python scripts and utility modules
which are compatible with both, python2 and python3. The build system
does not use distutils, it just copies the files into
/usr/share/pyshared/module/.
That's probably not ideal. pyshared is almost an internal implementation
detail of dh_python2 (although, one that's documented in the Python
Policy [0]). Upstream build systems should not be installing there. They
should install into the usual dist-packages directories, and dh_python2
will de-duplicate between python versions.
dh_python2 supports .pyinstall files, to achieve the same thing.
[0]:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-paths
As to installing for python3, you should install to
/usr/lib/python3/dist-packages in that binary package.
Now, I figured it would be as easy as
* adding a build-dependency on python and python3
* adding X-Python-Versino and X-Python3-Version tags
* adding ${python:Depends} and ${python3:Depends} to the respective
binary packages dependencies
* invoking the dh sequencer with the option --with=python2,python3
You also need to make sure the python modules go into the python-
package, and the python3 modules go into the python3- package.
With distutils, this means overriding dh_auto_*.
Anybody got a clue as to what I'm doing wrong here? Do I need to add an
extra binary python3-foo package?
Yes.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 461 1230 C: +27 72 419 8559
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724101220.go1...@bach.rivera.co.za
Re: Help needed with dh_python2 and dh_python3
On 07/24/2012 12:12 PM, Stefano Rivera wrote:
Hi Michael (2012.07.24_10:15:51_+0200)
I have a package that installs a few Python scripts and utility modules
which are compatible with both, python2 and python3. The build system
does not use distutils, it just copies the files into
/usr/share/pyshared/module/.
That's probably not ideal. pyshared is almost an internal implementation
detail of dh_python2 (although, one that's documented in the Python
Policy [0]). Upstream build systems should not be installing there. They
should install into the usual dist-packages directories, and dh_python2
will de-duplicate between python versions.
My misunderstanding, obviously. Simple to fix, as I actually forced the
build system to install there ;-)
dh_python2 supports .pyinstall files, to achieve the same thing.
[0]:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-paths
As to installing for python3, you should install to
/usr/lib/python3/dist-packages in that binary package.
Now, I figured it would be as easy as
* adding a build-dependency on python and python3
* adding X-Python-Versino and X-Python3-Version tags
* adding ${python:Depends} and ${python3:Depends} to the respective
binary packages dependencies
* invoking the dh sequencer with the option --with=python2,python3
You also need to make sure the python modules go into the python-
package, and the python3 modules go into the python3- package.
With distutils, this means overriding dh_auto_*.
Anybody got a clue as to what I'm doing wrong here? Do I need to add an
extra binary python3-foo package?
Yes.
SR
Stefano, Vincent: thanks for the hints.
Michael
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500e83f1.4090...@gmail.com
Re: nbc package has been removed from Mentors
Hi, Dňa Mon, 16 Jul 2012 12:34:55 +0200 George Danchev danc...@spnet.net napísal: Of course, you should try again. Just put some more salt, in hope to whet the prospective sponsor's appetite. thanks, i will wait some time now. IMO it seems as useless to try it in freeze time. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Bug#682680: RFS: clean-compiler/2.4-1 [ITP] -- The Clean language compiler
package sponsorship-requests severity 682680 wishlist user sponsorship-reque...@packages.debian.org usertags 682680 not-fit-for-wheezy thanks On Tue, Jul 24, 2012 at 04:55:49PM +0200, Patrick Uiterwijk wrote: Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Normal, for a new package? (I'm correcting that now; also setting not-fit-for-wheezy because it's a new package and thus cannot get a freeze exception.) * Package name: clean Your ITP is for clean-compiler. What's the difference about? * URL : http://wiki.clean.cs.ru.nl/ * License : GPLv2 The upstream page says The Simplified BSD License applies to the libraries, runtime system and examples, the LGPL to the rest. Your copyright file doesn't specify GPLv2 either. Where do you get GPLv2 from? Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/clean/clean_2.4-1.dsc Where did you download the original source tarball from? Your copyright file is vague about that. In any case it's none of the source tarballs downloadable from the location given: $ md5sum clean2*tar.gz Clean2.4Sources.tar.gz clean_2.4.orig.tar.gz b715e981dc1ef6702c2f670ad888f9af clean2.4_64_boot.tar.gz 558dc5c85322617ea7138a9a6838c89f clean2.4_boot.tar.gz 9474bfb60959a825fac883399a4812ce Clean2.4Sources.tar.gz de86967b3ea208017e1c32a8fbeaf7b0 clean_2.4.orig.tar.gz How do you plan to handle compiler bootstrapping? (That's it for now. I'll do a more thorough review once these questions have been addressed.) -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120724154703.gk3...@kukkavihko.kaijanaho.fi
Processed: Re: Bug#682680: RFS: clean-compiler/2.4-1 [ITP] -- The Clean language compiler
Processing commands for cont...@bugs.debian.org: package sponsorship-requests Limiting to bugs with field 'package' containing at least one of 'sponsorship-requests' Limit currently set to 'package':'sponsorship-requests' severity 682680 wishlist Bug #682680 [sponsorship-requests] RFS: clean-compiler/2.4-1 [ITP] -- The Clean language compiler Severity set to 'wishlist' from 'normal' user sponsorship-reque...@packages.debian.org Setting user to sponsorship-reque...@packages.debian.org (was antti-juh...@kaijanaho.fi). usertags 682680 not-fit-for-wheezy There were no usertags set. Usertags are now: not-fit-for-wheezy. thanks Stopping processing here. Please contact me if you need assistance. -- 682680: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682680 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13431448303938.transcr...@bugs.debian.org
Processed: clean-compiler: block ITP 680061 by RFS 682680
Processing commands for cont...@bugs.debian.org: block 680061 by 682680 Bug #680061 [wnpp] ITP: clean-compiler - The Clean language compiler 680061 was not blocked by any bugs. 680061 was not blocking any bugs. Added blocking bug(s) of 680061: 682680 stop Stopping processing here. Please contact me if you need assistance. -- 680061: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680061 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134314680014824.transcr...@bugs.debian.org
Re: Backporting a multi-arched package
Hello Martin, Remove multi-arch support: debian/control: * remove lines with Multi-Arch: * remove lines with Pre-Depends: * Move back to dephelper (= 8) debian/compat: * Move back to 8 debian/rules: * Remove lines which looks like support for multi-arch... debian/*.install: * change all library paths from usr/lib/*/ to usr/lib That should be all. --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120724204324.13f86...@jupiter.home
[k...@roeckx.be: Bug#680436: sra-sdk: FTBFS: gcc/i386/atomic32.h:125:5: error: impossible constraint in 'asm']
Hi, I tagged this bug help because I admit I do not have any clue about assembler programming and atomic operations. I did also forewarded the problem upstream. Any hint would be welcome Andreas. - Forwarded message from Kurt Roeckx k...@roeckx.be - Date: Thu, 5 Jul 2012 22:34:41 +0200 From: Kurt Roeckx k...@roeckx.be To: sub...@bugs.debian.org Subject: Bug#680436: sra-sdk: FTBFS: gcc/i386/atomic32.h:125:5: error: impossible constraint in 'asm' Source: sra-sdk Version: 2.1.7a-1 Severity: important Hi, It seems your packages uses i386 assembler unconditionally. I understand this is about atomic operations. gcc includes support for atomic operations. There is also atomic support in C11 / C++11. I suggest you use one of those. Kurt - End forwarded message - -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120724185734.gd28...@an3as.eu
Re: Taking over maintainership of gringotts
El 24/07/12 08:09, Bart Martens escribió: Other sponsors are welcome to review and upload these packages at any time without talking to me. For sure. Sorry. Bart, I made the changes requested in your comments but I'm not sure if I have to re-upload the packages bumping a new revision 1.2.10.-2 or I keep them on revision -1. I suggest to replace gringotts at mentors with the same number 1.2.10-1. Done. Now we have two versions at mentors with the same version. I thought they would be overwritten ... Another doubt is with bug #633167. It belongs to gringotts source package but whit the split I can't close it in libgringotts. I think we'll have to close it manually, won't we? You can simply use Closes: #633167 in debian/changelog of the package with the fix. I can't in gringotts source package where it belongs now. I mention this on libgringotts changelog but don't like to close it automatically. I see that gringotts 1.2.10~pre3-1 has Merge libgringotts source package in debian/changelog. You seem to be undoing that now. Intentional ? Yes, it's intentional. I comment this in changelogs and in the first post here. IMHO I think would be better for new software using its functionality. Sorry for the delay I tested the packages again. I don't want to waste your time. Thanks and regards. signature.asc Description: OpenPGP digital signature
