desktop July 2017

desktop@lists.fedoraproject.org

24 participants
15 discussions

file save / open dialogs do not show smb shares
by Chris Murphy 03 Jul '17

03 Jul '17

Can anyone else reproduce this? I don't know if this is a Fedora 26 regression, or if it's been around since Fedora 25, but I can only find old bugs about it. If it were not a very recent regression I'd expect there'd be a more current bug report already. The gist is that I don't see SMB shares in any open / save dialogs; I have to navigate to /run/user/1000/gvfs/smb-share:server=192.168.1.115,share=scratch/ And now I can open and save things... https://bugzilla.gnome.org/show_bug.cgi?id=784490 Except with flatpak programs, for which I opened a separate bug. https://github.com/flatpak/flatpak/issues/893 -- Chris Murphy

1 1

Re: ws/ostree: Use atomic product img
by Chris Murphy 03 Jul '17

03 Jul '17

On Mon, Jul 3, 2017 at 2:57 PM, Owen Taylor <otaylor(a)redhat.com> wrote: > I don't have any problem with switching to XFS or getting rid of the /home split. The former should be pretty invisible to users, and split home is more of a trap for users than a help. > > But switching to leaving most of the disk unpartitioned seems wrong. With the move to overlay2 for Docker storage, everything you want to do with disk space is inside / - the OS image, your overlay RMs, your docker storage, your home directory. Yes, early adopters of the Atomic Workstation can deal, but long term, we don't want Atomic Workstation to be for the adventurous - we want it to just work. > > Yes, it's easier to grow partitions then shrink them, but I don't think that can excuse leaving users out of the box with a less-than-useful partitioning setup. Short version: I'd say ideal scenario for Workstation-ostree is two partitions: one big XFS volume, and one appropriately sized swap. /boot and /home are directories. But due to an obscure bug [1] this practically means ext4 /boot, XFS for / and /home, and swap; or three partitions. I'd leave LVM out of it because it doesn't really bring anything to the table, but whatever. Long version: Unpartitioned space The way this is done now for Server and Atomic Host makes sense for those use cases. It doesn't make sense for Workstation-ostree. Right now Workstation and Workstation-ostree make root fs 50G, and the rest to /home. That needs revisiting for Workstation or Workstation-ostree, it's just more necessary for Workstation-ostree because platform libraries and flatpaks are bigger than traditional counterparts. Partitions v quotas It's better to use quotas as a limiter, rather than carving things up with multiple partitions (or LVs). Quotas achieve the same goal, but can be changed anytime and not having to worry if the user is going to get wedged into an overfull root fs or home with wasted space on the other. Of course the UIs for each filesystem's quota management are children of satan, but that's a separate convo. /home as separate partition I'm skeptical that ostree installations are less fragile than conventional installs, and obviate separate /home file systems, until Joe User is doing weird and crazy shiat with it. Anaconda enforces a reformat for ext4 and XFS root fs. So if /home is a directory, and a reinstall becomes necessary, it means /home isn't salvageable, it'll have to be restored from backups. Anaconda exempts reformat on Btrfs, instead enforcing the creation of a new subvolume for the root filesystem. Also separate root and home come in handy on Btrfs for snapshotting them separately, and using btrfs send/receive (directly or with btrbk) for home only backup and restore. Shrinking Btrfs has online only, atomic grow and shrink, and uses the same allocation code path for normal reads/writes and balancing, i.e. it's highly exercised code and integral to its design. XFS can't shrink, and ext4 only has offline shrink and while ostensibly safe (or else it's a big bug) it comes with its own risks and inefficiencies in the resulting layout. [1] Due to a combination of long delayed allocation on XFS flushing journal contents to fs metadata, and Plymouth making itself kill exempt, and systemd being unable to remount-ro, or umount the volume; when /boot is a dir on rootfs it's possible for bootloader configuration file changes to only hit the journal and not file system metadata at reboot time. And the bootloaders do not know how to read a dirty journal, so they don't see the updated bootloader file at all, it's missing, so reboot from updates can fail entirely. If you merely boot some other installation or live media and mount this root fs, the kernel reads the dirty journal and flushes its contents to fs metadata, and now everything is fine and the system will boot normally, xfs_repair isn't even needed. Merely a mount and umount. https://bugzilla.redhat.com/show_bug.cgi?id=1227736 Technically all file systems are susceptible to this problem when /boot is a directory and thus remount-ro fails and umount doesn't happen. But only XFS seems to manifest with a problem. ext4 and Btrfs must just flush to disk faster (or something). -- Chris Murphy

1 0

Status report on Flatpaks in Fedora Infrastructure
by Owen Taylor 03 Jul '17

03 Jul '17

I've just submitted a change proposal for creating Flatpaks out of Fedora package content: https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks This is submitted as a F27 change proposal, but it's expected that it will be multiple releases before everything in the final shape. My hope for Fedora 27 is that by the fall packagers will be able to start experimenting with making Flatpaks out of their graphical applications and there will be a small set of applications for users to install. There is more extensive documentation about the technical plan at: https://fedoraproject.org/wiki/Workstation/Flatpaks Building Packages ================= Flatpaks require rebuilding applications and bundled dependencies to be located with a prefix of /app rather than /usr. We're using the infrastructure created for modules to rebuild packages, and it has worked out very smoothly so far. There are prototype runtime and application modules at: https://src.fedoraproject.org/cgit/modules/eog.git https://src.fedoraproject.org/cgit/modules/flatpak-runtime.git Building Flatpaks out of Packages ================================= After building the packages, they need to be combined into a Flatpak runtime or application. There is a python script to do this locally in https://pagure.io/flaptak-module-tools, but the goal is do this within the same build pipeline as is used for containers, and I've started prototyping out changes to atomic-reactor. One element that is needed to built Flatpaks or containers against modules is published composes of modules. This will be provided by the "On Demand Compose Service". Development on this by the modularity team started recently, but seems to be going well. Distributing Flatpaks ===================== The goal is to distribute Flaptaks from registry.fedoraproject.org. This requires passing two hurdles: * Flatpaks are OCI Images, not docker containers, and we don't have OCI Image support in registry.fedoraproject.org (which is an instance of https://github.com/docker/distribution/) There is conceptual agreement to add this upstream, and a pull request that is blocked on finalizing the OCI Image specification. * For GNOME Software to provide a nice installation interface from the registry rather than an OSTree repository, we need to have a) an index of all flatpaks/containers in the registry b) appstream data for the containers in the registry. The cockpit team has similar requirements for their container installation interface, and we'll collaborate with them in coming up with a solution. This work is still at the research and discussion phase. Updates ======= There is work currently underway to add support to Bodhi for filing updates for containers rather than for packages should carry directly across to Flatpaks. This may be sufficient for F27. However, eventually it seems like we need to have automation, where updates of packages automatically cause updates of containers/flatpaks for those packages. This workflow still needs to be planned out in detail.

1 0

Workstation WG meeting recap 2017-Jul-03
by Paul W. Frields 03 Jul '17

03 Jul '17

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation.2… Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation.2… Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation.2… * * * ================================= #fedora-meeting-2: Workstation WG ================================= Meeting started by stickster at 13:00:10 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation.2… . Meeting summary --------------- * Roll call (stickster, 13:00:15) * Anaconda (stickster, 13:09:07) * anaconda has significant redundancy with gnome-initial-setup (mcatanzaro, 13:10:35) * AGREED: mcatanzaro to prepare F27 change proposal to remove redundancy between anaconda and gnome-initial-setup (+1: 5, 0: 0, -1: 0) (stickster, 13:23:33) * Removing LibreOffice Draw from Workstation (stickster, 13:28:39) * LINK: https://pagure.io/fedora-workstation/issue/16 (stickster, 13:28:41) * AGREED: Drop it (+1: 5, 0: 0, -1: 0) (stickster, 13:32:53) * ACTION: mcatanzaro file PR for fedora-comps to remove libreoffice-draw (stickster, 13:33:02) * fedora-workstation-repositories not in default install (stickster, 13:33:30) * LINK: https://pagure.io/fedora-workstation/issue/17 (stickster, 13:33:35) * All other business (stickster, 13:35:15) * LINK: https://fedoraproject.org/w/index.php?title=Workstation/VisualIdentity (ryanlerch, 13:53:04) * AGREED: ryanlerch to work on Change page, proposal coming soon (q.v. Anaconda Change above) (stickster, 13:57:07) Meeting ended at 13:57:12 UTC. Action Items ------------ * mcatanzaro file PR for fedora-comps to remove libreoffice-draw Action Items, by person ----------------------- * mcatanzaro * mcatanzaro file PR for fedora-comps to remove libreoffice-draw * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * stickster (74) * mcatanzaro (50) * otaylor (29) * juhp_ (16) * zodbot (12) * ryanlerch (10) * bowlofeggs (2) * rdieter (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

[Fedocal] Reminder meeting : Workstation WG
by stickster＠gmail.com 01 Jul '17

01 Jul '17

Dear all, You are kindly invited to the meeting: Workstation WG on 2017-07-03 from 09:00:00 to 10:00:00 America/New_York At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Regular meeting for the Workstation Working Group. Agenda: [https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting](https… More information available at: [https://fedoraproject.org/wiki/Workstation](https://fedoraproject.org/wiki/… Source: https://apps.fedoraproject.org/calendar/meeting/6331/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop July 2017