although package Docky was lot of work for me (licensing patching etc) I
am no longer using it and last two releases were very unstable. There
are couple of bugzillas reported mainly because of gconf migration.
Docky is an advanced shortcut bar that sits at the edges of your screen.
It provides easy access to some of the files, folders and applications
on your computer, displays which applications are currently running,
holds windows in their minimized state and more.
Docky is written in mono.
Please ping me if you are interested to maintain the package.
Lukas "lzap" Zapletal
since we provide cloud images starting with Fedora 19, I noticed that
cloud-init, which is used in these, does not execute user shell scripts
with $PATH set properly which is causing issues for packages that does
not provide full paths in scriplets.
I know we have some examples which relies on $PATH set to at least
/usr/bin and /sbin, for example:
I am searching for page that says one can rely on the $PATH. Cannot find
Lukas "lzap" Zapletal
irc: lzap #theforeman
-----BEGIN PGP SIGNED MESSAGE-----
I have imported ARM into primary and enabled armv7hl in the arches to
be built. right now the KDE stack is not entirely built and brought in
due to https://bugzilla.redhat.com/show_bug.cgi?id=988114 as soon as it
is resolved we will get everything fixed and brought in. at that point
arm will be added to the nightly composes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
Is there a wiki page on supporting new boards? I have a BeagleBone Black
that I'd prefer to use Fedora on, but the instructions on the wiki all
seem to be about how to install pre-made images, not how to create new
images. Is there instructions for how to do this anywhere?
= Proposed System Wide Change: Visible Cloud =
Change owner(s): Matthew Miller <mattdm at fedoraproject org>
With Fedora 19's First Class Cloud Images feature , we have Amazon EC2 and
downloadable cloud images (in qcow2 and raw.xz format) produced and released
together with the traditional desktop installer and and livecd images. Now,
let's go to the next level and present the cloud images as equal options.
== Detailed description ==
This involves three key changes. They are not significant changes to other
packages, but since this has implications for the distribution as a whole, I
thought it best considered as bigger than a self-contained change.
1. Refactoring of the Fedora web site to put the cloud image on equal footing
with the desktop image download. The new F19 cloud images page  is very
nice thanks to the hard work of the web team, but unfortunately, in order to
find it, one has to go down into the cellar, into a disused lavatory with a
sign on the door saying Beware of the Leopard. Let's put it on display in the
metaphorical front lobby.
2. Creating specific release criteria and tests for basic cloud image
functionality in, at least, Amazon EC2 and OpenStack. (Tests for smaller
public cloud services could be added once those services gain the ability for
us to provide official images directly. Tests for Eucalyptus and other IaaS
software could be added as well.)
3. Building images in Koji using virtualization and Anaconda, rather than
using a chroot-based appliance-creator. This will ensure that the cloud image
is more in line with The Real Fedora.
== Scope ==
Proposal owner: Coordination; working with web designers and documentation
writers to develop the new presentation, working with QA to develop criteria
and tests, and working with release engineering to land the changes to image
building. I plan to be actively involved in all of these.
Other developers: This will probably require a overhaul of the Get Fedora
website, as that is current primarily focused on the desktop download.
Release engineering: Yes, Jay Greguske, Andrew Thomas, and I are working on
the improvements to the image build system and coordinating with Dennis
Policies and guidelines: As noted, QA guidelines will need to be updated.
devel-announce mailing list
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual backing storage may be smaller, or
shared with other filesystems).
If your package reports disk space usage to users, and bases this on
filesystem free space, please consider whether it might need to take
LVM thin provisioning into account.
The same applies if your package automatically allocates a certain
proportion of the total or available space.
A quick way to check whether your package is likely to be affected, is
to look for statfs() or statvfs() calls in C, or the equivalent in
your higher-level library / programming language.
After discussion on #fedora-devel, my MATE co-maintainer raveit65,
Kalev, Misc, and previous conversations with Rex, I am ready to retire
LightDM seems to fully support systemd-logind.
However I have no rights to commit to systemd.
Lennart or any proven packager please add the following obsoletes tag
I will take care of testing, retiring and blocking the package.
Good day all,
Please join us today (Wednesday, July 31th) at 4PM EDT (8PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.
On the agenda so far..
0) Status of ACTION items from our previous meeting
1) Problem packages
2) Kernel Status Update
3) Aarch64 - Status Update, problem packages
- Koji Update
4) Open Floor
If there is something that you would like to discuss that isn't mentioned
please feel free to bring it up at the end of the meeting or send an email
to the list.