Hello,
Is there a problem with others files as well ?
Anyway, it looks like I have trouble with most/all of the OSCAR rpms.
I have errors like those ones :
rpm -Uvh packages/oda/RPMS/oda-1.30-1.noarch.rpm
erreur: packages/oda/RPMS/oda-1.30-1.noarch.rpm: Somme MD5: BAD
Expected(177d23138dbab9b60b6c90bb829fc1c3) !=
(507ef1c3783c7fe83b0d6c8109d51e18)
erreur: packages/oda/RPMS/oda-1.30-1.noarch.rpm ne peut être installé
rpm -Uvh share/prereqs/update-rpms/RPMS/update-rpms-1.1.10-16.noarch.rpm
erreur: share/prereqs/update-rpms/RPMS/update-rpms-1.1.10-16.noarch.rpm:
Somme MD5: BAD Expected(6e728fa68b2c1c24d5b32289f8c8d4a1) !=
(05bfc44a8ad8845a66dc9ab7a52d9d21)
erreur: share/prereqs/update-rpms/RPMS/update-rpms-1.1.10-16.noarch.rpm
ne peut être installé
(md5sum error, RPM can not be installed, etc.)
...
I'm using Fedora Core 2 and RPM 4.3.1
OSCAR HEAD from subversion
Subversion version : 1.0.6
svn proplist packages/oda/RPMS/oda-1.30-1.noarch.rpm
Properties on 'packages/oda/RPMS/oda-1.30-1.noarch.rpm':
svn:keywords
svn:eol-style
I think that because those are binary files, it should be :
svn:mime-type
(at least that's what I have in our subversion repository).
Has others experienced those problems as well ?
Ben
* Jeff Squyres <[EMAIL PROTECTED]> [04-08-21 18:45]:
> On Aug 19, 2004, at 11:38 PM, Thomas Naughton wrote:
>
> >After the call on monday I tried to build the 'oscarpkg-howto' so I
> >could
> >post a copy on the web. I soon realized that the make was tanking and
> >put
> >it aside for lack of time.
> >
> >Tonight I realized it was b/c the figs/*.png files were in ASCII.
> >Instead
> >of figuring out how to edit properties, I just copied some files I had
> >from
> >a previous CVS checkout and all built properly.
>
> As you mentioned below, yes, I did fix this on Monday.
>
> >Then I did a 'svn ci' (and a 'svn commit'). But I didn't get any
> >output
> >and wasn't prompted to enter a log message.
>
> If you didn't get prompted for anything, what happened?
>
> >However when I did a fresh
> >checkout to see if things were actually there, the properties had an
> >updated timestamp (Thu, 19 Aug 2004).
> >
> >I'm not sure if I fixed things or if this was Jeff's fix from Monday,
> >
> >-----------------------------------------------------------------------
> >-
> > r2583 | jsquyres | 2004-08-16 15:26:19 -0400 (Mon, 16 Aug 2004) | 2
> >lines
> >
> > Previous png files were imported incorrectly (ASCII). Fixed.
> >
> >If indeed this was fixed on Monday, what should I have done to bring my
> >previous checkout up to date? 'svn update' didn't seem to work.
>
> I think that this may actually be a SVN bug -- I meant to send
> something to the list about it (sorry). I'll explain more below, but I
> found that the following worked:
>
> cd oscar (your SVN top-level dir)
> rm -rf docs
> svn up
>
> That is, remove all the docs and then re-check them out. More
> specifically, you can be a little more fine-grained about your approach
> (e.g., perhaps just remove the howto directory), but removing an entire
> *directory* is important here. Alternatively, you can update the
> directory to a different revision (one that changes all the graphics)
> and then update it to the head again, and it should have the same
> effect.
>
> What I'm pretty sure is happening is that SVN is *not* re-downloading
> the files in binary mode when the properties are updated. This is
> because SVN keeps a copy of the file cached/hidden in the .svn
> directory so that you can do things like "svn diff" and "svn revert"
> without requiring network access. So when we updated the properties,
> if you just "rm foo.png; svn up", it'll just copy over the cached file
> -- which was probably downloaded in ASCII mode. So you really need to
> ditch the cached copy and force SVN to re-download in binary mode. The
> two ways to do this:
>
> - remove the entire directory where the file was (including its .svn
> meta directory) and force a re-download of everything
> - svn up to a different revision that changes the files in question
> (i.e., re-download to the cache) and then svn up to the head again
>
> I *think* that this is what is happening, but I didn't get a chance to
> test this theory.
>
> >Also, do
> >property edits have associated log msgs?
>
> Yes, they do. IIRC, that log message is from my commit of the property
> changes.
>
> *Hypothetically*, I could have just changed the properties and then
> forced a re-download and all would have been well (i.e., I think that
> SVN always stores things in binary mode, regardless of
> ascii/binary...?). But I didn't realize this at the time, so I didn't
> test it -- and therefore committed both corrected PNG files and new
> properties.
>
> I'l try this out in a demo SVN repository (we have one for such
> purposes ;-) ), and see what happens.
>
> --
> {+} Jeff Squyres
> {+} [EMAIL PROTECTED]
> {+} http://www.lam-mpi.org/
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Oscar-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/oscar-devel
--
Benoit des Ligneris Ph. D.
President de Revolution Linux http://www.revolutionlinux.com/
OSCAR Chair http://oscar.openclustergroup.org/
Chef de projet EduLinux http://www.edulinux.org/
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
