Bug 483301 - Review Request: muse - Midi/Audio Music Sequencer
Review Request: muse - Midi/Audio Music Sequencer
Status: CLOSED DUPLICATE of bug 484591
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-30 14:46 EST by Orcan Ogetbil
Modified: 2009-02-25 23:16 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-09 20:26:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orcan Ogetbil 2009-01-30 14:46:14 EST
Spec URL: http://oget.fedorapeople.org/review/muse.spec
SRPM URL: http://oget.fedorapeople.org/review/muse-0.9-3.fc10.src.rpm
Description: 
MusE is a MIDI/Audio sequencer with recording and editing capabilities. It can
perform audio effects like chorus/flanger in realtime via LASH and it supports
Jack and ALSA interfaces. MusE aims to be a complete multitrack virtual studio
for Linux.

rpmlint is silent.

Epoch: 1 is there for PlanetCCRMA compatibility. See AudioCreation SIG wiki for informations about PlanetCCRMA integration:
https://fedoraproject.org/wiki/AudioCreation
Comment 1 Orcan Ogetbil 2009-02-07 22:13:42 EST
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
Comment 2 Ralf Corsepius 2009-02-08 04:06:28 EST
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.
Comment 3 Orcan Ogetbil 2009-02-08 11:33:29 EST
(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.
Comment 4 Ralf Corsepius 2009-02-08 12:35:26 EST
(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.
Comment 5 Orcan Ogetbil 2009-02-08 15:04:45 EST
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!
Comment 6 Ralf Corsepius 2009-02-08 15:11:15 EST
(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.
Comment 7 Orcan Ogetbil 2009-02-08 15:18:37 EST
PLEASE


DO


NOT


POST


IN


MY


BUGS


!!!!
Comment 8 Ralf Corsepius 2009-02-08 15:23:44 EST
(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
Comment 9 Orcan Ogetbil 2009-02-08 15:30:03 EST
PLEASE


DO


NOT


POST


IN


MY


BUGS


!!!!
Comment 10 Kevin Kofler 2009-02-09 10:35:00 EST
Reopening, invalidly closed.
Comment 11 Kevin Kofler 2009-02-09 10:37:20 EST
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}
Comment 12 Rex Dieter 2009-02-09 12:27:40 EST
reclosing, rest in peace.
Comment 13 Jens Petersen 2009-02-09 20:26:05 EST

*** This bug has been marked as a duplicate of bug 484591 ***
Comment 14 Robert Scheck 2009-02-11 18:37:56 EST
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.
Comment 15 Orcan Ogetbil 2009-02-11 21:08:45 EST
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
Comment 16 Robert Scheck 2009-02-12 03:00:55 EST
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.
Comment 17 Fernando Lopez-Lezcano 2009-02-25 21:00:47 EST
(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.
Comment 18 Orcan Ogetbil 2009-02-25 23:16:48 EST
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

Note You need to log in before you can comment on or make changes to this bug.