packaging November 2010

packaging@lists.fedoraproject.org

33 participants
22 discussions

Koji push failure
by Viji V Nair 13 Nov '10

13 Nov '10

Hi 16 hours ago I have received 4 mails from koji saying: "python-tilecache-2.11-5.fc14 successfully moved from dist-f14-updates-candidate into dist-f14-updates-testing by bodhi" and "python-tilecache-2.11-5.fc13 successfully moved from dist-f13-updates-candidate into dist-f13-updates-testing by bodhi" "python-tilecache-2.11-5.fc13 successfully untagged from dist-f13-updates-testing-pending by bodhi" "python-tilecache-2.11-5.fc14 successfully untagged from dist-f14-updates-testing-pending by bodhi" but 12 hours ago I received couple of failure messages. python-tilecache-2.11-5.fc14 unsuccessfully untagged from dist-f14-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build python-tilecache-2.11-5.fc14 not in tag dist-f14-updates-testing-pending python-tilecache-2.11-5.fc13 unsuccessfully untagged from dist-f13-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build python-tilecache-2.11-5.fc13 not in tag dist-f13-updates-testing-pending I could see the packages have been pushed to testing, but yum returns nothing. https://admin.fedoraproject.org/updates/python-tilecache http://koji.fedoraproject.org/koji/buildinfo?buildID=204623 http://koji.fedoraproject.org/koji/buildinfo?buildID=204622 Thanks Viji

2 1

Re: [Fedora-packaging] Packaging ada libraries
by Björn Persson 12 Nov '10

12 Nov '10

Orion Poplawski wrote: > I'm thinking perhaps it is time to come up with a standard for how ada > libraries are installed. I don't know much about ada, but I package plplot > which has an ada interface. ada uses a couple different types of files: > adb, ads, ali, and perhaps .gpr and .lgpr for gnat. I have made a few Ada packages and have been trying to come up with some workable practices. The details are still subject to change but I'll try to write down how I currently do things. To make usage of Ada libraries smooth for programmers I have based my packaging on Gnat project files (.gpr files). Every Ada library should have a project file describing how to compile programs against the library. In order to work correctly in a multilib system, the project file should include common.gpr from the package fedora-gnat-project-common, and use the variable Common.Lib in place of "lib" or "lib64" in paths. The file common.gpr is one of the things that are subject to change. I have started thinking that maybe I should define some more complete paths there and rename it to "locations.gpr" or something. fedora-gnat-project-common also contains some RPM macros that should be used in spec files. > Example location from GtkAda-devel: > > /usr/include/gtkada/gtkada-types.adb > /usr/include/gtkada/gtkada-types.ads > /usr/lib/gnat/gtkada.gpr > /usr/lib/gnat/gtkada/gtkada.lgpr > /usr/lib/gtkada/relocatable/gtkada.ali > /usr/lib/gtkada/static/gtkada.ali > /usr/lib/libgtkada.so > > I don't know about the difference between relocatable and static. The GTKada build system has a rather unusual idea of putting shared and static libraries in separate subdirectories, with copies of the same .ali files in both subdirectories. The RPM spec fixes it up a bit by moving the shared libraries to %{_libdir} so that the linker can find them. In Fedora we shouldn't really package the static libraries. I'm sporadically working on a big patch to the GTKada build system that will provide a clean way of disabling the static libraries and putting the shared ones in the right place. It will also allow putting the .ali files directly in %{_libdir}/gtkada. > So this may be simple, but perhaps: > > %{_includedir}/<name>/ > %{_libdir}/<name>/ > > is sufficient. That's what I've been doing. Source code needed for compiling against the library (.ads and some .adb files) in %{_includedir}/<name>, linking information (.ali files) in %{_libdir}/<name>, and of course the library files themselves in %{_libdir}. I'll just add one thing: Gnat project files should go in %{_GNAT_project_dir}. That macro expands to /usr/lib/gnat, even on 64-bit systems, because that's where Gnat looks for project files. I think all that's technically required is that Gnat can find the project file and that the linker can find the library. Things should then work as long as the project file points correctly to the other files. None the less I want all files to be in standard locations so that humans can find them without too much trouble. > plplot-ada-devel currently puts files in: > > /usr/lib/ada/adalib/plplotadad/plplot.ali > /usr/share/ada/adainclude/plplotadad/plplot.adb > /usr/share/ada/adainclude/plplotadad/plplot.ads > > Not sure where they got that directory structure from. That looks reminiscent of a draft document that was called "GNU Ada Environment Specification". I never understood the purpose of that directory structure, but the Ada packages in Debian conform to it. Before I started packaging for Fedora I was going to review the specification and see if I could figure out what the advantage was, but all the links to it that I could find were broken. Since the GNU Ada Environment Specification seemed to be defunct, and GTKada – the only Ada library that I could find in Fedora at the time – didn't follow it, I decided to use a directory structure as close as possible to what is used for other compiled languages in Fedora. > plplot does not produce .gpr or .lgpr files. Not sure if this should be > enforced or how they are produced. As I wrote above, I want to require .gpr files. You'll need to write one by hand if upstream doesn't provide one, but it's really not too hard to do. You can look at pragmarc.gpr from PragmARC-devel for an example of what it will look like for an uncomplicated library. Lists of source files like GTKada's .lgpr files can be useful when compiling a project, but I can't see that they do any good for an installed library. Nor do I think that the ".lgpr" suffix is a widespread convention. Björn Persson

1 0

Packaging ada libraries
by Orion Poplawski 10 Nov '10

10 Nov '10

I'm thinking perhaps it is time to come up with a standard for how ada libraries are installed. I don't know much about ada, but I package plplot which has an ada interface. ada uses a couple different types of files: adb, ads, ali, and perhaps .gpr and .lgpr for gnat. Example location from GtkAda-devel: /usr/include/gtkada/gtkada-types.adb /usr/include/gtkada/gtkada-types.ads /usr/lib/gnat/gtkada.gpr /usr/lib/gnat/gtkada/gtkada.lgpr /usr/lib/gtkada/relocatable/gtkada.ali /usr/lib/gtkada/static/gtkada.ali /usr/lib/libgtkada.so I don't know about the difference between relocatable and static. So this may be simple, but perhaps: %{_includedir}/<name>/ %{_libdir}/<name>/ is sufficient. plplot-ada-devel currently puts files in: /usr/lib/ada/adalib/plplotadad/plplot.ali /usr/share/ada/adainclude/plplotadad/plplot.adb /usr/share/ada/adainclude/plplotadad/plplot.ads Not sure where they got that directory structure from. plplot does not produce .gpr or .lgpr files. Not sure if this should be enforced or how they are produced. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 0

Updating our rpath guidelines?
by Michel Alexandre Salim 09 Nov '10

09 Nov '10

Hi all, Several months ago, Mamoru Tasaka suggested a less intrusive way of patching a source package's bundled libtool so that /usr/lib64 does not end up in the installed binaries. So actually for most cases, the case that rpath /usr/lib64 is added (only for 64 bits arch) can be avoided by ------------------------------------------------------------------------ sed -i.libdir_syssearch -e \ '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib /lib64 |' \ configure ------------------------------------------------------------------------ i.e. just add the needed paths to sys_lib_dlsearch_path_spec in configure (note that libtool in the build directory is generated by configure) before calling %configure. - You can alternatively do "autoreconf -fi", however calling autotools is not recommended unless unavoidable. ---------- I have several packages using the old-style DIE_RPATH_DIE (http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath) sed hack, and while they've been working out fine so far, I just noticed when updating Vala today that this rather invasive change is responsible for Vala's test suite not to run: since the Vala libraries have not been installed on the system when the tests were run, Rpath is actually necessary to run the tests! Given that there are probably other packages where internal test suites depend on a currently-uninstalled shared library, updating the Rpath guidelines ought to have positive effect on packaging quality. We should probably also search for occurences of the old DIE_RPATH_DIE and convert them to the new format. Best regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: salimma(a)fedoraproject.org | GPG key ID: 78884778 Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 5

RFC before update PHP Guidelines about PEAR package documentation
by Remi Collet 08 Nov '10

08 Nov '10

For now, doc provided in pear package use an awful hack. Standard pear installation copy doc in /usr/share/pear/doc (known as %{pear_docdir} in spec file) After installation they are moved to a temporary location Something like mv %{buildroot}%{pear_docdir}/%{pear_name} docdir And then add to %file as %doc %doc docdir/* This seems awful for (at least) 2 reasons: - PHP developer are used to search them in /usr/share/pear/doc - report of "pear list-files <package>" is wrong Proposal : - keep documentation in standard pear location - tag them as doc files %doc %{pear_docdir}/%{pear_name} - add a README-DOCS-RPM in standard "fedora" location Documentation for %{pear_name} are in %{pear_docdir}/%{pear_name} Other tried solutions - soft link => will be impossible to handle update (from file to link) for all existing packages - overriding "doc_dir" in pear configuration before install => file list don't store full patch, but path relative to config so, this won't work, path must be the same for all packageq Any comment ? Others idea ? I will submit a draft for a PHP Guidelines update quite soon. Remi. P.S. for now, /usr/share/pear/doc only contains doc from php-pear main package, this is an exception which probably need to be fixed according to the Guidelines, if approved.

2 1

Koji Error - Policy Violation
by Viji V Nair 08 Nov '10

08 Nov '10

Hi, I am building some package for fedora and one of package is under review. (https://bugzilla.redhat.com/show_bug.cgi?id=649662). For the same I need to submit the output of koji build to the ticket, but I am getting the following error message when I try to build FAILED: ActionNotAllowed: policy violation $ koji --user=viji --password=**** build dist-f13-updates-candidate rpmbuild/SRPMS/python-tilecache-2.11-4.fc13.src.rpm Uploading srpm: rpmbuild/SRPMS/python-tilecache-2.11-4.fc13.src.rpm [====================================] 100% 00:00:09 69.54 KiB 7.62 KiB/sec Created task: 2586501 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2586501 Watching tasks (this may be safely interrupted)... 2586501 build (dist-f13-updates-candidate, python-tilecache-2.11-4.fc13.src.rpm): open (x86-17.phx2.fedoraproject.org) 2586501 build (dist-f13-updates-candidate, python-tilecache-2.11-4.fc13.src.rpm): open (x86-17.phx2.fedoraproject.org) -> FAILED: ActionNotAllowed: policy violation 0 free 0 open 0 done 1 failed 2586501 build (dist-f13-updates-candidate, python-tilecache-2.11-4.fc13.src.rpm) failed Thanks Viji

3 2

Help with rpath issue
by Jirka Hladky 06 Nov '10

06 Nov '10

Hello everybody! I have run into rpath issue when creating rpm for hwloc (you might want to check package review ticket at https://bugzilla.redhat.com/show_bug.cgi?id=606498) rpath is added by libtool. Libraries are getting installed into /usr/lib64 but libtool does not recognize this as default library location on 64-bit system. One solution was to add "/usr/lib64" directory into /etc/ld.so.conf. Practical solution to get rpm was to add sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool into the %configure stage in rpm specs. I would like to get rid of these sed lines. For me it seems either that libtool is buggy or "/usr/lib64" directory is missing in /etc/ld.so.conf. I (together with upstream) would highly appreciate any feedback on it. Thanks Jirka

6 8

Appropriate values fot gitversion, gitdate from git clone?
by Nick Urbanik 05 Nov '10

05 Nov '10

Dear Packagers, Wanting to build a new xorg-x11-drv-ati that will finally enable our iMac 27-inch machines to work with free radeon drivers, I don't understand how to select canonical values for gitversion and gitdate. If there is any documentation describing such RPM packaging standards relating to git, please point me at it. -- Nick Urbanik http://nicku.org nicku(a)nicku.org GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24

1 0

koji build server install - DatabaseError: error 'ERROR: relation "sessions_id_seq" does not exist
by steve.webb＠beatport.com 05 Nov '10

05 Nov '10

Hey there. I'm trying to build my own koji build server and following along with the instructions here: http://fedoraproject.org/wiki/Koji/ServerHowTo I got past the postgres authentication stuff and the SSL cert stuff, and now I'm trying to get basic functionality working with koji-hub and running into a bit of a sticky issue that I can't resolve on my own. The 'list-hosts' command seems to work ok: [kojiadmin@bpkojipoc001 ~]$ koji list-hosts Hostname Enb Rdy Load/Cap Arches Last Update But the "add-user" command gives me a: File "/usr/share/koji-hub/kojixmlrpc.py", line 191, in _marshaled_dispatch response = self._dispatch(method, params) File "/usr/share/koji-hub/kojixmlrpc.py", line 253, in _dispatch ret = func(*params,**opts) File "/usr/lib/python2.6/site-packages/koji/auth.py", line 649, in sslLogin return context.session.sslLogin(*args, **opts) File "/usr/lib/python2.6/site-packages/koji/auth.py", line 394, in sslLogin sinfo = self.createSession(user_id, hostip, koji.AUTHTYPE_SSL) File "/usr/lib/python2.6/site-packages/koji/auth.py", line 480, in createSession c.execute(q, {}) File "/usr/lib/python2.6/site-packages/koji/db.py", line 95, in execute ret = self.cursor.execute(operation, parameters) File "/usr/lib64/python2.6/site-packages/pgdb.py", line 174, in execute self.executemany(operation, (params,)) File "/usr/lib64/python2.6/site-packages/pgdb.py", line 195, in executemany raise DatabaseError, "error '%s' in '%s'" % ( msg, sql ) DatabaseError: error 'ERROR: relation "sessions_id_seq" does not exist LINE 1: SELECT nextval('sessions_id_seq') ^ ' in 'SELECT nextval('sessions_id_seq')' I checked out the DB schema and didn't see a 'sessions_id_seq' anywhere, and the only place that I could find it was in auth.py in the koji python utilities scripts (which is where it's failing, I believe). Can someone explain to me how this is being used and/or how to fix this issue? If this is not the correct place for this question, can someone please point me to a more koji-oriented mailing list? Thanks in advance. - Steve Webb -- Steve Webb | System Administrator Beatport | Music for DJ's ------------------------------------------ 2399 Blake Street, Suite 170 Denver, Colorado USA 80205 tel: +1.720.932.9103 fax: +1.720.932.9104 noc: +1.303.565.2710 mobile: +1.303.564.4269

2 2

Submitted my first packages and need a sponsor #649662
by Viji V Nair 04 Nov '10

04 Nov '10

Hi, As I have decided to take over the Fedora GIS spin, I am building some package for the same. I have submitted my first package for review and need a sponsor. https://bugzilla.redhat.com/show_bug.cgi?id=649662 Thanks & Regards Viji Nair

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2010