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.
This is my first package, requesting a sponsor.
> 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. ;)
(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.
(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.
(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".
(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.
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.
(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.
(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.
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.
Ok. I've made the 0.3.2 release which deals with all these comments from here. Anything else pending acceptance?
Ping. It seems everything has been done.
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?
(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?
> 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.
(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.
(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.
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.
(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.
Try 2: Spec URL: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.2-2.spec SRPM URL: http://people.freedesktop.org/~felipec/fedora/libmtag-0.3.2-2.fc12.src.rpm
> % 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?
(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.
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.
> % 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".
(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
Felipe, you changed the test-case and got the the sha1sum for an empty file. :-) qed
(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.
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.
(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.
> 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).
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
(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.
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.
(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.
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.
(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?
(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.
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.
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
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.
(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.
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.
(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
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
> 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.
(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.
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
(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.
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. ;-)
(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.
(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".
(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?
All the technical issues have been tackled and there's no response so I opening a new bug: #571019.