Bug 481601 - please update to at least 0.85-2
please update to at least 0.85-2
Status: CLOSED NOTABUG
Product: Fedora EPEL
Classification: Fedora
Component: rpmlint (Show other bugs)
el5
All Linux
low Severity medium
: ---
: ---
Assigned To: manuel wolfshant
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-26 12:38 EST by Levente Farkas
Modified: 2009-02-05 06:37 EST (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Levente Farkas 2009-01-26 12:38:13 EST
please update to at least version 0.85-2 in order to be able to build the latest mingw32-filesystem on epel too.
thanks.
Comment 1 manuel wolfshant 2009-01-26 14:07:56 EST
As you could see from the very first line of the changelog quoted below, the version of rpmlint which has just been pushed in EPEL-testing includes ALL the updates that the fedora rawhide version implemented until yesterday:

* Sun Jan 25 2009 Manuel Wolfshant <wolfy at fedoraproject.org> - 0.85-1
- Sync with Fedora rawhide version 0.85-3, including
-- Sync Fedora license list as Wiki revision 1.34)
-- filter out filename-too-long-for-joliet and symlink-should-be-*
   warnings in default config.


Could you please explain with more details what is the problem that you are facing (a show case proving that there is a problem would be excellent) ? Or maybe you have just been tricked by the release tag in epel (1) versus rawhide (3) ?
Please note that rpmlint in EPEL tracks to the best of my ability the version from rawhide and unless a very good reason is provided it will not implement checks which are not present over there.
Please also note that rpmlint never "disallows building", it is just a verification tool. Actual building is performed in mock and is completely independent of rpmlint.
Comment 3 manuel wolfshant 2009-01-26 17:12:28 EST
The patch referenced in https://www.zarb.org/pipermail/rpmlint-discuss/2009-January/000684.html is already in http://download.fedora.redhat.com/pub/epel/testing/5/i386/rpmlint-0.85-1.el5.noarch.rpm
Please be as kind as to test it and let me know the outcome.
Comment 4 Levente Farkas 2009-01-28 08:05:27 EST
thanks working.
Comment 5 manuel wolfshant 2009-01-28 08:48:09 EST
In this case I am going to close the bug.
Comment 6 Levente Farkas 2009-02-02 15:34:50 EST
wouldn't it be better if fedora and epel package version will be in sync?
Comment 7 manuel wolfshant 2009-02-03 02:56:32 EST
I examined this. But it seemed odd to push the very first version with a -3 tag. And I did my best to add all the relevant info in the changelog.
Comment 8 Levente Farkas 2009-02-03 03:43:46 EST
but this cause headache for other project. eg. when i project put 
BuildRequires: rpmlint >= 0.85-3
then it also has to have to split epel and fedora packages. which is a bad habbit. it'd be better for everyone to keep all branch as close together as possible. so imho it's smaller problem than start with -3 tag.
Comment 9 manuel wolfshant 2009-02-03 06:40:08 EST
Too bad that your request came a bit too late, as I have already started with -1 and the package has already been pushed.
I suggest to use different BRs in your spec because for sure the rawhide version of rpmlint will have many more releases than the ones from EPEL.
Comment 10 Levente Farkas 2009-02-03 06:57:25 EST
imho the best solution can be you simple push a new build into epel where the only changes is to change to -3. it won't cause any problem for anyone and will be in sync with rawhide. on the other hand of course rawhide can higher release in future then epel.
Comment 11 manuel wolfshant 2009-02-05 06:34:40 EST
I have just built -3.1 in plague.
hope this helps.
Comment 12 Levente Farkas 2009-02-05 06:37:52 EST
thanks.

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