On 02/14/2018 04:47 PM, Reindl Harald wrote:
Am 14.02.2018 um 22:27 schrieb David Cantrell:
I am not disputing the policy. I feel this change is pointless and is a lot of commits for no real benefit. They are not fixes. You're just scrubbing spec files that are not broken. Who cares? Update the packaging policy and be done with it
yeah, that's how most rpm-specs in Fedora look like "who cares, it works somehow, i can live with the mess" - for packages where i decided to start maintain them on my own i started with remove evrything i don't understand why it is needed and a large part of the specs was just gone and the remaining ones are clear
WTF - instead say thank you that somebody *does something* in Fedora instead talking and write pointless guidelines nobody seems to care about in the project a view people are pissed that he did the work teey should have been done long before as maintainer - seriously?
I'll back up. I combined both my opinion of the change itself and how I feel the change should be approached in Fedora.
First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached using pull requests. We have that functionality now thanks to Pagure, which is something we *never* had in dist-cvs or the former git system. Is that tedious? Yeah, it is. But pushing a change like that across many packages will not necessarily explain to package maintainers why that was done. If packages have not been cleaned up in that amount of time and things are still building, I question the urgency of the change. Pull requests give package maintainers an opportunity to be part of this change. Others have pointed this out too. Otherwise things like this will likely continue happening and package maintainers will overwhelming remain in the dark about what changes should be made in spec files.
I recognize the work is difficult and time consuming.
Again, this is my own opinion on how to approach the matter and however it is ultimately handled is fine with me.
On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached using pull requests. We have that functionality now thanks to Pagure, which is something we *never* had in dist-cvs or the former git system. Is that tedious? Yeah, it is. But pushing a change like that across many packages will not necessarily explain to package maintainers why that was done. If packages have not been cleaned up in that amount of time and things are still building, I question the urgency of the change. Pull requests give package maintainers an opportunity to be part of this change. Others have pointed this out too. Otherwise things like this will likely continue happening and package maintainers will overwhelming remain in the dark about what changes should be made in spec files.
What's the real benefit to getting each maintainer to remove the tag themselves via a pull request? After they get the pull request and understand the motivation they now know about something that should not be in their spec files. Is it really necessary for them to know a negative? Should they also remember a list of other tags that shouldn't be in there, or should we just remove the cruft, make sure the docs, examples and templates don't have those tags, and move on?
Remaining in the dark about a tag that has no meaning doesn't seem harmful.
I recognize the work is difficult and time consuming.
But removing a useless tag from spec files shouldn't be difficult and time consuming. One of Fedora's most productive and valuable maintainers is working on this, and you want to make it more difficult and slow him down?
On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached using pull requests. We have that functionality now thanks to Pagure, which is something we *never* had in dist-cvs or the former git system. Is that tedious? Yeah, it is. But pushing a change like that across many packages will not necessarily explain to package maintainers why that was done. If packages have not been cleaned up in that amount of time and things are still building, I question the urgency of the change. Pull requests give package maintainers an opportunity to be part of this change. Others have pointed this out too. Otherwise things like this will likely continue happening and package maintainers will overwhelming remain in the dark about what changes should be made in spec files.
What's the real benefit to getting each maintainer to remove the tag themselves via a pull request? After they get the pull request and understand the motivation they now know about something that should not be in their spec files. Is it really necessary for them to know a negative? Should they also remember a list of other tags that shouldn't be in there, or should we just remove the cruft, make sure the docs, examples and templates don't have those tags, and move on?
Remaining in the dark about a tag that has no meaning doesn't seem harmful.
My thinking there is that the PR serves as a way to communicate this change to package maintainers who have been copying existing spec files and templates to make new packages. Concern was mentioned that package maintainers keep using this tag when they don't need to, so the message has not been received. I think a PR serves as a good way to communicate that to maintainers.
Thanks,
On 15/02/18 11:10 -0500, David Cantrell wrote:
On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached using pull requests. We have that functionality now thanks to Pagure, which is something we *never* had in dist-cvs or the former git system. Is that tedious? Yeah, it is. But pushing a change like that across many packages will not necessarily explain to package maintainers why that was done. If packages have not been cleaned up in that amount of time and things are still building, I question the urgency of the change. Pull requests give package maintainers an opportunity to be part of this change. Others have pointed this out too. Otherwise things like this will likely continue happening and package maintainers will overwhelming remain in the dark about what changes should be made in spec files.
What's the real benefit to getting each maintainer to remove the tag themselves via a pull request? After they get the pull request and understand the motivation they now know about something that should not be in their spec files. Is it really necessary for them to know a negative? Should they also remember a list of other tags that shouldn't be in there, or should we just remove the cruft, make sure the docs, examples and templates don't have those tags, and move on?
Remaining in the dark about a tag that has no meaning doesn't seem harmful.
My thinking there is that the PR serves as a way to communicate this change to package maintainers who have been copying existing spec files and templates to make new packages. Concern was mentioned that package maintainers keep using this tag when they don't need to, so the message has not been received. I think a PR serves as a good way to communicate that to maintainers.
So remove it from all our specs and templates and let it be forgotten.
People keep copying it from existing specs because nobody has done the work of removing all the existing uses before now.
Once it's gone we can make rpmlint warn about it, so it doesn't keep coming back.
On 02/15/2018 06:19 PM, Jonathan Wakely wrote:
On 15/02/18 11:10 -0500, David Cantrell wrote:
On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached using pull requests. We have that functionality now thanks to Pagure, which is something we *never* had in dist-cvs or the former git system. Is that tedious? Yeah, it is. But pushing a change like that across many packages will not necessarily explain to package maintainers why that was done. If packages have not been cleaned up in that amount of time and things are still building, I question the urgency of the change. Pull requests give package maintainers an opportunity to be part of this change. Others have pointed this out too. Otherwise things like this will likely continue happening and package maintainers will overwhelming remain in the dark about what changes should be made in spec files.
What's the real benefit to getting each maintainer to remove the tag themselves via a pull request? After they get the pull request and understand the motivation they now know about something that should not be in their spec files. Is it really necessary for them to know a negative? Should they also remember a list of other tags that shouldn't be in there, or should we just remove the cruft, make sure the docs, examples and templates don't have those tags, and move on?
Remaining in the dark about a tag that has no meaning doesn't seem harmful.
My thinking there is that the PR serves as a way to communicate this change to package maintainers who have been copying existing spec files and templates to make new packages. Concern was mentioned that package maintainers keep using this tag when they don't need to, so the message has not been received. I think a PR serves as a good way to communicate that to maintainers.
So remove it from all our specs and templates and let it be forgotten.
People keep copying it from existing specs because nobody has done the work of removing all the existing uses before now.
Once it's gone we can make rpmlint warn about it, so it doesn't keep coming back.
Actually, inspired by this thread, rpm will start at least warning about BuildRoot tag in the next release or so.
The reason for silently ignoring all this time was to allow spec sharing between old and new rpm versions, but I guess the time has come to bury it for good.
- Panu -
On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote:
Actually, inspired by this thread, rpm will start at least warning about BuildRoot tag in the next release or so.
The reason for silently ignoring all this time was to allow spec sharing between old and new rpm versions, but I guess the time has come to bury it for good.
Please do not code packaging policies into rpm, that's what tools like rpmlint are for.
Thanks, Michael.
On 02/16/2018 12:54 PM, Michael Schroeder wrote:
On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote:
Actually, inspired by this thread, rpm will start at least warning about BuildRoot tag in the next release or so.
The reason for silently ignoring all this time was to allow spec sharing between old and new rpm versions, but I guess the time has come to bury it for good.
Please do not code packaging policies into rpm, that's what tools like rpmlint are for.
I don't see long, long since obsoleted rpm tag being packaging policy but a technical rpm matter.
Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out there that do. If rpm itself doesn't directly complain about such things they'll simply never get cleaned up.
- Panu -
On Fri, 2018-02-16 at 13:21 +0200, Panu Matilainen wrote:
On 02/16/2018 12:54 PM, Michael Schroeder wrote:
On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote:
Actually, inspired by this thread, rpm will start at least warning about BuildRoot tag in the next release or so.
The reason for silently ignoring all this time was to allow spec sharing between old and new rpm versions, but I guess the time has come to bury it for good.
Please do not code packaging policies into rpm, that's what tools like rpmlint are for.
I don't see long, long since obsoleted rpm tag being packaging policy but a technical rpm matter.
Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out there that do. If rpm itself doesn't directly complain about such things they'll simply never get cleaned up.
...if only we could collectively decide to write less guidelines and more rationales for rules enforced by tools... One can always dream.
In this particular case IMHO it would've been perfectly acceptable for koji to start bombing on builds with specs containing BuildRoot
-Yanko
On 16 February 2018 at 11:21, Panu Matilainen pmatilai@redhat.com wrote: [..]
Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out there that do. If rpm itself doesn't directly complain about such things they'll simply never get cleaned up.
And this is why for example calling rpmlint should be one of the pre steps done by koji on sending build request. It would be good to perform at least one time a month rpmlint test across all packages, and if it anything wrong automatically should be created git issue or bugzilla ticket.
kloczek
On 16/02/18 12:36, Tomasz Kłoczko wrote:
On 16 February 2018 at 11:21, Panu Matilainen <pmatilai@redhat.com mailto:pmatilai@redhat.com> wrote: [..]
Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out there that do. If rpm itself doesn't directly complain about such things they'll simply never get cleaned up.
And this is why for example calling rpmlint should be one of the pre steps done by koji on sending build request. It would be good to perform at least one time a month rpmlint test across all packages, and if it anything wrong automatically should be created git issue or bugzilla ticket.
Well rpmlint would need to be made a lot better first. The rate of false positives at the moment is enormous.
In fact pretty much any non-trivial package has rpmlint warnings which are no problem at all, even if only spellcheck issues.
Tom
On Fri, Feb 16, 2018 at 6:43 AM, Tom Hughes tom@compton.nu wrote:
On 16/02/18 12:36, Tomasz Kłoczko wrote:
On 16 February 2018 at 11:21, Panu Matilainen <pmatilai@redhat.com mailto:pmatilai@redhat.com> wrote: [..]
Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out there that do. If rpm itself doesn't directly complain about such things they'll simply never get cleaned up.
And this is why for example calling rpmlint should be one of the pre steps done by koji on sending build request. It would be good to perform at least one time a month rpmlint test across all packages, and if it anything wrong automatically should be created git issue or bugzilla ticket.
Well rpmlint would need to be made a lot better first. The rate of false positives at the moment is enormous.
In fact pretty much any non-trivial package has rpmlint warnings which are no problem at all, even if only spellcheck issues.
I think it would be better to have fedpkg run rpmlint on "fedpkg build". It can be informative only. At least then it would not require the maintainer to run rpmlint themselves.
One thing I started doing was ALWAYS using spectool to download the new sources for an update before doing a fedpkg upload-sources. I found that the download links moved from time to time with some upstreams. That way I know my source URL is good.
Thanks, Richard
On 16/02/18 13:13, Richard Shaw wrote:
I think it would be better to have fedpkg run rpmlint on "fedpkg build". It can be informative only. At least then it would not require the maintainer to run rpmlint themselves.
Please no. See above about ridiculous noise.
One thing I started doing was ALWAYS using spectool to download the new sources for an update before doing a fedpkg upload-sources. I found that the download links moved from time to time with some upstreams. That way I know my source URL is good.
I don't follow. How else (other than manual download) do you get your sources other than by spectool? Surely if you download them manually you would notice any URL change?
And it's fedpkg new-sources, not upload-sources ;-)
Tom
On Fri, Feb 16, 2018 at 7:22 AM, Tom Hughes tom@compton.nu wrote:
On 16/02/18 13:13, Richard Shaw wrote:
I think it would be better to have fedpkg run rpmlint on "fedpkg build".
It can be informative only. At least then it would not require the maintainer to run rpmlint themselves.
Please no. See above about ridiculous noise.
Less noise that doing it on commit :)
One thing I started doing was ALWAYS using spectool to download the new
sources for an update before doing a fedpkg upload-sources. I found that the download links moved from time to time with some upstreams. That way I know my source URL is good.
I don't follow. How else (other than manual download) do you get your sources other than by spectool? Surely if you download them manually you would notice any URL change?
I get notifications for most of my packages which provide download links which you can easily do "curl -LO <paste link>" which is what I used to do.
Even better would be to be able to tell fedpkg to go download the source directly instead of me downloading it and then uploading it.
And it's fedpkg new-sources, not upload-sources ;-)
Ehh.. I went from memory after only one cup of coffee :)
Thanks, Richard
I don't follow. How else (other than manual download) do you get your sources other than by spectool? Surely if you download them manually you would notice any URL change?
You can have an old source copy in Sources (downloaded manually of by spectool) but by the time you finish QA and start Fedora inclusion process the origin website restructured and the Source URL is no longer good.
And many people check the URL still exists, but not that the returned filename has not changed (and lastly you have the hash)
That's one of the many reasons I had to write %forgemeta (it's available in devel, use it, test it report problems!)
Regards,
On 16 February 2018 at 12:43, Tom Hughes tom@compton.nu wrote:
On 16/02/18 12:36, Tomasz Kłoczko wrote:
On 16 February 2018 at 11:21, Panu Matilainen <pmatilai@redhat.com mailto:pmatilai@redhat.com> wrote: [..]
Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out there that do. If rpm itself doesn't directly complain about such things they'll simply never get cleaned up.
And this is why for example calling rpmlint should be one of the pre steps done by koji on sending build request. It would be good to perform at least one time a month rpmlint test across all packages, and if it anything wrong automatically should be created git issue or bugzilla ticket.
Well rpmlint would need to be made a lot better first. The rate of false positives at the moment is enormous.
With such approach always will be chicken and egg problem because rpmlint will be not improving because it will be not used, and it will be not improving because it will not widely used. It is necessary to cut this loop somewhere, and if it will be added in whole pipeline of the Fedora processes single change in rpmlint will automatically expose some number of packages with some issues. I'm 100% sure that even current rpmlint will expose some number of specs which needs to be cleaned up.
"Not everybody runs rpmlint"
If everybody will be using rpmlint it will start improving .. as same as "build it and they will come".
kloczek
On 2018-02-16, 12:36 GMT, Tomasz Kłoczko wrote:
And this is why for example calling rpmlint should be one of the pre steps done by koji on sending build request. It would be good to perform at least one time a month rpmlint test across all packages, and if it anything wrong automatically should be created git issue or bugzilla ticket.
All that would be awesome (or even blocking Koji build on rpmlint errors), but rpmlint then have to be substantially better: I am not sure I met a real life package which would be completely silent (no warnings, no errors) on fedpkg lint.
It would be actually nice, if we could get there, but unfortunately it seems to me we are far from this goal yet (if anybody has that goal).
Best,
Matěj
On 02/16/2018 02:36 PM, Tomasz Kłoczko wrote:
On 16 February 2018 at 11:21, Panu Matilainen <pmatilai@redhat.com mailto:pmatilai@redhat.com> wrote: [..]
Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out there that do. If rpm itself doesn't directly complain about such things they'll simply never get cleaned up.
And this is why for example calling rpmlint should be one of the pre steps done by koji on sending build request.
People building packages on koji are an even smaller percentage because that's limited to the Fedora/EPEL ecosystem.
- Panu -
On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely jwakely@fedoraproject.org wrote:
On 15/02/18 11:10 -0500, David Cantrell wrote:
On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached using pull requests. We have that functionality now thanks to Pagure, which is something we *never* had in dist-cvs or the former git system. Is that tedious? Yeah, it is. But pushing a change like that across many packages will not necessarily explain to package maintainers why that was done. If packages have not been cleaned up in that amount of time and things are still building, I question the urgency of the change. Pull requests give package maintainers an opportunity to be part of this change. Others have pointed this out too. Otherwise things like this will likely continue happening and package maintainers will overwhelming remain in the dark about what changes should be made in spec files.
What's the real benefit to getting each maintainer to remove the tag themselves via a pull request? After they get the pull request and understand the motivation they now know about something that should not be in their spec files. Is it really necessary for them to know a negative? Should they also remember a list of other tags that shouldn't be in there, or should we just remove the cruft, make sure the docs, examples and templates don't have those tags, and move on?
Remaining in the dark about a tag that has no meaning doesn't seem harmful.
My thinking there is that the PR serves as a way to communicate this change to package maintainers who have been copying existing spec files and templates to make new packages. Concern was mentioned that package maintainers keep using this tag when they don't need to, so the message has not been received. I think a PR serves as a good way to communicate that to maintainers.
So remove it from all our specs and templates and let it be forgotten.
People keep copying it from existing specs because nobody has done the work of removing all the existing uses before now.
Once it's gone we can make rpmlint warn about it, so it doesn't keep coming back.
As upstream for rpmlint, I do not believe anyone cares at all about rpmlint in Fedora. One more warning or error won't mean anything. From time to time, I have considered making a proper rpmlint policy for Fedora, but I always decide not to because it's clear that that people don't care about it and ignore it.
Until we can fail builds on rpmlint errors (as both Mageia and openSUSE do), it's pointless to consider rpmlint as something that ensures things stay clean and sane.
On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote:
On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely jwakely@fedoraproject.org wrote:
On 15/02/18 11:10 -0500, David Cantrell wrote:
On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached using pull requests. We have that functionality now thanks to Pagure, which is something we *never* had in dist-cvs or the former git system. Is that tedious? Yeah, it is. But pushing a change like that across many packages will not necessarily explain to package maintainers why that was done. If packages have not been cleaned up in that amount of time and things are still building, I question the urgency of the change. Pull requests give package maintainers an opportunity to be part of this change. Others have pointed this out too. Otherwise things like this will likely continue happening and package maintainers will overwhelming remain in the dark about what changes should be made in spec files.
What's the real benefit to getting each maintainer to remove the tag themselves via a pull request? After they get the pull request and understand the motivation they now know about something that should not be in their spec files. Is it really necessary for them to know a negative? Should they also remember a list of other tags that shouldn't be in there, or should we just remove the cruft, make sure the docs, examples and templates don't have those tags, and move on?
Remaining in the dark about a tag that has no meaning doesn't seem harmful.
My thinking there is that the PR serves as a way to communicate this change to package maintainers who have been copying existing spec files and templates to make new packages. Concern was mentioned that package maintainers keep using this tag when they don't need to, so the message has not been received. I think a PR serves as a good way to communicate that to maintainers.
So remove it from all our specs and templates and let it be forgotten.
People keep copying it from existing specs because nobody has done the work of removing all the existing uses before now.
Once it's gone we can make rpmlint warn about it, so it doesn't keep coming back.
As upstream for rpmlint, I do not believe anyone cares at all about rpmlint in Fedora. One more warning or error won't mean anything. From time to time, I have considered making a proper rpmlint policy for Fedora, but I always decide not to because it's clear that that people don't care about it and ignore it.
I think this is more or less a chicken and egg problem - rpmlint output is currently so insanely bad and useless that most people indeed ignore it. So arguably if the output was better more people would likely use it.
Until we can fail builds on rpmlint errors (as both Mageia and openSUSE do), it's pointless to consider rpmlint as something that ensures things stay clean and sane.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On 16/02/18 17:21, Martin Kolman wrote:
On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote:
[...snip...]
As upstream for rpmlint, I do not believe anyone cares at all about rpmlint in Fedora. One more warning or error won't mean anything. From time to time, I have considered making a proper rpmlint policy for Fedora, but I always decide not to because it's clear that that people don't care about it and ignore it.
I think this is more or less a chicken and egg problem - rpmlint output is currently so insanely bad and useless that most people indeed ignore it. So arguably if the output was better more people would likely use it.
I certainly might be a weird guy with odd perspectives .... or I'm haven't touched packages which has had so enormous issues with rpmlint it didn't make sense to fix it. Or I'm lacking good enough experience (I've not been maintaining that many Fedora packages).
But my "worst" example was probably the openvpn package I'm now in charge for (and I am a core upstream developer for that project as well). But it didn't take that much efforts to iron out most of those issues. False positives are also easily filtered out by adding .rpmlint to the dist-git repository.
If anyone have examples of those really nasty rpmlint reports ... that would be far more valuable to this discussion than just claiming it is "insanely bad and useless". And since we have the attention of the rpmlint maintainer, perhaps there would be a better chance to figure out how to report those issues in a better way - or remove what isn't truly an issue.
On 16/02/18 18:26, David Sommerseth wrote:
But my "worst" example was probably the openvpn package I'm now in charge for (and I am a core upstream developer for that project as well). But it didn't take that much efforts to iron out most of those issues. False positives are also easily filtered out by adding .rpmlint to the dist-git repository.
I suspect approximately nobody knows that you can create such a file because as far as I can tell it's not well documented.
Even now having googled a bit I haven't managed to find anything telling me what I can put in it.
Tom
On 16/02/18 19:48, Tom Hughes wrote:
On 16/02/18 18:26, David Sommerseth wrote:
But my "worst" example was probably the openvpn package I'm now in charge for (and I am a core upstream developer for that project as well). But it didn't take that much efforts to iron out most of those issues. False positives are also easily filtered out by adding .rpmlint to the dist-git repository.
I suspect approximately nobody knows that you can create such a file because as far as I can tell it's not well documented.
Even now having googled a bit I haven't managed to find anything telling me what I can put in it.
Have a look here: /usr/share/doc/rpmlint*/config.example
On Fri, Feb 16, 2018 at 06:48:17PM +0000, Tom Hughes wrote:
On 16/02/18 18:26, David Sommerseth wrote:
But my "worst" example was probably the openvpn package I'm now in charge for (and I am a core upstream developer for that project as well). But it didn't take that much efforts to iron out most of those issues. False positives are also easily filtered out by adding .rpmlint to the dist-git repository.
I suspect approximately nobody knows that you can create such a file because as far as I can tell it's not well documented.
$ fedpkg lint --help usage: fedpkg lint [-h] [--info] [--rpmlintconf RPMLINTCONF]
Rpmlint can be configured using the --rpmlintconf/-r option or by setting a .rpmlint file in the working directory
optional arguments: -h, --help show this help message and exit --info, -i Display explanations for reported messages --rpmlintconf RPMLINTCONF, -r RPMLINTCONF Use a specific configuration file for rpmlint
On 02/17/2018 02:30 AM, Pierre-Yves Chibon wrote:
Rpmlint can be configured using the --rpmlintconf/-r option or by setting a .rpmlint file in the working directory
There's an open RFE to get taskotron to use such a file, though it hasn't yet been suggested that it use the same path as fedpkg:
https://pagure.io/taskotron/task-rpmlint/issue/5
I can't log in to Pagure right now for some reason, so I can't make that suggestion, but hopefully I'll remember to once that gets fixed ☺
On Friday, February 16, 2018 7:48:17 PM CET Tom Hughes wrote:
On 16/02/18 18:26, David Sommerseth wrote:
But my "worst" example was probably the openvpn package I'm now in charge for (and I am a core upstream developer for that project as well). But it didn't take that much efforts to iron out most of those issues. False positives are also easily filtered out by adding .rpmlint to the dist-git repository.
I suspect approximately nobody knows that you can create such a file because as far as I can tell it's not well documented.
Even now having googled a bit I haven't managed to find anything telling me what I can put in it.
If I'm not wrong, rpmlint doesn't *itself* accept that file: https://github.com/rpm-software-management/rpmlint/issues/125
Pavel
"DS" == David Sommerseth dazo@eurephia.org writes:
DS> False positives are also easily filtered out by adding .rpmlint to DS> the dist-git repository.
Which is an absolutely terrible name for that. Really. Why would anyone at all ever think it is a good idea to _hide_ the file that controls that?
- J<
On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"DS" == David Sommerseth dazo@eurephia.org writes:
DS> False positives are also easily filtered out by adding .rpmlint to DS> the dist-git repository.
Which is an absolutely terrible name for that. Really. Why would anyone at all ever think it is a good idea to _hide_ the file that controls that?
I agree. What do we need to do to change this to <srcpkgname>.rpmlintrc?
On Sat, Feb 17, 2018 at 10:37:08PM -0500, Neal Gompa wrote:
On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
> "DS" == David Sommerseth dazo@eurephia.org writes:
DS> False positives are also easily filtered out by adding .rpmlint to DS> the dist-git repository.
Which is an absolutely terrible name for that. Really. Why would anyone at all ever think it is a good idea to _hide_ the file that controls that?
I agree. What do we need to do to change this to <srcpkgname>.rpmlintrc?
A pull-request to fedpkg or rpkg sounds like a good start :)
Pierre
On Sun, Feb 18, 2018 at 09:13:22AM +0100, Pierre-Yves Chibon wrote:
On Sat, Feb 17, 2018 at 10:37:08PM -0500, Neal Gompa wrote:
On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
>> "DS" == David Sommerseth dazo@eurephia.org writes:
DS> False positives are also easily filtered out by adding .rpmlint to DS> the dist-git repository.
Which is an absolutely terrible name for that. Really. Why would anyone at all ever think it is a good idea to _hide_ the file that controls that?
I agree. What do we need to do to change this to <srcpkgname>.rpmlintrc?
A pull-request to fedpkg or rpkg sounds like a good start :)
https://pagure.io/rpkg/pull-request/293
"NG" == Neal Gompa ngompa13@gmail.com writes:
NG> As upstream for rpmlint, I do not believe anyone cares at all about NG> rpmlint in Fedora.
We seemingly care so little for it that the rpmlint status appears on every bodhi update.
I did spend some time trying to make rpmlint better ages ago and kind of got blocked by the restriction that it (at the time) had to conform to whatever RHEL4 wanted. But that was obviously a long time ago.
NG> Until we can fail builds on rpmlint errors (as both Mageia and NG> openSUSE do), it's pointless to consider rpmlint as something that NG> ensures things stay clean and sane.
If you can tolerate no false positives from rpmlint then there must be a pile of things it doesn't look at. I always saw it as a useful advisory tool but have difficulty imagining that you could gate off of it.
What I did was hack my local setup (which does auto-rpmlint directly within vim) to accept magic comments to tell it to stop complaining about certain things. I recall suggesting that upstream a long time ago but not having much luck. But again, we're talking over a decade here.
- J<
On Fri, Feb 16, 2018 at 4:24 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"NG" == Neal Gompa ngompa13@gmail.com writes:
NG> As upstream for rpmlint, I do not believe anyone cares at all about NG> rpmlint in Fedora.
We seemingly care so little for it that the rpmlint status appears on every bodhi update.
I did spend some time trying to make rpmlint better ages ago and kind of got blocked by the restriction that it (at the time) had to conform to whatever RHEL4 wanted. But that was obviously a long time ago.
NG> Until we can fail builds on rpmlint errors (as both Mageia and NG> openSUSE do), it's pointless to consider rpmlint as something that NG> ensures things stay clean and sane.
If you can tolerate no false positives from rpmlint then there must be a pile of things it doesn't look at. I always saw it as a useful advisory tool but have difficulty imagining that you could gate off of it.
What I did was hack my local setup (which does auto-rpmlint directly within vim) to accept magic comments to tell it to stop complaining about certain things. I recall suggesting that upstream a long time ago but not having much luck. But again, we're talking over a decade here.
The problem with Bodhi is that it's too late. By that point the build has been submitted, it's gone through all the steps involved in submitting updates, and to make matters worse, *all* test results are now hidden from people by default. It took me a while to figure out where the test results had gone after the change occurred. I honestly thought we had given up on those things initially. I've always felt that some of those tests should be happening post-build, not post-update submission. Failing builds on "obviously bad" packages makes for a bigger incentive to improve packaging.
As for toleration of false positives, that's more of a sign that we don't quite have a well-tuned configuration and maybe there are some checks in rpmlint itself that need to be tweaked. In both Mageia and openSUSE, we have rpmlint policy packages that define the checks, the "scores", and the threshold in which it is bad enough to make something be rejected. The reason for this is because we want to block packages that are "obviously wrong" from being accepted by the build system. It's really the only way to make people consider improving their packaging. Everyone has tried nicer ways, and it doesn't work.
And in both Mageia and openSUSE's case, you can define <srcpkgname>.rpmlintrc files that are picked up by the build system to ignore issues that are obvious false positives. Yes, this could be abused, and perhaps we shouldn't do that. But if you want packaging to improve, you need a way for people to reliably determine what they're doing is "good" or "bad". Right now, we don't have that, and my personal feeling is that if I spend the effort in doing so, it would be wasted because it wouldn't result in any improvement.
"NG" == Neal Gompa ngompa13@gmail.com writes:
NG> The problem with Bodhi is that it's too late.
I don't disagree, but you've switched up your argument. You made the statement that Fedora doesn't care about rpmlint so there's no point in improving it. People do care, and rpmlint is featured in an important place in an important application. It could even be used for gating, except that it gives far too many false positives.
NG> And in both Mageia and openSUSE's case, you can define NG> <srcpkgname>.rpmlintrc files that are picked up by the build system NG> to ignore issues that are obvious false positives.
And of course we have that, too, but it's not used in as many places. I would definitely want to get the name changed from the terrible ".rpmlint" before that happens, though.
- J<
On Sat, Feb 17, 2018 at 11:14 AM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"NG" == Neal Gompa ngompa13@gmail.com writes:
NG> The problem with Bodhi is that it's too late.
I don't disagree, but you've switched up your argument. You made the statement that Fedora doesn't care about rpmlint so there's no point in improving it. People do care, and rpmlint is featured in an important place in an important application. It could even be used for gating, except that it gives far too many false positives.
You mentioned Bodhi, so I mentioned that where it happens is not helpful. I could have also brought up the general attitude I encounter from people in the mailing list and on IRC that rpmlint is useless and its warnings and errors can be ignored, but that's not solvable without making it a centerpiece in the package build process.
I would argue that the way Bodhi shows the update checks is actually indicating that they're _not_ important. They're hidden away, and many times, clicking on that tab will give you nothing but an endless loading screen, which indicates that there's been no priority to ensuring the test data is always accessible, anyway. It is _not_ front and center in mock or koji builds. When tests have failures or warnings, they are _not_ featured on the update page itself. They are still hidden away.
Again, making the rpmlint policy that approximates Fedora packaging guidelines is possible, but I don't think it'd be used.
NG> And in both Mageia and openSUSE's case, you can define NG> <srcpkgname>.rpmlintrc files that are picked up by the build system NG> to ignore issues that are obvious false positives.
And of course we have that, too, but it's not used in as many places. I would definitely want to get the name changed from the terrible ".rpmlint" before that happens, though.
What do you want it to be?
Dne 17.2.2018 v 14:01 Neal Gompa napsal(a):
On Fri, Feb 16, 2018 at 4:24 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
> "NG" == Neal Gompa ngompa13@gmail.com writes:
NG> As upstream for rpmlint, I do not believe anyone cares at all about NG> rpmlint in Fedora.
We seemingly care so little for it that the rpmlint status appears on every bodhi update.
I did spend some time trying to make rpmlint better ages ago and kind of got blocked by the restriction that it (at the time) had to conform to whatever RHEL4 wanted. But that was obviously a long time ago.
NG> Until we can fail builds on rpmlint errors (as both Mageia and NG> openSUSE do), it's pointless to consider rpmlint as something that NG> ensures things stay clean and sane.
If you can tolerate no false positives from rpmlint then there must be a pile of things it doesn't look at. I always saw it as a useful advisory tool but have difficulty imagining that you could gate off of it.
What I did was hack my local setup (which does auto-rpmlint directly within vim) to accept magic comments to tell it to stop complaining about certain things. I recall suggesting that upstream a long time ago but not having much luck. But again, we're talking over a decade here.
The problem with Bodhi
The problem with Bodhi is that we don't use Bodhi for Rawhide where majority of work should be done.
Vít
is that it's too late. By that point the build has been submitted, it's gone through all the steps involved in submitting updates, and to make matters worse, *all* test results are now hidden from people by default. It took me a while to figure out where the test results had gone after the change occurred. I honestly thought we had given up on those things initially. I've always felt that some of those tests should be happening post-build, not post-update submission. Failing builds on "obviously bad" packages makes for a bigger incentive to improve packaging.
As for toleration of false positives, that's more of a sign that we don't quite have a well-tuned configuration and maybe there are some checks in rpmlint itself that need to be tweaked. In both Mageia and openSUSE, we have rpmlint policy packages that define the checks, the "scores", and the threshold in which it is bad enough to make something be rejected. The reason for this is because we want to block packages that are "obviously wrong" from being accepted by the build system. It's really the only way to make people consider improving their packaging. Everyone has tried nicer ways, and it doesn't work.
And in both Mageia and openSUSE's case, you can define <srcpkgname>.rpmlintrc files that are picked up by the build system to ignore issues that are obvious false positives. Yes, this could be abused, and perhaps we shouldn't do that. But if you want packaging to improve, you need a way for people to reliably determine what they're doing is "good" or "bad". Right now, we don't have that, and my personal feeling is that if I spend the effort in doing so, it would be wasted because it wouldn't result in any improvement.
On Mon, Feb 19, 2018 at 6:19 AM, Vít Ondruch vondruch@redhat.com wrote:
Dne 17.2.2018 v 14:01 Neal Gompa napsal(a):
On Fri, Feb 16, 2018 at 4:24 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
>> "NG" == Neal Gompa ngompa13@gmail.com writes:
NG> As upstream for rpmlint, I do not believe anyone cares at all about NG> rpmlint in Fedora.
We seemingly care so little for it that the rpmlint status appears on every bodhi update.
I did spend some time trying to make rpmlint better ages ago and kind of got blocked by the restriction that it (at the time) had to conform to whatever RHEL4 wanted. But that was obviously a long time ago.
NG> Until we can fail builds on rpmlint errors (as both Mageia and NG> openSUSE do), it's pointless to consider rpmlint as something that NG> ensures things stay clean and sane.
If you can tolerate no false positives from rpmlint then there must be a pile of things it doesn't look at. I always saw it as a useful advisory tool but have difficulty imagining that you could gate off of it.
What I did was hack my local setup (which does auto-rpmlint directly within vim) to accept magic comments to tell it to stop complaining about certain things. I recall suggesting that upstream a long time ago but not having much luck. But again, we're talking over a decade here.
The problem with Bodhi
The problem with Bodhi is that we don't use Bodhi for Rawhide where majority of work should be done.
Bodhi is too slow and too heavy for this. Before even thinking about doing this, fix Bodhi first. For the majority of my updates, I can't even *get* the check information, as it gets stuck fetching. Update merging into releases takes too long, and failed tests do not show up on the main page (probably was not considered because of how poorly the test information fetching goes).
I still disagree with Bodhi gating Rawhide, but if you're going to make things more difficult on people, at least fix it so Bodhi provides some value consistently.
On Mon, Feb 19, 2018 at 09:06:17AM -0500, Neal Gompa wrote:
failed tests do not show up on the main page (probably was not considered because of how poorly the test information fetching goes).
I guess you're referring to the: `Tests Passed` under the `Test Gating Status` on the right hand side menu of https://bodhi.fedoraproject.org/updates/FEDORA-2018-d7644a98e0 or maybe the `Tests Waiting` under the same section at the same place in https://bodhi.fedoraproject.org/updates/FEDORA-2018-e452cb1e69
Or do you have something else in mind?
Pierre
On Mon, Feb 19, 2018 at 11:30 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Mon, Feb 19, 2018 at 09:06:17AM -0500, Neal Gompa wrote:
failed tests do not show up on the main page (probably was not considered because of how poorly the test information fetching goes).
I guess you're referring to the: `Tests Passed` under the `Test Gating Status` on the right hand side menu of https://bodhi.fedoraproject.org/updates/FEDORA-2018-d7644a98e0 or maybe the `Tests Waiting` under the same section at the same place in https://bodhi.fedoraproject.org/updates/FEDORA-2018-e452cb1e69
Or do you have something else in mind?
Those are fine and dandy, but I'm referring to when there are *any* failed tests, their rows that show up under the "Automated Tests" tab should also show up at the top of the "Details" tab, under a "Failed Tests" section.
That way people can see them up front, click on them to see details, and it's much more obvious why an update is being blocked.
On 02/19/2018 06:19 AM, Vít Ondruch wrote:
The problem with Bodhi is that we don't use Bodhi for Rawhide where majority of work should be done.
There is an infrastructure hackathon in April where we hope to discuss a way to enable Bodhi for Rawhide so it can gate updates based on automated tests.
Dne 19.2.2018 v 15:30 Randy Barlow napsal(a):
On 02/19/2018 06:19 AM, Vít Ondruch wrote:
The problem with Bodhi is that we don't use Bodhi for Rawhide where majority of work should be done.
There is an infrastructure hackathon in April where we hope to discuss a way to enable Bodhi for Rawhide so it can gate updates based on automated tests.
Cool! Good to hear that.
V.