Hi,
On Wed, Sep 4, 2013 at 12:31 PM, Alec Leamas <leamas.alec(a)gmail.com> wrote:
On 2013-09-04 06:07, Parag N(पराग़) wrote:
Hi,
On Wed, Sep 4, 2013 at 12:23 AM, Alec Leamas <leamas.alec(a)gmail.com>wrote:
> On 2013-09-03 10:59, Parag N(पराग़) wrote:
>
> Hi,
>
> On Tue, Sep 3, 2013 at 12:37 PM, Alec Leamas <leamas.alec(a)gmail.com>wrote:
>
>> On 2013-09-03 06:38, Parag N(पराग़) wrote:
>>
>> Hi,
>>
>>
>> On Mon, Sep 2, 2013 at 8:55 PM, Alec Leamas <leamas.alec(a)gmail.com>wrote:
>>
>>> I have added a provisionary fonts plugin to fedora-review. It's
>>> available in the devel version, see [1].
>>>
>>> f-r is now early in the 0.5.1 cycle. To be successful, this plugin
>>> needs to be tested by people understanding fonts. I'm certainly no such
a
>>> person, so I would very much appreciate any kind of feedback on this
>>> plugin. In this list, in the upstream trac instance[2] or bugzilla;
>>> anything is fine. The upstream bugtracker is preferred, though.
>>>
>>>
>> Can you generate test tarball that I can just use and install to test
>> this new change?
>>
>> Regards,
>> Parag
>>
>> There's instructions on how to use the development version using
>> git in [1]. This is the simplest and most used option IMHO.
>>
>> Also, you can find tarballs and rpms at [2]. Note that the rpm's
>> version number are not upgradeable, new rpms sometimes have 'older'
version
>> than the previous so you must use rpm -U --force or similar to use them.
>> Tarballs are run the same way as the git snapshots using
>> ./try-fedora-review, see [1].
>>
>>
> Thanks for the rpms.
>
> 1) I generally test fedora-review on existing packages as e.g.
> $ fedora-review -rn trabajo-fonts-2.0-1.fc20.src.rpm -m
> fedora-rawhide-x86_64
>
> I really liked this 5.x.x releases which got more verbose and showing
> Active plugins. I can see for above command fonts plugin is used. But I am
> not sure why I got warning in following log.
> INFO: Downloading (Source0):
>
http://openfontlibrary.org/assets/downloads/trabajo/d8bc760f033341f410d8b...
> INFO: Using local file trabajo-fonts-fontconfig.conf as Source1
> WARNING: Package trabajo-fonts-2.0-1.fc19 not built
> INFO: Running checks and generating report
> INFO: Results and/or logs in:
> /home/parag/gitvcs/trabajo-fonts/master/trabajo-fonts/results
> INFO: Build completed
>
> Tested with other font package and got following warning for that
> package
> WARNING: Package lohit-devanagari-fonts-2.5.3-2.fc19 not built
>
> 2) I think its good to have results from repo-font-audit to be stored
> in fonts directory and not in parent directory of fedora-review command
> output.
>
>
> You mean s single directory like repo-font-audit and the results in
> there?
>
>
> 3) both the packages I used fedora-review command, its review.txt showed
> Rpmlint (installed packages)
> ----------------------------
> Cannot parse rpmlint output:
>
>
> Requires
> --------
>
>
> Provides
> --------
>
> this looks failed to provide output.
>
> 4) for fedora-review of culmus-fonts-0.130-3.fc20.src.rpm, I got
> following
> ERROR: 'More than one %_font_pkg macro found' (logs in
> /home/parag/.cache/fedora-review.log)
>
> The macro %_font_pkg more than one is expected as this srpm creates
> many subpackages with each subpackage needs its own %_font_pkg macro.
>
> Regards,
> Parag
>
> Hi!
>
>
> This actually revealed some internal bugs in fedora-review. I have pushed
> some commits taking care of this, and now at least these two examples runs
> cleanly, (besides the subdir for repo-font-audit results). Would appreciate
> some further tests...
>
>
>
Thanks for the update. I can see now above reported issues are fixed
except generating a new directory for repo-font-audit command. I will
request if there are some extra files getting generated using fedora-review
as part of enabling some plugin then good to use that plugin name as a
directory and store those generated files under that directory.
Regards,
Parag.
Yes, a directory named after the plugin (or at least prefixed with the
plugin name) is the proper solution. Fixed in new commit.
Thanks for all help, looking forward to hear about more exotic failures
over time :) BTW, the nightly rpms should now have a clean upgrade path.
Yes I saw that and I need to bump the release tag to get it updated locally
but I see this problem has gone now with updated nightly srpm.
Regards,
Parag.