Now that FESCo accepted http://fedoraproject.org/wiki/Features/RPM4.11 for F19... (in what might well be a record time - less than a minute in the meeting from proposal to acceptance :)
Rpm 4.11 alpha (or actually post-alpha snapshot to pull in a few accumulated fixes + enhancements) will be hitting rawhide shortly. There's no soname bump involved this time, so no rebuilds required.
There's one thing that does affect nearly every package: new warnings about bogus spec changelog dates. The most common cause is the day name not matching the given date, such as: warning: bogus date in %changelog: Tue Jun 03 2009 Panu Matilainen pmatilai@redhat.com - 4.7.0-5
Jun 03 2009 was Wednesday, not Tuesday, hence the warning. As rpm hasn't hasn't previously validated changelog dates make sense as a whole, nearly every spec has one or more of these mistakes. It's just a warning though and doesn't cause build failures.
Other than that, chances are you wont notice much anything at all. Assuming all goes well that is. So its the usual drill: keep your eyes open on rawhide builds and report any new oddities found ASAP. I'm not expecting any major issues with this but you never really know.
For further details see the draft release notes at http://rpm.org/wiki/Releases/4.11.0
- Panu -
On Thu, Nov 15, 2012 at 10:28:49AM +0200, Panu Matilainen wrote:
For further details see the draft release notes at http://rpm.org/wiki/Releases/4.11.0
Should we start changing
%doc README COPYING
to
%doc README %license COPYING
?
Rich.
On 11/15/2012 11:59 AM, Richard W.M. Jones wrote:
On Thu, Nov 15, 2012 at 10:28:49AM +0200, Panu Matilainen wrote:
For further details see the draft release notes at http://rpm.org/wiki/Releases/4.11.0
Should we start changing
%doc README COPYING
to
%doc README %license COPYING
?
Eventually yes, although that'd be up to FPC I guess.
Not yet however: while the produced packages are compatible with all older rpm versions, the spec is not. As long as there's a chance we might (temporarily) have to revert back to 4.10, you dont want to introduce spec-level changes that would cause build-failures on the older version.
- Panu -
On Thursday, November 15, 2012 06:20 PM, Panu Matilainen wrote:
On 11/15/2012 11:59 AM, Richard W.M. Jones wrote:
On Thu, Nov 15, 2012 at 10:28:49AM +0200, Panu Matilainen wrote:
For further details see the draft release notes at http://rpm.org/wiki/Releases/4.11.0
Should we start changing
%doc README COPYING
to
%doc README %license COPYING
?
Eventually yes, although that'd be up to FPC I guess.
Not yet however: while the produced packages are compatible with all older rpm versions, the spec is not. As long as there's a chance we might (temporarily) have to revert back to 4.10, you dont want to introduce spec-level changes that would cause build-failures on the older version.
Maybe redhat-rpm-config could define the %license macro to the same as %doc on Fedora<19 ?
On 11/15/2012 12:21 PM, Mathieu Bridon wrote:
On Thursday, November 15, 2012 06:20 PM, Panu Matilainen wrote:
On 11/15/2012 11:59 AM, Richard W.M. Jones wrote:
On Thu, Nov 15, 2012 at 10:28:49AM +0200, Panu Matilainen wrote:
For further details see the draft release notes at http://rpm.org/wiki/Releases/4.11.0
Should we start changing
%doc README COPYING
to
%doc README %license COPYING
?
Eventually yes, although that'd be up to FPC I guess.
Not yet however: while the produced packages are compatible with all older rpm versions, the spec is not. As long as there's a chance we might (temporarily) have to revert back to 4.10, you dont want to introduce spec-level changes that would cause build-failures on the older version.
Maybe redhat-rpm-config could define the %license macro to the same as %doc on Fedora<19 ?
Unfortunately that wont work: %license is clobbered by License: tag in specs. It could be aliased to %doc with a tiny patch to librpmbuild, but patching is needed.
- Panu -
On 11/15/2012 12:20 PM, Panu Matilainen wrote:
On 11/15/2012 11:59 AM, Richard W.M. Jones wrote:
On Thu, Nov 15, 2012 at 10:28:49AM +0200, Panu Matilainen wrote:
For further details see the draft release notes at http://rpm.org/wiki/Releases/4.11.0
Should we start changing
%doc README COPYING
to
%doc README %license COPYING
?
Eventually yes, although that'd be up to FPC I guess.
Not yet however: while the produced packages are compatible with all older rpm versions, the spec is not. As long as there's a chance we might (temporarily) have to revert back to 4.10, you dont want to introduce spec-level changes that would cause build-failures on the older version.
Oh and btw, the same goes for using %autosetup: please do test it locally [*] and report any issues you may find, but avoid using in Fedora specs just yet.
The whole %autosetup thing is implemented with macros and should be easy to pull into older Fedora releases once any early bugs have been shaken out.
[*] Her's a quickstart guide to using %autosetup:
1) Make sure all the patches are using same prefix level (eg -p1) 2) Replace %setup with %autosetup (all the same switches apply), add patch prefix level if needed with -p<N> 3) Eliminate all %patch directives from the spec
%autosetup defaults to using plain old 'patch' for the automated patch application, add -S <git|quilt|hg|bzr> to experiment with the DVCS intergration.
- Panu -
On Thu, Nov 15, 2012 at 2:28 AM, Panu Matilainen pmatilai@laiskiainen.orgwrote:
Now that FESCo accepted http://fedoraproject.org/wiki/**Features/RPM4.11http://fedoraproject.org/wiki/Features/RPM4.11for F19... (in what might well be a record time - less than a minute in the meeting from proposal to acceptance :)
Rpm 4.11 alpha (or actually post-alpha snapshot to pull in a few accumulated fixes + enhancements) will be hitting rawhide shortly. There's no soname bump involved this time, so no rebuilds required.
There's one thing that does affect nearly every package: new warnings about bogus spec changelog dates. The most common cause is the day name not matching the given date, such as: warning: bogus date in %changelog: Tue Jun 03 2009 Panu Matilainen < pmatilai@redhat.com> - 4.7.0-5
Jun 03 2009 was Wednesday, not Tuesday, hence the warning. As rpm hasn't hasn't previously validated changelog dates make sense as a whole, nearly every spec has one or more of these mistakes. It's just a warning though and doesn't cause build failures.
Other than that, chances are you wont notice much anything at all. Assuming all goes well that is. So its the usual drill: keep your eyes open on rawhide builds and report any new oddities found ASAP. I'm not expecting any major issues with this but you never really know.
For further details see the draft release notes at http://rpm.org/wiki/Releases/**4.11.0http://rpm.org/wiki/Releases/4.11.0
I can't build the latest wesnoth in rawhide, but I can in all older
releases. Fails because some of the data is missing.
http://kojipkgs.fedoraproject.org//work/tasks/9837/4709837/build.log
Is this RPM related?
-J
- Panu --- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
On 11/20/2012 07:45 PM, Jon Ciesla wrote:
On Thu, Nov 15, 2012 at 2:28 AM, Panu Matilainen <pmatilai@laiskiainen.org mailto:pmatilai@laiskiainen.org> wrote:
Now that FESCo accepted http://fedoraproject.org/wiki/__Features/RPM4.11 <http://fedoraproject.org/wiki/Features/RPM4.11> for F19... (in what might well be a record time - less than a minute in the meeting from proposal to acceptance :) Rpm 4.11 alpha (or actually post-alpha snapshot to pull in a few accumulated fixes + enhancements) will be hitting rawhide shortly. There's no soname bump involved this time, so no rebuilds required. There's one thing that does affect nearly every package: new warnings about bogus spec changelog dates. The most common cause is the day name not matching the given date, such as: warning: bogus date in %changelog: Tue Jun 03 2009 Panu Matilainen <pmatilai@redhat.com <mailto:pmatilai@redhat.com>> - 4.7.0-5 Jun 03 2009 was Wednesday, not Tuesday, hence the warning. As rpm hasn't hasn't previously validated changelog dates make sense as a whole, nearly every spec has one or more of these mistakes. It's just a warning though and doesn't cause build failures. Other than that, chances are you wont notice much anything at all. Assuming all goes well that is. So its the usual drill: keep your eyes open on rawhide builds and report any new oddities found ASAP. I'm not expecting any major issues with this but you never really know. For further details see the draft release notes at http://rpm.org/wiki/Releases/__4.11.0 <http://rpm.org/wiki/Releases/4.11.0>I can't build the latest wesnoth in rawhide, but I can in all older releases. Fails because some of the data is missing.
http://kojipkgs.fedoraproject.org//work/tasks/9837/4709837/build.log
Is this RPM related?
I would say no: if you compare the early parts of the build.log between f19 and eg f18 build, in the successful build the translations directory and its contents gets created in a big big pile of 'mo-update' calls:
-- Build files have been written to: /builddir/build/BUILD/wesnoth-1.10.5 Scanning dependencies of target mo-update [ 0%] mo-update [zh_TW]: Creating locale directory. [ 0%] mo-update [af]: Creating locale directory. [ 0%] mo-update [ang]: Creating locale directory. [ 0%] mo-update [ang@latin]: Creating locale directory. [ 0%] mo-update [ar]: Creating locale directory. [ 0%] Scanning dependencies of target wesnoth-lua
...but in the f19 build, no such thing occurs: -- Build files have been written to: /builddir/build/BUILD/wesnoth-1.10.5 Scanning dependencies of target wesnoth-lua [ 0%] Scanning dependencies of target wesnoth-core [...]
- Panu -
On Tue, Nov 20, 2012 at 12:08 PM, Panu Matilainen pmatilai@laiskiainen.orgwrote:
On 11/20/2012 07:45 PM, Jon Ciesla wrote:
On Thu, Nov 15, 2012 at 2:28 AM, Panu Matilainen <pmatilai@laiskiainen.org <mailto:pmatilai@laiskiainen.**orgpmatilai@laiskiainen.org>> wrote:
Now that FESCo accepted http://fedoraproject.org/wiki/**__Features/RPM4.11<http://fedoraproject.org/wiki/__Features/RPM4.11> <http://fedoraproject.org/**wiki/Features/RPM4.11<http://fedoraproject.org/wiki/Features/RPM4.11>>for F19... (in what might well be a record time - less than a minute in the meeting from proposal to acceptance :)
Rpm 4.11 alpha (or actually post-alpha snapshot to pull in a few accumulated fixes + enhancements) will be hitting rawhide shortly. There's no soname bump involved this time, so no rebuilds required. There's one thing that does affect nearly every package: new warnings about bogus spec changelog dates. The most common cause is the day name not matching the given date, such as: warning: bogus date in %changelog: Tue Jun 03 2009 Panu Matilainen <pmatilai@redhat.com <mailto:pmatilai@redhat.com>> - 4.7.0-5 Jun 03 2009 was Wednesday, not Tuesday, hence the warning. As rpm hasn't hasn't previously validated changelog dates make sense as a whole, nearly every spec has one or more of these mistakes. It's just a warning though and doesn't cause build failures. Other than that, chances are you wont notice much anything at all. Assuming all goes well that is. So its the usual drill: keep your eyes open on rawhide builds and report any new oddities found ASAP. I'm not expecting any major issues with this but you never reallyknow.
For further details see the draft release notes at http://rpm.org/wiki/Releases/_**_4.11.0<http://rpm.org/wiki/Releases/__4.11.0> <http://rpm.org/wiki/Releases/**4.11.0<http://rpm.org/wiki/Releases/4.11.0>I can't build the latest wesnoth in rawhide, but I can in all older releases. Fails because some of the data is missing.
http://kojipkgs.fedoraproject.**org//work/tasks/9837/4709837/**build.loghttp://kojipkgs.fedoraproject.org//work/tasks/9837/4709837/build.log
Is this RPM related?
I would say no: if you compare the early parts of the build.log between f19 and eg f18 build, in the successful build the translations directory and its contents gets created in a big big pile of 'mo-update' calls:
-- Build files have been written to: /builddir/build/BUILD/wesnoth-** 1.10.5 Scanning dependencies of target mo-update [ 0%] mo-update [zh_TW]: Creating locale directory. [ 0%] mo-update [af]: Creating locale directory. [ 0%] mo-update [ang]: Creating locale directory. [ 0%] mo-update [ang@latin]: Creating locale directory. [ 0%] mo-update [ar]: Creating locale directory. [ 0%] Scanning dependencies of target wesnoth-lua
...but in the f19 build, no such thing occurs: -- Build files have been written to: /builddir/build/BUILD/wesnoth-** 1.10.5 Scanning dependencies of target wesnoth-lua [ 0%] Scanning dependencies of target wesnoth-core [...]
I thought not, but wanted to be sure. It certainly f19-centric. Thanks!
And if anyone see something obvious here let me know.
-J
- Panu --- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Nov 20, 2012 at 18:15:26 GMT, Jon Ciesla wrote:
On Tue, Nov 20, 2012 at 12:08 PM, Panu Matilainen pmatilai@laiskiainen.org wrote:
-- Build files have been written to: /builddir/build/BUILD/wesnoth-** 1.10.5 Scanning dependencies of target mo-update [ 0%] mo-update [zh_TW]: Creating locale directory. [ 0%] mo-update [af]: Creating locale directory. [ 0%] mo-update [ang]: Creating locale directory. [ 0%] mo-update [ang@latin]: Creating locale directory. [ 0%] mo-update [ar]: Creating locale directory. [ 0%] Scanning dependencies of target wesnoth-lua
...but in the f19 build, no such thing occurs: -- Build files have been written to: /builddir/build/BUILD/wesnoth-** 1.10.5 Scanning dependencies of target wesnoth-lua [ 0%] Scanning dependencies of target wesnoth-core [...]
I thought not, but wanted to be sure. It certainly f19-centric. Thanks!
And if anyone see something obvious here let me know.
It's missing a VERBOSE=1 parameter to make (or the appropriate parameter to CMake which I can't remember off the top of my head) to show the actual commands being run.
Other than that, F19 has CMake 2.8.10.1 and F18 has 2.8.9. If using CMake 2.8.9 works, it should be reported upstream as a regression.
--Ben
On 11/22/2012 10:07 PM, Ben Boeckel wrote:
On Tue, Nov 20, 2012 at 18:15:26 GMT, Jon Ciesla wrote:
On Tue, Nov 20, 2012 at 12:08 PM, Panu Matilainen pmatilai@laiskiainen.org wrote:
-- Build files have been written to: /builddir/build/BUILD/wesnoth-** 1.10.5 Scanning dependencies of target mo-update [ 0%] mo-update [zh_TW]: Creating locale directory. [ 0%] mo-update [af]: Creating locale directory. [ 0%] mo-update [ang]: Creating locale directory. [ 0%] mo-update [ang@latin]: Creating locale directory. [ 0%] mo-update [ar]: Creating locale directory. [ 0%] Scanning dependencies of target wesnoth-lua
...but in the f19 build, no such thing occurs: -- Build files have been written to: /builddir/build/BUILD/wesnoth-** 1.10.5 Scanning dependencies of target wesnoth-lua [ 0%] Scanning dependencies of target wesnoth-core [...]
I thought not, but wanted to be sure. It certainly f19-centric. Thanks!
And if anyone see something obvious here let me know.
It's missing a VERBOSE=1 parameter to make (or the appropriate parameter to CMake which I can't remember off the top of my head) to show the actual commands being run.
If you use the %cmake macro, you'll get verbose builds.
Other than that, F19 has CMake 2.8.10.1 and F18 has 2.8.9. If using CMake 2.8.9 works, it should be reported upstream as a regression.
--Ben
On Fri, Nov 23, 2012 at 8:43 PM, Orion Poplawski orion@cora.nwra.comwrote:
On 11/22/2012 10:07 PM, Ben Boeckel wrote:
On Tue, Nov 20, 2012 at 18:15:26 GMT, Jon Ciesla wrote:
On Tue, Nov 20, 2012 at 12:08 PM, Panu Matilainen < pmatilai@laiskiainen.org> wrote:
-- Build files have been written to: /builddir/build/BUILD/wesnoth-**** 1.10.5 Scanning dependencies of target mo-update [ 0%] mo-update [zh_TW]: Creating locale directory. [ 0%] mo-update [af]: Creating locale directory. [ 0%] mo-update [ang]: Creating locale directory. [ 0%] mo-update [ang@latin]: Creating locale directory. [ 0%] mo-update [ar]: Creating locale directory. [ 0%] Scanning dependencies of target wesnoth-lua
...but in the f19 build, no such thing occurs: -- Build files have been written to: /builddir/build/BUILD/wesnoth-**** 1.10.5 Scanning dependencies of target wesnoth-lua [ 0%] Scanning dependencies of target wesnoth-core [...]
I thought not, but wanted to be sure. It certainly f19-centric. Thanks!
And if anyone see something obvious here let me know.
It's missing a VERBOSE=1 parameter to make (or the appropriate parameter to CMake which I can't remember off the top of my head) to show the actual commands being run.
If you use the %cmake macro, you'll get verbose builds.
Other than that, F19 has CMake 2.8.10.1 and F18 has 2.8.9. If using
CMake 2.8.9 works, it should be reported upstream as a regression.
--Ben
Must be cmake, switching to scons worked. Orion, what do you want to see
in a bug report?
-J
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
Looks like some packages make use of:
%doc --parents Copyright.txt README.html vtkLogo.jpg vtkBanner.gif Wrapping/*/README*
To pass "--parents" to the cp command. This appears to no longer work:
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.SeYbFF + umask 022 + cd /builddir/build/BUILD + cd VTK5.10.1 + DOCDIR=/builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1 + export DOCDIR + /usr/bin/mkdir -p /builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1 + cp -pr --parents /builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1 cp: missing destination file operand after '/builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1' Try 'cp --help' for more information.
Now, this seems like very much a hack that only accidentally worked. That said, can this functionality be restored somehow?
On 12/04/2012 01:59 AM, Orion Poplawski wrote:
Looks like some packages make use of:
%doc --parents Copyright.txt README.html vtkLogo.jpg vtkBanner.gif Wrapping/*/README*
To pass "--parents" to the cp command. This appears to no longer work:
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.SeYbFF
- umask 022
- cd /builddir/build/BUILD
- cd VTK5.10.1
DOCDIR=/builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1
- export DOCDIR
- /usr/bin/mkdir -p
/builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1
- cp -pr --parents
/builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1 cp: missing destination file operand after '/builddir/build/BUILDROOT/vtk-5.10.1-2.fc19.x86_64/usr/share/doc/vtk-5.10.1'
Try 'cp --help' for more information.
Now, this seems like very much a hack that only accidentally worked.
Ugh, the tricks people come up with...
That said, can this functionality be restored somehow?
There's no need for such %doc abuses. Construct a temporary directory with the structure of your liking in %install and use that for %doc, something like
%install [...] mkdir _wrappingdocs cp -pr --parents Wrapping/*/README* _wrappingdocs/
%files %doc _wrappingdocs/*
- Panu -
On 11/15/2012 01:28 AM, Panu Matilainen wrote:
Now that FESCo accepted http://fedoraproject.org/wiki/Features/RPM4.11 for F19... (in what might well be a record time - less than a minute in the meeting from proposal to acceptance :)
Rpm 4.11 alpha (or actually post-alpha snapshot to pull in a few accumulated fixes + enhancements) will be hitting rawhide shortly. There's no soname bump involved this time, so no rebuilds required.
There's one thing that does affect nearly every package: new warnings about bogus spec changelog dates. The most common cause is the day name not matching the given date, such as: warning: bogus date in %changelog: Tue Jun 03 2009 Panu Matilainen pmatilai@redhat.com - 4.7.0-5
Jun 03 2009 was Wednesday, not Tuesday, hence the warning. As rpm hasn't hasn't previously validated changelog dates make sense as a whole, nearly every spec has one or more of these mistakes. It's just a warning though and doesn't cause build failures.
Other than that, chances are you wont notice much anything at all. Assuming all goes well that is. So its the usual drill: keep your eyes open on rawhide builds and report any new oddities found ASAP. I'm not expecting any major issues with this but you never really know.
For further details see the draft release notes at http://rpm.org/wiki/Releases/4.11.0
- Panu -
Here's another %doc change:
%doc doc/Users\ guide\ Apache.html
Gets executed as:
+ cp -pr 'doc/Users /builddir/build/BUILDROOT/rubygem-passenger-3.0.19-1.fc19.i386/usr/share/doc/mod_passenger-3.0.19' cp: missing destination file operand after 'doc/Users /builddir/build/BUILDROOT/rubygem-passenger-3.0.19-1.fc19.i386/usr/share/doc/mod_passenger-3.0.19'
Filed http://rpm.org/ticket/858
On 01/20/2013 07:32 PM, Orion Poplawski wrote:
Here's another %doc change:
%doc doc/Users\ guide\ Apache.html
Gets executed as:
- cp -pr 'doc/Users
/builddir/build/BUILDROOT/rubygem-passenger-3.0.19-1.fc19.i386/usr/share/doc/mod_passenger-3.0.19'
cp: missing destination file operand after 'doc/Users /builddir/build/BUILDROOT/rubygem-passenger-3.0.19-1.fc19.i386/usr/share/doc/mod_passenger-3.0.19'
http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef017d3de376c0970c-pi
Thanks for reporting, will fix.
- Panu -
On 01/21/2013 10:39 AM, Panu Matilainen wrote:
On 01/20/2013 07:32 PM, Orion Poplawski wrote:
Here's another %doc change:
%doc doc/Users\ guide\ Apache.html
Gets executed as:
- cp -pr 'doc/Users
/builddir/build/BUILDROOT/rubygem-passenger-3.0.19-1.fc19.i386/usr/share/doc/mod_passenger-3.0.19'
cp: missing destination file operand after 'doc/Users /builddir/build/BUILDROOT/rubygem-passenger-3.0.19-1.fc19.i386/usr/share/doc/mod_passenger-3.0.19'
http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef017d3de376c0970c-pi
Thanks for reporting, will fix.
Hmm... turns out it's not quite that simple.
This is actually another case of relying on undocumented behavior: backslash-escaping of spaces has never worked in %files section, it only accidentally "worked" for %doc due to side-effects of how they got passed to shell/cp. Same goes for ''-quoting (as used in the ticket): it only works because of side-effects, not intentionally.
But then, the "official" %files list way of ""-quoting to get around spaces has never worked in any rpm version AFAICT.
*facepalm*
What does work everywhere is globs, eg:
%doc doc/Users?guide?Apache.html
...so there is a backwards-compatible workaround. And now back to wondering what to do about this mess...
- Panu -
devel@lists.stg.fedoraproject.org
-
Ben Boeckel -
Jon Ciesla -
Mathieu Bridon -
Orion Poplawski -
Panu Matilainen -
Richard W.M. Jones