desktop June 2017

desktop@lists.fedoraproject.org

34 participants
20 discussions

Fedora 26 is missing GNOME Recipes
by rugk 18 Jul '17

18 Jul '17

…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

7 15

Some performance criticisms of F25
by Michael Catanzaro 09 Jul '17

09 Jul '17

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

7 14

[PATCH] ws/ostree: Use atomic product img
by Colin Walters 04 Jul '17

04 Jul '17

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

5 11

Re: Schedule concern next week: holidays ahead!
by Adam Williamson 29 Jun '17

29 Jun '17

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

5 4

Re: Schedule concern next week: holidays ahead!
by Adam Williamson 29 Jun '17

29 Jun '17

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

1 0

Default wallpapers splitted into *-extras
by Jiří Eischmann 26 Jun '17

26 Jun '17

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

10 14

Testing ostree Workstation
by Adam Williamson 24 Jun '17

24 Jun '17

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=R… (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

4 8

F21-F26 boot time comparison
by Adam Williamson 23 Jun '17

23 Jun '17

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

3 3

Workstation WG meeting recap 2017-Jun-19
by Paul W. Frields 19 Jun '17

19 Jun '17

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-06-19/workstation.2… Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2017-06-19/workstation.2… Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-06-19/workstation.2… * * * ================================= #fedora-meeting-2: Workstation WG ================================= Meeting started by stickster at 13:00:26 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2017-06-19/workstation.2… . Meeting summary --------------- * Roll call (stickster, 13:00:32) * Agenda (not ordered): https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting (stickster, 13:05:00) * Removing at (stickster, 13:05:59) * LINK: https://pagure.io/fedora-workstation/issue/19 (stickster, 13:06:01) * AGREED: +6, -0: remove at from default install, since chrome will pull it in anyway atm (stickster, 13:22:10) * ACTION: cschalle ask devs to contact Google about using a systemd timer for their cleanup bits (stickster, 13:22:26) * REVISED: +7, -0 on above vote (stickster, 13:22:43) * ACTION: kalev fix up distro/comps stuff to make it happen (stickster, 13:23:16) * F26 Final blockers (stickster, 13:24:34) * LINK: https://pagure.io/fedora-workstation/issue/20 (stickster, 13:24:37) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1404285 (stickster, 13:25:25) * gnome-documents bug, moved out of gjs by catanzaro (stickster, 13:25:47) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1340203 (stickster, 13:26:04) * GOA issue, seems to have popped up intermittently as blocker beforfe (stickster, 13:26:47) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1462444 (stickster, 13:26:53) * gjs issue prevents GNOME Shell login (stickster, 13:27:31) * ACTION: stickster reassign BZ 1340203 to halfline (stickster, 13:34:16) * ACTION: cschalle follow up on BZ 1340203 (stickster, 13:34:24) * ACTION: mclasen assign BZ 1404285 to garnacho and follow up (stickster, 13:39:37) * ACTION: otaylor follow up on BZ 1462444 (stickster, 13:40:21) * Workstation repository (stickster, 13:41:00) * LINK: https://pagure.io/fedora-workstation/issue/17 (stickster, 13:41:03) * sgallagh advises that we should be able to keep our own repo package (stickster, 13:45:20) * ACTION: cschalle to have Council review 3rd-party repo policy (stickster, 13:45:42) * ACTION: stickster make sure this is clearer in ticket so we don't run round in circles (stickster, 13:45:56) * Packaging guidelines for app independence (stickster, 13:46:44) * LINK: https://pagure.io/fedora-workstation/issue/13 (stickster, 13:46:48) * Any other (admin) business (stickster, 13:51:24) Meeting ended at 13:54:35 UTC. Action Items ------------ * cschalle ask devs to contact Google about using a systemd timer for their cleanup bits * kalev fix up distro/comps stuff to make it happen * stickster reassign BZ 1340203 to halfline * cschalle follow up on BZ 1340203 * mclasen assign BZ 1404285 to garnacho and follow up * otaylor follow up on BZ 1462444 * cschalle to have Council review 3rd-party repo policy * stickster make sure this is clearer in ticket so we don't run round in circles Action Items, by person ----------------------- * cschalle * cschalle ask devs to contact Google about using a systemd timer for their cleanup bits * cschalle follow up on BZ 1340203 * cschalle to have Council review 3rd-party repo policy * kalev * kalev fix up distro/comps stuff to make it happen * mclasen * mclasen assign BZ 1404285 to garnacho and follow up * otaylor * otaylor follow up on BZ 1462444 * stickster * stickster reassign BZ 1340203 to halfline * stickster make sure this is clearer in ticket so we don't run round in circles * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * stickster (90) * otaylor (30) * juhp_ (17) * kalev (16) * mclasen (14) * zodbot (12) * cschalle (8) * sgallagh (4) * ryanlerch (2) * misc (1) * rdieter (0) * juhp (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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

1 0

Re: Draft of desktop application packaging document
by William Moreno 19 Jun '17

19 Jun '17

You can find the current draft here: https://github.com/cschalle/content/blob/master/start/sw/ gui-app/how-to-package-a-desktop-application.md Was this file moved to other place?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop June 2017