Bug 529496

Summary: Review Request: libmtag - An advanced C music tagging library with a simple API
Product: [Fedora] Fedora Reporter: Felipe Contreras <felipe.contreras>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: fedora-package-review, notting, rc040203
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-06 06:28:36 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Felipe Contreras 2009-10-17 12:48:39 EDT
Spec URL: http://people.freedesktop.org/~felipec/fedora/libmtag.spec
SRPM URL: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.2-1.fc11.src.rpm
Description: libmtag is essentially wrapping the taglib API into a useful C library, plus providing a bit more functionality.
Comment 1 Felipe Contreras 2009-10-17 12:52:03 EDT
This is my first package, requesting a sponsor.
Comment 2 Michael Schwendt 2009-10-25 16:36:53 EDT
> Summary:        An advanced C music tagging library with a simple API

It's widely accepted practise to omit leading articles, such as "An" and "A" to shorten summaries even further:

  Summary: Advanced C music tagging library with a simple API

That also looks better when displayed during installation.


> Source0:        http://libmtag.googlecode.com/files/%{name}-%{version}.tar.gz

0.3.2 is not available there. 404 Not Found.


* Spelling errors:  sed -i 's!excercise!exercise!g' libmtag.spec


> License:        LGPLv2

You should include the LGPL text in your tarball and confirm the licensing in the source files:
https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text


> Requires: taglib

Found in the pkgconfig file. And this dependency is not true. It would only be true if you had a build-time dependency on taglib headers or static library.


> mtag.cpp

Is there any reason why you include C headers instead of their Standard C++ Library counterparts, such as <cstdio> and <cstring>?


* Please also take a look at the compiler warnings related to mtag.cpp and mtag.c. Currently:

mtag.cpp:38: warning: suggest parentheses around assignment used as truth value
mtag.cpp:79: warning: suggest parentheses around assignment used as truth value
mtag.cpp:95: warning: suggest parentheses around assignment used as truth value
mtag.cpp:113: warning: suggest parentheses around assignment used as truth value
mtag.cpp:126: warning: no return statement in function returning non-void
mtag.cpp:136: warning: suggest parentheses around assignment used as truth value
mtag.cpp:143: warning: suggest parentheses around assignment used as truth value
mtag.cpp:150: warning: suggest parentheses around assignment used as truth value
mtag.cpp:310: warning: suggest parentheses around assignment used as truth value
mtag.cpp:331: warning: suggest parentheses around assignment used as truth value
mtag.c:179: warning: implicit declaration of function 'basename'
mtag.c:179: warning: format '%s' expects type 'char *', but argument 2 has type 'int'


> libmtag-tools

$ mtag
Error: Bad arguments: No filename specified

$ mtag --help
mtag: unrecognized option '--help'
Error: Bad arguments: No filename specified

$ mtag test1.mp3 
Error: Bad arguments: No filename specified

$ mtag test1.ogg
Error: Bad arguments: No filename specified


Without the README (which you don't include in the package), the mtag tool is not very helpful about telling how to use it.

Run "rpmlint" on all the packages (src.rpm and built rpms).
https://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint

It would have warned about lack of documentation files. ;)
Comment 3 Felipe Contreras 2009-10-26 10:30:47 EDT
(In reply to comment #2)
> > Summary:        An advanced C music tagging library with a simple API
> 
> It's widely accepted practise to omit leading articles, such as "An" and "A" to
> shorten summaries even further:
> 
>   Summary: Advanced C music tagging library with a simple API
> 
> That also looks better when displayed during installation.

Ok.

> > Source0:        http://libmtag.googlecode.com/files/%{name}-%{version}.tar.gz
> 
> 0.3.2 is not available there. 404 Not Found.

Yes, I want to release 0.3.2 after fixing all the issues mentioned here.

> * Spelling errors:  sed -i 's!excercise!exercise!g' libmtag.spec

Ooops. Fixed.

> > License:        LGPLv2
> 
> You should include the LGPL text in your tarball and confirm the licensing in
> the source files:
> https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text

Sure, I can put the license in the COPYING file. But I don't see anything in the guidelines regarding the source files.

> > Requires: taglib
> 
> Found in the pkgconfig file. And this dependency is not true. It would only be
> true if you had a build-time dependency on taglib headers or static library.

Strange, I don't have that in my .spec file. Maybe I send an outdated one.

> > mtag.cpp
> 
> Is there any reason why you include C headers instead of their Standard C++
> Library counterparts, such as <cstdio> and <cstring>?

No. I'm not familiar with cstdio and cstring so I don't know why I should include them. libmtag is a C library, and C++ is used only when necessary.

> * Please also take a look at the compiler warnings related to mtag.cpp and
> mtag.c. Currently:
> 
> mtag.cpp:38: warning: suggest parentheses around assignment used as truth value
> mtag.cpp:79: warning: suggest parentheses around assignment used as truth value
> mtag.cpp:95: warning: suggest parentheses around assignment used as truth value
> mtag.cpp:113: warning: suggest parentheses around assignment used as truth
> value
> mtag.cpp:126: warning: no return statement in function returning non-void
> mtag.cpp:136: warning: suggest parentheses around assignment used as truth
> value
> mtag.cpp:143: warning: suggest parentheses around assignment used as truth
> value
> mtag.cpp:150: warning: suggest parentheses around assignment used as truth
> value
> mtag.cpp:310: warning: suggest parentheses around assignment used as truth
> value
> mtag.cpp:331: warning: suggest parentheses around assignment used as truth
> value
> mtag.c:179: warning: implicit declaration of function 'basename'
> mtag.c:179: warning: format '%s' expects type 'char *', but argument 2 has type
> 'int'

I didn't get those warnings, but I'll changes the CFLAGS to catch them in the future, and I'll fix them.

> > libmtag-tools
> 
> $ mtag
> Error: Bad arguments: No filename specified
> 
> $ mtag --help
> mtag: unrecognized option '--help'
> Error: Bad arguments: No filename specified
> 
> $ mtag test1.mp3 
> Error: Bad arguments: No filename specified
> 
> $ mtag test1.ogg
> Error: Bad arguments: No filename specified

I'll improve the help for that app.

> Without the README (which you don't include in the package), the mtag tool is
> not very helpful about telling how to use it.
> 
> Run "rpmlint" on all the packages (src.rpm and built rpms).
> https://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint

I did.

> It would have warned about lack of documentation files. ;)  

Warnings not always need to be fixed.

Thanks for the review. I'll come up with a second version soon.
Comment 4 Ralf Corsepius 2009-10-26 10:54:53 EDT
(In reply to comment #3)

> > > License:        LGPLv2
> > 
> > You should include the LGPL text in your tarball and confirm the licensing in
> > the source files:
> > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text
> 
> Sure, I can put the license in the COPYING file. But I don't see anything in
> the guidelines regarding the source files.

This is not the FPG's business - It's the GPL which asks _upstream_'s to
include a copy of the GPL in _their_ tarball. With you seemingly being "upstream", you in your role as upstream - should include it.
Comment 5 Felipe Contreras 2009-10-26 11:22:55 EDT
(In reply to comment #4)
> (In reply to comment #3)
> 
> > > > License:        LGPLv2
> > > 
> > > You should include the LGPL text in your tarball and confirm the licensing in
> > > the source files:
> > > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text
> > 
> > Sure, I can put the license in the COPYING file. But I don't see anything in
> > the guidelines regarding the source files.
> 
> This is not the FPG's business - It's the GPL which asks _upstream_'s to
> include a copy of the GPL in _their_ tarball. With you seemingly being
> "upstream", you in your role as upstream - should include it.  

That's the COPYING file, which I already said I'm going to include. The question was about source-code files. In Michael's words: "confirm the licensing in
the source files".
Comment 6 Ralf Corsepius 2009-10-26 12:17:52 EDT
(In reply to comment #5)

> That's the COPYING file, which I already said I'm going to include.
Then please do so now.

In other words: keep your upstream and Fedora packager's role separate.
I.e. first release a tarball, then package this tarball for Fedora, not vice versa.

> The
> question was about source-code files. In Michael's words: "confirm the
> licensing in the source files".  

I can only guess what he meant. My guess would be, he is asking you to add a copyright/license disclaimer line to each of the source files.

However, this also is upstream business.
Comment 7 Michael Schwendt 2009-10-27 06:01:28 EDT
With "confirm the licensing in the source files" I actually refer to the Appendix of the GPL and LGPL. Worth reading.

And it's true, I'm not a reviewing-monkey who only follows an incomplete checklist of stuff to examine.


> I didn't get those warnings

Try again. They are printed with default %optflags on Fedora 11. Plain rpmbuild. Not even mock is necessary.

You could also follow the guidelines and submit a scratch-build in the official Fedora Build System "koji":
https://fedoraproject.org/wiki/PackageMaintainers/Join


> rpmlint

> Warnings not always need to be fixed.

The ReviewGuidelines (which are not specific to package reviewers, because packagers ought to review their own packages, too), say:

| MUST: rpmlint must be run on every package. The output should
| be posted in the review.[1] 

The second part of that rule is just a "should", but if you are in search of a sponsor, you ought to follow such recommendations and do this homework. At the same time you could explain why you don't fix things rpmlint reports.


> Strange, I don't have that in my .spec file. Maybe I send an outdated one.

I explicitly referred to the pkgconfig file, NOT the .spec file. Take your time when reading reviews, don't rush.
Comment 8 Felipe Contreras 2009-11-08 10:52:01 EST
(In reply to comment #6)
> (In reply to comment #5)
> 
> > That's the COPYING file, which I already said I'm going to include.
> Then please do so now.

I already said I will. Since I'm doing this on my free time I'll do so at my earliest convenience.

> In other words: keep your upstream and Fedora packager's role separate.
> I.e. first release a tarball, then package this tarball for Fedora, not vice
> versa.

What's the point of releasing a package that doesn't meet Fedora's standards? I would need to make another release just after receiving more feedback. I'll rather wait.

> > The
> > question was about source-code files. In Michael's words: "confirm the
> > licensing in the source files".  
> 
> I can only guess what he meant. My guess would be, he is asking you to add a
> copyright/license disclaimer line to each of the source files.

I don't see anything on the license that *requires* to add copyright/license disclaimers to each file. It says it's *desirable*, but ultimately an "upstream" choice.

> However, this also is upstream business.  

Yes, it's "upstream" business, but if it was *only* upstream business, then you would have accepted this packages already, and you clearly have issues with it that "upstream" (me) doesn't have strong feelings about.
Comment 9 Felipe Contreras 2009-11-08 11:26:06 EST
(In reply to comment #7)
> With "confirm the licensing in the source files" I actually refer to the
> Appendix of the GPL and LGPL. Worth reading.

That text says "It is safest" to do that, but there's no actual *requirement*.

You can find many source files in the linux kernel that don't have such notices.

> > I didn't get those warnings
> 
> Try again. They are printed with default %optflags on Fedora 11. Plain
> rpmbuild. Not even mock is necessary.

Right. I saved the output and now I can see it. It's a bit difficult to spot them with so much noise. But anyway, those are fixed now.

> > rpmlint
> 
> > Warnings not always need to be fixed.
> 
> The ReviewGuidelines (which are not specific to package reviewers, because
> packagers ought to review their own packages, too), say:
> 
> | MUST: rpmlint must be run on every package. The output should
> | be posted in the review.[1] 
> 
> The second part of that rule is just a "should", but if you are in search of a
> sponsor, you ought to follow such recommendations and do this homework. At the
> same time you could explain why you don't fix things rpmlint reports.

I followed the "Package Review Process" and I don't see this in any of the steps  for my role of "Contributor".

I see it on the list of things for the reviewer, but the reference points to:
http://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint

If you want people to post rpmlint output on the first run, then the review process document must be updated.

> > Strange, I don't have that in my .spec file. Maybe I send an outdated one.
> 
> I explicitly referred to the pkgconfig file, NOT the .spec file. Take your time
> when reading reviews, don't rush.  

Ok. I don't seem to find any documentation that says which dependencies I should put there, and which not. Anyway, I guess it makes sense to remove it.
Comment 10 Felipe Contreras 2009-11-08 11:35:08 EST
I've made the following changes upstream:

 * Fix all compilation warnings
 * Add LICENSE file
 * Added copyright and license notices:
---
/*
 * Copyright (C) 2007-2009 Felipe Contreras
 *
 * This code is licenced under the LGPLv2.1.
 */
---
 * Removed taglib as dependency from the pkg-config file

The code is in the usual place:
git://github.com/felipec/libmtag.git

If there's no more feedback I would like to release 0.3.2 and I guess the spec file would just work as is.
Comment 11 Felipe Contreras 2009-11-21 14:31:17 EST
Ok. I've made the 0.3.2 release which deals with all these comments from here.

Anything else pending acceptance?
Comment 12 Felipe Contreras 2009-12-20 20:36:28 EST
Ping. It seems everything has been done.
Comment 13 Michael Schwendt 2010-01-11 12:39:41 EST
Felipe,

I have no interest in argueing. I also don't want to appear as a commander who orders you to do something. Yet your replies make this bugzilla ticket more tiresome than necessary. As such I won't be the one to approve your account. There are others who may do so.

If most of your answers to requests/recommendations are of the types "I refuse to do this" and "I want to retain the freedom to not that", this causes unnecessary trouble. I don't want to put my hands into the fire for such people.

> I don't see anything on the license that *requires* to add
> copyright/license disclaimers to each file. It says it's
> *desirable*, but ultimately an "upstream" choice.

So what? It's a HOWTO: "How to apply these terms to your program?"  I consider it good practise to actually apply the licence terms like that. Hence I told you about it, since you did not even include the license text. All that mattered to me at that point of the review was your comment on that hint, not immediate action. Consider it an attitude-check.

> You can find many source files in the linux kernel that don't have such
> notices.

And that doesn't change anything. You can find many packages, which are bad examples. If we had based early Fedora on bad/poor examples, it would have failed.


[compiler warnings]

> It's a bit difficult to spot them with so much noise.

Redirect stderr. Or use grep.


[rpmlint]

> I followed the "Package Review Process" and I don't see this in any
> of the steps  for my role of "Contributor".

It's related to getting sponsored and being a packager, who knows the guidelines: https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Reviewing_Packages

Why would you ignore rpmlint output without a brief comment on it? A short comment would have been a change to show that you know your stuff.

> If you want people to post rpmlint output on the first run,
> then the review process document must be updated.

So, you want to _be forced_ to run helpful tools? And you would only take a look at compiler output if you were forced to do that?
Comment 14 Felipe Contreras 2010-01-11 15:01:41 EST
(In reply to comment #13)
> I have no interest in argueing. I also don't want to appear as a commander who
> orders you to do something. Yet your replies make this bugzilla ticket more
> tiresome than necessary. As such I won't be the one to approve your account.
> There are others who may do so.
> 
> If most of your answers to requests/recommendations are of the types "I refuse
> to do this" and "I want to retain the freedom to not that", this causes
> unnecessary trouble. I don't want to put my hands into the fire for such
> people.

Is there a policy against thinking? I haven't refused to do anything, I've just asked a question: Why? If that's too tiresome for you, I'm sure you can find more edifying experiences with people that don't ask questions and just do as you say.

> > I don't see anything on the license that *requires* to add
> > copyright/license disclaimers to each file. It says it's
> > *desirable*, but ultimately an "upstream" choice.
> 
> So what? It's a HOWTO: "How to apply these terms to your program?"  I consider
> it good practise to actually apply the licence terms like that. Hence I told
> you about it, since you did not even include the license text. All that
> mattered to me at that point of the review was your comment on that hint, not
> immediate action. Consider it an attitude-check.

There's a difference between a *requirement* and a *recommendation*. It is perfectly OK for me not to follow a *recommendation*, and you should not punish me for having a different opinion.

> > You can find many source files in the linux kernel that don't have such
> > notices.
> 
> And that doesn't change anything. You can find many packages, which are bad
> examples. If we had based early Fedora on bad/poor examples, it would have
> failed.

*You* think it's a bad example, *I* think it's a good example. Fedora doesn't have a policy on this, and GNU says it's OK.

If you want to push for your preference, this bug is not the right place to do that, but some Fedora guideline.

> [compiler warnings]
> 
> > It's a bit difficult to spot them with so much noise.
> 
> Redirect stderr. Or use grep.

Even better would be to reduce the noise in the first place.

> [rpmlint]
> 
> > I followed the "Package Review Process" and I don't see this in any
> > of the steps  for my role of "Contributor".
> 
> It's related to getting sponsored and being a packager, who knows the
> guidelines:

I'm sorry, my intention here is to get my package accepted (contribute). Later I might apply to actually be a packager if that's not too much trouble. In any case, I was under the impression that the *first step* was to submit a package. Reviewing comes later.

> Why would you ignore rpmlint output without a brief comment on it? A short
> comment would have been a change to show that you know your stuff.

It's a *warning*. I thought commenting on unimportant stuff would be detrimental. If it was really important it wouldn't be a warning, but an error.

That of course depends on the definition of "warning", but I'm not a mind-reader.

> > If you want people to post rpmlint output on the first run,
> > then the review process document must be updated.
> 
> So, you want to _be forced_ to run helpful tools? And you would only take a
> look at compiler output if you were forced to do that?

*first run* <- see this?

On the first try people are bound to follow the instructions, and that's *exactly* what I did.


Now, let's be productive and focus on *this bug* which is about reviewing the libmtag package. All the requirements have been met, haven't they? If not, what's missing?
Comment 15 Michael Schwendt 2010-01-12 06:04:54 EST
> There's a difference between a *requirement* and a *recommendation*.

One reason why some of Fedora's guidelines have been upgraded from a SHOULD to a MUST or vice versa. All SHOULD items could be dropped from the Wiki if there were no interest in making them recommendations.

Several things I suggest in my reviews are a SHOULD, albeit with a rationale (such as mentioning what is considered common practise or a good habit). Fedora's guidelines will never be complete and will never cover everything -- or else they would reach the size of a book.


> It is perfectly OK for me not to follow a *recommendation*, and you
> should not punish me for having a different opinion.

Nah, I don't punish anyone "for having a different opinion".

Just as you like to retain your freedom to do many things the way you like to, I'm not being forced to give blanket-approval to arbitrary people. Afterall, there even are recommendations about what ought to happen before someone gets sponsored: https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Reviewing_Packages
I don't do many reviews anymore these days (perhaps one a week), but typically I'm mostly interested in finding out whether a person is open-minded and easy to deal with, and whether a person is willing to absorb the Packaging documentation even without a reviewer requesting to do so.


[GPL/LGPL Appendix]

> *You* think it's a bad example, *I* think it's a good example.
> Fedora doesn't have a policy on this, and GNU says it's OK.

Do you realise how you override what is being considered the safest and preferred way how to apply the licence terms? Just for fun? Or what makes it a good example?


[compiler warnings]

> Even better would be to reduce the noise in the first place.

Now what sort of comment is that again? It doesn't add any value. You are not just a packager of the software, but the developer of the software. What is so difficult about developing your software with appropriate compiler flags such as -Wall -Werror? And here during review, initially you refused to acknowledge the warnings even. It required multiple comments, and still you did not even show real interest in fixing (or commenting on) at least this one:

mtag.c:179: warning: format '%s' expects type 'char *', but argument 2 has type 'int'


> I'm sorry, my intention here is to get my package accepted (contribute).
> Later I might apply to actually be a packager if that's not too much trouble.
> In any case, I was under the impression that the *first step* was to submit
> a package. Reviewing comes later.

A false impression then. The following page explains it:
https://fedoraproject.org/wiki/Package_Review_Process


[rpmlint]

> It's a *warning*. I thought commenting on unimportant stuff would be
> detrimental. If it was really important it wouldn't be a warning, but
> an error.

Splitting-hairs. As it is valid for some packages to be without documentation, one cannot turn all warnings into errors without creating false positives. Just as a rootkit checker, rpmlint wants you to add more intelligence and verify the output.

What had happened actually is that rpmlint warned you -- the developer of the software -- about the total lack of documentation files. And the best you could come up with was to ignore that warning and not comment on it?


> On the first try people are bound to follow the instructions,
> and that's *exactly* what I did.

Bugzilla is not suitable for multi-level '>', so let me point at
https://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint
once more, which is linked from many places including:
https://fedoraproject.org/wiki/Package_Review_Process#Contributor

The "How to get sponsored" page even gives some background as why packagers ought to become familiar with the reviewing guidelines, too:
https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Reviewing_Packages


> Now, let's be productive and focus on *this bug* which is
> about reviewing the libmtag package. All the requirements
> have been met, haven't they? If not, what's missing?    

An updated/fixed package to continue with.
Comment 16 Felipe Contreras 2010-01-12 08:33:48 EST
(In reply to comment #15)
> > There's a difference between a *requirement* and a *recommendation*.
> 
> One reason why some of Fedora's guidelines have been upgraded from a SHOULD to
> a MUST or vice versa. All SHOULD items could be dropped from the Wiki if there
> were no interest in making them recommendations.
> 
> Several things I suggest in my reviews are a SHOULD, albeit with a rationale
> (such as mentioning what is considered common practise or a good habit).
> Fedora's guidelines will never be complete and will never cover everything --
> or else they would reach the size of a book.

And I followed all your suggestions that are mentioned in Fedora guidelines.

> > It is perfectly OK for me not to follow a *recommendation*, and you
> > should not punish me for having a different opinion.
> 
> Nah, I don't punish anyone "for having a different opinion".
> 
> Just as you like to retain your freedom to do many things the way you like to,
> I'm not being forced to give blanket-approval to arbitrary people. Afterall,
> there even are recommendations about what ought to happen before someone gets
> sponsored:

As a good sponsor you *should* leave aside your personal agendas and follow Fedora's guidelines. Of course, nobody is forcing you to do that.

> I don't do many reviews anymore these days (perhaps one a week), but typically
> I'm mostly interested in finding out whether a person is open-minded and easy
> to deal with, and whether a person is willing to absorb the Packaging
> documentation even without a reviewer requesting to do so.

I am. However, I missed one link:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

> > *You* think it's a bad example, *I* think it's a good example.
> > Fedora doesn't have a policy on this, and GNU says it's OK.
> 
> Do you realise how you override what is being considered the safest and
> preferred way how to apply the licence terms? Just for fun? Or what makes it a
> good example?

Just for fun? How about you stop assuming worst intentions?

Here are a few reasons:
 * The text says 'library', and I often have to change it to 'program'
 * If the FSF changes their address (again), all the notices have to be updated (again). Having a physical mail address is completely stupid anyway (who uses physical mail anyway?)
 * I always have to remove ', or (at your option) any later version' just to be safe

IMHO that notice is a complete waste of space. If I add it to lib/mtag.h the size will increase 30%.

If I was a mindless drone I would do what everybody else does, but instead, I like to think and see what I consider "good examples" like linux, and git. And surprise! Just as I expected, they don't enforce these notices.

You are free to think that linux, git, and libmtag are "bad examples", but that's *your* opinion, so please treat it as such.

> > Even better would be to reduce the noise in the first place.
> 
> Now what sort of comment is that again? It doesn't add any value. You are not
> just a packager of the software, but the developer of the software. What is so
> difficult about developing your software with appropriate compiler flags such
> as -Wall -Werror? And here during review, initially you refused to acknowledge
> the warnings even. It required multiple comments, and still you did not even
> show real interest in fixing (or commenting on) at least this one:
> 
> mtag.c:179: warning: format '%s' expects type 'char *', but argument 2 has type
> 'int'

WTF are you talking about? My first reply (comment #3) was:
I didn't get those warnings, but I'll changes the CFLAGS to catch them in the
future, and I'll fix them.

What you are saying is not true.

> > I'm sorry, my intention here is to get my package accepted (contribute).
> > Later I might apply to actually be a packager if that's not too much trouble.
> > In any case, I was under the impression that the *first step* was to submit
> > a package. Reviewing comes later.
> 
> A false impression then. The following page explains it:
> https://fedoraproject.org/wiki/Package_Review_Process

I have re-read that text many times, but until now I found this link:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

I didn't know as a Contributor I was supposed to join as maintainer.

> > It's a *warning*. I thought commenting on unimportant stuff would be
> > detrimental. If it was really important it wouldn't be a warning, but
> > an error.
> 
> Splitting-hairs. As it is valid for some packages to be without documentation,
> one cannot turn all warnings into errors without creating false positives. Just
> as a rootkit checker, rpmlint wants you to add more intelligence and verify the
> output.
> 
> What had happened actually is that rpmlint warned you -- the developer of the
> software -- about the total lack of documentation files. And the best you could
> come up with was to ignore that warning and not comment on it?

I did consider the warnings and I chose not to comment on them, just like I do when I ignore checkpatch warnings for lines bigger than 80 characters.

Now, if you do want me to comment on the lack of documentation of the 'tools' package, I would rather remove it. And for the 'devel' package, well I'm a big believer in self-documenting code, and an API that's 48 lines of code (including notices and extra chunk), I think it doesn't require any documentation.

> > On the first try people are bound to follow the instructions,
> > and that's *exactly* what I did.
> 
> Bugzilla is not suitable for multi-level '>', so let me point at
> https://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint
> once more, which is linked from many places including:
> https://fedoraproject.org/wiki/Package_Review_Process#Contributor

Yeah, I followed that; I used rpmlint as mentioned. However, it's not mentioned that I need to provide the output. Sure, it's mentioned somewhere else, but not there.

> The "How to get sponsored" page even gives some background as why packagers
> ought to become familiar with the reviewing guidelines, too:
> https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Reviewing_Packages

Yeah, but as I said before, I didn't know I *had* to be following the procedure to become a maintainer as of now.

> > Now, let's be productive and focus on *this bug* which is
> > about reviewing the libmtag package. All the requirements
> > have been met, haven't they? If not, what's missing?    
> 
> An updated/fixed package to continue with.    

And what needs fixing? As I mentioned in comment #19; everything has been addressed upstream... there's no need to update the spec file.
Comment 17 Felipe Contreras 2010-01-12 08:36:45 EST
(In reply to comment #16)
> And what needs fixing? As I mentioned in comment #19; everything has been
> addressed upstream... there's no need to update the spec file.    

I meant comment #10.
Comment 18 Michael Schwendt 2010-01-12 10:50:46 EST
No reviewer will approve a src.rpm that gives 404 Not Found already for the 
source tarball.

And with a manual download by visiting the web page, the result is:

$ md5sum libmtag-0.3.2-1.fc11.src/libmtag-0.3.2.tar.gz
6c57340a60a82f2732d5b55c78c994f0  libmtag-0.3.2-1.fc11.src/libmtag-0.3.2.tar.gz

$ md5sum ~/Downloads/libmtag-0.3.2.tar.gz 
7374002ed89009f5f932da4494acff0e  /home/qa/Downloads/libmtag-0.3.2.tar.gz

That's something you do need to fix, because so far it doesn't demonstrate that you know your stuff.

The other issues pointed out in comment 2 are still true, too. If you cannot proceed without releasing a new tarball upstream first, well, then consider doing that release. Where exactly are your difficulties in preparing an updated spec and src.rpm that would pass review? AFAIK, 0.3.2 has been released by you in Nov 2009 already.

It's spelled out in the guide:

http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Make_a_Package

| * Make sure that your package meets the  Packaging Guidelines
| and  PackageNamingGuidelines .
|
| * Be aware of Forbidden Items and Package Review Guidelines
| (they will be used during the package review). 

Effectively, the person who wants to join the package collection maintainers (aka the "packager" group in the Fedora Account System) is expected to do a little bit of home work prior to and during the review process.

The detailed documentation for the Review Process explicitly explains that it may be necessary to provide an updated spec file and src.rpm after issues have been pointed out: http://fedoraproject.org/wiki/Package_Review_Process


> As a good sponsor you *should* leave aside your personal agendas and
> follow Fedora's guidelines.

Which ones are that? These?
http://fedoraproject.org/wiki/Package_sponsor_responsibilities

What you've been given in this ticket so far by two people is general guidance, especially since you are upstream *and* the package submitter. [Normally, the packager would communicate with upstream and forward flaws found during review.]

A more interesting read is this:

https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Sponsorship_model

It explains what is expected from you at a technical level.


[Applying the LGPL]

> * The text says 'library', and I often have to change it to 'program'
> * If the FSF changes their address (again), all the notices
[snip]

That's splitting-hairs again. The tarball in the src.rpm, which is presented for review, does not mention the licensing at all. That's the worst-case.

You were pointed at Fedora's guidelines about that. You refused to include the license terms in the tarball, 
https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text
and you refused to acknowledge the licensing in the source files (three files only at present).

However, in 0.3.2 upstream tarball, without mentioning it here, you added a one-line licensing header to the source files nevertheless. Some sort of compromise. That's not the best you could have done, but it's a beginning. 


[compiler warnings]

> WTF are you talking about?

About strange/superfluous comments that only confuse matters. One can really get lost in all your excuses, such as the one about too much noise in compiler output. You can fill pages with ramblings about stuff you don't like to do, and at the end still all that will be important is to provide a src.rpm that actually fixes issues and will pass review.


> I didn't know as a Contributor I was supposed to join as maintainer.

Then that would have been a chance to ask here or in relevant places. Several web pages end at the same "Join" page for package maintainers:

http://join.fedoraproject.org
 -> http://fedoraproject.org/join-fedora
 --> https://fedoraproject.org/wiki/PackageMaintainers/Join

And another page explains the details, such as updating a src.rpm with fixes during review: https://fedoraproject.org/wiki/Package_Review_Process#Contributor


> Now, if you do want me to comment on the lack of documentation
> of the 'tools' package, I would rather remove it.

That would be an option.
Comment 19 Felipe Contreras 2010-01-12 11:56:52 EST
(In reply to comment #18)
> No reviewer will approve a src.rpm that gives 404 Not Found already for the 
> source tarball.

Again, I don't know what you are talking about:
% spectool -g libmtag.spec
“./libmtag-0.3.2.tar.gz” saved

> And with a manual download by visiting the web page, the result is:

[...]

> That's something you do need to fix, because so far it doesn't demonstrate that
> you know your stuff.

[...]

That's 200 words just to say "update the SRPM". An SRPM is essentially a .spec + a tarball. The spec is the same posted since the beginning, and the tarball was released as mentioned in comment #11. But if you want me to do 'rpmbuild -bs libmtag.spec', ok, will do.

[...]

> [Applying the LGPL]
> 
> > * The text says 'library', and I often have to change it to 'program'
> > * If the FSF changes their address (again), all the notices
> [snip]
> 
> That's splitting-hairs again. The tarball in the src.rpm, which is presented
> for review, does not mention the licensing at all. That's the worst-case.

Not "is presented"; "was presented".

> You were pointed at Fedora's guidelines about that. You refused to include the
> license terms in the tarball,

That's a lie. I never refused to do that.

> https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text
> and you refused to acknowledge the licensing in the source files (three files
> only at present).

That link mentions the license in it's own file, which was fixed upstream, as recommended:
http://github.com/felipec/libmtag/blob/master/LICENSE

> However, in 0.3.2 upstream tarball, without mentioning it here, you added a
> one-line licensing header to the source files nevertheless. Some sort of
> compromise. That's not the best you could have done, but it's a beginning. 

It was clearly mentioned in comment #10. Also mentioned was the full addition of LGPLv2 text in the "LICENSE" file.

> [compiler warnings]
> 
> > WTF are you talking about?
> 
> About strange/superfluous comments that only confuse matters. One can really
> get lost in all your excuses, such as the one about too much noise in compiler
> output. You can fill pages with ramblings about stuff you don't like to do, and
> at the end still all that will be important is to provide a src.rpm that
> actually fixes issues and will pass review.

If you are not able to receive constructive criticism just ignore it.

[...]

> > Now, if you do want me to comment on the lack of documentation
> > of the 'tools' package, I would rather remove it.
> 
> That would be an option.    

Since it seems to be the easiest, I'll do it.
Comment 21 Michael Schwendt 2010-01-12 12:35:58 EST
> % spectool -g libmtag.spec
> “./libmtag-0.3.2.tar.gz” saved

$ rpmdev-extract libmtag-0.3.2-1.fc11.src.rpm 
libmtag-0.3.2-1.fc11.src/libmtag-0.3.2.tar.gz
libmtag-0.3.2-1.fc11.src/libmtag.spec
$ md5sum libmtag-0.3.2-1.fc11.src/libmtag-0.3.2.tar.gz
6c57340a60a82f2732d5b55c78c994f0  libmtag-0.3.2-1.fc11.src/libmtag-0.3.2.tar.gz
$ spectool -g libmtag-0.3.2-1.fc11.src/libmtag.spec
--2010-01-12 18:07:56--  http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz
Resolving libmtag.googlecode.com... 209.85.135.82
Connecting to libmtag.googlecode.com|209.85.135.82|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2010-01-12 18:07:56 ERROR 404: Not Found.
$ rm -f libmtag-0.3.2-1.fc11.src/libmtag-0.3.2.tar.gz
$ spectool -g libmtag-0.3.2-1.fc11.src/libmtag.spec
--2010-01-12 18:08:32--  http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz
Resolving libmtag.googlecode.com... 74.125.43.82
Connecting to libmtag.googlecode.com|74.125.43.82|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2010-01-12 18:08:33 ERROR 404: Not Found.
$ rm -f libmtag-0.3.2.tar.gz
$ md5sum libmtag-0.3.2.tar.gz 
7374002ed89009f5f932da4494acff0e  libmtag-0.3.2.tar.gz


So:

1.) The checksums still didn't match until you updated the src.rpm!
2.) The 404 error is a problem of wget+googlecode.com on Fedora 12, to reproduce:

$ touch libmtag-0.3.2.tar.gz
$ wget http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz 2>&1|grep 404
HTTP request sent, awaiting response... 404 Not Found
2010-01-12 18:11:44 ERROR 404: Not Found.


Only 0.3.2-2 includes the changed tarball now.


> That's 200 words just to say "update the SRPM".

Bottom of comment 15 did it in ~6 words.


> An SRPM is essentially a .spec + a tarball. The spec is the same
> posted since the beginning, and the tarball was released as mentioned
> in comment #11. But if you want me to do 'rpmbuild -bs libmtag.spec',
> ok, will do.

It's common practise to do so, not only so reviewers can use rpmdiff as a  convenient tool to examine the changes between package releases.

https://fedoraproject.org/wiki/Package_Review_Process#Contributor
says: "please post the URLs to the updated SPEC and SRPM file"


> > You were pointed at Fedora's guidelines about that.
> > You refused to include the license terms in the tarball,
>
> That's a lie. I never refused to do that.

And still the 0.3.2-2 src.rpm doesn't include the license terms.
Originally, I just followed:

| https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
| 
| SHOULD: If the source package does not include license text(s)
| as a separate file from upstream, the packager SHOULD query
| upstream to include it.

Let's see. You added a LICENSE file in upstream git on Nov 8th with the commit message

| Add licence and copyright information
| 
| This should have been like that since the beginning.

(hear! hear!) only to release the 0.3.2 tarball on Nov 21th _without_ including this LICENSE file. And in the updated src.rpm, you also did not consider fixing this. How to make sense of that?
Comment 22 Felipe Contreras 2010-01-12 14:54:13 EST
(In reply to comment #21)
> > % spectool -g libmtag.spec
> > “./libmtag-0.3.2.tar.gz” saved

[...]

> So:
> 
> 1.) The checksums still didn't match until you updated the src.rpm!

Obviously. Because the SRPM was created from with code from October, while the release tarball was created after the fixes were done, on November.

> 2.) The 404 error is a problem of wget+googlecode.com on Fedora 12, to
> reproduce:
> 
> $ touch libmtag-0.3.2.tar.gz
> $ wget http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz 2>&1|grep 404
> HTTP request sent, awaiting response... 404 Not Found
> 2010-01-12 18:11:44 ERROR 404: Not Found.

% touch libmtag-0.3.2.tar.gz
% get http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz 2>&1|grep 404
(nothing)

Seems to be a problem on your end; I'm also using F12.

> Only 0.3.2-2 includes the changed tarball now.

You mean the new SRPM? Of course.

> > That's 200 words just to say "update the SRPM".
> 
> Bottom of comment 15 did it in ~6 words.

That depends on definition of "package", clearly I didn't know you meant the SRPM.

> > An SRPM is essentially a .spec + a tarball. The spec is the same
> > posted since the beginning, and the tarball was released as mentioned
> > in comment #11. But if you want me to do 'rpmbuild -bs libmtag.spec',
> > ok, will do.
> 
> It's common practise to do so, not only so reviewers can use rpmdiff as a 
> convenient tool to examine the changes between package releases.
> 
> https://fedoraproject.org/wiki/Package_Review_Process#Contributor
> says: "please post the URLs to the updated SPEC and SRPM file"

Yeah if the SPEC file is updated of course the SRPM needs to be updated, but I didn't know that the SRPM needed to be updated even if the SPEC file stayed the same, and only upstream was changed.

Anyway, all you needed was to clarify.

> > > You were pointed at Fedora's guidelines about that.
> > > You refused to include the license terms in the tarball,
> >
> > That's a lie. I never refused to do that.
> 
> And still the 0.3.2-2 src.rpm doesn't include the license terms.
> Originally, I just followed:

[...]

> Let's see. You added a LICENSE file in upstream git on Nov 8th with the commit
> message
> 
> | Add licence and copyright information
> | 
> | This should have been like that since the beginning.
> 
> (hear! hear!) only to release the 0.3.2 tarball on Nov 21th _without_ including
> this LICENSE file. And in the updated src.rpm, you also did not consider fixing
> this. How to make sense of that?    

Why would anybody add a LICENSE file to the SCM and not release it on the tarball? I'll help you here: it was a mistake.

Anyway, I've revamped the build system and now the LICENSE is included.
Comment 23 Felipe Contreras 2010-01-12 14:58:10 EST
Try 3:

spec: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.3-1.spec
srpm: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.3-1.fc12.src.rpm

I don't really see much point in providing a separate spec file if it's already included in the SRPM, but whatever.
Comment 24 Michael Schwendt 2010-01-12 16:22:22 EST
> % touch libmtag-0.3.2.tar.gz
> % get http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz 2>&1|grep 404
> (nothing)

get? Run "wget" as in spectool!  Due to the redirection of stderr and grep, you would not even see the "command not found" for "get".
Comment 25 Felipe Contreras 2010-01-12 16:58:58 EST
(In reply to comment #24)
> get? Run "wget" as in spectool!  Due to the redirection of stderr and grep, you
> would not even see the "command not found" for "get".    

typo

% rm -f libmtag-0.3.2.tar.gz
% touch libmtag-0.3.2.tar.gz
% wget -q http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz
% sha1sum libmtag-0.3.2.tar.gz 
da39a3ee5e6b4b0d3255bfef95601890afd80709  libmtag-0.3.2.tar.gz
Comment 26 Michael Schwendt 2010-01-12 17:26:32 EST
Felipe,

you changed the test-case and got the the sha1sum for an empty file. :-)

qed
Comment 27 Felipe Contreras 2010-01-12 17:48:16 EST
(In reply to comment #26)
> you changed the test-case and got the the sha1sum for an empty file. :-)

Right, but it doesn't matter; the point is that there is no error 404.

% rm -f libmtag-*
% touch libmtag-0.3.2.tar.gz
% wget http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz 2>&1|grep 404   
% sha1sum libmtag-*
da39a3ee5e6b4b0d3255bfef95601890afd80709  libmtag-0.3.2.tar.gz
340f35da95c4d6bb0f5e0ddbf1334703df816739  libmtag-0.3.2.tar.gz.1
% wget -c http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz 2>&1|grep 404
% sha1sum libmtag-*
340f35da95c4d6bb0f5e0ddbf1334703df816739  libmtag-0.3.2.tar.gz
340f35da95c4d6bb0f5e0ddbf1334703df816739  libmtag-0.3.2.tar.gz.1

In any case, there is no problem with the url nor the spec.
Comment 28 Ralf Corsepius 2010-01-12 23:04:49 EST
MUSTFIX:

* Package doesn't build in mock:
...
 make -j2
   CXX        lib/mtag.o
   CC         src/mtag.o
   CC         tests/reader.o
   LINK       libmtag.so
/usr/bin/ld: lib/mtag.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
lib/mtag.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libmtag.so] Error 1

* Spec-filename ("libmtag-1.spec") doesn't comply to Fedora conventions.

* Building is non-verbose (cf. above).

* autoreconf -fi fails == Upstream tarball is broken.
From what I see, you abandoned using automake and switched to using manually written Makefiles. Likely you believe this to be a good idea ... I don't.
Comment 29 Felipe Contreras 2010-01-13 05:22:26 EST
(In reply to comment #28)
> MUSTFIX:
> 
> * Package doesn't build in mock:

[...]

> /usr/bin/ld: lib/mtag.o: relocation R_X86_64_32 against `.rodata' can not be
> used when making a shared object; recompile with -fPIC

Oops, fixed.

> * Spec-filename ("libmtag-1.spec") doesn't comply to Fedora conventions.

libmtag.spec, right? If so, fixed.

> * Building is non-verbose (cf. above).

Fixed.

> * autoreconf -fi fails == Upstream tarball is broken.

You mean that I forgot to remove configure.ac? Fixed.

> From what I see, you abandoned using automake and switched to using manually
> written Makefiles. Likely you believe this to be a good idea ... I don't.

Well, that's your opinion, you are entitled to it.
Comment 30 Michael Schwendt 2010-01-13 05:24:23 EST
> the point is that there is no error 404.

There is.

Sorry that you have no interest in that, but in comment 2 spectool -g gave 404 for me and the manually downloaded tarball didn't match either because the tarball you included has been modified without changing its filename. Hence I did have to look into this further. 404 is a server return value, so it could also have been an unstable mirroring system or some sort of corruption in wget.

Anyway, I've had a closer look now and compared with a separate environment: 

It's wget times-tamping which fails with googlecode.com. I use -N by default in my wget alias. And that also influences spectool. Seems the googlecode server doesn't like the last-modified query for repeated downloads with wget -N (and the normal sequence of using rpmdev-extract + spectool).
Comment 31 Felipe Contreras 2010-01-13 05:29:34 EST
Try 4:

The 0.3.4 upstream release is pending, I would like to hold it a bit in case there are more comments here.

srpm: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.4-1.fc12.src.rpm
Comment 32 Felipe Contreras 2010-01-13 05:37:26 EST
(In reply to comment #30)
> > the point is that there is no error 404.
> 
> There is.

There is not.

> Sorry that you have no interest in that, but in comment 2 spectool -g gave 404
> for me

Sorry that you are not interested in reading what I say, but I explained in comment #3 that 0.3.2 wasn't released yet (Oct 26), it was released as explained in comment #11 (Nov 21).

Don't bother trying 0.3.4 because it's not released yet either, and you don't seem to get the concept.

> Anyway, I've had a closer look now and compared with a separate environment: 
> 
> It's wget times-tamping which fails with googlecode.com. I use -N by default in
> my wget alias. And that also influences spectool. Seems the googlecode server
> doesn't like the last-modified query for repeated downloads with wget -N (and
> the normal sequence of using rpmdev-extract + spectool).

wget -N also works for me: no error 404.
Comment 33 Michael Schwendt 2010-01-13 06:34:05 EST
No, it doesn't. You add too much confusion because you change the test-case again and again.

$ ssh fedorapeople.org
$ wget -nv -N http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz
2010-01-13 11:31:21 URL:http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz [304704/304704] -> "libmtag-0.3.2.tar.gz" [1]
[mschwendt@people1 ~]$ wget -nv -N http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz
http://libmtag.googlecode.com/files/libmtag-0.3.2.tar.gz:
2010-01-13 11:31:22 ERROR 404: Not Found.

Enough said.
Comment 34 Ralf Corsepius 2010-01-13 06:49:51 EST
(In reply to comment #29)
> (In reply to comment #28)
> > MUSTFIX:
> > 
> > * Package doesn't build in mock:

Package still does not build:


RPM build errors:
error: File not found by glob: /builddir/build/BUILDROOT/libmtag-0.3.4-1.fc13.x86_64/usr/lib64/*.so.*
    File not found by glob: /builddir/build/BUILDROOT/libmtag-0.3.4-1.fc13.x86_64/usr/lib64/*.so.*
Child returncode was: 1

Apparently you don't test the stuff you want us to review.

> > * Spec-filename ("libmtag-1.spec") doesn't comply to Fedora conventions.
> 
> libmtag.spec, right? If so, fixed.
Yes.

> > * Building is non-verbose (cf. above).
> 
> Fixed.
No - Either you broke things even more or you demonstrated why "non-verbose makefiles are harmful":


g++ -ggdb -Wall -Wextra -Wno-unused-parameter -I/usr/include/taglib   -I./lib -fPIC  -MMD -o lib/mtag.o -c lib/mtag.cpp
gcc -ggdb -Wall -Wextra -Wno-unused-parameter -I./lib  -MMD -o src/mtag.o -c src/mtag.c
gcc -ggdb -Wall -Wextra -Wno-unused-parameter -I./lib  -MMD -o tests/reader.o -c tests/reader.c

=> NEW: MUSTFIX: Package doesn't honor RPM_OPT_FLAGS

> > From what I see, you abandoned using automake and switched to using manually
> > written Makefiles. Likely you believe this to be a good idea ... I don't.
> 
> Well, that's your opinion, you are entitled to it.    
Well, you are not the first person who is outsmarting himself by using handwritten makefiles. This review and your behavior as upstream speaks a very clear language.
Comment 35 Michael Schwendt 2010-01-13 07:07:23 EST
In comment 7, I had pointed out the possibility to submit test-builds in the Fedora build system. I also provided a link into the Wiki for further reading.
Comment 36 Felipe Contreras 2010-01-13 07:55:11 EST
(In reply to comment #34)
> Package still does not build:

[...]

> Apparently you don't test the stuff you want us to review.

Why do you have to assume the worst? Maybe you should try to think of another non-antagonist option (hint: 64).

> => NEW: MUSTFIX: Package doesn't honor RPM_OPT_FLAGS

Ok, fixed:
make V=y CFLAGS="$RPM_OPT_FLAGS" %{?_smp_mflags}

> Well, you are not the first person who is outsmarting himself by using
> handwritten makefiles.

That's an uncalled for assumption, and ad hominem attack. What do you even know about me?
Comment 37 Felipe Contreras 2010-01-13 09:01:30 EST
(In reply to comment #35)
> In comment 7, I had pointed out the possibility to submit test-builds in the
> Fedora build system. I also provided a link into the Wiki for further reading.    

I'm trying now and I don't seem to find any information for test packages:
koji build --scratch --skip-tag dist-f12 'http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.4-1.fc12.src.rpm'

Just fails.
Comment 38 Felipe Contreras 2010-01-13 09:13:45 EST
Ah, I was reading:
http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji
and
http://fedoraproject.org/wiki/Koji

But it seems to be explained in:
http://fedoraproject.org/wiki/PackageMaintainers/Join

So I did some modifications for libdir, and they seem to work fine.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1918761

I guess it's time to release 0.3.4.
Comment 39 Felipe Contreras 2010-01-13 09:33:55 EST
Try 5:

srpm: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.4-2.fc12.src.rpm

This time the real 0.3.4 release is used (ccff7ec7fc902eaf8b996ea98bb679bc24e77cfb)

And it build properly on Koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1918805
Comment 40 Michael Schwendt 2010-01-13 10:09:09 EST
What tests have you performed with libmtag-0.3.4-2.fc12.src.rpm?

In particular, have you verified that older issues are fixed within that package?

For example:
* It still doesn't honour RPM_OPT_FLAGS. 
* It still doesn't include the licence terms file.
* MUSTFIX: In parts of the package it now hardcodes /usr/lib also for 64-bit multi-arch platforms where %_libdir expands to /usr/lib64.
Comment 41 Felipe Contreras 2010-01-13 10:23:51 EST
(In reply to comment #40)
> What tests have you performed with libmtag-0.3.4-2.fc12.src.rpm?

I don't know what you mean; it works.

> In particular, have you verified that older issues are fixed within that
> package?

*sight*

Yes

> For example:
> * It still doesn't honour RPM_OPT_FLAGS.

Is it so difficult to open the koji task and see?

As mentioned in comment #36; fixed.

> * It still doesn't include the licence terms file.

As mentioned in comment #22 (bottom); fixed.

% tar -tf libmtag-0.3.4.tar.gz | grep LICENSE
libmtag-0.3.4/LICENSE

> * MUSTFIX: In parts of the package it now hardcodes /usr/lib also for 64-bit
> multi-arch platforms where %_libdir expands to /usr/lib64.    

As mentioned in comment #38; fixed.
Comment 42 Michael Schwendt 2010-01-13 10:39:16 EST
Exercises for you:

1) Show that the C++ file is built with Fedora's global optflags.

2) Show that the file LICENSE is included in the packages built from the src.rpm.

3) Show that no file in libmtag-devel.x86_64 (and libmtag-devel.ppc64) contains a hardcoded /usr/lib.
Comment 43 Felipe Contreras 2010-01-13 11:08:11 EST
(In reply to comment #42)
> 1) Show that the C++ file is built with Fedora's global optflags.

Do you have trouble clicking links?
http://koji.fedoraproject.org/koji/getfile?taskID=1918807&name=build.log

Or do you want me to grep the CFLAGS for you?
make V=y 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' -j4

> 2) Show that the file LICENSE is included in the packages built from the
> src.rpm.

You mean the binary package? If so, will add.

> 3) Show that no file in libmtag-devel.x86_64 (and libmtag-devel.ppc64) contains
> a hardcoded /usr/lib.    

% rpm -q -l -p libmtag-0.3.4-2.fc12.x86_64.rpm
/usr/lib64/libmtag.so.0

% rpm -q -l -p libmtag-devel-0.3.4-2.fc12.x86_64.rpm 
/usr/include/libmtag
/usr/include/libmtag/mtag.h
/usr/lib64/libmtag.so
/usr/lib64/pkgconfig/libmtag.pc
Comment 44 Felipe Contreras 2010-01-13 11:13:04 EST
Try 6:

srpm:
http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.4-3.fc12.src.rpm

This time the LICENSE file is included in the binary rpm:

% rpm -q -l -p libmtag-0.3.4-3.fc12.i686.rpm
/usr/lib/libmtag.so.0
/usr/share/doc/libmtag-0.3.4
/usr/share/doc/libmtag-0.3.4/LICENSE
Comment 45 Michael Schwendt 2010-01-13 11:21:48 EST
> Or do you want me to grep the CFLAGS for you?

No, I want to you show that the C++ file is compiled with Fedora's flags.

Just do it, please. There's nothing wrong with trial-and-error packaging attempts.

> make V=y 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' -j4

That's just the "make" invocation. Verify that those CFLAGS are used properly by the compiler invocations.

> % rpm -q -l -p libmtag-devel-0.3.4-2.fc12.x86_64.rpm 
> /usr/include/libmtag
> /usr/include/libmtag/mtag.h
> /usr/lib64/libmtag.so
> /usr/lib64/pkgconfig/libmtag.pc    

Now have a look at the contents of libmtag.pc.
Comment 46 Felipe Contreras 2010-01-13 12:30:24 EST
(In reply to comment #45)
> No, I want to you show that the C++ file is compiled with Fedora's flags.
> 
> Just do it, please. There's nothing wrong with trial-and-error packaging
> attempts.
> 
> > make V=y 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' -j4
> 
> That's just the "make" invocation. Verify that those CFLAGS are used properly
> by the compiler invocations.

You could just say: "gcc is ok, but g++ is not using the flags"

Nah, that would be too direct. It's better to go back and forth a couple of times without pointing out the problem.

Anyway, fixed.

> > % rpm -q -l -p libmtag-devel-0.3.4-2.fc12.x86_64.rpm 
> > /usr/include/libmtag
> > /usr/include/libmtag/mtag.h
> > /usr/lib64/libmtag.so
> > /usr/lib64/pkgconfig/libmtag.pc    
> 
> Now have a look at the contents of libmtag.pc.

Presumably that's your indirect way of pointing a problem; if that problem is a wrong libdir, then, also fixed.
Comment 47 Felipe Contreras 2010-01-13 13:05:53 EST
Try 7:

srpm: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.5-1.fc12.src.rpm

g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/taglib   -I./lib -fPIC  -MMD -o lib/mtag.o -c lib/mtag.cpp

libmtag-devel-0.3.5-1.fc12.x86_64.rpm:libmtag.pc:
prefix=/usr
libdir=/usr/lib64
includedir=${prefix}/include
Comment 48 Ralf Corsepius 2010-01-13 13:17:05 EST
(In reply to comment #36)
> (In reply to comment #34)
> > Package still does not build:
> 
> [...]
> 
> > Apparently you don't test the stuff you want us to review.
> 
> Why do you have to assume the worst?
As I wrote before: The way this review proceeds speaks for itself.

IMO, it's only thanks to Michael's seemingly endless patience, this review has not yet found a premature end.

> Maybe you should try to think of another
> non-antagonist option (hint: 64).
Pardon? It's a reviewer's job to test your work and to point out your bugs.

If you didn't test on 64bit platforms, this is your fault.

> > Well, you are not the first person who is outsmarting himself by using
> > handwritten makefiles.
> 
> That's an uncalled for assumption, and ad hominem attack.
No, it's 20 years of SW development experience.

As I tried to tell you before, you are not the first persoon who is switching to manually written makefiles without being aware about the bugs and short comings his approach carries - There have been generations of programmers before you.

> What do you even know about me?    
Well, to me, it's apparent that you are at the very beginning of getting started with packaging and system integration.
Comment 49 Michael Schwendt 2010-01-13 13:47:58 EST
Felipe,

you presume too much.

Go back a few comments to see that I explicitly referred to "the C++ file". And
still you didn't take a close look at the build.log. You choose to pay no
attention to "the C++ file".

Prior to that you could have simply taken the review serious. At least a little
bit of trust in that the reviewer *may* be right. I wrote: "It still doesn't
honour RPM_OPT_FLAGS" which referred to the earlier mission objective. Instead
of trying to insult me, you could have asked for help on how to verify optflags
usage. A simple reply such as "Where? I fail to see it" would have done it. The
way you reacted left much to be desired, however.


As a general comment on those optflags: It's easy to miss such a detail in the
build.log. It's only one small item in the packaging guidelines. In the review
guidelines, it's only covered indirectly by this:

   MUST: The package must meet the Packaging Guidelines.

And burried deep in the packaging guidelines, it's this:
http://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags

It can happen that a single subdirectory doesn't apply the optflags, while the
rest of a project applies them just fine. Or a single subdir overrides the
optflags in questionable ways.


Anyway, many reviews don't just consist of a sequence of "do this, do that"
items, or else the reviewer would simply provide the fixed spec file. Packagers
are expected to do most of the work, to learn, to read the packaging
guidelines, to become capable of fixing packages themselves in accordance with
additional documentation, and to show whether they know their stuff in order to
convince a sponsor. [Many packagers are expected to demonstrate an
understanding of the review guidelines even, by doing a couple of reviews
completely on their own.] Once a packager's account request is approved, there
isn't any package reviewing process for updates applied to packages in fedora
package scm. That means, you will get less hand-guiding or none at all - unless
your sponsor (or somebody else) monitors your packaging activity closely.


> It's better to go back and forth a couple of
> times without pointing out the problem.

Nah, that's just your rather typical way of twisting things and making the
process tiresome. The initial mission objective was clear:

  MUSTFIX: Package doesn't honor RPM_OPT_FLAGS

Either you understand what that means, where to look it up in the guidelines,
and how to fix the issue -- or you don't. In case of the latter, ask. Simple as
that.

[...]

Rest assured, my patience is not endless. I only made the mistake of letting bugzilla put me onto the Cc list again. ;-)
Comment 50 Felipe Contreras 2010-01-13 13:57:10 EST
(In reply to comment #48)
> (In reply to comment #36)
> > Why do you have to assume the worst?
> As I wrote before: The way this review proceeds speaks for itself.

Let's be clear: you are assuming either I don't know what I'm doing here, or I don't care enough to try my own stuff. Either way it's not only a wrong assumption (I did test my stuff), but it's offensive.

> > Maybe you should try to think of another
> > non-antagonist option (hint: 64).
> Pardon? It's a reviewer's job to test your work and to point out your bugs.

But that's not what you did; after you pointed out the problem, then you implied I didn't even test my own stuff: that doesn't serve any purpose other than to offend.

> If you didn't test on 64bit platforms, this is your fault.

If by "test" you mean build, install, and run tests; then I disagree. It's impossible to do this for every platform out there.

If what you mean is to just build on Koji, then perhaps, but I was never told it was a *requirement* only that it would be nice.

In any case, I didn't deny there was a problem, or tried to deflect my fault; all I did was to object to your offensive comment.

> > > Well, you are not the first person who is outsmarting himself by using
> > > handwritten makefiles.
> > 
> > That's an uncalled for assumption, and ad hominem attack.
> No, it's 20 years of SW development experience.

Your experience can give you statistical guidance to assume that *probably* I'm shooting myself in the foot here, but that's not what you said. You didn't show any doubt that I was outsmarting myself, without knowing anything about me; that's a fallacy of accident.

> As I tried to tell you before, you are not the first persoon who is switching
> to manually written makefiles without being aware about the bugs and short
> comings his approach carries - There have been generations of programmers
> before you.

I maintain multiple widely used packages that don't use autotools, and in each one of them I've found it's significantly easier to deal with, even on multiple platforms (which I test) like: i386, arm, and mingw32.

Besides, I'm encouraged by good examples (IMO) of packages that don't use autotools: git, qemu, ffmpeg.

Your FUD doesn't scare me. 

> > What do you even know about me?    
> Well, to me, it's apparent that you are at the very beginning of getting
> started with packaging and system integration.    

You are wrong, I maintain important packages on the Nokia N900 (debian based):
http://maemo.gitorious.org/maemo-multimedia/gst-dsp
http://maemo.gitorious.org/maemo-multimedia/gst-openmax
http://maemo.gitorious.org/maemo-multimedia/dsp-tools

But that was actually a rhetorical question: it doesn't matter what you think about me; the choice of not using autotools resides completely on upstream, and is not something to be discussed in this review request.
Comment 51 Felipe Contreras 2010-01-13 14:27:21 EST
(In reply to comment #49)
> you presume too much.

It's hard to know what exactly I'm wrongly presuming, but I'm going to make a guess that it's:
You could just say: "gcc is ok, but g++ is not using the flags"

If that's the case I don't think so. You certainly could have said that, and saved us a lot of time.

> Go back a few comments to see that I explicitly referred to "the C++ file". And
> still you didn't take a close look at the build.log. You choose to pay no
> attention to "the C++ file".

Indeed, because I was under the impression that this was not a game of finding the clues.

> Prior to that you could have simply taken the review serious. At least a little
> bit of trust in that the reviewer *may* be right. I wrote: "It still doesn't
> honour RPM_OPT_FLAGS" which referred to the earlier mission objective. Instead
> of trying to insult me, you could have asked for help on how to verify optflags
> usage. A simple reply such as "Where? I fail to see it" would have done it. The
> way you reacted left much to be desired, however.

The fact of the matter is that the statement "It still doesn't honour RPM_OPT_FLAGS" is ambiguous. The .spec file was honoring the flags, the .c rules of the Makefile were honoring the flags, but not the .cpp rules. So at best that statement is 2/3 true.

> As a general comment on those optflags: It's easy to miss such a detail in the
> build.log. It's only one small item in the packaging guidelines. In the review
> guidelines, it's only covered indirectly by this:

[...]

Indeed, I agree.

> Anyway, many reviews don't just consist of a sequence of "do this, do that"
> items, or else the reviewer would simply provide the fixed spec file. Packagers
> are expected to do most of the work, to learn, to read the packaging
> guidelines, to become capable of fixing packages themselves in accordance with
> additional documentation, and to show whether they know their stuff in order to
> convince a sponsor. [Many packagers are expected to demonstrate an
> understanding of the review guidelines even, by doing a couple of reviews
> completely on their own.] Once a packager's account request is approved, there
> isn't any package reviewing process for updates applied to packages in fedora
> package scm. That means, you will get less hand-guiding or none at all - unless
> your sponsor (or somebody else) monitors your packaging activity closely.

Yes, I understand that, but how exactly am I supposed to learn more about packaging if you don't point the issues directly? Or was your objective to inflict more pain than necessary in order for the experience to stick on my brain? If so, mission accomplished.

> > It's better to go back and forth a couple of
> > times without pointing out the problem.
> 
> Nah, that's just your rather typical way of twisting things and making the
> process tiresome. The initial mission objective was clear:
> 
>   MUSTFIX: Package doesn't honor RPM_OPT_FLAGS
> 
> Either you understand what that means, where to look it up in the guidelines,
> and how to fix the issue -- or you don't.
> In case of the latter, ask. Simple as that.

Are you implying that I didn't understand what that means?

When I mentioned this line:
make V=y CFLAGS="$RPM_OPT_FLAGS" %{?_smp_mflags}

It was perfectly clear that I understood what that means.

Now, the fact that this particular package has C++ code (which I usually avoid), means that was not enough, and that was an *oversight* from my part.

The only lesson to learn here is: be careful with CFLAGS and C++ code. Not pointing out the problem directly didn't help at all to learn this lesson, so it served *absolutely no purpose*.

OTOH, maybe I'm wrong, and the lesson actually was "Michael speaks in riddles".
Comment 52 Felipe Contreras 2010-01-22 15:01:10 EST
(In reply to comment #42)
> Exercises for you:
> 
> 1) Show that the C++ file is built with Fedora's global optflags.
> 
> 2) Show that the file LICENSE is included in the packages built from the
> src.rpm.
> 
> 3) Show that no file in libmtag-devel.x86_64 (and libmtag-devel.ppc64) contains
> a hardcoded /usr/lib.    

All the issues have been addressed, and the latest SRPM file is up-to-date. So there's nothing pending acceptance, is there?
Comment 53 Felipe Contreras 2010-03-06 06:28:36 EST
All the technical issues have been tackled and there's no response so I opening a new bug: #571019.