DevHeads.net

Postings by Owen Taylor

Call for participation: Fedora Flatpaks

I'd like to invite Fedora contributors to start creating Flatpaks of
graphical applications in Fedora. We're still working on putting the final
pieces into place to have a complete story from end to end, but it's
definitely close enough to get started.

If you maintain a graphical application, please try creating a Flatpak of
it.

Flatpaks in src.fedproject.org - a namespace conumdrum

The current idea
=============

A Flatpak is a module. The way that the module is deployed is by creating a
Flatpak container from the module.

Perl dependencies of KDE libraries

Hi Rex,

As part of my Flaptak efforts, I've been looking what libraries and other
packages are used by our most popular applications and I noticed that all
applications using KDE libraries are pulling in a pile of perl packages. As
far as I can tell, this is only because of the two scripts:

/usr/share/kf5/kjs/create_hash_table (kf5-kconfigwidgets)
/usr/bin/preparetips5 (kf5-kjs)

Are there other reasons that Perl is needed? What if we moved the scripts
to the corresponding -devel packages? They seem to be developer focused and
not needed at application run time.

Thanks!
Owen

RFC: Flatpak application versioning: rolling stable

The Fedora today, there was a presentation about a vision for how
applications should have a different life cycle than the operating system:

<a href="https://flock2018.sched.com/event/Fjdk/at-long-last-rings-split-lifecycles" title="https://flock2018.sched.com/event/Fjdk/at-long-last-rings-split-lifecycles">https://flock2018.sched.com/event/Fjdk/at-long-last-rings-split-lifecycles</a>

For Flatpaks, the future is now - as soon as we start building them, I'd
like to start immediately in a model where the application lifecycle is not
tied to the traditional release cadence.

My basic idea is that applications consumed as Flatpaks should have a
"rolling stable" model - there is a *single* default version of the
application for all Fedora users, and that version i

Clutter 1.5.8 in rawhide

Just a quick heads up - I'm currently building Clutter 1.5.8 into
rawhide.

Supposedly this is 100% compatible with Clutter 1.4, but there are a lot
of internal changes in the backend parts so there's a possibility of
bugs/regressions.

(I was waiting to upgrade in Rawhide until we got the necessary bugs
fixed to make it work well with GNOME Shell; 1.5.8 achieves that.)

If you run into anything, just file it in bugzilla and I'll take care of
investigating and upstreaming as necessary.

- Owen

Compile with -fno-omit-frame-pointer on x86_64?

Lack of decent profiling is a major problem for making our operating
system fast. By far the most effective of profiling is sampling profile
with callgraph information.

Soeren's comment from March:

<a href="http://lwn.net/Articles/380582/" title="http://lwn.net/Articles/380582/">http://lwn.net/Articles/380582/</a>

Basically summarizes the situation, and as far as I know nothing has
changed ...

Page flipping on intel (2.11 driver)

With the 2.11 update for xorg-x11-drv-intel in updates-testing we have a
couple of serious problems occurring with gnome-shell on Intel systems:

A) A complete hang where the system can't even be pinged.

B) A problem where the system continues to run fine but the GPU gets
"stuck" and no further drawing happens until the system is rebooted.

We've also had similar reports for Compiz.

These problems seem to be associated in particular with the "page
flipping" functionality that it enables.

--host=i386-redhat-linux-gnu --target=i686-redhat-linux-gnu ???

Looking at the build logs for F-12, e.g.:

<a href="http://kojipkgs.fedoraproject.org/packages/glib2/2.22.4/1.fc12/data/logs/i686/build.log" title="http://kojipkgs.fedoraproject.org/packages/glib2/2.22.4/1.fc12/data/logs/i686/build.log">http://kojipkgs.fedoraproject.org/packages/glib2/2.22.4/1.fc12/data/logs...</a>

we seem to have things set up to run configure as:

--build=i386-redhat-linux-gnu
--host=i386-redhat-linux-gnu
--target=i686-redhat-linux-gnu

Which, according to my reading of the autoconf manual means:

* Build on a i386-redhat-linux-gnu
* Create code that runs on i386-redhat-linux-gnu
* Build a cross tool chain that targets i686-redhat-linux-gnu

and really doesn't make sense.

PackageKit policy: background and plans

I wanted to provide an update to the list on the current thinking about
the PackageKit policy issue from the perspective of the people working
on the core desktop packages and on the desktop user experience.

There was informal meeting earlier today with Richard Hughes, and
myself, and a couple of people who could provide help with big-picture
Fedora issues like Bill Nottingham and Jesse Keating, to try and figure
out if there were obvious steps to take in the short term.

an update to automake-1.11?

I was rather surprised to see:

<a href="https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661" title="https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661">https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661</a>
<a href="https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076" title="https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076">https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076</a>
<a href="https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370" title="https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370">https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370</a>

Where the automake was upgraded to 1.11 for F9, F10, and F11.

In general automake hasn't had a very good track record of compatibility
between 1.x and 1.y, though this has been getting better recently.
I don't see any specific mentions of incompatible changes in a quick
scan of:

<a href="http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html" title="http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html">http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html</a>

But it is also a pretty long rele