Re: Koji feature proposals

2009-01-08 Thread Jesse Keating
On Thu, 2009-01-08 at 08:42 +0100, Oliver Falk wrote:
> Alright. I got it now - I think :-)
> 
> So a build in koji will produce a noarch package for every arch. And 
> then you need to decide which noarch package to take and how to find out 
> if there are (arch specific) differences in those "noarch's", right?

Yep!  You got it now.

-- 
Jesse Keating
Fedora -- FreedomĀ² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Re: Koji feature proposals

2009-01-08 Thread Bryce
Oliver Falk wrote:
> Jesse Keating wrote:
>> 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.
>
> Alright. I got it now - I think :-)
>
> So a build in koji will produce a noarch package for every arch. And
> then you need to decide which noarch package to take and how to find
> out if there are (arch specific) differences in those "noarch's", right?
>
> -of
>

huh? the entire reason a package is noarch is that it doesn't have any
difference on what  architecture it was built or installed. Usually
shell scripts or data sets make up the bulk of noarch rpms. If a noarch
package differs when built on different architectures then you can't
call it a noarch rpm!

Now that said, I have generated noarch packages that are actually x86_64
binaries so that they will install in an x86 environment without a need
to pass --ignorearch to rpm, but, they forced me do it *sob* I didn't
want to do it that way *cry* it was awful, my soul is  dead *breakdown bawl*

Phil
=--=





--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


Re: Koji feature proposals

2009-01-07 Thread Oliver Falk

Jesse Keating wrote:

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.


Alright. I got it now - I think :-)

So a build in koji will produce a noarch package for every arch. And 
then you need to decide which noarch package to take and how to find out 
if there are (arch specific) differences in those "noarch's", right?


-of

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


Re: Koji feature proposals

2009-01-07 Thread Jesse Keating
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


signature.asc
Description: This is a digitally signed message part
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Re: Koji feature proposals

2009-01-07 Thread Oliver Falk

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


Re: Koji feature proposals

2009-01-07 Thread Jesse Keating
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


signature.asc
Description: This is a digitally signed message part
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Re: Koji feature proposals

2009-01-07 Thread Oliver Falk

Jason L Tibbitts III wrote:

"OF" == Oliver Falk  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


Re: Koji feature proposals

2009-01-07 Thread Oliver Falk

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


Re: Koji feature proposals

2009-01-06 Thread Jason L Tibbitts III
> "MB" == Mike Bonnet  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


Re: Koji feature proposals

2009-01-06 Thread Mike Bonnet
On Tue, 2009-01-06 at 15:21 -0600, Jason L Tibbitts III wrote:
> > "OF" == Oliver Falk  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


Re: Koji feature proposals

2009-01-06 Thread Jason L Tibbitts III
> "OF" == Oliver Falk  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


Re: Koji feature proposals

2009-01-06 Thread Mike Bonnet
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


Re: Koji feature proposals

2009-01-06 Thread Oliver Falk

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


Koji feature proposals

2009-01-06 Thread Mike Bonnet
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! :)

Thanks,
Mike

build the srpm in a chroot: https://fedorahosted.org/koji/ticket/103
support for building isos and disk images in Koji: 
https://fedorahosted.org/koji/ticket/122
koji callback system: https://fedorahosted.org/koji/ticket/123
drop the rpmfiles and rpmdeps tables: https://fedorahosted.org/koji/ticket/124
noarch subpackage support: https://fedorahosted.org/koji/ticket/125


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list