…and I too. :)
In the release blog post of GNOME v3.24, the recipes application was promised:
> This release also includes a new Recipes application, which contains recipes contributed by members of the GNOME community. It has an extensive set of features for adding and editing recipes, creating shopping lists, adjusting quantities and even has a hands-free cooking mode.
https://www.gnome.org/news/2017/03/gnome-3-24-released/
Now, Fedora 26 is using v 3.24, but this application is not there?
This should be fixed until the final Fedora 26 release as, well…, it has been promised. And breaking promises is not good. It makes users sad… ;)
Originially raised in https://bugzilla.redhat.com/show_bug.cgi?id=1462008, where Zbigniew Jędrzejewski-Szmek also commented:
> I think it would be a shame not to package it in time for F26 final.
I agree… so could someone help here?
Best regards,
rugk

Hi,
Jiri found this review (among many) of Fedora 25:
http://www.hecticgeek.com/2016/12/fedora-25-review/
It includes a couple recommendations:
* We should restore systemd-readahead to speed boot time by ~30% for
users without SSDs. Endless has a downstream patch for this. Or we
could use Ubuntu's readahead utility.
* We should switch from CFQ to deadline I/O scheduler (which Ubuntu
has been using for years) for subjective massive responsiveness
improvements when the system is under load
Of these, the later seems easier to change and more important. Anyone
know why we're still using CFQ? If the answer is "it's better for
servers" then perhaps we need a mechanism to adjust this on a per-
product basis.
Just wanted to put these issues back on the radar....
Michael

The actual PR is posted in: https://pagure.io/pungi-fedora/pull-request/257
This is only for: https://fedoraproject.org/wiki/Changes/WorkstationOstree
The primary reason to do this is that the blivet defaults break with ostree,
since `/home` needs to be `/var/home` with ostree.
https://bugzilla.redhat.com/show_bug.cgi?id=1382873
But bigger picture than that, having a split `/home` makes less sense using
rpm-ostree, because the primary original rationale for introducing that split
was to make upgrades easier by reinstalling but preserving `/home`. With
rpm-ostree upgrades should be much more reliable and easier.
We also to use XFS (as opposed to the blivet ext4 default) for the same reason as Atomic/Server -
it works better with overlay2 because it avoids inode limits.
And not using all of the disk makes it easier to do more advanced
partitioning *post* installation. For example, in the past I've used dm-crypt
for the OS and `/home`, but not for `/srv` where I put non-private data like my
git repositories. (Although I recently switched back to dm-crypt for everything
for simplicity).
Another good example of this is that `container-storage-setup` supports
allocating a separate LV for `/var/lib/docker`, so container storage is isolated
from the host.
Anaconda is making it easier to do arbitrary partitioning in the installer via
blivet-gui, but I think doing it post-install is more flexible. One can
use scripts as well (e.g. Ansible).
The flip side of course is that users are going to wonder why they only have
`14G` of space...we should likely teach the installer to have a simple "use all
of my disk" button, and also have one post-install (something like Nautilus
launching `Disks` with awareness of LVM)?
Signed-off-by: Colin Walters <walters(a)verbum.org>
---
fedora.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora.conf b/fedora.conf
index a7d403b..edc3586 100644
--- a/fedora.conf
+++ b/fedora.conf
@@ -812,7 +812,7 @@ ostree_installer = [
"x86_64": {
"repo": "Everything",
"release": None,
- "installpkgs": ["fedora-productimg-workstation"],
+ "installpkgs": ["fedora-productimg-atomic"],
"rootfs_size": "8",
"add_template": ["workstation-ostree-installer/lorax-configure-repo.tmpl",
"workstation-ostree-installer/lorax-embed-repo.tmpl"],
--
2.9.4

On Wed, 2017-06-28 at 21:41 -0400, Mohan Boddu wrote:
> Hi,
>
> I think we can have RC compose once all the blockers are resolved and QA
> files the ticket even during the holidays, even though I am not
> guaranteeing it but I think someone will get to it sooner or later.
>
> But my major concern is blockers, I am not sure if we can get all the
> blockers fixed by next Tue.
>
> Also, there are few proposed blockers and I dont know how many people will
> show up for Blocker Review meeting.
So here's a very quick and informal blocker status mail:
There are four accepted blockers.
#1462825 doesn't look like it should be particularly difficult for the
right people to fix - i.e. folks who know libreport and anaconda's
interface with it. We just need to make sure we have their eyes on it;
I've attempted to CC all appropriate people.
We have an approach for fixing #1449752 agreed and it just needs the
maintainer to go ahead and do it. I've tried to explain the urgency of
this in the bug this afternoon.
#1436873 is in a state of slight disagreement about whether it's really
happening, I think. ;) The openQA test is still failing quite often
(although not always). I will try and reproduce the issue manually
tomorrow, since there appears to be scepticism among the KDE folks. But
in general the KDE folks are quite fast to fix issues once we do pin
them down specifically, I would be quite optimistic about getting this
one fixed.
#1404285 is a GNOME crash quite a lot of people seem to be encountering
in different ways (possibly because it's a tracker issue and tracker is
hooked into lots of things). In at least some cases it causes GNOME as
a whole to crash back to GDM, which is of course bad. There are various
different reproduction steps documented in the bug. I'm hoping the
desktop team is looking at this, and will be able to provide us with
some more assessment.
There are five proposed blockers. My professional guesstimate *at this
point* is that at least four of them will probably be rejected, though
that could change with more data (attention pjones: if #1418360 and
#1451071 are more serious than they seem to us so far, please do let us
know). #1462444 is the most unclear one, but it doesn't seem like a lot
of people are running into it, and we may wind up rejecting it also on
that basis.
Given the holiday situation, it might make sense to do a blocker
meeting tomorrow (Thursday) or Friday, depending on how much notice
folks need, to give us at least a shot at doing an RC on Friday or over
the weekend, if all the accepted blockers happen to get resolved.
There are also a *ton* of proposed FEs for broken dependencies; we
might also want to blow through those quickly at a meeting.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

On Thu, 2017-06-29 at 10:19 -0400, Peter Jones wrote:
> On Wed, Jun 28, 2017 at 06:53:58PM -0700, Adam Williamson wrote:
> > There are five proposed blockers. My professional guesstimate *at this
> > point* is that at least four of them will probably be rejected, though
> > that could change with more data (attention pjones: if #1418360 and
> > #1451071 are more serious than they seem to us so far, please do let us
> > know).
>
> They absolutely are: basically Secure Boot doesn't trigger kmod
> signature checking, read-only /dev/mem, etc., in the current trees.
> This update fixes a grub bug that's triggering that behavior in the
> newer kernels, but was not triggering it in the older ones.
>
> So yes, I very much think these should be blockers.
Ah, from the description I thought it was purely an informational thing
(just the user couldn't tell whether SB was enabled, but if it was in
fact enabled, it was working properly). So basically the appropriate
protections aren't put in place when SB is active, making it quite easy
to subvert SB?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Hi,
after the last update in F26 my wallpaper disappeared. Indeed all of
them, but the default one were gone from /usr/share/backgrounds/gnome.
When I investigated why, I found out that the default set of wallpapers
was plit into gnome-backgrounds and gnome-backgrounds-extras. gnome-
backgrounds now only include the default wallpaper, everything else is
in *-extras.
First I have no idea why this change was made. Can anyone explain it to
me?
Second it brings two problems:
1. until gnome-backgrounds-extras is added to the list of pre-installed
packages we will only have two wallpapers pre-installed (GNOME default,
Fedora default), that's kinda too few.
2. the transition is not handled very well, wallpapers are removed from
gnome-backgrounds, but gnome-backgrounds-extras don't get installed. So
many users lose wallpapers they've set and end up with a blank desktop
wondering what has happened.
Jiri

Hi folks!
So, since we've been getting Workstation ostree installer images in the
last few Rawhide composes, I've been setting up openQA to test it. This
is not at present deployed to production openQA, but it *is* deployed
to staging openQA. Unfortunately the last few Rawhide composes have
contained a broken anaconda so the image has not been built, but the
20170615.n.0 compose *did* feature a working image, and you can see the
test results there:
https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version...
(note that *right now* there's an infra outage going on so as I write
this the page is inaccessible, but all should be back to normal
shortly).
Look for the Workstation dvd-ostree 'Flavor'. As you can see, for now I
just have it running a subset of the regular Workstation tests, with
the update-related tests - which assume an RPM-based system - left out,
for now. Everything mostly appears to work well, except for the known
bug https://bugzilla.redhat.com/show_bug.cgi?id=1193590 (that's the
cause of most of the tests showing up as 'soft failures', the 'orange'
state, rather than 'passes' / green).
So I have two purposes here: firstly just to let you know that this
testing is now happening (they will be run for any Rawhide or Branched
compose which contains a Workstation ostree installer image), and
secondly to ask about any other testing that would be useful. Is there
any practical way we can actually test the ostree update process, for
instance? For testing RPM-based updates, what we do is install a
'dummy' python3-kickstart package, with a NEVR known to be lower than
any 'real' version of the package, so we know for sure that an update
will be available from the official repositories, and then we go ahead
and run an update in the usual fashion. Would there be any similar kind
of possibility for testing ostree updates? The goals of openQA testing
are to test as 'realistically' as possible, so we only test unmodified
images, and want to have the test behave as similarly as possible to
how the 'real' operation would behave on an end user's system.
And besides updates, can anyone think of any other test that would be
particularly useful to run?
Of course, to be clear, this is mostly 'advisory' testing for now: this
image is still not a release-blocking image, so failures of the tests
will not automatically trigger any kind of special attention or even
bugs being filed, it will require people to be interested in looking at
them and filing bugs. I will try and do so, of course.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

So, funny story: my todo list has this item, which I'm crossing off
with this mail:
compare f21 / f22 / f23 boot on rust:
https://blogs.gnome.org/mcatanzaro/2016/01/31/on-boot-times/#comment-120
It's only been on my list since 2016-02-06, no big deal, right?
However, never let it be said that I'm a liar! I *did* finally get
around to doing it, plus I included F24, F25 and the current F26
nightly compose as well.
I tested each by installing from the x86_64 Workstation live image to
my test box, which has a low-end AMD CPU (A4-7300), 8GB of RAM, and a
Seagate 500GB SATA hard disk (not an SSD). I created a user during the
install (so first boot wouldn't hit gnome-initial-setup before gdm),
then measured the boot time from hitting 'enter' on the bootloader
screen to GDM appearing fully loaded. I then measured the time it took
from hitting 'enter' on the password prompt to GNOME appearing fully
loaded. Then I rebooted and did the same measurements again (to see if
second boot differed significantly from first boot). I did not use
encryption.
The results were in contrast to mcatanzaro's from that blog post. I
found no significant difference in boot times across F21-F25. With only
one exception, pretty much every 'boot to GDM' measurement came out at
30 seconds, give or take a second or two, and every 'GDM to GNOME'
measurement came out in the range of 6 to 8 seconds.
The exception was the first boot of Fedora 21, which took a little over
a minute. The second boot took 29 seconds, though, in line with all
other tests.
However, F26 does seem slightly slower than F21-F25. First boot to GDM
for today's F26 nightly measured at 42 seconds. Second and third boot
measured 39 seconds. GNOME load time was 8-9 seconds. Looking at the
systemd-analyze info, I don't see any obvious single 'culprit', it
seems more like approximately the same stuff is happening during boot,
it's just all taking a bit longer.
So I'm *still* not sure what's behind the very slow F23 boot Michael
reported, but my test couldn't reproduce that slowness or show any
significant difference between any of the releases from F21 to F25. The
difference between F25 and F26 might be worth some independent re-
testing and deeper analysis.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net