Mike Bonnet wrote:
On Tue, 2009-01-06 at 21:51 +0100, Oliver Falk wrote:
Hi Mike!
Mike Bonnet schrieb:
I've just created tickets for a few Koji features that I've been wanting
to implement for a while (as well as updated an old one), and I'm
planning to devote some time to in the near future. If you have any
comments on these features feel free to post to the tickets, or talk to
me at FUDCon this weekend. Just figured people might want to see the
direction that Koji is headed. The future is now! :)
[ ... ]
drop the rpmfiles and rpmdeps tables: https://fedorahosted.org/koji/ticket/124
-1
Only if you provide the same functionality using another approach :-)
Yes, the plan is to query the information directly from the rpms rather
than from the database.
You'll likely need to cache the list of files somewhere. Just to mention
it: Using yum metadata isn't enough, as you'll only query the latest pkgs...
> The content on the rpminfo page in the web UI
should not change at all from the user perspective.
Good.
*I* do use it quite often; Find out which file belongs to which pkg(s).
However, this was quite slow and now doesn't even seem to work in
koji.fpo. :-(
Hmmm, it should be. In what way is it not working?
Query for Files (eg. /bin/ls):
Mod_python error: "PythonHandler mod_python.publisher"
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
299, in HandlerDispatch
result = object(req)
File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line
213, in handler
published = publish_object(req, object)
File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line
412, in publish_object
return publish_object(req,util.apply_fs_data(object, req.form,
req=req))
File "/usr/lib/python2.4/site-packages/mod_python/util.py", line 439,
in apply_fs_data
return object(**args)
File "/usr/share/koji-web/scripts/index.py", line 1680, in search
start=start, dataName='results', prefix='result', order=order)
File "/usr/share/koji-web/lib/kojiweb/util.py", line 123, in
paginateMethod
totalRows = getattr(server, methodName)(*args, **kw)
File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1133,
in __call__
return self.__func(self.__name,args,opts)
File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1378,
in _callMethod
raise err
Fault:
noarch subpackage support: https://fedorahosted.org/koji/ticket/125
Duh? We do have already (at least one) packages that build arch-specific
and noarch pkgs -> kernel or do we use some *hack* in the kernel.spec?
We use a hack in the kernel specfile and in the build system. The
noarch subpackage support in rpm is much more generic and flexible, and
we need to support it without build system hacks.
OK. I wasn't quite sure how it's working now... However, now that I know
I do understand.
And regarding your point: '... different arches build noarch subpackage
with different contents'. Well, then it's definitly not *noarch*, is't
it? :-)
True, but it's still possible, and we may need to check for this case
and handle is appropriately (possibly by failing the build).
Yet another post install section processing script (YAPISPS) :-)
And yes, if it's not really noarch, it should fail. But shouldn't rpm
itself check that? I mean, if someone writes a script to check that it
should possibly go directly into rpm upstream sources...
-of
--
Fedora-buildsys-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
