Re: How to include fonts in Gnome Software?
by Richard Hughes
On 15 October 2014 16:38, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> wrote:
> maybe you could include some more information how the font appdata
> files themselves should look, as opposed to the one-level-up metadata
> files
Right, the examples I gave there are the actual files; that is the
post-0.6 AppStream version which only works with Fedora > 20.
> E.g. I looked at the schema at http://people.freedesktop.org/~hughsient/appdata/
> and they don't seem to have the string "font" in them at all.
Right, those are AppData files for applications, not MetaInfo files
for fonts and addons. When F20 is EOL I'll update that page to the new
metadata format.
> Some more examples would be good too. Does [1] look OK?
> appdata-validate complains about missing screenshots, are those necessary
> for fonts' appdata?
Right; you need to use a metainfo file and a git version of
appstream-glib to validate those. I only wrote the code 6 hours ago :)
> [1] http://pkgs.fedoraproject.org/cgit/unifont.git/tree/unifont.appdata.xml
Not appdata.xml, but metainfo.xml -- This is the patch I want to apply for lato:
diff --git a/lato-fonts.spec b/lato-fonts.spec
index 0eb3837..e0f1fa8 100644
--- a/lato-fonts.spec
+++ b/lato-fonts.spec
@@ -64,9 +64,30 @@ install -m 0755 -d
$RPM_BUILD_ROOT%{_fontconfig_templatedir} $RPM_BUILD_ROOT%{_f
install -m 0644 -p %{SOURCE1}
$RPM_BUILD_ROOT%{_fontconfig_templatedir}/%{fontconf}
ln -s %{_fontconfig_templatedir}/%{fontconf}
$RPM_BUILD_ROOT%{_fontconfig_confdir}/%{fontconf}
+# Add AppStream metadata
+mkdir -p $RPM_BUILD_ROOT%{_datadir}/appdata
+cat > $RPM_BUILD_ROOT%{_datadir}/appdata/Lato.metainfo.xml <<EOF
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Copyright 2014 Richard Hughes <richard(a)hughsie.com> -->
+<component type="font">
+ <id>Lato</id>
+ <metadata_license>CC0-1.0</metadata_license>
+ <name>Lato</name>
+ <summary>A classical sans-serif font family</summary>
+ <description>
+ <p>
+ The semi-rounded details of the letters give Lato a feeling of warmth,
+ while the strong structure provides stability and seriousness.
+ </p>
+ </description>
+ <updatecontact>richard_at_hughsie_dot_com</updatecontact>
+ <url type="homepage">http://www.latofonts.com/</url>
+</component>
+EOF
%_font_pkg -f %{fontconf} *.ttf
%doc Lato2OFL/{OFL.txt,README.txt}
+%{_datadir}/appdata/Lato.metainfo.xml
Richard
9 years, 6 months
Re: How to include fonts in Gnome Software?
by Richard Hughes
On 14 October 2014 22:41, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> wrote:
> I was looking into what I need to do to have my fonts in displayed
> in gnome-software. They all seem to fail with <veto>appdata required</veto>.
I'm going to work on documenting the font requirements today; I'll
follow up with a blog post and some new instructions :)
Richard
9 years, 6 months
Beta / Final release criteria for Workstation
by Adam Williamson
Hi, folks. I wanted to ask if you envisage a need for release criteria
for Workstation at Beta (or Final) over and above those that already
exist for 'desktop' stuff. Areas I notice:
SSSD is listed in the tech spec. We have server-side requirements for
FreeIPA in the Server product; do we want to formulate client-side
requirements?
We don't really have criteria relating to a11y or complex input methods;
this isn't Workstation-y in particular, but something that might be
interesting?
Appearance is something we'd want to enforce if it were actually done,
but I get the impression the Qt variant of Adwaita isn't actually
written yet.
Functional requirements for the 'core apps' - we have requirements for
graphical updating (but not package install), web browser, and terminal
in the current criteria, but not for text editor, file manager, Boxes,
or 'developer assistant'.
Do remember that anything we write in the release criteria is something
we expect to enforce: if you don't actually want the release to be
delayed if it's not done, best not to have a criterion for it. More
aspirational 'to-do' or 'it'd be good if...' lists can be handled
somewhere else, I don't know/care where, but not in the criteria :)
Thanks folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 6 months
Goals for Fedora Workstation upgrades
by Owen Taylor
The discussion about F20 to F21 upgrades has been largely focused on the
technolaogy - what will happen if we make package X depend on package Y
and obsolete package Z. I understand the motivation behind wanting
upgrades to be encoded in the package set and to keep special casing to
a minimum. But I think we can't just shrug and consider that the end -
we need to know what we are trying to achieve to figure out when we need
to special case and do ugly things to get there.
Before going too far into the practicalities of what we can achieve for
Fedora 21, I decided try to write down what we'd want for F21 => F22 and
beyond. I mean this to be Workstation specific - not apply to other
products or non-productized installations of Fedora.
* The end result of an upgrade to F<n> must have all the packages that
would have been installed for a fresh install of F<n>
* In general, packages that were originally installed by default on the
system, but no longer installed by default in F<n> should be removed.
This may not always be practical, but after the upgrade:
- There must be no duplication of applications in system roles. For
example, there must not be two character map applications
- There should be no left over system services started at boot
If a default application is removed without any replacement in the new
default set (e.g. we stop installing an office suite), leaving the old
application is acceptable.
* Normal user configuration of the pre-upgraded system via
(non-tweak-tool) desktop configuration must not leave the system in a
broken state after the upgrade.
* After the upgrade, the user should see the new defaults for things
like backgrounds unless they have explicitly configured non-default
settings.
* We test the following upgrades:
fresh install F<n-1> => f<n>
fresh install F<n-2> => f<n>
serial upgrade fresh install F<n0> => F<n0+1> => ... f<n> (n0 to be
determined - f20 or f21 most likely)
9 years, 6 months
Minutes for Workstation WG 2014-10-08 Meeting
by Josh Boyer
Mostly a discussion meeting today. Please review the logs if you are
interested.
=======================================
#fedora-meeting: Workstation WG meeting
=======================================
Meeting started by jwb at 15:00:04 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-10-08/workstation.20...
.
Meeting summary
---------------
* init (jwb, 15:00:04)
* Include wayland session by default for F21? (jwb, 15:07:49)
* AGREED: include the wayland session for beta and reevaluate the
decision before the final freeze (jwb, 15:18:01)
* Open WG seat (jwb, 15:18:19)
* Upgrades (jwb, 15:34:14)
Meeting ended at 16:05:33 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jwb (66)
* kalev (38)
* otaylor (24)
* mclasen (22)
* juhp_ (22)
* wwoods (16)
* drago01 (16)
* rdieter (8)
* zodbot (4)
* cwickert (3)
* sgallagh (1)
* ryanlerch (0)
* juhp (0)
* cschalle (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
9 years, 6 months
Workstation WG 2014-10-08 Meeting Agenda
by Josh Boyer
Meeting in #fedora-meeting on Wed Oct 08, 2014 @ 15:00 UTC
* Include wayland session by default for F21?
* Open WG seat
- Rex Dieter and Allan Day suggested as candidates
- Others?
* Upgrades
- Apps vs. core components
- Supported upgrade lineage (N-2, N-1, N) etc
9 years, 6 months
Workstation WG membership
by Paul W. Frields
IIRC the WG was going to meet today and might be having a vote on new
members. I think both people under consideration, Allan and Rex, are
qualified and would be effective contributors. However, I'd like to
see Rex be part of the official WG effort, and here's why.
I'm strongly supportive of the effort to make a polished GNOME-based
workstation. At the same time, I'd like for this effort not to be
perceived either as a monoculture, or disinterested in input from the
community at large. Having the WG entirely made up of Red Hat
associates makes that difficult. We have numerous participants from
the GNOME upstream and Red Hat desktop team involved in Workstation.
That's not just helpful but important, and I believe the effort is
clearly on the right path.
Rex has a long history of positive, constructive collaboration with
people across Fedora. I'm confident he'd make substantial
contributions in the group. At the same time, I don't think making
Rex part of the group needs to limit input from contributors such as
Allan, who clearly has critical input to offer for design and cohesion
in the Workstation. I'm also confident other WG members can reflect
that input effectively.
It would also be useful to have close, regular input on opportunities
for freedesktop.org and other unifying systems that we can consider
while increasing workstation polish. I believe Rex's experience in
KDE would be helpful in that regard, and needn't change or dilute the
focus on a vastly improved Fedora Workstation.
Again, none of this is intended to reflect anyone's relative value as
a Fedora contributor. My only intention is to ensure we stay
welcoming and responsive to a diverse participant base, while not
diluting our goal of a polished, coherent, GNOME-based offering.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
9 years, 6 months
