koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=9962951

Updated to v6.00

Spec URL: https://alexpl.fedorapeople.org/packages/fonts/gdouros/gdouros-anaktoria-fonts/gdouros-anaktoria-fonts.spec

SRPM URL: https://alexpl.fedorapeople.org/packages/fonts/gdouros/gdouros-anaktoria-fonts/gdouros-anaktoria-fonts-6.00-1.fc23.src.rpm

Sources cannot be found any more!

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> Sources cannot be found any more!

In protest of the recent events in Europe and Greece, the creator has removed all of his fonts (including seven that are already in Fedora). I have written to him urging him to reconsider his decision, but I have not heard back.

Meanwhile, I have uploaded the latest source packages for the fonts I maintain to our cvs and for the ones under review it's just what you see in the source rpms.

OK. I guess that's fine: the font is open source and either the author will re-post it or it will pop up somewhere else. Where is the license specified?

%description seems to contain a private use unicode character (1480﷐[U+FF004]﷑
1561).

[ ]: Each %files section contains %defattr if rpm < 4.4
     Note: %defattr present but not needed

[ ]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 808960 bytes in 1 files.
That's borderline. A bit too small to create a separate package.

Appdata file should be validated in %check
[https://fedoraproject.org/wiki/Packaging:AppData].

$ appstream-util validate-relax /usr/share/appdata/gdouros-anaktoria.metainfo.xml
/usr/share/appdata/gdouros-anaktoria.metainfo.xml: FAILED:
• markup-invalid        : <id> does not have correct extension for kind
• tag-missing           : <extends> is not present
Validation of files failed

Thank you for taking the time to review this.

Source rpm and spec file updated.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> Where is the license specified?

There never was a license file. See here, bottom of the page:

https://web.archive.org/web/20150625020428/http://users.teilar.gr/~g1951d/

> %description seems to contain a private use unicode character (1480﷐[U+FF004]﷑
> 1561).

Thanks, there was a funny-looking zero, I fixed it in both the spec file and the metainfo.xml file. By the way, which tool picked that up?

> [ ]: Each %files section contains %defattr if rpm < 4.4
>      Note: %defattr present but not needed

But I don't have a %defattr directive, where is this coming from?
 
> [ ]: Large documentation must go in a -doc subpackage. Large could be size
>      (~1MB) or number of files.
>      Note: Documentation size is 808960 bytes in 1 files.
> That's borderline. A bit too small to create a separate package.

See comments 1 & 4 here:

https://bugzilla.redhat.com/show_bug.cgi?id=1208842

> Appdata file should be validated in %check
> [https://fedoraproject.org/wiki/Packaging:AppData].

Does this apply to metainfo.xml files? I thought it was just for the appdata.xml ones.

> $ appstream-util validate-relax
> /usr/share/appdata/gdouros-anaktoria.metainfo.xml
> /usr/share/appdata/gdouros-anaktoria.metainfo.xml: FAILED:
> • markup-invalid        : <id> does not have correct extension for kind
> • tag-missing           : <extends> is not present
> Validation of files failed

On an F22 system, I'm getting this:
$ appstream-util validate-relax rpmbuild/SOURCES/gdouros-anaktoria.metainfo.xml 
rpmbuild/SOURCES/gdouros-anaktoria.metainfo.xml: OK

I can't understand why there would be a problem with the id tag or why the extends tag would be needed, it does not extend anything.

On what system did you run fedora-review?

I've just noticed that fedora-review on this system creates an F21 package even though I fed it an F23 source rpm built in mock, is there a setting someplace that I've missed?

(In reply to Alexander Ploumistos from comment #6)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> > Where is the license specified?
> 
> There never was a license file. See here, bottom of the page:
So please add a comment to the spec file explaining this. I think you should even
include the "license text" in that comment.

# https://web.archive.org/web/20150625020428/http://users.teilar.gr/~g1951d/
# "in lieu of a licence:
# Fonts and documents in this site are not pieces of property or merchandise items;
# they carry no trademark, copyright, license or other market tags; they are free
# for any use. George Douros"

> > %description seems to contain a private use unicode character (1480﷐[U+FF004]﷑
> > 1561).
> 
> Thanks, there was a funny-looking zero, I fixed it in both the spec file and
> the metainfo.xml file. By the way, which tool picked that up?
I does not display properly in firefox on my system, and I started investigating.
You probably have the right font installed.

> > [ ]: Each %files section contains %defattr if rpm < 4.4
> >      Note: %defattr present but not needed
> But I don't have a %defattr directive, where is this coming from?
Oh, indeed. It must be coming from one of the macros. I fixed
https://bugzilla.redhat.com/show_bug.cgi?id=1047031 some time ago.
I'm not sure where this one came from. Please ignore, it's not a bug
in your package anyway.

> > [ ]: Large documentation must go in a -doc subpackage. Large could be size
> >      (~1MB) or number of files.
> >      Note: Documentation size is 808960 bytes in 1 files.
> > That's borderline. A bit too small to create a separate package.
> 
> See comments 1 & 4 here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1208842
Yeah, agreed.

> > Appdata file should be validated in %check
> > [https://fedoraproject.org/wiki/Packaging:AppData].
> 
> Does this apply to metainfo.xml files? I thought it was just for the
> appdata.xml ones.
Yes. That paragraph talks about both kinds of files, and says that files should
be checked with making a distinction between the two types.

> > $ appstream-util validate-relax
> > /usr/share/appdata/gdouros-anaktoria.metainfo.xml
> > /usr/share/appdata/gdouros-anaktoria.metainfo.xml: FAILED:
> > • markup-invalid        : <id> does not have correct extension for kind
> > • tag-missing           : <extends> is not present
> > Validation of files failed
> 
> On an F22 system, I'm getting this:
> $ appstream-util validate-relax
> rpmbuild/SOURCES/gdouros-anaktoria.metainfo.xml 
> rpmbuild/SOURCES/gdouros-anaktoria.metainfo.xml: OK
> 
> I can't understand why there would be a problem with the id tag or why the
> extends tag would be needed, it does not extend anything.
> 
> On what system did you run fedora-review?
I run that on F21. On rawhide indeed it doesn't say anything.

> I've just noticed that fedora-review on this system creates an F21 package
> even though I fed it an F23 source rpm built in mock, is there a setting
> someplace that I've missed?
Most likely you have /etc/mock/default.cfg linked to fedora-21-x86_64.cfg.
I link it to fedora-rawhide-x86_64.cfg instead.

--

To sum up, please add:
- a comment about the license
- %check with appstream-util validate-relax

Package is APPROVED.

Are all Douros fonts packaged? If you have any left to package, I'll be happy to review.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #7)
> > > %description seems to contain a private use unicode character (1480﷐[U+FF004]﷑
> > > 1561).
> > 
> > Thanks, there was a funny-looking zero, I fixed it in both the spec file and
> > the metainfo.xml file. By the way, which tool picked that up?
> I does not display properly in firefox on my system, and I started
> investigating.
> You probably have the right font installed.

I usually edit files in bluefish, vi or gedit and their monospace fonts displayed a regular zero. When I transferred the description text to libreoffice writer I was able to see what was wrong.

> Most likely you have /etc/mock/default.cfg linked to fedora-21-x86_64.cfg.
> I link it to fedora-rawhide-x86_64.cfg instead.

Actually it was linked to fedora-20-x86_64.cfg. Strange.

> To sum up, please add:
> - a comment about the license
> - %check with appstream-util validate-relax

I have updated the spec file with a license-like comment, "BuildRequires:  libappstream-glib" and the appstream validation check. I should probably amend my other gdouros-*-fonts packages as well.

> Package is APPROVED.

Great, thanks! So can I set the cvs flag now? 

> Are all Douros fonts packaged? If you have any left to package, I'll be
> happy to review.

That would be really nice of you. I have Aroania and Asea in the review queue (and I've just updated their spec files according to your remarks) which together with Anaktoria and Alexander comprise upstream's TextFonts package:
https://bugzilla.redhat.com/show_bug.cgi?id=1228868
https://bugzilla.redhat.com/show_bug.cgi?id=1228869

There are a few more of his fonts that have never been packaged, I hope the internet archive keeps a copy of all of them, just in case.

(In reply to Alexander Ploumistos from comment #8)
> Great, thanks! So can I set the cvs flag now? 
Yes.

Hm, one more thing: why not just build use a single source package for Alexander/Anaktoria/Aroania/Asea ?

(In reply to Zbigniew Jędrzejewski-Szmek from comment #10)
> Hm, one more thing: why not just build use a single source package for
> Alexander/Anaktoria/Aroania/Asea ?

Mainly because of this:
https://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#How_many_font_files_can_I_put_in_a_font_.28sub.29package.3F

Also, even though they are in the same package, they are not always updated at the same time. For example, Alexander, Anaktoria and Aroania are currently at v6.00, while Asea is still at 5.01.

New Package SCM Request
=======================
Package Name: gdouros-anaktoria-fonts
Short Description: A font based on "Grecs du roi" and the "First Folio Edition of Shakespeare"
Upstream URL: http://users.teilar.gr/~g1951d/
Branches: f21 f22 f23 master
Owners: alexpl
InitialCC: fonts-sig

I don't think it is really mandatory to add license text in the spec file as the text given in the upstream website already matches with the definition of Public Domain license given on https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing page.

But if needed to be added they should be added just before License: tag and not at the start of spec file which will look as if its the license of this spec file.

I have already pushed updates with the license comment like this for more than half of the gdouros fonts, what should I do?

For the time being, given how Mr Douros' page has been altered, I think that if not the full text, at least the internet archive link should be referenced somewhere, so that everyone is clear on the licensing terms.

In Fedora rpm packaging, I will suggest whenever something extra you need to add in spec file, good to add it just before the start of that relevant section/line.

I have no concern over adding more text in the spec file but its place at top of the spec file.

(In reply to Parag AN(पराग) from comment #15)
> I have no concern over adding more text in the spec file but its place at
> top of the spec file.

OK, got it. I'll rearrange the text and update everything over the weekend. I hope no one minds me hogging up koji...

By the way, is there a fedpkg option to submit all of the branches at once to the remote and/or koji?

(In reply to Alexander Ploumistos from comment #16)
> (In reply to Parag AN(पराग) from comment #15)
> > I have no concern over adding more text in the spec file but its place at
> > top of the spec file.
That's bikeshedding ;) While I agree that putting the license at the top is a bit
awkward, it certainly isn't wrong.

> OK, got it. I'll rearrange the text and update everything over the weekend.
> I hope no one minds me hogging up koji...
There's certainly no need to rebuild everything for this. Since it's just a change in the spec file, it's totally fine to do it by just pushing the git commit without bumping the version and/or rebuilding the package. Also, even if you built some package, there's no need to submit an update.

> By the way, is there a fedpkg option to submit all of the branches at once
> to the remote and/or koji?
fedpkg no. But you can use something like:

git push origin master master:f23 master:f22 master:f21

if f21/f22/f23/master are the same, or update each branch locally if branches are not at the same commit and:

git push origin master f23 f22 f21

I don't think there's a way to submit multiple builds, but you can use:

fedpkg build --nowait

to submit a job and immediately continue. Something like:

fedpkg build --nowait ... && fedpkg build --nowait ... && ...

(In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
> There's certainly no need to rebuild everything for this. Since it's just a
> change in the spec file, it's totally fine to do it by just pushing the git
> commit without bumping the version and/or rebuilding the package. Also, even
> if you built some package, there's no need to submit an update.
 
Phew, good to know. Desperation had started to creep up on me.

> > By the way, is there a fedpkg option to submit all of the branches at once
> > to the remote and/or koji?
> fedpkg no. But you can use something like:
> 
> git push origin master master:f23 master:f22 master:f21
> 
> if f21/f22/f23/master are the same, or update each branch locally if
> branches are not at the same commit and:
> 
> git push origin master f23 f22 f21

When I want to apply the same changes as in master to a branch, I switch to that branch and issue "git merge master". Does the first format of the push command alleviate the need for the merge? Also, if I have merged the changes from the master branch to the others and use the second syntax, the result would be the same as in the first case?  

> I don't think there's a way to submit multiple builds, but you can use:
> 
> fedpkg build --nowait
> 
> to submit a job and immediately continue. Something like:
> 
> fedpkg build --nowait ... && fedpkg build --nowait ... && ...

That's probably what I need. The man page does not say what will happen in case of error. Will I be notified in the terminal or do I need to watch the web interface to koji?

(In reply to Alexander Ploumistos from comment #18)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
> > There's certainly no need to rebuild everything for this. Since it's just a
> > change in the spec file, it's totally fine to do it by just pushing the git
> > commit without bumping the version and/or rebuilding the package. Also, even
> > if you built some package, there's no need to submit an update.
>  
> Phew, good to know. Desperation had started to creep up on me.
:)

> > > By the way, is there a fedpkg option to submit all of the branches at once
> > > to the remote and/or koji?
> > fedpkg no. But you can use something like:
> > 
> > git push origin master master:f23 master:f22 master:f21
> > 
> > if f21/f22/f23/master are the same, or update each branch locally if
> > branches are not at the same commit and:
> > 
> > git push origin master f23 f22 f21
> 
> When I want to apply the same changes as in master to a branch, I switch to
> that branch and issue "git merge master". Does the first format of the push
> command alleviate the need for the merge? Also, if I have merged the changes
> from the master branch to the others and use the second syntax, the result
> would be the same as in the first case?  
Yes, exactly. Try 'gitk --all &' for visual overview.

> > I don't think there's a way to submit multiple builds, but you can use:
> > 
> > fedpkg build --nowait
> > 
> > to submit a job and immediately continue. Something like:
> > 
> > fedpkg build --nowait ... && fedpkg build --nowait ... && ...
> 
> That's probably what I need. The man page does not say what will happen in
> case of error. Will I be notified in the terminal or do I need to watch the
> web interface to koji?
Each of those commands will print the job number. You can then watch them
from the command line with 'koji watch-task ID1 ID2 ...'
Or you can use 'koji list-tasks --mine' to list the tasks and start watching them.

I can't thank you enough, this information should be on the wiki in huge, bold letters next to your picture wearing a halo.

On to git...

Git done (by process-git-requests).