Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
Den 16:16 20. desember 2011 skrev Jeffrey Johnson følgende:
>
> On Dec 20, 2011, at 9:55 AM, Per Øyvind Karlsen wrote:
>
>> Den 17:39 21. oktober 2011 skrev Jeff Johnson følgende:
>>> RPM Package Manager, CVS Repository
>>> http://rpm5.org/cvs/
>>>
>>>
>>> Server: rpm5.org Name: Jeff Johnson
>>> Root: /v/rpm/cvs Email: j...@rpm5.org
>>> Module: rpm Date: 21-Oct-2011 17:39:03
>>> Branch: rpm-5_4 Handle: 2011102115390101
>>>
>>> Modified files: (Branch: rpm-5_4)
>>> rpm CHANGES
>>> rpm/macros macros.rpmbuild.in
>>> rpm/scripts find-debuginfo.sh
>>>
>>> Log:
>>> - debuginfo: use current dir instead of $RPM_BUILD_DIR.
>> D'oh, a bit late discovered, but better than never..
>>
>> $RPM_BUILD_DIR == %{_builddir}
>> while
>> $PWD == %{_builddir}/%{?buildsubdir}
>>
>> So for most packages which have their own %buildsubdir, this will mess
>> up the paths for debug packages, ie. see the following example:
>>
>
> I hope "… have their own %buildsubdir …" doesn't mean that some
> package monkey is trying to set/change %builddubdor in a *.spec file.
Nope, I'm referring to whether %buildsubdir is set or not (as
controlled by %setup).
For most packages it's set, with the default being %{name}-%{version}.
So "%{_builddir} / %{buildsubdir}" will be ie. "/usr/src/rpm/BUILD / foo-1.2.3".
>
> Meanwhile, I'm not sure what you have "discovered": literally nothing has
> changed in this area for most of this century, the whole mechanism
> if fabulously broken and mis-designed and mis-implemented imho.
Simply that $PWD == %{_builddir}/%{?buildsubdir}, thus $RPM_BUILD_DIR=`pwd`
is incorrect with the consequence of messing up paths in debug packages..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
On Dec 20, 2011, at 9:55 AM, Per Øyvind Karlsen wrote:
> Den 17:39 21. oktober 2011 skrev Jeff Johnson følgende:
>> RPM Package Manager, CVS Repository
>> http://rpm5.org/cvs/
>>
>>
>> Server: rpm5.org Name: Jeff Johnson
>> Root: /v/rpm/cvs Email: j...@rpm5.org
>> Module: rpm Date: 21-Oct-2011 17:39:03
>> Branch: rpm-5_4 Handle: 2011102115390101
>>
>> Modified files: (Branch: rpm-5_4)
>>rpm CHANGES
>>rpm/macros macros.rpmbuild.in
>>rpm/scripts find-debuginfo.sh
>>
>> Log:
>>- debuginfo: use current dir instead of $RPM_BUILD_DIR.
> D'oh, a bit late discovered, but better than never..
>
> $RPM_BUILD_DIR == %{_builddir}
> while
> $PWD == %{_builddir}/%{?buildsubdir}
>
> So for most packages which have their own %buildsubdir, this will mess
> up the paths for debug packages, ie. see the following example:
>
I hope "… have their own %buildsubdir …" doesn't mean that some
package monkey is trying to set/change %builddubdor in a *.spec file.
Meanwhile, I'm not sure what you have "discovered": literally nothing has
changed in this area for most of this century, the whole mechanism
if fabulously broken and mis-designed and mis-implemented imho.
No change to any of these conventions should be undertaken, nor do I
have any interest in "fixes" short of scrapping everything and reimplementing
more soundly, and that effort cannot be done without a ROADMAP
and goals and automated testing and more.
But "Have it your own way!" feel free to change whatever you wish,
just don't check any "wild hacking" changes in.
hth
73 de Jeff__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
Den 17:39 21. oktober 2011 skrev Jeff Johnson følgende:
> RPM Package Manager, CVS Repository
> http://rpm5.org/cvs/
>
>
> Server: rpm5.org Name: Jeff Johnson
> Root: /v/rpm/cvs Email: j...@rpm5.org
> Module: rpm Date: 21-Oct-2011 17:39:03
> Branch: rpm-5_4 Handle: 2011102115390101
>
> Modified files: (Branch: rpm-5_4)
> rpm CHANGES
> rpm/macros macros.rpmbuild.in
> rpm/scripts find-debuginfo.sh
>
> Log:
> - debuginfo: use current dir instead of $RPM_BUILD_DIR.
D'oh, a bit late discovered, but better than never..
$RPM_BUILD_DIR == %{_builddir}
while
$PWD == %{_builddir}/%{?buildsubdir}
So for most packages which have their own %buildsubdir, this will mess
up the paths for debug packages, ie. see the following example:
[peroyvind@t61 linux_logo]$ rpm -qpl
/home/peroyvind/RPM/linux_logo/RPMS/x86_64/linux_logo-debug-5.11-1-mdv2012.0.x86_64.rpm
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/02
/usr/lib/debug/.build-id/02/da5f6707c052c4293ea8e055de33d2704a3933
/usr/lib/debug/.build-id/02/da5f6707c052c4293ea8e055de33d2704a3933.debug
/usr/lib/debug/usr
/usr/lib/debug/usr/bin
/usr/lib/debug/usr/bin/linux_logo.debug
/usr/src/debug/defaults.h
/usr/src/debug/home
/usr/src/debug/home/peroyvind
/usr/src/debug/home/peroyvind/RPM
/usr/src/debug/home/peroyvind/RPM/linux_logo
/usr/src/debug/home/peroyvind/RPM/linux_logo/BUILD
/usr/src/debug/home/peroyvind/RPM/linux_logo/BUILD/linux_logo-5.11
/usr/src/debug/libsysinfo-0.2.2
/usr/src/debug/libsysinfo-0.2.2/Linux
/usr/src/debug/libsysinfo-0.2.2/Linux/cpuinfo_x86.c
/usr/src/debug/libsysinfo-0.2.2/Linux/sysinfo_linux.c
/usr/src/debug/libsysinfo-0.2.2/all
/usr/src/debug/libsysinfo-0.2.2/all/fix_mhz.c
/usr/src/debug/libsysinfo-0.2.2/all/parsing.c
/usr/src/debug/libsysinfo-0.2.2/all/sysinfo_common.c
/usr/src/debug/libsysinfo-0.2.2/all/uname.c
/usr/src/debug/libsysinfo-0.2.2/sysinfo.h
/usr/src/debug/linux_logo.c
/usr/src/debug/linux_logo.h
/usr/src/debug/load_logo.c
/usr/src/debug/load_logos.h
/usr/src/debug/logo_types.h
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
On Apr 10, 2011, at 1:43 PM, Hatle, Mark wrote:
>
> Heh. Since we're still planning for poky/OE-core I figured it made sense to
> know how others have solved this issue so we can come up with an appropriate
> solution for our embedded needs... But the more I look at the Mandriva
> approach the less I think it's applicable for what we're doing.
>
Well you (meaning Poky) *are* better positioned to automate a look-aside
in CFLAGS for per-arch content. Nothing at all wrong with
methodology and discipline used wisely in Makefile's.
It's %{_arch} (which was a really flimsy/feeble attempt
on my part in 1999 to capture canonical "i386" != target "i486"
in per-arch CPU--OS/macros configgery that is the fundamental
issue.
Noone has any clue how to configure rpmbuild wisely and usefully
and reliably, its all
Have it your own way!
search paths with globs and more that noone can possibly be
using (because strace -e open shows me unexpanded macros in file
paths at least weekly).
The other issue is that if you convolve build system configgery
like %{_arch} into the paths/content distributed in packages,
the "Well duh!" corollary is this:
You WILL have broken packages every time the build system
is misconfigured.
WHich is surprisingly often in the "real world" of rpmbuild configgery
cluelessness.
hth
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
On Apr 10, 2011, at 8:29 AM, "Jeff Johnson" wrote:
>
> On Apr 10, 2011, at 10:30 AM, Hatle, Mark wrote:
>
>>
>> Do you have a pointer or any documentation on how to use these new macros
>> and helpers?
>>
>
> The multiarch macros?
>
> I can tell you what I see:
>
> Instead of ensuring that /usr/include/*.h is independent of arch
> (this was what was done @redhat, took several months of churn-and-burn
> to get the packaging policy to the MANDATORY/ENFORCING level),
> Mandriva has chosen a VPATH-like approach in the build environment,
> where a %{_arch}-mumbo-jumbo is automagically added to rpmbuild
> CFLAGS and there's additional macro magic to rearrange %files.
>
Right now (in poky) the plan is to work like the redhat way... We intend to
put in the checks, validation, etc to find and assist people in fixing multilib
header issues..
> Since the whole scheme is based on consistent use of %{_arch}, the
> scheme can/will depend on build system setup in some excruciatingly
> painful ways.
>
> This has just happened in Mandriva Cooker, where %{_arch}
> happened to end-up with "i586" not "i386" (the correct value afaik).
>
>
> And for extra speshul painfulness on my own aging box, libcpuinfo
> has decided to put "pentium4" into varous arch-related configgery
> in order to assist me with RPM configgery.
>
>
> You WILL got nutso if you attempt Mandriva multiarch packaging
> policy like this in Poky imho. Cleaner/easier is to patch out
> (or use) @redhat derived packaging instead.
>
Heh. Since we're still planning for poky/OE-core I figured it made sense to
know how others have solved this issue so we can come up with an appropriate
solution for our embedded needs... But the more I look at the Mandriva
approach the less I think it's applicable for what we're doing.
> But you are not using rpmbuild w Poky so it hardly matters.
>
> hth
>
> 73 de Jeff
>> Thanks!
>>
>>
>> On Apr 10, 2011, at 6:53 AM, "Per Øyvind Karlsen" wrote:
>>
>>> RPM Package Manager, CVS Repository
>>> http://rpm5.org/cvs/
>>>
>>>
>>> Server: rpm5.org Name: Per Øyvind Karlsen
>>> Root: /v/rpm/cvs Email: pkarl...@rpm5.org
>>> Module: rpm Date: 10-Apr-2011 15:53:32
>>> Branch: rpm-5_4 Handle: 2011041013533001
>>>
>>> Added files: (Branch: rpm-5_4)
>>> rpm/scripts check-multiarch-files mkmultiarch
>>> multiarch-dispatch multiarch-dispatch.h
>>> multiarch-platform
>>> Modified files: (Branch: rpm-5_4)
>>> rpm CHANGES
>>> rpm/macros macros.rpmbuild.in
>>> rpm/scripts Makefile.am
>>>
>>> Log:
>>> merge multiarch-utils from mandriva.
>>>
>>> Summary:
>>> RevisionChanges Path
>>> 1.3501.2.109+1 -0 rpm/CHANGES
>>> 1.4.4.1 +20 -2 rpm/macros/macros.rpmbuild.in
>>> 1.75.2.6+7 -1 rpm/scripts/Makefile.am
>>> 1.1.2.2 +92 -0 rpm/scripts/check-multiarch-files
>>> 1.1.2.2 +91 -0 rpm/scripts/mkmultiarch
>>> 1.1.2.2 +31 -0 rpm/scripts/multiarch-dispatch
>>> 1.1.2.2 +172 -0 rpm/scripts/multiarch-dispatch.h
>>> 1.1.2.2 +14 -0 rpm/scripts/multiarch-platform
>>>
>>>
>>> patch -p0 <<'@@ .'
>>> Index: rpm/CHANGES
>>>
>>> $ cvs diff -u -r1.3501.2.108 -r1.3501.2.109 CHANGES
>>> --- rpm/CHANGES10 Apr 2011 11:20:10 -1.3501.2.108
>>> +++ rpm/CHANGES10 Apr 2011 13:53:31 -1.3501.2.109
>>> @@ -1,4 +1,5 @@
>>> 5.4.0 -> 5.4.1:
>>> +- proyvind: merge multiarch-utils from mandriva.
>>> - proyvind: macros: sync with updated python macros from mandriva.
>>> - proyvind: rpmfc: add internel dep generator helper for kernel modules.
>>> - provyind: kmod-deps.sh: add dependency extractor from mandriva.
>>> __
>> RPM Package Managerhttp://rpm5.org
>> Developer Communication Listrpm-devel@rpm5.org
>>
>
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
On Apr 10, 2011, at 11:42 AM, Per Øyvind Karlsen wrote:
>>
>> This has just happened in Mandriva Cooker, where %{_arch}
>> happened to end-up with "i586" not "i386" (the correct value afaik).
> First and only time it has happened, related to me wiping away the
> same macros maintained for mandriva specifically from rpm-setup,
> ie. a rpm bug. ;p
The incidence isn't as important as the experience.
I used to build rpm all the time and tried to
have rpm self-configure from information available
in the build system (up to and including trapping
on SIGILL when asm voo-doo happened to encounter
a buggy flashing on a cpu. Yes "segfault" is/was
the means of identifying ppc64 cross-dressed as ppc32).
I've gotten burned so so so many times because --
when you convolve information from build system
into a per-package build -- then the packaging breakes EVERY time
the build system is misconfigured.
And the answer is no where near as simple as claiming
Mandriva build systems *NEVER* brak, are *ALWAYS*
perfectly configured.
KISS instead: the whole issue can be avoided is %{_arch} isn't
used with %multiarch but rather make multiarch packages per-arch
with hardwired "i386" strings in paths if that is what you choose
to do.
ANd even KISSier is patching /usr/include/*.h so that
source is arch independent. If you send patches upstream
there's even hope of fixing the problem everwhere and always.
RPM "file conflict" detection is no package management "feature" imho.
> hehe
>>
>>
>> And for extra speshul painfulness on my own aging box, libcpuinfo
>> has decided to put "pentium4" into varous arch-related configgery
>> in order to assist me with RPM configgery.
>>
> The pentium4 macros was already part of cpu-os-macros.tar.gz before
> me touching it, otherwise I wouldn't have added it.. :p
I do not use cpu-os-macros at all. I quite well know what
evil lurks within. I ripped out cpu-os-macros at my
first opportunity @rpm5.org and have continued on the path
RPMTAG_ARCH is DEAD! DEAD! DEAD!
and have negative interest in returning to paths already well known.
>>
>> You WILL got nutso if you attempt Mandriva multiarch packaging
>> policy like this in Poky imho. Cleaner/easier is to patch out
>> (or use) @redhat derived packaging instead.
> Fixing is of course preferred and often what is being done, but
> maintainers doesn't always have the necessary insight and knowledge
> to fix this, which makes it convenient to workaround it easily.
> Detection during build is useful either direction. :)
>>
>> But you are not using rpmbuild w Poky so it hardly matters.
>>
> Regards,
> Per Øyvind
> __
> RPM Package Managerhttp://rpm5.org
> Developer Communication Listrpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
2011/4/10 Jeff Johnson :
>
> On Apr 10, 2011, at 10:30 AM, Hatle, Mark wrote:
>
>>
>> Do you have a pointer or any documentation on how to use these new macros
>> and helpers?
>>
>
> The multiarch macros?
>
> I can tell you what I see:
>
> Instead of ensuring that /usr/include/*.h is independent of arch
> (this was what was done @redhat, took several months of churn-and-burn
> to get the packaging policy to the MANDATORY/ENFORCING level),
> Mandriva has chosen a VPATH-like approach in the build environment,
> where a %{_arch}-mumbo-jumbo is automagically added to rpmbuild
> CFLAGS and there's additional macro magic to rearrange %files.
Yeah, it provides support for working around it easily rather than fixing
it, but once I've fixed the multiarch check, it will be useful for detecting
offenders for fixing (rather than working around by rearranging) as well. :)
>
> Since the whole scheme is based on consistent use of %{_arch}, the
> scheme can/will depend on build system setup in some excruciatingly
> painful ways.
>
> This has just happened in Mandriva Cooker, where %{_arch}
> happened to end-up with "i586" not "i386" (the correct value afaik).
First and only time it has happened, related to me wiping away the
same macros maintained for mandriva specifically from rpm-setup,
ie. a rpm bug. ;p
hehe
>
>
> And for extra speshul painfulness on my own aging box, libcpuinfo
> has decided to put "pentium4" into varous arch-related configgery
> in order to assist me with RPM configgery.
>
The pentium4 macros was already part of cpu-os-macros.tar.gz before
me touching it, otherwise I wouldn't have added it.. :p
>
> You WILL got nutso if you attempt Mandriva multiarch packaging
> policy like this in Poky imho. Cleaner/easier is to patch out
> (or use) @redhat derived packaging instead.
Fixing is of course preferred and often what is being done, but
maintainers doesn't always have the necessary insight and knowledge
to fix this, which makes it convenient to workaround it easily.
Detection during build is useful either direction. :)
>
> But you are not using rpmbuild w Poky so it hardly matters.
>
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
On Apr 10, 2011, at 10:30 AM, Hatle, Mark wrote:
>
> Do you have a pointer or any documentation on how to use these new macros and
> helpers?
>
The multiarch macros?
I can tell you what I see:
Instead of ensuring that /usr/include/*.h is independent of arch
(this was what was done @redhat, took several months of churn-and-burn
to get the packaging policy to the MANDATORY/ENFORCING level),
Mandriva has chosen a VPATH-like approach in the build environment,
where a %{_arch}-mumbo-jumbo is automagically added to rpmbuild
CFLAGS and there's additional macro magic to rearrange %files.
Since the whole scheme is based on consistent use of %{_arch}, the
scheme can/will depend on build system setup in some excruciatingly
painful ways.
This has just happened in Mandriva Cooker, where %{_arch}
happened to end-up with "i586" not "i386" (the correct value afaik).
And for extra speshul painfulness on my own aging box, libcpuinfo
has decided to put "pentium4" into varous arch-related configgery
in order to assist me with RPM configgery.
You WILL got nutso if you attempt Mandriva multiarch packaging
policy like this in Poky imho. Cleaner/easier is to patch out
(or use) @redhat derived packaging instead.
But you are not using rpmbuild w Poky so it hardly matters.
hth
73 de Jeff
> Thanks!
>
>
> On Apr 10, 2011, at 6:53 AM, "Per Øyvind Karlsen" wrote:
>
>> RPM Package Manager, CVS Repository
>> http://rpm5.org/cvs/
>>
>>
>> Server: rpm5.org Name: Per Øyvind Karlsen
>> Root: /v/rpm/cvs Email: pkarl...@rpm5.org
>> Module: rpm Date: 10-Apr-2011 15:53:32
>> Branch: rpm-5_4 Handle: 2011041013533001
>>
>> Added files: (Branch: rpm-5_4)
>> rpm/scripts check-multiarch-files mkmultiarch
>> multiarch-dispatch multiarch-dispatch.h
>> multiarch-platform
>> Modified files: (Branch: rpm-5_4)
>> rpm CHANGES
>> rpm/macros macros.rpmbuild.in
>> rpm/scripts Makefile.am
>>
>> Log:
>> merge multiarch-utils from mandriva.
>>
>> Summary:
>> RevisionChanges Path
>> 1.3501.2.109+1 -0 rpm/CHANGES
>> 1.4.4.1 +20 -2 rpm/macros/macros.rpmbuild.in
>> 1.75.2.6+7 -1 rpm/scripts/Makefile.am
>> 1.1.2.2 +92 -0 rpm/scripts/check-multiarch-files
>> 1.1.2.2 +91 -0 rpm/scripts/mkmultiarch
>> 1.1.2.2 +31 -0 rpm/scripts/multiarch-dispatch
>> 1.1.2.2 +172 -0 rpm/scripts/multiarch-dispatch.h
>> 1.1.2.2 +14 -0 rpm/scripts/multiarch-platform
>>
>>
>> patch -p0 <<'@@ .'
>> Index: rpm/CHANGES
>>
>> $ cvs diff -u -r1.3501.2.108 -r1.3501.2.109 CHANGES
>> --- rpm/CHANGES10 Apr 2011 11:20:10 -1.3501.2.108
>> +++ rpm/CHANGES10 Apr 2011 13:53:31 -1.3501.2.109
>> @@ -1,4 +1,5 @@
>> 5.4.0 -> 5.4.1:
>> +- proyvind: merge multiarch-utils from mandriva.
>> - proyvind: macros: sync with updated python macros from mandriva.
>> - proyvind: rpmfc: add internel dep generator helper for kernel modules.
>> - provyind: kmod-deps.sh: add dependency extractor from mandriva.
>> __
> RPM Package Managerhttp://rpm5.org
> Developer Communication Listrpm-devel@rpm5.org
>
smime.p7s
Description: S/MIME cryptographic signature
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
2011/4/10 Hatle, Mark : > > Do you have a pointer or any documentation on how to use these new macros and > helpers? > > Thanks! There's a reference to a page covering it on the mandriva wiki (http://wiki.mandriva.com/en/Policies/Multiarch) stuffed into the macros. It's a bit dated though, and untill the multiarch check during build has been fixed, you won't really be able to easily spot the offenders before you hit them yourself though. I'll probably rewrite the check-multiarch perl script as part of the process fixing it and implementing build termination on positive finding though, so I'll try update and clean up the docs on it afterwards. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
Do you have a pointer or any documentation on how to use these new macros and helpers? Thanks! On Apr 10, 2011, at 6:53 AM, "Per Øyvind Karlsen" wrote: > RPM Package Manager, CVS Repository > http://rpm5.org/cvs/ > > > Server: rpm5.org Name: Per Øyvind Karlsen > Root: /v/rpm/cvs Email: pkarl...@rpm5.org > Module: rpm Date: 10-Apr-2011 15:53:32 > Branch: rpm-5_4 Handle: 2011041013533001 > > Added files: (Branch: rpm-5_4) >rpm/scripts check-multiarch-files mkmultiarch >multiarch-dispatch multiarch-dispatch.h >multiarch-platform > Modified files: (Branch: rpm-5_4) >rpm CHANGES >rpm/macros macros.rpmbuild.in >rpm/scripts Makefile.am > > Log: >merge multiarch-utils from mandriva. > > Summary: >RevisionChanges Path >1.3501.2.109+1 -0 rpm/CHANGES >1.4.4.1 +20 -2 rpm/macros/macros.rpmbuild.in >1.75.2.6+7 -1 rpm/scripts/Makefile.am >1.1.2.2 +92 -0 rpm/scripts/check-multiarch-files >1.1.2.2 +91 -0 rpm/scripts/mkmultiarch >1.1.2.2 +31 -0 rpm/scripts/multiarch-dispatch >1.1.2.2 +172 -0 rpm/scripts/multiarch-dispatch.h >1.1.2.2 +14 -0 rpm/scripts/multiarch-platform > > > patch -p0 <<'@@ .' > Index: rpm/CHANGES > > $ cvs diff -u -r1.3501.2.108 -r1.3501.2.109 CHANGES > --- rpm/CHANGES10 Apr 2011 11:20:10 -1.3501.2.108 > +++ rpm/CHANGES10 Apr 2011 13:53:31 -1.3501.2.109 > @@ -1,4 +1,5 @@ > 5.4.0 -> 5.4.1: > +- proyvind: merge multiarch-utils from mandriva. > - proyvind: macros: sync with updated python macros from mandriva. > - proyvind: rpmfc: add internel dep generator helper for kernel modules. > - provyind: kmod-deps.sh: add dependency extractor from mandriva. >
