Hi list: I'm the packager of APLpy: http://aplpy.github.com/ I'm going to update it to a new version, which comes with a set of tests, but I'm not sure about what to do with them. I asked upstream and the answer is: "The tests are there for us to diagnose any issues related to specific dependency versions and platforms, and to make sure that we don't break anything when making changes. It would be useful if you include them so that we can ask users to run them if they are having issues we can't reproduce, but you don't need to run the tests as part of the build/setup." I'm still not sure. Should I include them in the package?

Have a nice day, Germán. -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

On Mon, Apr 30, 2012 at 8:56 AM, Jon Ciesla&lt;limburgher(a)gmail.com&gt; wrote: > On Mon, Apr 30, 2012 at 8:50 AM, "Germán A. Racca" > <german.racca(a)gmail.com&gt; wrote: >> Hi list: >> >> I'm the packager of APLpy: http://aplpy.github.com/ >> >> I'm going to update it to a new version, which comes with a set of tests, >> but I'm not sure about what to do with them. I asked upstream and the answer >> is: >> >> "The tests are there for us to diagnose any issues related to specific >> dependency versions and platforms, and to make sure that we don't >> break anything when making changes. It would be useful if you include >> them so that we can ask users to run them if they are having issues we >> can't reproduce, but you don't need to run the tests as part of the >> build/setup." >> >> I'm still not sure. Should I include them in the package? > > Unless they impose huge build deps or something, run them in make check. To more directly answer your question, yes, include and run tests whenever possible. :)

On 04/30/2012 10:57 AM, Jon Ciesla wrote: > > On Mon, Apr 30, 2012 at 8:56 AM, Jon Ciesla&lt;limburgher(a)gmail.com&gt;  wrote: >> >> On Mon, Apr 30, 2012 at 8:50 AM, "Germán A. Racca" >> <german.racca(a)gmail.com&gt;  wrote: >>> >>> Hi list: >>> >>> I'm the packager of APLpy: http://aplpy.github.com/ >>> >>> I'm going to update it to a new version, which comes with a set of >>> tests, >>> but I'm not sure about what to do with them. I asked upstream and the >>> answer >>> is: >>> >>> "The tests are there for us to diagnose any issues related to specific >>> dependency versions and platforms, and to make sure that we don't >>> break anything when making changes. It would be useful if you include >>> them so that we can ask users to run them if they are having issues we >>> can't reproduce, but you don't need to run the tests as part of the >>> build/setup." >>> >>> I'm still not sure. Should I include them in the package? >> >> >> Unless they impose huge build deps or something, run them in make check. > > > To more directly answer your question, yes, include and run tests > whenever possible. :) Thanks Jon :) This is a Python package. Under what directory should I put them?

The tests ran fine in my computer[*], but what should I do in case of a negative outcome?

Germán. [*] $ python runtests.py =================== test session starts ==================== platform linux2 -- Python 2.7.2 -- pytest-2.2.0 collected 186 items tests/test_axis_labels.py ...... tests/test_beam.py ................ tests/test_colorbar.py ....... tests/test_contour.py .. tests/test_downsample.py . tests/test_frame.py .. tests/test_grid.py ....... tests/test_init_cube.py ............................ tests/test_init_image.py ........................................................................ tests/test_save.py ........................ tests/test_scalebar.py .......... tests/test_tick_labels.py ..... tests/test_ticks.py ...... =============== 186 passed in 106.97 seconds =============== -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

On Mon, Apr 30, 2012 at 3:57 PM, Jon Ciesla <limburgher(a)gmail.com&gt; wrote: > On Mon, Apr 30, 2012 at 8:56 AM, Jon Ciesla <limburgher(a)gmail.com&gt; wrote: >> On Mon, Apr 30, 2012 at 8:50 AM, "Germán A. Racca" >> <german.racca(a)gmail.com&gt; wrote: >>> Hi list: >>> >>> I'm the packager of APLpy: http://aplpy.github.com/ >>> >>> I'm going to update it to a new version, which comes with a set of tests, >>> but I'm not sure about what to do with them. I asked upstream and the answer >>> is: >>> >>> "The tests are there for us to diagnose any issues related to specific >>> dependency versions and platforms, and to make sure that we don't >>> break anything when making changes. It would be useful if you include >>> them so that we can ask users to run them if they are having issues we >>> can't reproduce, but you don't need to run the tests as part of the >>> build/setup." >>> >>> I'm still not sure. Should I include them in the package? >> >> Unless they impose huge build deps or something, run them in make check. > > To more directly answer your question, yes, include and run tests > whenever possible. :) This sounds like a SHOULD: include tests whenever possible... It's enough to run it in %check and normally a user of the package doesn't need to have the tests around. I'd only include them, when upstream wants to have tham in and installs them with "make" or "setup.py". And only in the latter case, you need to decide to split the tests into a subpackage.

=?ISO-8859-1?Q?=22Germ=E1n_A=2E_Racca=22?=&lt;german.racca(a)gmail.com&gt; writes: > I'm the packager of APLpy: http://aplpy.github.com/ > I'm going to update it to a new version, which comes with a set of > tests, but I'm not sure about what to do with them. I think you do want to make the tests available to users, but they don't necessarily have to be part of the base package. If the tests are large relative to the base package, a fairly common solution is to split them out into a sub-package, say aplpy-test. (This is in addition to running them during the build.) regards, tom lane

On 04/30/2012 04:22 PM, "Germán A. Racca" wrote: > > On 04/30/2012 11:09 AM, Tom Lane wrote: >> >> =?ISO-8859-1?Q?=22Germ=E1n_A=2E_Racca=22?=&lt;german.racca(a)gmail.com&gt; >> writes: >>> >>> I'm the packager of APLpy: http://aplpy.github.com/ >>> I'm going to update it to a new version, which comes with a set of >>> tests, but I'm not sure about what to do with them. >> >> >> I think you do want to make the tests available to users, but they don't >> necessarily have to be part of the base package. >> If the tests are large relative to the base package, a fairly common >> solution is to split them out into a sub-package, say aplpy-test. >> >> (This is in addition to running them during the build.) >> >> regards, tom lane > > > Hi Tom: > > $ du -sh aplpy/ > 300K aplpy/ > > $ du -sh tests/ > 192K tests/ > > So I think that a split is not needed in this case. This reasoning is dangerous: a) Testsuites usually pull in further dependencies, which are not required by the corresponding runtimes and therefore cause bloat. b) If everybody thinks the "These 100k more don't matter" way, the distro very soon will have problems. That said, my pragmatical recommendation would be a) Only explicitly package a testsuite, if upstream explicitly support this (I.e. if "make install" or similar install this testsuite). And if, do so in a separate package. b) Check carefully, if a test is actually designed to be externally (often this does not apply) or if it's an internal "self-testsuite". Apart of this, experience tells, *-test packages cause more trouble thany they use and often are removed in not too distant future.

Ralf -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

> Apart of this, experience tells, *-test packages cause more trouble thany > they use and often are removed in not too distant future. > Exactly, hence my suggestion to put it in %doc, to prevent deps, though it doesn't help with disk space as much as leaving it out.

Hi, Is it permissible to run a shell script, which has commands like: echo "Installing Development Tools" yum $YUMOPTS groupinstall "Development Tools" echo "Installing other packages" yum $YUMOPTS install python-devel.i386 yum $YUMOPTS install postgresql84-server.i386 postgresql84-devel.i386 postgresql84-python.i386 # note: check install script that already exists. ask kamal. # Download and install other packages echo "Installing Asterisk" wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-10... tar xvzf asterisk-10.2.1.tar.gz cd asterisk-10.2.1 ./configure make make install chkconfig asterisk on in the %post  section ?

Thanks, -Kamal. -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

what about, lets say: Requires(post): openssl >= 0.9.7f-4, /bin/cat i would like to package openssl in the rpm , is that possible ? or the standard way, is that if openssl is not installed, i just get an error, and have to manually install it? I am taking example of openssh, so when i do yum -y install openssh , it installs the openssh-server and openssh-client and also executes/runs the binary.

I found these in a article on mach: ref: http://psg.com/~brian/howto/mach.html 1. Given a spec file, rpmbuild won't download the source tarball and/or patches. You have to fetch those yourself into the SOURCES directory. 2. rpmbuild will abort if any build-time dependencies are missing, forcing you to stop what you're doing, and go and build and install those packages too. 3. When your package configures itself, it may auto-detect libraries which are available on your build system, but which are not going to be available on the target system. For example, if openldap-devel is present then openldap may be linked into your binaries, but if the RPM doesn't declare openldap as a dependency, then it will fail to run on the target system. This is an insiduous problem, which I call "the curse of autoconf". 4. You can only build packages for the same type of system as your build machine (e.g. CentOS 4 binaries on a CentOS 4 build system) Is there a way we can use rpmbuild to resolve these issues?

mock seems better than mach, but they both seem to be good for testing , before publishing RPMs What i wanted to know if there is a way to AUTO install the dependencies rather than just pointing them out I could do it in %post.

Now the binaries for the dependencies along with their respective config files with become part of the rpm that i ship.

Any comments ? Thanks, -Kamal. ________________________________ From: Michael Schwendt <mschwendt(a)gmail.com&gt; To: packaging(a)lists.fedoraproject.org Sent: Tuesday, May 1, 2012 3:34 PM Subject: Re: [Fedora-packaging] Can rpmbuild resolve these 4 issues ? On Tue, 1 May 2012 12:21:40 -0700 (PDT), KA (Kamal) wrote: > > I found these in a article on mach: > ref: http://psg.com/~brian/howto/mach.html > > >     1. Given a spec file, rpmbuild won't download the source tarball > and/or > patches. You have to fetch those yourself into the SOURCES directory. >     2. rpmbuild will abort if any build-time dependencies are missing, > forcing > you to stop what you're doing, and go and build and install those packages > too. >     3. When your package configures itself, it may auto-detect libraries > which > are available on your build system, but which are not going to be > available > on the target system. For example, if openldap-devel is present then > openldap may be linked into your binaries, but if the RPM doesn't declare > openldap as a dependency, then it will fail to run on the target system. > This is an insiduous problem, which I call "the curse of autoconf". >     4. You can only build packages for the same type of system as your > build > machine (e.g. CentOS 4 binaries on a CentOS 4 build system) > Is there a way we can use rpmbuild to resolve these issues? Take a look at "mock" instead? yum -y install mock ; man mock -- Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64 loadavg: 0.11 0.07 0.05 -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

I am trying to package a python application in rpm Source1: http://pypi.python.org/packages/source/Z/ZSI/ZSI-2.0-rc3.tar.gz %build {__python} setup.py build But i get an error: /usr/bin/python: can't open file 'ZSI-2.0-rc3/setup.py': [Errno 2] No such file or directory

Could it be that RPM Does not support building multiple applications ? I have a custom binary package, and since ZSI is a pre-requisite, i am trying to make XSI part of this RPM, so when the rpm is installed the dependency gets installed as well

I apologize for the context. Here is what i am trying to do: I have a Custom Application, that i managed to build RPM for. Now this application has some dependencies, like ZSI ( a Python Soap Framework ) what i am trying to do , is to package ZSI as part of the RPM.

hence: Source0: core-0.2.tar.gz Source1: ZSI-2.1-a1.tar.gz %prep %setup -qn core %setup -q -n ZSI-2.1-a1

%build #make core hnb_oct %{__make} core hnb_oct #%{__python} setup.py build %{__python} ZSI-2.1-a1/setup.py build But i get error: + cd ZSI-2.1-a1 /var/tmp/rpm-tmp.63811: line 47: cd: ZSI-2.1-a1: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.63811 (%prep)

1. is it possible to to build ZSI as part of this RPM ? I see that openssh does it by packaging client and server in one RPM.

2. I could not find any example that is close to what i am trying to do.

On Mon, Apr 30, 2012 at 9:48 AM, Ralf Corsepius&lt;rc040203(a)freenet.de&gt; wrote: > On 04/30/2012 04:22 PM, "Germán A. Racca" wrote: >> >> On 04/30/2012 11:09 AM, Tom Lane wrote: >>> >>> =?ISO-8859-1?Q?=22Germ=E1n_A=2E_Racca=22?=&lt;german.racca(a)gmail.com&gt; >>> writes: >>>> >>>> I'm the packager of APLpy: http://aplpy.github.com/ >>>> I'm going to update it to a new version, which comes with a set of >>>> tests, but I'm not sure about what to do with them. >>> >>> >>> I think you do want to make the tests available to users, but they don't >>> necessarily have to be part of the base package. >>> If the tests are large relative to the base package, a fairly common >>> solution is to split them out into a sub-package, say aplpy-test. >>> >>> (This is in addition to running them during the build.) >>> >>> regards, tom lane >> >> >> Hi Tom: >> >> $ du -sh aplpy/ >> 300K aplpy/ >> >> $ du -sh tests/ >> 192K tests/ >> >> So I think that a split is not needed in this case. > > > This reasoning is dangerous: > > a) Testsuites usually pull in further dependencies, which are not required > by the corresponding runtimes and therefore cause bloat. > > b) If everybody thinks the "These 100k more don't matter" way, the distro > very soon will have problems. > > > That said, my pragmatical recommendation would be > > a) Only explicitly package a testsuite, if upstream explicitly support this > (I.e. if "make install" or similar install this testsuite). And if, do so in > a separate package. > > b) Check carefully, if a test is actually designed to be externally (often > this does not apply) or if it's an internal "self-testsuite". > > Apart of this, experience tells, *-test packages cause more trouble thany > they use and often are removed in not too distant future. > Exactly, hence my suggestion to put it in %doc, to prevent deps, though it doesn't help with disk space as much as leaving it out. -J > > Ralf > > > > > -- > packaging mailing list > packaging(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/packaging

On 04/30/2012 11:48 AM, Ralf Corsepius wrote: > > On 04/30/2012 04:22 PM, "Germán A. Racca" wrote: >> >> On 04/30/2012 11:09 AM, Tom Lane wrote: >>> >>> =?ISO-8859-1?Q?=22Germ=E1n_A=2E_Racca=22?=&lt;german.racca(a)gmail.com&gt; >>> writes: >>>> >>>> I'm the packager of APLpy: http://aplpy.github.com/ >>>> I'm going to update it to a new version, which comes with a set of >>>> tests, but I'm not sure about what to do with them. >>> >>> >>> I think you do want to make the tests available to users, but they don't >>> necessarily have to be part of the base package. >>> If the tests are large relative to the base package, a fairly common >>> solution is to split them out into a sub-package, say aplpy-test. >>> >>> (This is in addition to running them during the build.) >>> >>> regards, tom lane >> >> >> Hi Tom: >> >> $ du -sh aplpy/ >> 300K aplpy/ >> >> $ du -sh tests/ >> 192K tests/ >> >> So I think that a split is not needed in this case. > > > This reasoning is dangerous: > > a) Testsuites usually pull in further dependencies, which are not > required by the corresponding runtimes and therefore cause bloat. Well, here I'm facing the problem that, for running the tests in %check section (after %build), all the required packages for runtime are also needed as BR. Should I continue to run tests in %check and add the corresponding BRs? In this case it'd be: BuildRequires:  python-devel numpy python-matplotlib pyfits pywcs Requires:       numpy python-matplotlib pyfits pywcs Or should I stop because of this additional BRs?

Germán. > b) If everybody thinks the "These 100k more don't matter" way, the > distro very soon will have problems. > > > That said, my pragmatical recommendation would be > > a) Only explicitly package a testsuite, if upstream explicitly support > this (I.e. if "make install" or similar install this testsuite). And if, > do so in a separate package. > > b) Check carefully, if a test is actually designed to be externally > (often this does not apply) or if it's an internal "self-testsuite". > > Apart of this, experience tells, *-test packages cause more trouble > thany they use and often are removed in not too distant future. > > > Ralf > > > > -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging