FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Build System

 
 
LinkBack Thread Tools
 
Old 01-06-2009, 07:51 PM
Oliver Falk
 
Default Koji feature proposals

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 :-)

*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. :-(



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?


And regarding your point: '... different arches build noarch subpackage
with different contents'. Well, then it's definitly not *noarch*, is't
it? :-)


-of

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-06-2009, 08:04 PM
Mike Bonnet
 
Default Koji feature proposals

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. The content on the rpminfo page in the web UI
should not change at all from the user perspective.

> *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?

> > 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.

> 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).


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-06-2009, 08:21 PM
Jason L Tibbitts III
 
Default Koji feature proposals

>>>>> "OF" == Oliver Falk <oliver@linux-kernel.at> writes:

OF> And regarding your point: '... different arches build noarch
OF> subpackage with different contents'. Well, then it's definitly not
OF> *noarch*, is't it? :-)

It is quite possible for the contents to differ by, say, date, or by
timestamps being included in plain text output. Why would that render
the output arch-specific?

- J<

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-06-2009, 08:40 PM
Mike Bonnet
 
Default Koji feature proposals

On Tue, 2009-01-06 at 15:21 -0600, Jason L Tibbitts III wrote:
> >>>>> "OF" == Oliver Falk <oliver@linux-kernel.at> writes:
>
> OF> And regarding your point: '... different arches build noarch
> OF> subpackage with different contents'. Well, then it's definitly not
> OF> *noarch*, is't it? :-)
>
> It is quite possible for the contents to differ by, say, date, or by
> timestamps being included in plain text output. Why would that render
> the output arch-specific?

I'm not so much worried about that level of difference as I am of say
different file lists from noarch rpms built on different hosts, or maybe
different endianness of data files. There is some set of post-build
checks we may want to run on these noarch subpackages to ensure they are
in fact noarch, and that their content is sane. This noarch subpackage
feature is new, and there are things Koji can and probably should be
doing to make sure it's being used correctly.


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-06-2009, 09:46 PM
Jason L Tibbitts III
 
Default Koji feature proposals

>>>>> "MB" == Mike Bonnet <mikeb@redhat.com> writes:

MB> There is some set of post-build checks we may want to run on these
MB> noarch subpackages to ensure they are in fact noarch, and that
MB> their content is sane.

I think it would be sufficient to collect all of the noarch packages
generated from the various arch builds, run rpmdiff -t on them, and
fail the build if there is any output.

That's a pretty strict test, but honestly I'd be concerned of any
package that didn't pass it.

- J<

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-07-2009, 07:08 AM
Oliver Falk
 
Default Koji feature proposals

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
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-07-2009, 07:16 AM
Oliver Falk
 
Default Koji feature proposals

Jason L Tibbitts III wrote:

"OF" == Oliver Falk <oliver@linux-kernel.at> writes:


OF> And regarding your point: '... different arches build noarch
OF> subpackage with different contents'. Well, then it's definitly not
OF> *noarch*, is't it? :-)

It is quite possible for the contents to differ by, say, date, or by
timestamps being included in plain text output. Why would that render
the output arch-specific?


We where talking about *real* content... :-)

What I could imaging to happen is something like this (just an example,
but it should make my point clear):


i386:
somescript.sh
#!/usr/libexec/blabla/i386-bla-bla/bla/binary
...

x86_64:
somescript.sh
#!/usr/libexec/blabla/x86_64-bla-bla/bla/binary
...

alpha:
somescript.sh
#!/usr/libexec/blabla/alpha-bla-bla/bla/binary
...

It's hard to check something like this, isn't it? Well, as long as it's
only the interpreter line at the beginning it might be simple, but ....


But don't worry, since we do have a few arches already, such bugs should
be found quite fast and maybe we can add additional checks later :-)


-of

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-07-2009, 01:34 PM
Jesse Keating
 
Default Koji feature proposals

On Wed, 2009-01-07 at 09:08 +0100, Oliver Falk wrote:
> 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...

rpm itself only ever builds for one target at a time, so a script to
check to see if what was produced from one target build is different
from another target build doesn't necessarily make sense in rpm sources,
at least not something ran automated.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-07-2009, 03:23 PM
Oliver Falk
 
Default Koji feature proposals

Jesse Keating wrote:

On Wed, 2009-01-07 at 09:08 +0100, Oliver Falk wrote:

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...


rpm itself only ever builds for one target at a time, so a script to
check to see if what was produced from one target build is different
from another target build doesn't necessarily make sense in rpm sources,
at least not something ran automated.


OKOK. I thought rpmbuild will automagically produce arch-specific and
noarch packages in 'one step'...


-of

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 01-07-2009, 03:31 PM
Jesse Keating
 
Default Koji feature proposals

On Wed, 2009-01-07 at 17:23 +0100, Oliver Falk wrote:
>
> OKOK. I thought rpmbuild will automagically produce arch-specific and
> noarch packages in 'one step'...

It will, for one arch. You do a rpmbuild --rebuild foo (on x86_64) and
it'll spit out x86_64 binary packages and potentially a noarch package.
What we care about is doing the same command on i386 and generating i386
packages and a noarch package, having the i386 produced noarch package
match the x86_64 produced noarch package. To the best of my knowledge
there is no way to convince rpmbuild to produce both i386 /and/ x86_64
packages in the same run.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 

Thread Tools




All times are GMT. The time now is 07:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org