[opensuse-buildservice] Did have method to disable obs check requires in cycle?
hi, all I'm researching the build ablity of obs, and I'm find that any events of every package in the project should change the schedule of task. My step is: 1. create a new project, no repository added 2. use a script commit more than 1000 srpm packages auto in batch. 3. all packages commit done, I added a standard repository 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 pkgs 3. redo 1 and 2 Questions: did obs have a solution to made a only one schedule list ? 1. do requires check based on current pkgs, and create a schedule list 2. do building. 3. user can select do or not do check and rebuilding after the schedule list executed done. Thanks, ---- 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
Am Montag, 21. Dezember 2009 04:34:26 schrieb Jian Lee:
hi, all
I'm researching the build ablity of obs, and I'm find that any events of every package in the project should change the schedule of task.
My step is:
1. create a new project, no repository added
2. use a script commit more than 1000 srpm packages auto in batch.
3. all packages commit done, I added a standard repository
Result: the obs-server working in a cycle
Who is working in a cycle ? The scheduler ? How do you see this ? 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
On Mon, Dec 21, 2009 at 11:34:26AM +0800, Jian Lee wrote:
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 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);} -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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
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
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
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 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
-- 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
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.
thanks, all
Monday 21 December 200921:22:00Petit 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 ] -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi, Adrian
Thank you very much !
But I have two questions:
1. Does the "Ignore" used as following in
/srv/obs/projects/<MyProject>.conf ?
----------------------------------------------
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" ?
2. How to "high chances to break your distro"? Is that means I should
to stop building all pkgs in my distro?
"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
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 ---- 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
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
Am Dienstag, 22. Dezember 2009 09:41:48 schrieb Petit Eric:
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 ?
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
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
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
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 -- 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
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
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 -- 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
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
participants (4)
-
Adrian Schröter
-
Jian Lee
-
Michael Schroeder
-
Petit Eric