Hi,
the new expanded setup increased the "felt speed" significantly.
Great work, Adrian, Michael, and Co.
OTOH, I noticed some strange behavior, too.
Please have a look at
https://build.opensuse.org/package/show/home:frispete:python/python-ZODB3
Many builds are flagged failed, although they built perfectly, e.g.:
[ 40s] RPMLINT report: [ 40s] =============== [ 42s] python-ZODB3.noarch: W: no-dependency-on python(abi) 2.7 [ 42s] 2 packages and 0 specfiles checked; 0 errors, 1 warnings. [ 42s] [ 42s] ... creating baselibs [ 42s] ... comparing built packages with the former built [ 42s] /usr/lib/build/rpm-check.sh [ 42s] compare /.build.oldpackages/python-ZODB3-3.11.0a3-2.1.src.rpm /home/abuild/rpmbuild/SRPMS/python-ZODB3-3.11.0a3-2.2.src.rpm [ 42s] compare /.build.oldpackages/python-ZODB3-3.11.0a3-2.1.noarch.rpm /home/abuild/rpmbuild/RPMS/noarch/python-ZODB3-3.11.0a3-2.2.noarch.rpm [ 42s] comparing /.build.oldpackages/rpmlint.log and /home/abuild/rpmbuild/OTHER/rpmlint.log [ 42s] compare validated built as identical ! [ 42s] ... saving built statistics [ 42s] ... saving built packages [ 42s] /home/abuild/rpmbuild/RPMS/noarch/python- ZODB3-3.11.0a3-2.2.noarch.rpm [ 43s] /home/abuild/rpmbuild/SRPMS/python-ZODB3-3.11.0a3-2.2.src.rpm [ 43s] /home/abuild/rpmbuild/OTHER/_statistics [ 43s] /home/abuild/rpmbuild/OTHER/rpmlint.log [ 43s] [ 43s] cloud119 finished "build python-ZODB3.spec" at Tue Sep 10 08:30:51 UTC 2013. [ 43s] [ 48s] [ 27.640676] SysRq : Power Off [ 48s] [ 27.796563] Power down. [ 48s] build: extracting built packages... [ 48s] python-ZODB3-3.11.0a3-2.2.noarch.rpm [ 48s] python-ZODB3-3.11.0a3-2.2.src.rpm [ 48s] _statistics [ 48s] rpmlint.log
Of course, I tried a rebuild -f already.
Any idea anybody?
TIA, Pete
Am Dienstag, 10. September 2013, 10:45:10 schrieb Hans-Peter Jansen:
Hi,
the new expanded setup increased the "felt speed" significantly.
Great work, Adrian, Michael, and Co.
OTOH, I noticed some strange behavior, too.
Please have a look at
https://build.opensuse.org/package/show/home:frispete:python/python-ZODB3
...
Of course, I tried a rebuild -f already.
Any idea anybody?
sorry, my bad. As coolo found out a commit from me broke the "build unchanged" handling.
However, it is "just" cosmetic (nothing else would happend, except the wrong state is displayed). And it is fixed now.
Sorry, we have no test case for this yet :/
Dear Adrian,
On Dienstag, 10. September 2013 11:03:49 Adrian Schröter wrote:
Am Dienstag, 10. September 2013, 10:45:10 schrieb Hans-Peter Jansen:
Hi,
the new expanded setup increased the "felt speed" significantly.
Great work, Adrian, Michael, and Co.
OTOH, I noticed some strange behavior, too.
Please have a look at
https://build.opensuse.org/package/show/home:frispete:python/python-ZODB3
...
Of course, I tried a rebuild -f already.
Any idea anybody?
sorry, my bad. As coolo found out a commit from me broke the "build unchanged" handling.
However, it is "just" cosmetic (nothing else would happend, except the wrong state is displayed). And it is fixed now.
Good to know.
Sorry, we have no test case for this yet :/
No need to feel sorry, thing break, thing get fixed. This is called progress ;-) A test case is always a good idea, though.
While at it, you might want to look into:
https://build.opensuse.org/package/live_build_log/home:frispete:python/pytho...
This is a strange biest: the test code just creates a file and tests for it later on. This is the only failing instance after a full package rebuild, which looks much better than before. Two or three weeks ago, OBS managed to fail 2/3 builds of this project. I didn't observe this anywhere else. It might be related to the type of host, where the build happens, now that we have two of them.
Sorry for not reporting this earlier, but customer/project needs always take precedence.
Cheers, Pete
Dear Adrian, Michael and co,
this issue is still nagging.
Overall problem: a certain test of a certain package fails spuriously for random builds.
The test does nothing else than deleting a file, that was created before. It fails, since for some reason, the file doesn't exist.
I tried to trigger this issue locally, but even by building this project a hundred times doesn't trigger the failure.
I tend to believe, that some filesystem synchronization issue of certain build hosts is the reason for this..
Since it is fairly good reproducible with this package, one kind soul might look into it. I've checked the test, and I don't believe, the test is responsible for that behavior - wouldn't it trigger locally than, too?
If this *is* some strange build host glitch, than this might be a good opportunity to examine it. It may happen in other scenarios without noticing..
Cheers, Pete
On Donnerstag, 12. September 2013 03:04:16 Hans-Peter Jansen wrote:
While at it, you might want to look into:
https://build.opensuse.org/package/live_build_log/home:frispete:python/pytho n-zdaemon/openSUSE_12.1/i586
This is a strange biest: the test code just creates a file and tests for it later on. This is the only failing instance after a full package rebuild, which looks much better than before. Two or three weeks ago, OBS managed to fail 2/3 builds of this project. I didn't observe this anywhere else. It might be related to the type of host, where the build happens, now that we have two of them.
Sorry for not reporting this earlier, but customer/project needs always take precedence.
Am 25.09.2013 00:16, schrieb Hans-Peter Jansen:
Dear Adrian, Michael and co,
this issue is still nagging.
Overall problem: a certain test of a certain package fails spuriously for random builds.
The test does nothing else than deleting a file, that was created before. It fails, since for some reason, the file doesn't exist.
I tried to trigger this issue locally, but even by building this project a hundred times doesn't trigger the failure.
I tend to believe, that some filesystem synchronization issue of certain build hosts is the reason for this..
Since it is fairly good reproducible with this package, one kind soul might look into it. I've checked the test, and I don't believe, the test is responsible for that behavior - wouldn't it trigger locally than, too?
If this *is* some strange build host glitch, than this might be a good opportunity to examine it. It may happen in other scenarios without noticing..
Change your spec file to run the test through strace.
Greetings, Stephan
Am Mittwoch, 25. September 2013, 07:29:48 schrieb Stephan Kulow:
Am 25.09.2013 00:16, schrieb Hans-Peter Jansen:
Dear Adrian, Michael and co,
this issue is still nagging.
Overall problem: a certain test of a certain package fails spuriously for random builds.
The test does nothing else than deleting a file, that was created before. It fails, since for some reason, the file doesn't exist.
I tried to trigger this issue locally, but even by building this project a hundred times doesn't trigger the failure.
I tend to believe, that some filesystem synchronization issue of certain build hosts is the reason for this..
Since it is fairly good reproducible with this package, one kind soul might look into it. I've checked the test, and I don't believe, the test is responsible for that behavior - wouldn't it trigger locally than, too?
If this *is* some strange build host glitch, than this might be a good opportunity to examine it. It may happen in other scenarios without noticing..
Change your spec file to run the test through strace.
and you may want to build it also locally inside kvm or xen.
If you think it is caused by build hosts, please try to find some pattern. osc jobhistory can help here a lot.
However, currently we have relativ old and as stable known images running. So it would be some new, not yet known issue.
So, I would suspect something in the build environment atm.
Hans-Peter Jansen hpj@urpla.net writes:
Overall problem: a certain test of a certain package fails spuriously for random builds.
The test does nothing else than deleting a file, that was created before. It fails, since for some reason, the file doesn't exist.
Are you sure the test is race-free? AFAIU, the file is created by some subprocess, which may take some time to start and create the file. Note that the file is confirmed to not exist before it is tried to be removed.
I can see a lot of other races in the testsuite.
Andreas.
buildservice@lists.opensuse.org
-
Adrian Schröter -
Andreas Schwab -
Hans-Peter Jansen -
Stephan Kulow