SCIENTIFIC-LINUX-DEVEL Archives

September 2007

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Tue, 18 Sep 2007 13:54:34 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (118 lines)
Hi Jan,
Just because we didn't reply to this, didn't mean we didn't read it and are 
looking at it.
We've also found that the pam packages are this way too.  We're in the process 
of rebuilding them.
The two questions are,
Where do we put them when we've recompiled them?  In the errata?  They will 
definatly make it into SL 5.1.

and Is there a nice way to check all these packages?  I'd hate to find them all 
one by one as we get errors.

Troy

Jan Iven wrote:
> Dear all,
>  we have had some trouble trying to install both the i386 and x86_64 
> flavours of libgcj-3.4.6-8 on SL4. Unless this is done at (Kickstart) 
> install time, RPM reports file-level conflicts for the man pages in this 
> case:
> 
> ...
>   file /usr/share/man/man1/fastjar.1.gz from install of libgcj-3.4.6-8 
> conflicts with file from package libgcj-3.4.6-8
> ...
> 
> The reason for this appears to be (both RPMs rotten multilib 
> implementation and) the fact that the man pages are not identical 
> between i386 and x86_64, so that the 
> "these-files-are-the-same-so-we-can-silently-ignore-the-conflict" RPM 
> logic doesn't kick in:
> 
> $ rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}:\n[ 
> %{FILENAMES}\t %{FILEMD5S}\n]\n' libgcj | grep 
> '^lib\|/usr/share/man/man1/fastjar.1.gz'
> libgcj-3.4.6-8.i386:
>   /usr/share/man/man1/fastjar.1.gz       631cf1102cf16d285f6d36b45e8fffe8
> libgcj-3.4.6-8.x86_64:
>   /usr/share/man/man1/fastjar.1.gz       7448711dd9efa98ff8ac7709df6b7a4a
> 
> Whereas on a "real" TUV4.5 machine, we get
> libgcj-3.4.6-8.i386:
>   /usr/share/man/man1/fastjar.1.gz       20048e9160b185a6d3b1b6bf2df90949
> libgcj-3.4.6-8.x86_64:
>   /usr/share/man/man1/fastjar.1.gz       20048e9160b185a6d3b1b6bf2df90949
> 
> 
> The difference between these files on SLC4 is
> < .TH JAR 1 "2007-05-03" "gcc-3.4.6" "GNU"
> ---
>  > .TH JAR 1 "2007-05-07" "gcc-3.4.6" "GNU"
> 
> i.e. they got rebuilt on a different day, and unfortunately decided to 
> record the fact in the man page.
> 
> Similarly, fontconfig-2.2.3-7.{i386,x86_64} has in 
> usr/share/man/man5/fonts-conf.5.gz:
> 
> < .TH "FONTS-CONF" "5" "17 February 2005" "" ""
> ---
>  > .TH "FONTS-CONF" "5" "14 March 2005" "" ""
> 
> TUV in both cases has the same file/date - presumably they got rebuild 
> on the same day.
> 
> 
> Would it perhaps be possible to rebuild these two packages? - I guess 
> they will cause trouble for others in the future as well...
> 
> 
> fontconfig-2.2.3-7:
> < /usr/share/man/man5/fonts-conf.5.gz    1d94a3481d2ee2894cead03cf82a02e6
> ---
>> /usr/share/man/man5/fonts-conf.5.gz    c895dcf301435cdb0f8ab38de027f87a
> 
> libgcj-3.4.6-8:
> < /usr/share/man/man1/fastjar.1.gz       631cf1102cf16d285f6d36b45e8fffe8
> < /usr/share/man/man1/gij.1.gz   bef80782f78e4385e3eb9cd89432e563
> < /usr/share/man/man1/grepjar.1.gz       4e98e29086af1a753c6cddf5bbf47462
> < /usr/share/man/man1/grmic.1.gz         2bc72c4ef345ea42778f6e7aae82ae3f
> < /usr/share/man/man1/grmiregistry.1.gz  5fc12c7c062aef2ba079f78982f15d14
> < /usr/share/man/man1/jv-convert.1.gz    cafb9362ce42ef95a39f4aeb34dc2875
> ---
>> /usr/share/man/man1/fastjar.1.gz       7448711dd9efa98ff8ac7709df6b7a4a
>> /usr/share/man/man1/gij.1.gz   d4a0193bff8c5a71e8b72b66b554617d
>> /usr/share/man/man1/grepjar.1.gz       b1cc08d598a3f75ebc3196bdcf584c83
>> /usr/share/man/man1/grmic.1.gz         d68d2326078935a9497989fdd2b924ee
>> /usr/share/man/man1/grmiregistry.1.gz  77159807060980a1923b68479ff2479e
>> /usr/share/man/man1/jv-convert.1.gz    833630556953aa6c17d304214eab1db8
> 
> 
> 
> TIA
> Jan
> 
> 
> PS: red herring ahead:
> 
> Such differences can also be due to the fact that "compressed" files 
> carry a timestamp by default, unless some care is taken to avoid this. 
> http://www.redhat.com/magazine/009jul05/features/multilib/ has some more 
> insights into this:
> 
>> If the 32-bit package is built just one second later than the 64-bit 
>> package,
>  > the timestamp in the compressed file will be different in each package.
> 
> Which is why rpm-build's "brp-compress" script uses
> COMPRESS="gzip -9 -n"
> since the early days of SLC41..


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________

ATOM RSS1 RSS2