[opensuse-packaging] upgrading nasm to 2.09.07
Okay, I need help - I've made my way through Andreas' page: http://lizards.opensuse.org/2009/06/20/opensuse-factory-fixing-packages/ and I've built things locally, worked fine. Then I did "osc commit" etcetera, and I notice that it didn't work quite so well: osc results openSUSE_11.2 x86_64 failed openSUSE_11.2 i586 failed openSUSE_11.3 i586 failed openSUSE_11.3 x86_64 failed openSUSE_11.4 i586 failed openSUSE_11.4 x86_64 failed openSUSE_Factory i586 failed openSUSE_Factory x86_64 failed SLE_10 i586 failed SLE_10 x86_64 failed SLE_11_SP1 i586 failed SLE_11_SP1 x86_64 failed I checked the build log and found this: error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here? -- Per Jessen, Zürich (10.4°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, Mar 16, 2011 at 08:26:25AM +0100, Per Jessen wrote:
Okay, I need help - I've made my way through Andreas' page:
http://lizards.opensuse.org/2009/06/20/opensuse-factory-fixing-packages/
and I've built things locally, worked fine. Then I did "osc commit" etcetera, and I notice that it didn't work quite so well:
osc results openSUSE_11.2 x86_64 failed openSUSE_11.2 i586 failed openSUSE_11.3 i586 failed openSUSE_11.3 x86_64 failed openSUSE_11.4 i586 failed openSUSE_11.4 x86_64 failed openSUSE_Factory i586 failed openSUSE_Factory x86_64 failed SLE_10 i586 failed SLE_10 x86_64 failed SLE_11_SP1 i586 failed SLE_11_SP1 x86_64 failed
I checked the build log and found this:
error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory
nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here?
adding it to the sources checkin... osc add nasm-2.09.07.tar.bz2 osc ci Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Marcus Meissner wrote:
error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory
nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here?
adding it to the sources checkin...
osc add nasm-2.09.07.tar.bz2 osc ci
Ciao, Marcus
Duh! thanks. -- Per Jessen, Zürich (9.7°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday, March 16, 2011 09:07:36 Per Jessen wrote:
Marcus Meissner wrote:
error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory
nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here?
adding it to the sources checkin...
osc add nasm-2.09.07.tar.bz2 osc ci
Ciao, Marcus
Duh! thanks.
In general: run osc status and install osc-source_validator package, it will do some checks during checkin that would have shown you the problem, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Per Jessen wrote:
Marcus Meissner wrote:
error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory
nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here?
adding it to the sources checkin...
osc add nasm-2.09.07.tar.bz2 osc ci
Ciao, Marcus
Duh! thanks.
Okay, next stumbling block: my new nasm package built everywhere except SLE_10 : gcc -c -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -W -Wall -std=c99 -pedantic -DHAVE_CONFIG_H -I. -I. -o ver.o ver.c ver.c:39: error: '__TIMESTAMP__' undeclared here (not in a function) make: *** [ver.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.45632 (%build) What I don't understand is - ver.c wasn't changed, so how does/did the currently released nasm build on SLE_10? -- Per Jessen, Zürich (10.8°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/3/16 Per Jessen <per@opensuse.org>:
Per Jessen wrote:
Marcus Meissner wrote:
error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory
nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here?
adding it to the sources checkin...
osc add nasm-2.09.07.tar.bz2 osc ci
Ciao, Marcus
Duh! thanks.
Okay, next stumbling block:
my new nasm package built everywhere except SLE_10 :
gcc -c -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -W -Wall -std=c99 -pedantic -DHAVE_CONFIG_H -I. -I. -o ver.o ver.c ver.c:39: error: '__TIMESTAMP__' undeclared here (not in a function) make: *** [ver.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.45632 (%build)
What I don't understand is - ver.c wasn't changed, so how does/did the currently released nasm build on SLE_10?
Anyway you should patch/sed out that __TIMESTAMP__ to allow build-compare to do its work. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Cristian Morales Vega wrote:
2011/3/16 Per Jessen <per@opensuse.org>:
Per Jessen wrote:
Marcus Meissner wrote:
error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory
nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here?
adding it to the sources checkin...
osc add nasm-2.09.07.tar.bz2 osc ci
Ciao, Marcus
Duh! thanks.
Okay, next stumbling block:
my new nasm package built everywhere except SLE_10 :
gcc -c -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -W -Wall -std=c99 -pedantic -DHAVE_CONFIG_H -I. -I. -o ver.o ver.c ver.c:39: error: '__TIMESTAMP__' undeclared here (not in a function) make: *** [ver.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.45632 (%build)
What I don't understand is - ver.c wasn't changed, so how does/did the currently released nasm build on SLE_10?
Anyway you should patch/sed out that __TIMESTAMP__ to allow build-compare to do its work.
It's actually a __DATE__ and I can certainly get rid of it, but I'd like to understand _why_ before I do it. (Remember, I'm VERY new to this). -- Per Jessen, Zürich (10.8°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/3/16 Per Jessen <per@opensuse.org>:
Cristian Morales Vega wrote:
2011/3/16 Per Jessen <per@opensuse.org>:
Per Jessen wrote:
Marcus Meissner wrote:
error: File /usr/src/packages/SOURCES/nasm-2.09.07.tar.bz2: No such file or directory
nasm-2.09.07.tar.bz2 is the new tarball. What am I missing here?
adding it to the sources checkin...
osc add nasm-2.09.07.tar.bz2 osc ci
Ciao, Marcus
Duh! thanks.
Okay, next stumbling block:
my new nasm package built everywhere except SLE_10 :
gcc -c -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -W -Wall -std=c99 -pedantic -DHAVE_CONFIG_H -I. -I. -o ver.o ver.c ver.c:39: error: '__TIMESTAMP__' undeclared here (not in a function) make: *** [ver.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.45632 (%build)
What I don't understand is - ver.c wasn't changed, so how does/did the currently released nasm build on SLE_10?
Anyway you should patch/sed out that __TIMESTAMP__ to allow build-compare to do its work.
It's actually a __DATE__ and I can certainly get rid of it, but I'd like to understand _why_ before I do it. (Remember, I'm VERY new to this).
You want two builds from the same source to generate the same binary. This allows the user to verify the binary hasn't been corrupted/compromised. Also, the openSUE Build service rebuilds the package everytime a dependency changes, but after the build there is a script that checks if there is any important difference between the new build and the old one. If the two build are equal the new package is discarded, so the user doesn't needs to redownload a new package that is exactly equal to the one he already has. But __TIMESTAMP__, __DATE__ and __TIME__ macros make every build different since they add the build time to the binary. Usually you substitute the macro with the timestamp from the .changes file (using sed) to avoid the problem. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Cristian Morales Vega wrote:
You want two builds from the same source to generate the same binary. This allows the user to verify the binary hasn't been corrupted/compromised. Also, the openSUE Build service rebuilds the package everytime a dependency changes, but after the build there is a script that checks if there is any important difference between the new build and the old one. If the two build are equal the new package is discarded, so the user doesn't needs to redownload a new package that is exactly equal to the one he already has. But __TIMESTAMP__, __DATE__ and __TIME__ macros make every build different since they add the build time to the binary. Usually you substitute the macro with the timestamp from the .changes file (using sed) to avoid the problem.
Thanks for the explanation, that was just what I needed. And look what the spec file has: %build touch -r ./ver.c ./ver.c.stamp sed -i -e s@__DATE__@__TIMESTAMP__@ ./ver.c touch -r ./ver.c.stamp ./ver.c -- Per Jessen, Zürich (12.2°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Per Jessen wrote:
Cristian Morales Vega wrote:
You want two builds from the same source to generate the same binary. This allows the user to verify the binary hasn't been corrupted/compromised. Also, the openSUE Build service rebuilds the package everytime a dependency changes, but after the build there is a script that checks if there is any important difference between the new build and the old one. If the two build are equal the new package is discarded, so the user doesn't needs to redownload a new package that is exactly equal to the one he already has. But __TIMESTAMP__, __DATE__ and __TIME__ macros make every build different since they add the build time to the binary. Usually you substitute the macro with the timestamp from the .changes file (using sed) to avoid the problem.
Thanks for the explanation, that was just what I needed. And look what the spec file has:
%build touch -r ./ver.c ./ver.c.stamp sed -i -e s@__DATE__@__TIMESTAMP__@ ./ver.c touch -r ./ver.c.stamp ./ver.c
However, the changelog actually says: ------------------------------------------------------------------- Mon Aug 30 22:49:25 UTC 2010 - cristian.rodriguez@opensuse.org - use __TIMESTAMP__ instead of __DATE__ to make build-compare happy. So what's the story? -- Per Jessen, Zürich (12.1°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 16/03/11 09:35, Per Jessen escribió:
------------------------------------------------------------------- Mon Aug 30 22:49:25 UTC 2010 - cristian.rodriguez@opensuse.org
- use __TIMESTAMP__ instead of __DATE__ to make build-compare happy.
So what's the story?
That rings a bell here ;) why I did that ? huh, replace __TIMESTAMP__ in the sed script by "??? ?? ????" or $(date '+%b %e %Y' -r ver.c) As ugly as it may seem "??? ?? ????" is within the standard ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/3/16 Per Jessen <per@opensuse.org>:
However, the changelog actually says:
------------------------------------------------------------------- Mon Aug 30 22:49:25 UTC 2010 - cristian.rodriguez@opensuse.org
- use __TIMESTAMP__ instead of __DATE__ to make build-compare happy.
So what's the story?
IMHO it makes no sense. I usually use FAKE_BUILDDATE=$(LC_ALL=C date -u -r %{_sourcedir}/%{name}.changes '+%%b %%e %%Y') sed -i "s/__DATE__/\"$FAKE_BUILDDATE\"/" ver.c But the ver.c.stamp part makes sense, perhaps I should start to use it :-) (shouldn't my SRPMs been reported as different?) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Wed, 16 Mar 2011, Per Jessen wrote:
Thanks for the explanation, that was just what I needed. And look what the spec file has:
%build touch -r ./ver.c ./ver.c.stamp sed -i -e s@__DATE__@__TIMESTAMP__@ ./ver.c touch -r ./ver.c.stamp ./ver.c
However, the changelog actually says:
------------------------------------------------------------------- Mon Aug 30 22:49:25 UTC 2010 - cristian.rodriguez@opensuse.org
- use __TIMESTAMP__ instead of __DATE__ to make build-compare happy.
So what's the story?
That is because Cristian M. is wrong: DATE and TIME depend on the current time of compilation, but TIMESTAMP, as the name implies, depends on the mtime of the file to be compiled, hence as long as it isn't changed it will stay the same for each compilation, exactly what we want for build compare. Of course the very replacing of __DATE__ for __TIMESTAMP__ does change the file, hence mtime, ergo __TIMESTAMP__. That's why Cristian R. did the creative use of 'touch -r' to save/restore mtime. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 16/03/11 13:41, Michael Matz escribió:
Of course the very replacing of __DATE__ for __TIMESTAMP__ does change the file, hence mtime, ergo __TIMESTAMP__. That's why Cristian R. did the creative use of 'touch -r' to save/restore mtime.
creative^^W hackish ;) not happy with the hack anyway, probably a patch to the source code is cleaner, also it has come to my attention that some packages parse the output of --version version numbers and fail to run properly when it is modified. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Wed, 16 Mar 2011, Cristian Rodríguez wrote:
Of course the very replacing of __DATE__ for __TIMESTAMP__ does change the file, hence mtime, ergo __TIMESTAMP__. That's why Cristian R. did the creative use of 'touch -r' to save/restore mtime.
creative^^W hackish ;) not happy with the hack anyway, probably a patch to the source code is cleaner,
Also patching the sources will change the mtime (well, if not using -Z/-T for patch, and the .diff including a proper time entry). The only way around would be to include a so changed source file into the tarball already. Ciao, Michael.
participants (6)
-
Andreas Jaeger -
Cristian Morales Vega -
Cristian Rodríguez -
Marcus Meissner -
Michael Matz -
Per Jessen