(In reply to comment #0)
> This Review Request have been opened before (bug #483301) but someone with
> personality issues have closed that bug. Let us hope he doesn't taint this one.
Orcan, I appreciate your Fedora work, and I can understand that you have issues with a certain person. But you *MUST* stop offending other Fedora contributors. Stop writing: "please do not post in my bugs" and certainly don't accuse other contributors of "personality issues". You may disagree on technical grounds with Ralf and so do others of us from time to time. But *YOUR* behaviour here is completely unacceptable, you need to *STOP* this immediately!
There is a huge difference between discussing about technical issues and sometimes being rather stubborn about them (Ralf) and between anti-social behaviour. it is *YOU* who is way out of line here not Ralf.

With that said, and hopefully made very clear! I would like to review this package as I think it is great that someone is working on moving packages from planetccrma into Fedora proper.
The Epoch is fine, but with the other 2 issues I have to side with Ralf, using "AutoProv: no" is not acceptable, your package will miss essential requires and adding them manually is error prone and will break when the soname's of libraries you use change (and you do a rebuild). The correct solution here is to use filtering of the generated provides as explained in the previous review request.
Also the warnings are serious and need fixing, Ralf has already explained how (replace "%d" with "%zd"), let me know if there are other warnings which you need help fixing.
Can you please do a new revision with these 2 issues fixed? then I'll do a full review.

(Note that I mailed to Orcan privately...)
(In reply to comment #3)
> The correct solution here is
> to use filtering of the generated provides as explained in the previous review
> request.
- As Kevin said in the comment 4 (and as I reported on the bug
484837), the filtering method proposed on the previous review request
is not correct on x86_64
(In reply to comment #4)
> Oops, the solution I provided for filtering is faulty, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=484837
>
> %{__sed} '/\.so$/d' needs to be: %{__sed} '/\.so\(()(64bit)\)\?$/d'
- This time it is not correct on i386.
> Also the warnings are serious and need fixing, Ralf has already explained how
> (replace "%d" with "%zd"), let me know if there are other warnings which you
> need help fixing.
- Would you explain why you "particularly" mention these warnings?
These warnings all comes from (f)printf with passing incorrect format,
however I have already seen in other review requests that
many warnings which seemed more and more critical than this
(like one related to implicit function declaration you mentioned
before) were just ignored.
Of course I admit that fixing these warnings are desirable, however
I am against making these warning the "blocker" for this review
request.
If you surely think these warnings are blockers, would you propose
fedora-packaging-list about what warnings should be treated as
review blockers?
It is really appreciated because I had repeatedly been asked
"is it a blocker??"

(In reply to comment #5)
> > Also the warnings are serious and need fixing, Ralf has already explained how
> > (replace "%d" with "%zd"), let me know if there are other warnings which you
> > need help fixing.
>
> - Would you explain why you "particularly" mention these warnings?
> These warnings all comes from (f)printf with passing incorrect format,
> however I have already seen in other review requests that
> many warnings which seemed more and more critical than this
> (like one related to implicit function declaration you mentioned
> before) were just ignored.
> Of course I admit that fixing these warnings are desirable, however
> I am against making these warning the "blocker" for this review
> request.
> If you surely think these warnings are blockers, would you propose
> fedora-packaging-list about what warnings should be treated as
> review blockers?
> It is really appreciated because I had repeatedly been asked
> "is it a blocker??"
As Ralf has demonstrated these warnings are usually a real issue, which only shows on 64 bit systems. But usually these are in debug printf's and thus quite often people don't care about fixing them. I agree this is not something which we normally block reviews on. So I wont do that in this case either. Still this something which really should be fixed, so consider this a should fix item.

(In reply to comment #6)
> As Ralf has demonstrated these warnings are usually a real issue, which only
> shows on 64 bit systems. But usually these are in debug printf's and thus quite
> often people don't care about fixing them. I agree this is not something which
> we normally block reviews on. So I wont do that in this case either. Still this
> something which really should be fixed, so consider this a should fix item.
That's why I had labeled it "SHOULD".
It's a classic of the 32bit->64bit portability problems.
It is broken code which is guaranteed to be non-functional under certain conditions. The only question is when this bug will hit, not if this will this will hit.
Due to the nature of size_t, such kind of bugs show when some variable will exceed sizeof(int) (4GB) or when some computations will be performed on size_t's.
The former will usually only cause visible problems in "big use-cases", while the later usually shows as "corrupt output".

(In reply to comment #7)
> > > %{__sed} '/\.so$/d' needs to be: %{__sed} '/\.so\(()(64bit)\)\?$/d'
> > - This time it is not correct on i386.
>
> It is, see bug 484837.
Yes, I missed the question mark.
By the way this package does no build on dist-f11 (koji)
One issue is g++44 issue, however there is another.
configure says:
-----------------------------------------------
checking for DocBook V4.1...
no
configure: WARNING: DocBook 4.1 DTD not found or not usable - documentation will not be built
-----------------------------------------------
config.log says:
-----------------------------------------------
configure:19341: checking for DocBook V4.1
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:8:19:E: "X21B6" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:9:19:E: "X21B7" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:10:17:E: "X21D3" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:11:18:E: "X21CA" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:12:18:E: "X21C3" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:13:18:E: "X21C2" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:14:18:E: "X21DA" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:15:17:E: "X219E" is not a function name
onsgmls:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-42.fc11/ent/iso-amsa.ent:16:18:E: "X21C7" is not a function name
........................
........................
-------------------------------------------------
I am not sure what is causing this, because
- with dist-f10-updates-candidate, checking for DocBook V4.1...
returns yes
- My local build passes this point

Thank you Hans, for your concern. But I do have objections/corrections:
(In reply to comment #2)
> Orcan, I appreciate your Fedora work, and I can understand that you have issues
> with a certain person.
I am trying to be a productive member for our community. Having started about 4 months ago (thanks to Mamoru), I made about 10 packages here at Fedora and a few at RPMfusion. I have done more than 40 package reviews and I try to participate on certain SIGs. So, you're welcome as every other community member is.
That being said, I have to make it clear that it is not me who has issues with a certain person.
> But you *MUST* stop offending other Fedora contributors.
> Stop writing: "please do not post in my bugs" and certainly don't accuse other
> contributors of "personality issues".
This is a free world, and I have all the right to make such "requests". The keyword here is "requests" which should not be confused with "orders".
I did not accuse anyone with anything. Having a personality issue is not a crime. It is a psychological disorder. One can not accuse another with a disorder.
I just stated a fact.
> You may disagree on technical grounds
> with Ralf and so do others of us from time to time. But *YOUR* behaviour here
> is completely unacceptable, you need to *STOP* this immediately!
>
> There is a huge difference between discussing about technical issues and
> sometimes being rather stubborn about them (Ralf) and between anti-social
> behaviour. it is *YOU* who is way out of line here not Ralf.
Am I anti-social? I am the one who is in contact with end-users. I am the one who is in contact with upstream developers. I am the one who is in contact with fellow contributors, minus those who have certain disorders.
Well, if excluding a few people from my contact list to keep myself sane and productive is considered anti-socialism, then I'm anti-social. And Fedora does not exclude anti-social people like me. At least, as far as I know, there is no guideline against them.
Anti-social me has had conversations with many people at #fedora-devel and learned about the enemies this disordered person made in our community. Certainly, I was not his first target. But I do hope that I will be the last.
If you still think that my behavior is unacceptable, please allow me some time to consider for myself whether it is worth to try to change myself in these matters. This is what I am and what I have been.
I would like to thank to everyone who have personally emailed me or messaged me by other means. I have replied to some of these messages and I will reply to the remaining ones ASAP.
About the package... I don't know... I do feel discouraged... Maybe I need some more time.

muse-1.0-0.4.rc1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update muse'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2070