fedora-review 0.5.0 released
by Stanislav Ochotnicky
Codename: "Thursday Release"
fedora-review devs proudly announce new release with tons of bugfixes and new
features.
Kudos to our latest contributors:
- Pavel Raiskup (autotools checks)
- Josef Stribny (update of ruby checks)
Gentle reminder for PHP reviewers: you should install php-pci package to get
static code analysis during review (split off due to big dependency chain).
New stuff
=========
- Removing the only php test which is outdated (5addbb4).
- Add checks for autotools obsolete macro usage (#206).
- Update ruby macro usage (#212).
- Automate several directory ownership checks (#187).
- Support display and modification of active plugins, initiated by
discussion in bz 989946. Adds plugin and flag feedback to template.
New --display-plugins and --plugins options.
- New DISTTAG flag used when disttag can't be deduced from prebuilt
packages (09304f2).
- Add hint if package has ExclusiveArch in deps (#166).
- Don't use and require mock when using --prebuilt (#208).
- Fix macro usage test which was misleading and plain wrong (#227).
- Fix bug for packages with a '++' in their name (bz 971977).
- Fix bug for check-desktop-database (#127, bz 952593).
- Preserve modification times when unpacking srpm and rpms (bz 982101).
- Don't flag remove %buildroot/path as error (bz 972672)
- Run rpmlint also on srpm (bz 981977)
- Support display and modification of active plugins, initiated by
discussion in bz 989946. Adds plugin and flag feedback to template.
- New --display-plugins and --plugins options.
- Stability tested on > 12000 packages. Fixes:
+ Corner case .desktop files (544eca2, 18cc82f).
+ Macros in %files line (7566e91).
+ Subpackages with version <> base package (4a6597a).
+ CheckDisttag: many fixes (ee87f44).
+ Look in %post/%postun for update-mime-database (7e73f89).
+ Clean up check-large-data output (8a37267).
+ Don't require R:rubygems on -doc, -devel and -fonts (#224).
+ Update check for static libs to current GL (#222).
+ Corner case checking desktop-file-validate w bash variabLe (#223).
+ Handle upstream rpm bug making %check test in ruby hard (#225).
- Fix URL for gtk-query-immodules (bz 980308).
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
10 years, 8 months
Re: Overall fedora-review test results.
by Alec Leamas
On 08/22/2013 07:20 PM, Michael Schwendt wrote on #fedora-devel:
> On Thu, 22 Aug 2013 15:27:47 +0200, Alec Leamas wrote:
>
>> The overall results with some comments are at http://ur1.ca/f5xxw .
> The CheckSoFiles results might be .so plug-in libs (extension modules),
> which are stored in private paths, i.e. outside run-time linker's search.
> Or even non-versioned shared libs ending with .so, but being ordinary
> run-time libs (and no build-time libs for optional -devel packages).
Indeed. My current understanding about this:
- f-r should not be afraid to warn about things. But this test should
not really fail, just inform about the so-files and leave the decision
to user.
- That said, f-r should understand the ocaml and haskell exceptions.
- Likewise, it shouldn't be too hard to exclude private files outside
ld.so's load path.
Moving discussion to fedora-review list,
--alec
10 years, 8 months
Overall fedora-review test results.
by Alec Leamas
In an attempt to test fedora-review we have run it on almost allpackages
in the complete rawhide distribution. Our primary objective is to
certify that fedora-review is stable for all this kind of input. Also,
these test reveals some false warnings and other errors. Some are
detected and fixed, some certainly not. This is a lot of data.
The overall results with some comments are at http://ur1.ca/f5xxw . Here
are some interesting findings such as a package with files in /buildroot
and more than 1200 packages without working source url. However, this
is basically excess information for me. Hereby shared.
--alec
10 years, 8 months
fedora-review release-0.5.0 branch created - release getting near
by Stanislav Ochotnicky
Hi everyone,
As Alec and me agreed we are nearing a release with several features and
bugfixes (see NEWS files). To that end I have branched off release-0.5.0. Feel
free to work on devel as you wish. Bugfixes should ideally be added to
release-0.5.0 branch currently and only new features developed on devel.
I am a fan of each release having a code name, maybe we should add one to
fedora-review as well. I am open to suggestions ranging from Doctor Who
references all the way to...fruits :-)
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
10 years, 8 months
Possible git reset needed to fix history
by Stanislav Ochotnicky
Heya all,
as has happened before...it's happened again :-/ fedora-review repo (devel
branch) has become a mess due to recent cross-merging.
We can either let it be or fix it by resetting devel branch to commit b80cd0
(NEWS: update from Alec) and then rebasing issue-212 on top of that + add latest
commit from Alec. Amount of work is quite minimal, but this would of course
break all clones out there + Jenkins would have to be reset (this is a minor
issue though).
I *really* hate to reset things and break peoples' clones, but current history
is confusing as hell. If you feel strongly one way or the other, reply. I'll
wait a few days before reset.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
10 years, 8 months
activate/disable plugins (a. k. a. 989946)
by Alec Leamas
After some thinking about bug 989946 I think the elephant in the room is
the activation of plugins. This is done using heuristics which works
reasonably well in most cases. However, if these heuristics doesn't
work, it puts the user in a awkward position. In the 999846 case, we run
java tests on a non-java package, and user has really no way to disable
this, or even understand the problem.
I have pushed a feature branch plugin-fixes. Basically, it does two things:
- Adds some feedback about enabled and disabled plugins.
- Adds a new --plugins option which can be used to enable/disable
plugins, overriding the heuristics.
What I try to do is to make the whole "what plugins should be run" mess
visible and configurable. In the 989946 scenario, user could the use
--plugins to disable the bogus java tests. This means a new option, we
don't want that. But perhaps it can be justified in this case (?)
Depending on input, I plan to merge this to devel eventually.
Notes:
- Here is no feedback on why certain plugins are run (Stan's proposal).
It certainly be added
- I actually still don't think java tests should be run just because the
unpatched sources contains a .java file. Too aggressive IMHO. But this
should be resolved in the bug context.
--alec
10 years, 8 months