2:28 a.m.
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(a)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 -
3:59 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
4:20 a.m.
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 -
4:21 a.m.
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 ?
--
Mathieu
4:41 a.m.
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 -
6:09 a.m.
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 -
11:45 a.m.
On Thu, Nov 15, 2012 at 2:28 AM, Panu Matilainen
<pmatilai(a)laiskiainen.org>wrote:
Now that FESCo accepted
http://fedoraproject.org/wiki/**Features/RPM4.11<http://fedoraproject....
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(a)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.1...
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(a)lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...
--
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
12:08 p.m.
On 11/20/2012 07:45 PM, Jon Ciesla wrote:
On Thu, Nov 15, 2012 at 2:28 AM, Panu Matilainen
<pmatilai(a)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(a)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 -
12:15 p.m.
On Tue, Nov 20, 2012 at 12:08 PM, Panu Matilainen
<pmatilai(a)laiskiainen.org>wrote:
On 11/20/2012 07:45 PM, Jon Ciesla wrote:
>
>
> On Thu, Nov 15, 2012 at 2:28 AM, Panu Matilainen
> <pmatilai(a)laiskiainen.org
<mailto:pmatilai@laiskiainen.**org<pmatilai@laiskiainen.org>>>
> wrote:
>
>
> Now that FESCo accepted
>
http://fedoraproject.org/wiki/**__Features/RPM4.11<http://fedoraprojec...
>
<http://fedoraproject.org/**wiki/Features/RPM4.11<http://fedoraproject....
> 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(a)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/_...
>
<http://rpm.org/wiki/Releases/**4.11.0<http://rpm.org/wiki/Releases/4.1...
> >
>
> 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
[...]
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(a)lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...
--
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
11:07 p.m.
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(a)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
8:43 p.m.
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(a)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
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
1:32 p.m.
On Fri, Nov 23, 2012 at 8:43 PM, Orion Poplawski <orion(a)cora.nwra.com>wrote:
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(a)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(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...
--
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
5:59 p.m.
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?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
3:48 a.m.
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 -
11:32 a.m.
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(a)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
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
2:39 a.m.
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'
Filed http://rpm.org/ticket/858
http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef017d3de376c0970c-pi
Thanks for reporting, will fix.
- Panu -
3:57 a.m.
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'
>
>
> Filed http://rpm.org/ticket/858
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 -
4113
days inactive
4180
days old
16 comments
6 participants
participants (6)
-
Ben Boeckel -
Jon Ciesla -
Mathieu Bridon -
Orion Poplawski -
Panu Matilainen -
Richard W.M. Jones