We've been working on the idea that we should have a way to take Fedora RPMs and
convert them into xdg-app runtimes and applications; by doing this inside of Koji
we would be able to pretty transparently provide a set of xdg-apps for many
existing applications in Fedora.
(https://fedoraproject.org/wiki/Workstation/BuildingXdgApps tries to work out
possible details.)
I have an initial prototype of this working with a branch of Koji
(https://pagure.io/fork/otaylor/koji/commits/xdg-app, still rough), and that
raised some questions to me about around versioning:
* How should the fedora runtime be versioned? Is each Fedora release (23,24,25)
a separate branch in the repository? (I'm not entirely sure if the "branch"
of the runtime the same as "runtime-version" that is part of
the xdg-app app metadata?)
* What happens if we evolve the Fedora runtime during the development release -
say we add a new package to it that we find we are repeatedly bundling into
applications. Can we make the behavior for the user better than simply having
xdg-apps that rely on the new package in the runtime die with obscure error
messages?
* How should apps generated from Fedora packages be versioned? Presumably we don’t
want each Fedora version to be a branch in this case, since we want automatic
updates. Are refs pointing to devel/testing/stable versions are something
added post-build into the repository?
* We probably will be creating some sort of bundles when we build apps and runtimes
in Koji. (This is what my prototype does using the existing xdg-app ostree delta
format.) What do we use for filenames for these bundles? The RPM nvr of the
application itself doesn't tell the story because of the bundling of dependencies
in the application. Is the filename just based off the hash of the xdg-app like
‘eog-f23-d3dafc9cf48.xdgapp’? Do we add a build-serial to make it clear what bundle
is newer - e.g. ‘eog-f23-14-d3dafc9cf48.xdgapp’ ?
Thanks,
Owen

This bug is proposed as a Fedora 24 blocker, anaconda component:
Laptop does not resume from hibernate, boots instead
https://bugzilla.redhat.com/show_bug.cgi?id=1206936
That bug is already 45 comments long and goes back over a year.
Hibernation as a subject involves the DE, upower, systemd, kernel,
firmware, and the OS installer so a full discussion is massive. I
tried to narrow the scope of this to just one central argument which
is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1206936#c46
The gist is:
If a hibernation image exists, there probably should be a best effort
to resume that image to avoid data loss. Right now there is no resume=
boot parameter option so if a hibernation image exists it will not be
resumed. Should the lack of resume= boot parameter be considered a
release blocking bug?
This intentionally doesn't answer myriad other questions: when is
there a hibernation image; why can that fail; what happens if the
hibernation image is there, is resumed, but still fails; whether swap
is of sufficient size; whether swap can be on an LVM2 logical volume;
the fact Secure Boot enabled currently means hibernation image
creation is disabled, etc. I'm considering those out of scope for
sanity sake for this particular bug. Quite honestly I'd like to see
all the DE's drop hibernation from their GUIs since it's grossly
misleading to the user at best, but that too is set aside.
The central question is: does the existence of resume= cause more
problems than it solves? i.e. is it possible a hibernation image gets
loaded, is not invalidated by the kernel, but is somehow
non-deterministically unstable such that subsequent corruption or data
loss is still decently possible? If that's a yes then I'd say this is
not an anaconda blocker but places a significant burden on DE's to
disable and hide hibernation UI elements. If hibernation resumption is
safer than not resuming, then this is probably a legitimate blocker
but I think ultimately that's a judgment call for the folks who turn
up to vote at blocker review :-)
Thanks,
--
Chris Murphy

You have been invited to the following event.
Title: Fedora Release Tools Demo (Live Broadcast)
Hangout:
The hangout will be broadcast live & posted:
http://www.youtube.com/watch?v=ivZqOR82ocQ
Q&A - #fedora-meeting
--
Purpose: The purpose of a demo is to show our stakeholders what we
completed this iteration, get feedback from them about the changes & set
some context and expectation with them about our direction.
Demo agenda & previous demos can be viewed here:
http://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-to...
Highlights today:
* OSBS + registry deployment in stage (building & pulling Cockpit image)
* OStree builds in Pungi
When: Thu Apr 21, 2016 12pm - 1pm Eastern Time
Where: Hangout on Air / YouTube live stream
Calendar: acarter(a)redhat.com
Who:
* acarter(a)redhat.com - organizer
* rbarlow(a)redhat.com
* twaugh(a)redhat.com
* mmcgrath(a)redhat.com
* dperpeet(a)redhat.com
* server(a)lists.fedoraproject.org
* rel-eng(a)lists.fedoraproject.org
* desktop(a)lists.fedoraproject.org
* kasingh(a)redhat.com
* rcm-tools(a)redhat.com
* sgallagh(a)redhat.com
* aos-devel
* cloud(a)lists.fedoraproject.org
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=dHMxNWN2ajBiNjNmYjY...
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
desktop(a)lists.fedoraproject.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
https://support.google.com/calendar/answer/37135#forwarding