2:21 p.m.
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
2:51 p.m.
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
3:04 p.m.
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).
2:08 a.m.
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
8:34 a.m.
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
10:23 a.m.
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
10:31 a.m.
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
1:42 a.m.
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
6:13 a.m.
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
=--=
6:22 a.m.
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
3:21 p.m.
>>>> "OF" == Oliver Falk
<oliver(a)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<
3:40 p.m.
On Tue, 2009-01-06 at 15:21 -0600, Jason L Tibbitts III wrote:
>>>>> "OF" == Oliver Falk
<oliver(a)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.
4:46 p.m.
>>>> "MB" == Mike Bonnet
<mikeb(a)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<
2:16 a.m.
Jason L Tibbitts III wrote:
>>>>> "OF" == Oliver Falk
<oliver(a)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
5585
days inactive
5587
days old
buildsys@lists.fedoraproject.org
13 comments
5 participants
participants (5)
-
Bryce -
Jason L Tibbitts III -
Jesse Keating -
Mike Bonnet -
Oliver Falk