you cannot "manage" this with the build and publish flags ? Perhaps at the end it will cost less time ? http://picpaste.com/pics/Capture-5.1261401374.png 2009/12/21 Jian Lee :

Hi, Michael

Thanks for your reply,

but I have more than 1000 pkgs to build currently, and the features of obs about circular build dependencies doesn't help me at this task, too many time waste on compute dependencies.

I've use 1 week to build the 1000 pkgs , and I use 5 machines, total more than 64+64+24+8+4 core. the last, just about 100 pkgs have builded successed, because the successed pkgs must be rebuild for some events.

I want to disable this  circular build dependencies at this tasks, or configure the scheduler demo to compute dependencies more directly.

did any one have a idea?

Thanks,all

Monday 21 December 200918:10:38Michael Schroeder 写道：

...

Result:  the obs-server working in a cycle

1. do some requires  check, select some packages to build and many packages to waiting

2. the successed packages made a event to rebuild some successed

On Mon, Dec 21, 2009 at 11:34:26AM +0800, Jian Lee wrote: pkgs

In that case you've got circular build dependencies. That's not that bad as it sounds, the build service knows how to deal with that case. Some packages will get built multiple times, though, to make sure that all packages are build with packages created from the latest source.

Cheers,  Michael.

-- Michael Schroeder                                   mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}

----

Jian Lee   [ http://jianlee.ylinux.org ] -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-- Cordially. Small Eric Quotations of the days: --------------------------------------------------------------------------- I have no special talents. I am only passionately curious -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag, 21. Dezember 2009 14:22:00 schrieb Petit Eric:

2009/12/21 Petit Eric :

...

you cannot "manage" this with the build and publish flags ? Perhaps at the end it will cost less time ? http://picpaste.com/pics/Capture-5.1261401374.png

Because my suggestion could be confuse here it is more details, idea should be to disable all build and/or publish, use an worksheet to list all order dependency, build the package at the highest level, publish it, once published, disable it again, build the second package, etc, then when all dependency packages are build, published and disable, enable all other packages.

this is a even more horrible workaround. Best solution is to reduce the cycles as much as possible. Working around the cycle handling only means that you have high chances to get broken packages. And if you don't know why the cyclces are there (or that many and large) you have also high chances to break your distro. If you know why they are there, you should be able also to break them for example via "Ignore:" statements in your project configuration in a valid way. as usual, this has absolut nothing to do with monoosc so it can't be used to solve the problem. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Dienstag, 22. Dezember 2009 02:38:33 schrieb Jian Lee:

Hi, Adrian

Thank you very much !

But I have two questions:

1. Does the "Ignore" used as following in /srv/obs/projects/<MyProject>.conf ?

yes

---------------------------------------------- Ignore: initscripts:kernel,udev,ethtool,mingetty Ignore: tetex:tetex-fonts,desktop-file-utils Ignore: pam:glib2 Ignore: libraw1394:kernel

Ignore: gettext-devel:libgcj,libstdc++-devel Ignore: pam-modules:resmgr Ignore: rpm:suse-build-key,build-key Ignore: bind-utils:bind-libs Ignore: alsa:dialog,pciutils Ignore: portmap:syslogd Ignore: fontconfig:freetype2 Ignore: fontconfig-devel:freetype2-devel Ignore: xorg-x11-libs:freetype2 =================================

for example, what's the meaning of "Ignore: fontconfig:freetype2"? and "Ignore: alsa:dialog,pciutils" ?

It means to ignore the dependency to freetype2 from fontconfig package. So, freetype2 will not get installed if it just get pulled by fontconfig.

2. How to "high chances to break your distro"? Is that means I should to stop building all pkgs in my distro?

No, that the built packages may not be compatible to each other. Esp. when you submit changes in multiple packages (but can also happen with a single changed package). bye adrian

"And if you don't know why the cyclces are there (or that many and large) you have also high chances to break your distro."

Thanks, all

Monday 21 December 200921:28:31Adrian Schröter 写道：

Am Montag, 21. Dezember 2009 14:22:00 schrieb Petit Eric:

...

2009/12/21 Petit Eric :

...

you cannot "manage" this with the build and publish flags ? Perhaps at the end it will cost less time ? http://picpaste.com/pics/Capture-5.1261401374.png

Because my suggestion could be confuse here it is more details, idea should be to disable all build and/or publish, use an worksheet to list all order dependency, build the package at the highest level, publish it, once published, disable it again, build the second package, etc, then when all dependency packages are build, published and disable, enable all other packages.

this is a even more horrible workaround.

Best solution is to reduce the cycles as much as possible. Working around the cycle handling only means that you have high chances to get broken packages.

And if you don't know why the cyclces are there (or that many and large) you have also high chances to break your distro.

If you know why they are there, you should be able also to break them for example via "Ignore:" statements in your project configuration in a valid way.

as usual, this has absolut nothing to do with monoosc so it can't be used to solve the problem.

bye adrian

-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

2009/12/22 Jian Lee :

Hi, Petit

Thanks for your reply, but how to get an worksheet ? and how to use it ? Your first reply is to disable build and publish, I'm sure that's not my hope. yes , as Adrian say, it is "horrible" and i believe him, his an better expert of OBS as me :-) About the worksheet, that was an manual one elaborate by the hand :-) Perhaps another horrible and bad idea, but playing with the "buildrequiere" and using an exact revision number ?

thanks, all

Monday 21 December 200921:22:00Petit Eric 写道：

2009/12/21 Petit Eric :

...

you cannot "manage" this with the build and publish flags ? Perhaps at the end it will cost less time ? http://picpaste.com/pics/Capture-5.1261401374.png

Because my suggestion could be confuse here it is more details, idea should be to disable all build and/or publish, use an worksheet to list all order dependency, build the package at the highest level, publish it, once published, disable it again, build the second package, etc, then when all dependency packages are build, published and disable, enable all other packages.

...

2009/12/21 Jian Lee :

...

Hi, Michael

Thanks for your reply,

but I have more than 1000 pkgs to build currently, and the features

...

...

obs about circular build dependencies doesn't help me at this task, too many time waste on compute dependencies.

I've use 1 week to build the 1000 pkgs , and I use 5 machines, total more than 64+64+24+8+4 core. the last, just about 100 pkgs have builded successed, because the successed pkgs must be rebuild for some events.

I want to disable this circular build dependencies at this tasks, or configure the scheduler demo to compute dependencies more directly.

did any one have a idea?

Thanks,all

Monday 21 December 200918:10:38Michael Schroeder 写道：

...

Result: the obs-server working in a cycle

1. do some requires check, select some packages to build and many packages to waiting

2. the successed packages made a event to rebuild some successed

On Mon, Dec 21, 2009 at 11:34:26AM +0800, Jian Lee wrote: pkgs

In that case you've got circular build dependencies. That's not that bad as it sounds, the build service knows how to deal with that case. Some packages will get built multiple times,

of though,

...

...

to make sure that all packages are build with packages created from the latest source.

Cheers, Michael.

-- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}

----

Jian Lee [ http://jianlee.ylinux.org ] -- To unsubscribe, e-mail: opensuse- buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse- buildservice+help@opensuse.org

-- Cordially.

Small Eric Quotations of the days:

---------------------------------------------------------------------------

...

I have no special talents. I am only passionately curious

-- Cordially.

Small Eric Quotations of the days: --------------------------------------------------------------------------- I have no special talents. I am only passionately curious

----

Jian Lee [ http://jianlee.ylinux.org ]

-- Cordially. Deploy your softwares for all platforms and finally update them in 3 clicks. Try now the OpenSource MonoOSC tool http://monoosc.sourceforge.net/ http://download.opensuse.org/repositories/home:/surfzoid/ http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/ http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu:/Mono... Small Eric Quotations of the days: --------------------------------------------------------------------------- I have no special talents. I am only passionately curious -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

2009/12/22 Jian Lee :

...

Hi, Petit

Thanks for your reply, but how to get an worksheet ? and how to use it ? Your first reply is to disable build and publish, I'm sure

Thanks, Adrian but how to set cycle of 3 ? I'm hacking the bs_sched script, and want it to drop pkgs which would be rebuild : 1. read a list file to a perl array which contain all pkgs of my project: ------------------------------ my $removed_from_relsync = \ "$BSConfig::bsdir/TRepos/removed_from_relsync.list"; open (F,$removed_from_relsync) || die ("Open $removed_from_relsync\ have a error : $!\n"); my @removed_from_relsync; while(<F>) {chomp;push(@removed_from_relsync,$_);}; close(F); ============ 2. at the place that check $reporoot/$prp/$myarch/:logfiles.fail to drop pkgs , added this: ------------------------------------ if (%relsynctrigger) { # filter failed packages for (ls("$reporoot/$prp/$myarch/:logfiles.fail")) { delete $relsynctrigger{$_}; } # add a hacking method # 1. "osc ls GTES:11:U6 > XXX/remove_relsync.list" # 2. drop pkg from remove_relsync.list for (@removed_from_relsync) { delete $relsynctrigger{$_}; print "Delete $_ from rebuild relsync.\n"; } } } ====================== I'm testing it, and I'm not sure it should be work correct. Thanks, Tuesday 22 December 200916:45:49Adrian Schröter 写道： Am Dienstag, 22. Dezember 2009 09:41:48 schrieb Petit Eric: that's

...

not my hope.

yes , as Adrian say, it is "horrible" and i believe him, his an better expert of OBS as me :-) About the worksheet, that was an manual one elaborate by the hand :-) Perhaps another horrible and bad idea, but playing with the "buildrequiere" and using an exact revision number ?

revision numbers won't help, but removing dependencies to either break cycles or to reduce the size of the cycle. A cycle of just three packages is way faster bootstrapped than a cycle of 10 for example. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse- buildservice+help@opensuse.org ---- Jian Lee [ http://jianlee.ylinux.org ] -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Thanks, Adrian Yes, the method to drop rebuild event before is wrong, all schedule was stopped. So, the adventure is failed :-) I've considered 'meta change' before, but have not test that idea because confused by the exact meanings of 'meta change'. Could you give me a exact description ? Now, I'm testing to drop 'meta change' event for rebuild, by add a "next;" before set $reason : ---------------------------------------------------- # Jian Lee: drop 'meta change' event for rebuild next; my @diff = diffsortedmd5(0, \@meta, \@new_meta); print " - $packid ($packtype)\n"; print " $_\n" for @diff; print " meta change, start build\n"; $reason = { 'explain' => 'meta change', 'packagechange' => sortedmd5toreason(@diff) }; ============================ I'll report that result. Thanks, Tuesday 22 December 200918:28:45Adrian Schröter 写道： Am Dienstag, 22. Dezember 2009 10:57:37 schrieb Jian Lee:

Thanks, Adrian

but how to set cycle of 3 ?

You can't set it somewhere, you can just change your package dependencies so that the cycles will reduce. Check the scheduler log file output to see your current cycles.

I'm hacking the bs_sched script, and want it to drop pkgs which would

relsync can be configured via BSConfig.pm, no need to change the scheduler for this. What you want is to avoid the trigger on "meta change" and only trigger on source change. Check for "meta change" string in the code. But be warned, you will most likely quite often build broken repostories. You will hunt problems in your packages which comes and go and you will never know when you have a clean state which can be tested. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de ---- Jian Lee [ http://jianlee.ylinux.org ] -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Thanks, Adrian I'm looking at the code of bs_sched. any hacking idea should base on the master of code. My test of "drop 'meta change'" seems to stop the building. I'am tired of the cycle building, I'll find a good way to do that. I'll back after read code done. btw, Merry Christmas everyone! thanks, Wednesday 23 December 200914:56:39Adrian Schröter 写道： Am Mittwoch, 23. Dezember 2009 04:15:38 schrieb Jian Lee:

Thanks, Adrian

Yes, the method to drop rebuild event before is wrong, all schedule was stopped. So, the adventure is failed :-)

I've considered 'meta change' before, but have not test that idea because confused by the exact meanings of 'meta change'. Could you give me a exact description ?

Now, I'm testing to drop 'meta change' event for rebuild, by add a "next;" before set $reason :

try it, but if you go on christmas vacations, just consider to let your system building without that hack. You may get a real bootstrapped system when you come back as new years present :) The scheduler is able to handle all these cycles, it is breaking them, but needs nevertheless building the packages multiple times. In case of large cycles this takes quite some time. But it shall finish at some point in time in any case. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de ---- Jian Lee [ http://jianlee.ylinux.org ] -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org