Marcus Rueckert wrote:

On 2007-02-13 13:24:02 +0100, Martin Mohring wrote:

...

a while ago, Michael told me that openSUSE:Factory is a "realtime mirror" of the openSUSE Factory Distribution. I am looking for the Project tomcat55, now part of the Factory but not yet "visible" in openSUSE:Factory.

Also, it seems not to be build in tomcat5.

only packages checked in since december are in openSUSE:Factory. so it seems there was no change to tomcat55 since december. :)

darix

But it seems not to be mentioned in the the "opensuse-commit" mailinglist. And I can remember it appearing in the openSUSE Factory mirrors end of Jan/begin Feb.

From the specfile of tomcat55:

%changelog -n tomcat55 * Fri Jan 12 2007 - dbornkessel@suse.de - first version for autobuild But I dont know if this fulfils the conditions of beeing in "openSUSE:Factory". Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hi, it was reported that you will later provide us with tagging and changelog support. How will this work with links? Will there be smart links able to link to a Project with a specific tag? I am asking because lateron openSUSE:Factory will become openSUSE:10.3, and I have addon packages that I would like to tag lateron without modifying the links inside. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hi, when currently building my Package"CrossToolchain:sh4/cross-sh4-binutils", I get expansion errors for SUSE_Linux_10.0 + SUSE_Linux_10.1 only: buildinfo is broken... it says: expansion error: nothing provides linux-kernel-headers needed by glibc-devel Getting buildinfo from server /tmp/buildinfo.dDpgTj.xml My Package was not changed today. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Michael Schroeder wrote:

On Tue, Feb 13, 2007 at 07:42:52PM +0100, Martin Mohring wrote:

...

Hi,

when currently building my Package"CrossToolchain:sh4/cross-sh4-binutils", I get expansion errors for SUSE_Linux_10.0 + SUSE_Linux_10.1 only:

buildinfo is broken... it says: expansion error: nothing provides linux-kernel-headers needed by glibc-devel

That's because your "cross-sh4-glibc-bootstrap" glibc package contains this requirement. Why do you need this "bootstrap" package?

Cheers, Michael.

I have to bootstrap a cross toolchain in 3 iterations (without target binaries): 1. provide cross-binutils 2. provide cross-kernel-headers 3. provide cross-glibc-headers 4. build empty cross-gcc 5. build initial glibc without programs 6. build real cross-gcc 7. build real cross-glibc So my naming for the packages is: 1. cross-sh4-binutils 2. cross-sh4-kernel-headers 3. cross-sh4-glibc-headers 4. cross-sh4-bootstrap-gcc 5. cross-sh4-glibc-bootstrap 6. cross-sh4-gcc 7. cross-sh4-glibc Packages 6+7 are not yet finished, Richard Günther started with them using an old version of the packages (Project: "Base"). Now we have decided to switch to the openSUSE:Factory codebase. BTW: I generate the cross-sh4-*.spec file from the templates by pre_checkin.sh scripts, as was the procedure logs since in original binutils Package. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Michael Schroeder wrote:

On Tue, Feb 13, 2007 at 08:21:44PM +0100, Martin Mohring wrote:

...

I have to bootstrap a cross toolchain in 3 iterations (without target binaries):

1. provide cross-binutils 2. provide cross-kernel-headers 3. provide cross-glibc-headers

4. build empty cross-gcc 5. build initial glibc without programs

6. build real cross-gcc 7. build real cross-glibc

So my naming for the packages is:

1. cross-sh4-binutils 2. cross-sh4-kernel-headers 3. cross-sh4-glibc-headers 4. cross-sh4-bootstrap-gcc 5. cross-sh4-glibc-bootstrap 6. cross-sh4-gcc 7. cross-sh4-glibc

But your "cross-sh4-glibc-bootstrap" produced rpms named "glibc-..." instead of rpms prefixed with "cross-...". That's why you're in trouble right now. If that's really intended you might just need to switch the Requires in cross-sh4-glibc-bootstrap from kernel-headers to cross-sh4-kernel-headers.

I dont see what you mean. Which line in cross-sh4-glibc-bootstrap.spec contains kernel-headers? Why did it produce glibc* without prefix? Could it be that this was caused by an initial checkin of a link to "openSUSE:Factory/glibc" before I checked in the other files? I am a little bit confused. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

May I make a suggestion: Could you please add some functions, so that poor people like me can do the same? Sometimes it would help very much if you could add a function like: - clobber (clean all build packages) - reevaluate the spec files - a package in a project is in deactivated state when it is added. It must first be activated. so that you can overcome such a situation. I was just using the function "add link" in the webinterface. Lateron I worked with osc command client. I work in a way so I first test everything with a local "osc build" before I check in everything. Michael Schroeder wrote:

On Tue, Feb 13, 2007 at 09:00:48PM +0100, Martin Mohring wrote:

...

I dont see what you mean. Which line in cross-sh4-glibc-bootstrap.spec contains kernel-headers?

Why did it produce glibc* without prefix? Could it be that this was caused by an initial checkin of a link to "openSUSE:Factory/glibc" before I checked in the other files?

I am a little bit confused.

Ok, cross-sh4-glibc-bootstrap got built with srcmd5 34cb71b9b87005b8fdea565d4d3be843 (as stated in the logfile), that's local srcmd5 "d548487d1004c16c57c699164f4ccba4" which contained just the link, but no other spec file. The link was created at 16:42, packages finished building at 17:48.

As it was a plain link the build used glibc.spec (as also stated in the logfile), thus the bad requires and package names.

At 19:15 you added a different specfile, but then the damage was already done, no more building was possible...

I've wiped all the rpms from the cross-sh4-glibc-bootstrap packages, so the build should now pick up the right specfile.

Cheers, Michael.

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wed, Feb 14, 2007 at 12:59:44PM +0100, Marcus Rueckert wrote:

On 2007-02-14 10:10:46 +0100, Martin Mohring wrote:

...

- clobber (clean all build packages)

basically purging all rpms? why?

Just read Michael's last mail in this thread to have a use case. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

On Wed, Feb 14, 2007 at 02:10:04PM +0100, Martin Mohring wrote:

@Michael: Why did the server come into the state where the normal "trigger rebuild" does not help?

Also I am not Michael and I don't know what was the exact reason for _this_ case I can explain you a case that can lead to situations like this: All build rely on a certain set of base backages like the glibc for instance. Without a working glibc version you cannot build any package. If you have an empty project you don't have a glibc in your project but you are still happy because you get this from your "parent" project. Now if you build a glibc package yourself this will be used for future builds. If the glibc you built is broken (but does still build) then you are out of luck because you no longer get the glibc from your parrent project but your own broken version. That way you cannot build _any_ package any more. You even can't rebuild the package that created the broken glibc to fix the issue. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

On Wed, Feb 14, 2007 at 02:34:57PM +0100, Martin Mohring wrote:

@Michael: Is is OK for you to add such a "clobber & rebuild" function in addition to "trigger rebuild" or would you change "trigger rebuild" to do more things?

IMHO an extra 'clobber & rebuild' is the way to go. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wed, 14 Feb 2007, Marcus Rueckert wrote:

On 2007-02-14 10:10:46 +0100, Martin Mohring wrote:

...

- clobber (clean all build packages)

basically purging all rpms? why?

Additionally to Martin's answer: When a package build succeeded, I detect that there is nevertheless some deeper error in the resulting RPM and disable the Package/Target/whatever. Now I need to get rid of the old RPM's. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 2007-02-14 16:34:46 +0100, Christian Boltz wrote:

Date: Wed, 14 Feb 2007 16:34:46 +0100 From: Christian Boltz Subject: Re: [opensuse-buildservice] add function: clobber Project (was: expansion errors for SUSE_Linux_10.0 + SUSE_Linux_10.1) To: opensuse-buildservice@opensuse.org

Hello,

on Mittwoch, 14. Februar 2007, Marcus Rueckert wrote:

...

On 2007-02-14 10:10:46 +0100, Martin Mohring wrote: {...]

...

- a package in a project is in deactivated state when it is added. It must first be activated.

you can do that in osc createpac already. there is an uncommented example disable block. when you create the package in the webfrontend you can click the disable link there.

... and hope you are fast enough. Or only create packages when the build queue is long enough ;-)

Another idea: When adding new build targets, it should be possible to disable this target in all projects by default. This could be done by a checkbox on the "new target" page.

Reasons, usecases and examples:

Say I have updated a package for an older distribution and add the latest openSUSE (which has a newer version already), I don't want to build this package because it would in fact be a downgrade. Example: courier-authlib in home:cboltz, which is only needed for <= 10.1 - 10.2 contains the changes I need out of the box

Another case is doing some experimental stuff like testing Fontlinge on lots of distributions. This doesn't mean that I want to build all my other packages for all these distributions. Example: Fontlinge and Fontlinge-QA in home:cboltz

Yes, you can already disable the new target per package - and hope you are fast enough (see above) ;-) - but this is not a real solution. Imagine you have to disable a new target in a project with >50 packages...

A related feature request: The project overview page has a target list including a [Remove] link for every target. It should also have a [Disable] / [Enable] link to globally disable or enable a build target.

disable/enable handling at project level is active work in progress. stay tuned darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org