[Magazine] Tip for using the Molot font in featured images
by Paul W. Frields
There are a number of us who help with featured images on the Magazine
articles. The images help the articles look attractive on social
media and invite people to visit and read.
Here's a tip for using the Molot font in your images. I picked this
tip up silently from Ryan, by looking at some of his work.
I typically use Molot for emphasizing words in a technically focused
post, or for very important text. Molot's default spacing is really
wide -- abnormally so, in a way that doesn't look very attractive
IMHO.
When I use Molot for more than one word on a line, I use Inkscape's
word spacing tools to *reduce* the between-word spacing to a more
reasonable size. It makes the headline look more attractive. For
this reason, I also use Molot sparingly.
That being said, this is just my $0.02 and I'm very happy to see that
other folks are helping pitch in with featured images. Nice work
everyone!
--
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
7 years, 10 months
Marketing-trac: #224: Requesting accoutn permissions change
by Marketing Team
#224: Requesting accoutn permissions change
---------------------------------+--------------------------
Reporter: linuxmodder | Owner: linuxmodder
Type: task | Status: new
Priority: normal | Milestone: Open
Component: Internal operations | Severity: not urgent
Keywords: | Blocked By:
Blocking: |
---------------------------------+--------------------------
= phenomenon =
Changed fas nicks FROM `corey84` TO `linuxmodder`
= background analysis =
Pagure permissions for my account still reside on corey84 (inactive)
thusly preventing me push access to my fork(s).
= implementation recommendation =
change permissions of Corey Sheldon (corey84) TO Corey Sheldon
(linuxmodder)
--
Ticket URL: <https://fedorahosted.org/marketing-team/ticket/224>
Marketing Team <https://fedoraproject.org/wiki/Marketing>
The Trac site for the Fedora Project Marketing team. This Trac serves as a place to list out tasks, define objectives, and work on monitoring our progress with key tasks and goals.
7 years, 10 months
Marketing-trac: #223: Create Social Media Accounts for Fedora on Diaspora and GNU Social
by Marketing Team
#223: Create Social Media Accounts for Fedora on Diaspora and GNU Social
-------------------------+-------------------------
Reporter: dhanvi | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Open
Component: General | Severity: not urgent
Keywords: | Blocked By:
Blocking: |
-------------------------+-------------------------
We have discussed about it here
https://lists.fedoraproject.org/archives/list/commops@lists.fedoraproject...
Joe Brockmeier raised few question such as
1) How are we managing the new accounts?
2) Who has the "keys" to the account?
a) We need more than one person, and ideally folks who are
"accountable" to Fedora. (e.g., Matthew Miller, someone on the council,
etc.)
3) Do we have a plan for managing them? Who's taking responsibility for
that.
If you guys need any help with managing, I can help you with the same
--
Ticket URL: <https://fedorahosted.org/marketing-team/ticket/223>
Marketing Team <https://fedoraproject.org/wiki/Marketing>
The Trac site for the Fedora Project Marketing team. This Trac serves as a place to list out tasks, define objectives, and work on monitoring our progress with key tasks and goals.
7 years, 10 months
Re: Fedora development of Snap packages
by Matthew Miller
On Wed, Jun 15, 2016 at 05:08:07PM +0200, Alexander Larsson wrote:
> Snappy fundamentally relies on apparmour to do confinement (i.e. it
> doesn't use filesystem namespaces like flatpak), how does this work on
> fedora? You can't use selinux and apparmour at the same time, so this
> shouldn't be able to work, unless they disable the containment feature.
As I understand it, that's exactly what they do — there's a new
"--disable-confinement" flag which is used¹. Additionally the COPR
instructions² ask users to switch SELinux to permissive mode for F24
(but note that "this restriction will be lifted later).
1. http://copr-dist-git.fedorainfracloud.org/cgit/zyga/snapcore/snap-confine...
2. https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7 years, 10 months
Re: Fedora development of Snap packages
by Josh Boyer
On Wed, Jun 15, 2016 at 10:13 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
>
>
> On Tue, Jun 14, 2016 at 1:41 PM, Josh Boyer <jwboyer(a)fedoraproject.org>
> wrot:e
>>
>> How do you plan on addressing the problem reporting issue? In your
>> example, the Inkscape package will still exist in RPM form for other
>> Editions. That means there are potentially two versions of Inkscape,
>> one from upstream and one packaged in Fedora. How do you ensure
>> problem reports are routed to the correct issue tracker?
>
>
> Something Flatpak, or any other packaging method, could make easier for
> developers and users is integrating an in-app bug reporting mechanism.
That is a thing that could be done.
> The packager chooses which (and possibly more than one) bug tracking system
> to use and bakes that into the application in a way that abstracts the user
> from this very long standing mess. So upstream packaged applications would
> behind the scene submit the bug to the upstream preferred bug reporting
> system; and Fedora packages applications to RHBZ or upstream or both.
One of the issues with this idea is scale. It requires app developers
to do this. Not every app developer will do this. Which means the
distributions are still going to have to solve this problem.
josh
7 years, 10 months
"A day in the Life of a Fedora Packager" article
by James Hogarth
Hi guys,
Since jflory liked the look of my blog post for an article in IRC the other
day it's now been polished up as a Fedora Magazine article with that
audience in mind.
It's currently in draft state and can be seen here:
https://fedoramagazine.org/?p=13166&preview_id=13166
I'm trying to think of what imagery I could add to it but struggling a
little in this department. Perhaps pictures of the koji build and bodhi
update? or a snippet of the ansible playbook running?
I'd be happy to link to the playbooks on github if people think that's
sensible (I've removed the links to my blog that discuss how the dynamic
inventory works as I suspect my little blog may not survive the traffic
directed at it) ...
Could you please give it a look over and let me know your thoughts on it.
Cheers,
James
7 years, 10 months
Re: Fedora development of Snap packages
by Josh Boyer
On Tue, Jun 14, 2016 at 3:32 PM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
>> Does anyone in marketing or development now what the article is
>> referring
>> to and what's going on?
>
> Hi,
>
> There's an article on Ars as well. The "working with Fedora developers"
> claim is probably a misunderstanding on Softpedia's part; it's not
> true, and I doubt Canonical would have said that. What's going on is
> that Canonical beat us to market in development... and now their
> marketing folks have beat us in marketing, too. We of course have zero
> plans to adopt Snappy in Fedora, and in fact multiple Fedora developers
> are working on a competing solution, Flatpak [1] (formerly xdg-app),
> which is also being adopted by GNOME and Endless. Until today, Snappy
> was viewed as Ubuntu-specific, which is why there was so little
> interest in it.
"...interest in it within Fedora." is probably what you meant?
> We have not considered, and need to discuss, whether to allow that
> snapcore package into Fedora proper; there's a strong argument to be
> made that we should accept all free software, but doing that could
> undercut our Flatpak effort. If popular upstreams start distributing
> snaps, then we'll probably have to support it, though.
I'm sorry, but undercutting a competing effort isn't a disqualifier
for packaging within Fedora. That would be like saying KDE undercuts
GNOME or emacs undercuts vi, etc. Software should compete on it's
technical merits and generally be available within the Fedora
packaging repositories as long as its license and packaging is
acceptable.
> Challenge for the marketing folks: can we get these tech journalism
> sites writing about Flatpak instead? About GNOME Software's new support
> for displaying and installing Flatpaks in F24? Otherwise, I see
> upstreams adopting Snappy and not Flatpak.
That's certainly something worth doing.
> Background info: In the Workstation working group, we're currently
> planning to allow replacing RPM packages for graphical apps with
> Flatpaks. We're also planning to remove Fedora packages for selected
> apps that are offered as Flatpaks by upstream. For instance, if
> (hypothetical) Inkscape were to offer a Flatpak download on their web
> site, the Inkscape developers could request that we remove the Inkscape
> Fedora package and display their Flatpak in GNOME Software instead; the
> goal here is to reduce friction between upstream and downstream that
> people complain about so often, while ensuring it's still very easy to
> find and install software that runs reliably on Fedora. I guess we
How do you plan on addressing the problem reporting issue? In your
example, the Inkscape package will still exist in RPM form for other
Editions. That means there are potentially two versions of Inkscape,
one from upstream and one packaged in Fedora. How do you ensure
problem reports are routed to the correct issue tracker?
Even ignoring a potential overlap with upstream Flatpak vs. RPM, the
problem reporting issue exists. If GNOME Software is offering up
upstream flatpaks directly, I'm concerned it is going to lead to
confusion for users when they have issues.
josh
7 years, 10 months
