Bug 483301

New upstream release. I removed the patches that are no longer necessary.

Spec URL: http://oget.fedorapeople.org/review/muse.spec
SRPM URL: http://oget.fedorapeople.org/review/muse-1.0-0.1.rc1.fc10.src.rpm

Some comments:

MUSTFIX:
* AutoReqProv:   no
This disables rpm's automatic dependency tracking and therefore is strongly frowned upon.

* Epoch: 1
Setting epoch to != 0 for a package to be included into Fedora is hardly useful.

SHOULD:
* Building on x86_64 emits serious warning, e.g. this

memory.h: In member function 'void* Pool::alloc(size_t)':
memory.h:55: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
memory.h: In member function 'void Pool::free(void*, size_t)':
memory.h:73: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'

In many cases, this kind of warnings are the origin of mal-functions.

(In reply to comment #2)
> Some comments:
> 
> MUSTFIX:
> * AutoReqProv:   no
> This disables rpm's automatic dependency tracking and therefore is strongly
> frowned upon.
> 
> * Epoch: 1
> Setting epoch to != 0 for a package to be included into Fedora is hardly
> useful.
> 
As I wrote above about Epoch and as a comment in the SPEC file about AutoReqProv, there are valid reasons for using both.

> SHOULD:
> * Building on x86_64 emits serious warning, e.g. this
> 
> memory.h: In member function 'void* Pool::alloc(size_t)':
> memory.h:55: warning: format '%d' expects type 'int', but argument 2 has type
> 'size_t'
> memory.h: In member function 'void Pool::free(void*, size_t)':
> memory.h:73: warning: format '%d' expects type 'int', but argument 2 has type
> 'size_t'
> 
> In many cases, this kind of warnings are the origin of mal-functions.

I use the software. I didn't encounter any problems (yet). But I'll see what we can do.


Finally, I made a request to you at RPMFusion. I am re-iterating it: Please, pretty please, do not write in my bugs.

(In reply to comment #3)
> (In reply to comment #2)
>
> Finally, I made a request to you at RPMFusion. I am re-iterating it: Please,
> pretty please, do not write in my bugs.
OK, I am closing this PR.

I put so much time into this package. I am still actively working on it and I am in contact with upstream and helping them fixing things out. There are people waiting for this package.

Who the piteous are you to close my bug??

This is vile, disrespectful, inconsiderate and ignorant.

One more time: PLEASE DO NOT POST IN MY BUGS!

(In reply to comment #5)
> I put so much time into this package. I am still actively working on it and I
> am in contact with upstream and helping them fixing things out. There are
> people waiting for this package.

I rejected your package because you made it clear you are either unwilling or unable to make it compliant to the Fedora packaging standards.

PLEASE


DO


NOT


POST


IN


MY


BUGS


!!!!

(In reply to comment #7)
Stop trolling.



#include <stdio.h>

int main()
{
  size_t x = 0x100000000;

  printf( "%d\n", x);
  printf( "%zd\n", x);
}

(In reply to comment #7)
> > memory.h:73: warning: format '%d' expects type 'int', but argument 2 has type
> > 'size_t'
> > 
> > In many cases, this kind of warnings are the origin of mal-functions.
> 
> I use the software. I didn't encounter any problems (yet). But I'll see
> what we can do.

Let me demonstrate the seriousness of this bug:

Compile this code on x86_64:

#include <stdio.h>
int main()
{
  size_t x = 0x100000000;

  printf( "%d\n", x);
  printf( "%zd\n", x);
}

# gcc -Wall -O2 -o foo foo.c
foo.c: In function ‘main’:
foo.c:7: warning: format ‘%d’ expects type ‘int’, but argument 2 has type

Then run it:
./foo
0
4294967296

=> Mal-function

PLEASE


DO


NOT


POST


IN


MY


BUGS


!!!!

Reopening, invalidly closed.

FYI, a good solution to get rid of unwanted Provides for plugins and only those is the one we're using in XChat:

# do not Provide plugins .so
%define _use_internal_dependency_generator 0
%{__cat} << \EOF > %{name}.prov
#!%{_buildshell}
%{__grep} -v %{_docdir} - | %{__find_provides} $* \
        | %{__sed} '/\.so$/d'
EOF
%define __find_provides %{_builddir}/%{name}-%{version}/%{name}.prov
%{__chmod} +x %{__find_provides}

reclosing, rest in peace.

*** This bug has been marked as a duplicate of bug 484591 ***

Orcan, it would be useful, if you would accept input from packagers, even
if you don't like them e.g. on personal base or caused by their input. From
my point of view of being a provenpackager (ueberpackager), comment #2 is 
is useful and should be followed (the Epoch thing can be discussed maybe).

With respect to all what happened unil now: Valid input needs to be taken,
handled and/or discussed. If such things are refused without a valid reason,
rejecting a package review request seems to be pretty okay for me. Packaging
is not that easy as it maybe seems or some people want to have it.

Dear Robert,
I would like you to analyze the progression of this situation rather than looking at it as a whole.

Please go ahead and have a look at my SPEC file, and comment #1. I properly stated why I used Epoch:1 and AutoReqProv:no. I accept that I may have made a wrong choice to handle them. Then, please read comment #2. I do NOT consider it useful to explain what I did wrong. Saying "this and this is not useful" and disregarding my comments about both issues do not help me correct myself. If you want a useful comment, have a look at comment #11 and bug #484591's comment #3.

Then, please read my answer, comment #3 on this bug. Do you think that I am "refusing things without a valid reason"? Again, please read comment #3 once more and explain me how you arrive at this conclusion. This is the point where the disordered person closed my bug.



Once, I nicely told this person to not follow me around and post on my bugs. He does nothing but gets in my nerves. 

If you want to know where this happened, please have a look at this link (comments #2 and #3):
https://bugzilla.rpmfusion.org/show_bug.cgi?id=195
Otherwise, please proceed to the next paragraph. I apologize to bring over a conversation that has nothing to do with Fedora, to Fedora.

Now, knowing that I do NOT want him around me (since the information he provides has been wrong in certain cases if you saw that in the above link, plus his repulsive attitude that has been confirmed by many people in Fedora, is offensive), he picks my bug among 750+ other open review requests and posts here. This has no other purpose than blowing my fuse.


I'm cutting this here. If majority of our community thinks that my behavior is unacceptable while his is appropriate (including closing my bug), then perhaps Fedora is not the place where I belong.

Regards,
Orcan

I won't go into that more. You know my points and for the rest I mostly
agree with Hans until now (especially when looking to bug #484591). From
the technical point, Ralf pointed same things out as Hans did (ignoring
epoch difference). Hans used a few more words, but nothing else. Finally,
no need for me and you to tell things twice, my thinking is very closed 
to Hans' ones until now.

Possibilities to filter out unwanted dependencies by not using AutoReqProv:
are on the Fedora wiki for a long time now. Ever consumed that Guideline
before this bug report? Seemingly not and yes, you were not pointed to it
in this bug report. But a thing which could get improved on both sides...

Ralf is maybe not liked that much by multiple/several persons or whatelse,
but I'm pretty sure, if you would asked him nicely, would have provided you
a patch solving the 64 bit things (even if i's just debug stuff) which you
could send to upstream.

(In reply to comment #14)
> From
> my point of view of being a provenpackager (ueberpackager), comment #2 is 
> is useful and should be followed (the Epoch thing can be discussed maybe).

Sorry for being late on commenting on this (dues to filtering problems I was not seeing email from bugzilla@redhat). 

Please consider keeping Epoch:1. 

This package is migrating from Planet CCRMA to Fedora. If the epoch is dropped current Planet CCRMA users will not see upgrades coming from Fedora, which would be really bad. _I_ am responsible for the epoch bump which happened a long time ago in the Planet CCRMA repositories. I can go to my logs if needed to try to find out why I did that, I take epochs seriously.

Fernando,
The bug was reopened in bug# 484591 because of some, uhm... some issues and got accepted.

We kept the Epoch: 1 as is, so no need to worry.

Additionally, I included you as the co-owner of this package. You should have CVS access to it now.

Here is the web interface for CVS browsing:
   http://cvs.fedora.redhat.com/viewvc/devel/muse/

and here is the package database info:
   https://admin.fedoraproject.org/pkgdb/packages/name/muse