Koji push failure
by Viji V Nair
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
13 years, 5 months
Re: [Fedora-packaging] Packaging ada libraries
by Björn Persson
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
13 years, 5 months
Packaging ada libraries
by Orion Poplawski
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
13 years, 5 months
Updating our rpath guidelines?
by Michel Alexandre Salim
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
13 years, 5 months
RFC before update PHP Guidelines about PEAR package documentation
by Remi Collet
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.
13 years, 5 months
Koji Error - Policy Violation
by Viji V Nair
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
13 years, 5 months
Help with rpath issue
by Jirka Hladky
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
13 years, 5 months
Appropriate values fot gitversion, gitdate from git clone?
by Nick Urbanik
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
13 years, 5 months
koji build server install - DatabaseError: error 'ERROR: relation "sessions_id_seq" does not exist
by steve.webb＠beatport.com
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
13 years, 5 months
