Re: FreeDiams (no) qmake Problem ;)
On Mon, Mar 29, 2010 at 09:15:07AM +0200, Eric MAEKER wrote: Try in rules override_dh_install: make install Sounds very reasonable. Sorry for introducing this problem by choosing short dh command. While I made several positive experiences with this change it opens a pitfall here. I have no time to work on the package now but my problem seems to be solved and I'll try to continue with the restructuring this evening. Thanks for your effort Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329082150.ga24...@an3as.eu
FreeDiams: RPATH problem solved, upstream install target disturbs symlinks
Hi, I worked around the RPATH issue of FreeDiams by patching[1] which is not a really clean solution but works. The patch file contains a comment about my previous more clean trial. Eric, perhaps you might like to read more about this issue[2]. There is one problem remaining in the final package: The different SO versions of the dynamic libraries are not symlinks but just identical copies of these files. While the temporary build directory contains symlinks the make install target is mixing this up. This also concerns upstream and before I change the packaging I would like to let you know about this issue. My prefered solution in packaging would probably to skip the make install target completely and be more verbose in the debian/*.install files to let dh_install copy the symlinks directly. Kind regards Andreas. [1] http://svn.debian.org/wsvn/debian-med/trunk/packages/freediams/trunk/debian/patches/20_no_rpath.patch [2] http://wiki.debian.org/RpathIssue -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329130352.ga...@an3as.eu
Re: Status of SIGAR (Was: InVesalius packaging)
Dear Andreas, Until now, we haven't had advances on SIGAR packaging [1]. How should we proceed? Kind regards, Tatiana [1] https://groups.google.com/group/linux.debian.devel.mentors/browse_thread/thread/163e37501dea0d7a?pli=1 On 25 March 2010 13:45, Tatiana Al-Chueyr tatiana.alchu...@gmail.comwrote: Sorry, missing reference: [1] https://groups.google.com/group/linux.debian.devel.mentors/browse_thread/thread/163e37501dea0d7a?pli=1 On 25 March 2010 13:44, Tatiana Al-Chueyr tatiana.alchu...@gmail.comwrote: Dear Andreas, On 23 March 2010 07:11, Andreas Tille andr...@fam-tille.de wrote: Hi, I would like to come back to the InVesalius packaging which depends from SIGAR Thiago posted yesterday a message to the mailing list you proposed, regarding SIGAR packaging [1]. Should we have any advances in this subject, we´ll post to Debian-Med list...! Kind regards, Tatiana . On Thu, Feb 25, 2010 at 10:25:23PM +0100, Andreas Tille wrote: Can we (Thiago) pack SIGAR oficially? Sure. That's the best thing you can do to speed InVesalius packaging up. Is there any progress done to get an official sigar package? Kind regards Andreas. PS: In case you do not remember the context of this question have a look into the archive (second half of the mail): http://lists.debian.org/debian-med/2010/02/msg00056.html -- http://fam-tille.de -- Tatiana Al-Chueyr -- Tatiana Al-Chueyr -- Tatiana Al-Chueyr
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 10:11:09AM -0300, Tatiana Al-Chueyr wrote: Until now, we haven't had advances on SIGAR packaging [1]. How should we proceed? I had a (quick) look at Thiagos packaging[2] and while the package builds somehow there are several lintian warnings. If you try lintian -i *.dsc *.deb you get explanations and several of these are relatively easy to fix. An absolute no go is the missing copyright information which definitely needs fixing. Please try to work down the list of lintian problems and feel free to ask for any help if something remains unclear. BTW, it might make sense to join a packaging team on alioth (python-modules-team ??) and use their SVN for the packaging stuff. This enables potential helpers for packaging to commit changes easily. Hope this helps for the moment Andreas. [1] http://lists.debian.org/debian-mentors/2010/03/msg00324.html [2] http://dl.dropbox.com/u/817671/packages/sigar_1.7.0%7Esvn5287-1.dsc -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329134010.ga2...@an3as.eu
Re: FreeDiams: RPATH problem solved, upstream install target disturbs symlinks
Le 29 mars 10 à 15:03, Andreas Tille a écrit : Hi, I worked around the RPATH issue of FreeDiams by patching[1] which is not a really clean solution but works. The patch file contains a comment about my previous more clean trial. Eric, perhaps you might like to read more about this issue[2]. Ok I'll take a look tonight. Thanks. There is one problem remaining in the final package: The different SO versions of the dynamic libraries are not symlinks but just identical copies of these files. While the temporary build directory contains symlinks the make install target is mixing this up. This also concerns upstream and before I change the packaging I would like to let you know about this issue. I can clean this part. Without changing the make install behavior. My prefered solution in packaging would probably to skip the make install target completely and be more verbose in the debian/*.install files to let dh_install copy the symlinks directly. May be the install.pri adaptation is a better solution. Give me some days please. Kind regards Andreas. Thanks Eric -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2ebb9be9-987a-462d-9db3-55d5e2a4c...@gmail.com
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.dewrote: On Mon, Mar 29, 2010 at 10:11:09AM -0300, Tatiana Al-Chueyr wrote: Until now, we haven't had advances on SIGAR packaging [1]. How should we proceed? I had a (quick) look at Thiagos packaging[2] and while the package builds somehow there are several lintian warnings. If you try lintian -i *.dsc *.deb you get explanations and several of these are relatively easy to fix. An absolute no go is the missing copyright information which definitely needs fixing. Please try to work down the list of lintian problems and feel free to ask for any help if something remains unclear. BTW, it might make sense to join a packaging team on alioth (python-modules-team ??) and use their SVN for the packaging stuff. This enables potential helpers for packaging to commit changes easily. Hope this helps for the moment Andreas. [1] http://lists.debian.org/debian-mentors/2010/03/msg00324.html [2] http://dl.dropbox.com/u/817671/packages/sigar_1.7.0%7Esvn5287-1.dsc -- http://fam-tille.de Thanks Andreas, I fixed some of lintian problems. One of the problems that remains is: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) Thanks!
Re: FreeDiams: RPATH problem solved, upstream install target disturbs symlinks
On Mon, Mar 29, 2010 at 04:29:15PM +0200, Eric MAEKER wrote: May be the install.pri adaptation is a better solution. It would be the better solution ... if it would work. The approach I tried first does not work, but the hack does. I'd prefer a clean solution as well but I do not know the qmake build system enough. Give me some days please. Sure. Take the time you need and just commit your changes to SVN. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329191116.ga16...@an3as.eu
Re: Status of SIGAR (Was: InVesalius packaging)
Hey, On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.dewrote: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I wasn't following this effort before -- forgive me if that had been talked about before. Looks like the Python-bindings (and others too) should go into separate binary packages and be handled by proper tools. pysupport should take care of all Python-related issue (including the one above). Is there any reason for this verbose rules file. Both debhelper7 and cdbs should help a lot with the common cases of packaging (like this one) and also provide convenient helpers for python packages. I might be able to help with the general and python-related aspects of this packaging, but wanted to ask first if there is need to stay close to the current state? Right now the packaging looks quite raw -- lots of unused/unedited files. The rules file only seems to build the python-bindings and none of the rest -- including the main library -- is that intended? Given these facts the binary package should be named 'python-sigar'. Is there a repository for this packaging somewhere? You chose to take an SVN snapshot (upstream also offers the code in git). Did you just download that snapshot or have the code in a repository together with the packaging? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329192755.ga22...@meiner
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 4:27 PM, Michael Hanke michael.ha...@gmail.comwrote: Hey, On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.de wrote: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I wasn't following this effort before -- forgive me if that had been talked about before. Looks like the Python-bindings (and others too) should go into separate binary packages and be handled by proper tools. pysupport should take care of all Python-related issue (including the one above). Is there any reason for this verbose rules file. Both debhelper7 and cdbs should help a lot with the common cases of packaging (like this one) and also provide convenient helpers for python packages. I might be able to help with the general and python-related aspects of this packaging, but wanted to ask first if there is need to stay close to the current state? Right now the packaging looks quite raw -- lots of unused/unedited files. The rules file only seems to build the python-bindings and none of the rest -- including the main library -- is that intended? Given these facts the binary package should be named 'python-sigar'. Is there a repository for this packaging somewhere? You chose to take an SVN snapshot (upstream also offers the code in git). Did you just download that snapshot or have the code in a repository together with the packaging? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.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/20100329192755.ga22...@meiner Hi Michael, No, it's not needed to stay close to the current state. I only packaged the python-bindings because the project I work [1] needs only the python-bindings. The last stable version from sigar doesn't compile, then it was necessary to compile the trunk version (svn or git). The package is in our Download page [2] (Ubuntu and Fedora). Thanks for help! [1] - http://svn.softwarepublico.gov.br/trac/invesalius/ [2] - http://svn.softwarepublico.gov.br/trac/invesalius/wiki/downloads/3.0-beta-2#GNULinuxInstaller
