desktop July 2015

desktop@lists.fedoraproject.org

22 participants
17 discussions

GTK+ issues breaking openQA tests
by Adam Williamson 10 Jul '15

10 Jul '15

Hey, folks, just wanted to give a summary of the various issues I've found that are affecting openQA testing of Rawhide at the moment. There are two apparent rendering issues in GTK+: https://bugzilla.gnome.org/show_bug.cgi?id=752247 https://bugzilla.gnome.org/show_bug.cgi?id=752200 #752247 is the thing that stops the 'boot.iso default install' test working ATM, and would probably break all other tests too if they made it that far. The 'Begin Installation' button on the hub is drawn as if it were inactive even when all spokes are complete - it's actually active, you can click on it, but the openQA tests require it to display correctly (or else they can't tell the difference between ready and not -ready). #752200 causes all tests that do software selection to fail before they reach #752247, because the lists on the Software Selection screen don't render correctly. Again this messes up the openQA tests, as they expect the blue highlights in order to know which item in the list is currently active. Finally there's that icky font rendering stuff I was chasing down all week. mclasen's upstream commit should result in rendering on boot.iso and Workstation live being consistent once it lands in Fedora: https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5 340246e713f73f but we'll have to redo a lot of screenshots, I think. Most of our current screenshots were taken with F22 netinst images , i.e. with the 96.09dpi rendering; after that commit both boot.iso and Workstation will have the 96dpi rendering. Quite a lot of the screenshots do match sufficiently with either rendering - so far I've only found the root password and user creation screens fail - but often the match is only just barely OK (for instance, the 'Done' button needle matches at exactly 96% - right on the threshold - with Workstation live images), so I think it would make sense to redo all screenshots with text matches with the 96dpi rendering so we get stronger matches (and make it less likely any further little discrepancies push the match below the threshold). I was planning to backport the patch to Rawhide, but I wanted to check with mclasen first and he's been off IRC for the last few days, so I haven't done it yet. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

improving the appstream metadata
by kendell clark 09 Jul '15

09 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 hi all I'd like to help improve two key areas of fedora and by extension, gnome. They both have to do with appstream, which is, I think, what gnome software uses to display metadata about a package, license, description, etc. The first is the data itself. Some packages are missing the metadata. The second has to do with handling of unknown mime types. Whenever the system comes up with a file type it can't handle it opens up gnome software to install something that can handle that type. Usually this results in a generic "unfortunately, we couldn't find anything to handle this type" message. I'd like to fix this. I'm just not sure how this works. Looking in my appstream data in /usr/share/appdata, I see that some applications have two files. applicationName.appdata.xml, which is the metadata, license, description, etc. And appName.metainfo.xml, which looks like what I'm looking for. Would it be at all possible to parse the .desktop file for applications and extract the mime type data from there? This would improve the accuracy significantly since most desktop files say what mime types they can handle. We could then use the data to generate either an appstream file or a metainfo file. This might not need much work, all it would need would be changes to appstream-builder and possibly either an extension to the freedesktop desktop file standard or adding extra tags, something like x-license="license" and x-description="description". Sorry if I'm getting a little technical. I'm also trying to figure out how gnome software finds applications when typed into the search field. Most of the time, typing in an application name results in a "no application found" message, even though that app is indeed available. Is this related to the appstream data again? Or is there something else? A good example is orca, the screen reader. Type orca into gnome software and you'll get an error message. I hope this isn't the wrong place to write this, but it was the only one I could think of. Thanks for reading Kendell clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVnwgBAAoJEGYgJ5/kqBTdrUoP/21D7NXbfFrURqP653iCnT/1 fVyneOycksS5XkORPTrLuXRjv9H6dXrx7Kxi1yRusgsip4tqoCnYbTjqkii4/Z65 pGVKvA/xt0FmLPRuY8rul8+JgIVwFkJ52VtnLKnRp5wf8qfVHu9OfyED4zZCbqI2 wdtPK6HtAv0R/21eOrMOmY2QUAFid8DR0mk05au25q9STnTEAHlvqgElxIQcVds9 kYtauicDf8Vknle4xuALVZwYHtHbBXFTsmSn5bx5VUDditaRtTpo8/lYI1V7sZ0g 4ihnvJSUNr/M0Rwh1usNXcK9cs740Z/kChrxFBTuZIoeOJ5A5SRW/DjHvMaz+RUP vQYzIDf71Fq0EAQFBE4eAze7NZGI6TBx1T32p4igFT8C1OMSbF1Zes+8wGu717p6 xOynciLKpN+ZQD2RZpHrH+4eTHZI21dEQ0e4PSw2MoT6sJx8FGpBiyVR0uxDHdR1 lXbG2Cjy821kVEuAGYvu1FAahA0QWuqFKYVVnnXFej0sImNeanfs4twEUD+ewfN/ RT2UUS5rHaT4fO5fPvrhpOuqL/UmSgjhJy7bv62vBN2IR0KfxXgNEWEN/K9h0X6P wo19717LFk62+EaCtqIp9vj4xT6ObDXzr8kyCGRWDDXR7fCchR8+jlZBTNSO0x9c xFaC+ksTAIltY5RVwO5R =8eEK -----END PGP SIGNATURE-----

1 0

Planning for an "Atomic Workstation"
by Owen Taylor 09 Jul '15

09 Jul '15

The classic mode of updating a Linux system or upgrading it to a new version, where we take the package set for the old system and a new package repository and compute an individualized upgrade to the new version works pretty well most of the time. But sometimes the local system is outside the bounds of what has been tested, and the upgrade fails, requiring an experienced sysadmin to recover it. Even if upgrades succeed, a system that is serially upgraded between versions over a long period of time will eventually be much different from a freshly installed system. These disadvantages are a big part of the barrier to using Fedora for the average user: with our release cycle, the user *has* to upgrade, and eventually the result of upgrading will be a degraded or non-functional system. Within Fedora, we first looked these issues with the Stateless Linux project (http://blog.ometer.com/2004/09/13/stateless-linux/), over 10 years ago. It resulted in a lot of fixes to Fedora to reduce the need to locally modify configuration files and otherwise remove unnecessary state. But there were two big things we never really solved: first, we didn't have a good system for distributing updates incrementally and updating the operating system image in an atomic way. Second there was no way to install software on top of the base operating system. The OLPC project subsequently worked on both areas, though in ways that didn't obviously relate back to normal desktop Linux. ostree, which Colin Walters started work on in 2011, is meant to solve the operating system update problem, and provide the ability to efficiently distribute different operating system trees, have multiple trees installed on the system and switch between them atomically. This forms the basis of Project Atomic (http://www.projectatomic.io/) and Fedora Atomic Host (https://fedoraproject.org/wiki/F21_release_announce ment#Fedora_Atomic_Host), which target a different place where sysadmin attention is limited: a cloud hosting environment with large numbers of systems. With rpm-ostree, used in Fedora Atomic Host, the operating system is still assembled from individual RPMs built the same way as before, but it is distributed and updated as a while. If the base operating system is a unified whole, then we need a way to install software on top, and in particular, to install desktop applications. Although we can use some of the same kernel mechanisms as are used for containerized server applications to provide encapsulation for desktop applications, there are also a range of desktop-specific needs. Among other things: there needs standardized integration points with the desktop, it should be possible to install and run applications without having root privileges on the system, and individual applications should be as small and lightweight to download and update as possible. Last fall, Alex Larsson started an effort to look at sandboxed application installation (https://mail.gnome.org/archives/gnome-os-list/2014-September/msg00000.html), which eventually became xdg-app (https://mail.gnome.org/archives/gnome-announce-list/2015-June/msg00017.html). The combination of rpm-ostree and xdg-app provide the basis for a future version of Fedora Workstation that has a split between an atomically updated unified core operating system, and encapsulated applications installed on top. But there is a lot of work to be done to get there. We need to deal with the details of creating trees, installing the operating system, and updating it in a user-friendly and consistent manner. We need to build out the pieces of an xdg-app ecosystem that is as broad as possible - that isn't just for GNOME applications, or just for Fedora. And most of all, we need to figure out how people continue to do all the things that they currently accomplish with Fedora Workstation. Although the classic package-by -package installation of Fedora isn't going to be go away for quite a while, an Atomic Workstation can't be just for people running GUI pre -packaged applications - it needs to be usable for the core developer target of Fedora Workstation and even for people who are creating the operating system. I've created a wiki page to motivate in more detail the advantages of such a separation, and to start figuring out in detail what we'd need to get there: https://fedoraproject.org/wiki/Workstation/AtomicWorkstation xdg-app and rpm-ostree are already in Fedora, and it's possible to create test images right now. But overall, this is not a short term project, and in particular, the goal of fully sandboxed applications relies on other major technical pieces like Wayland and perhaps kdbus that are still in progress. At this point, I'd like to get some discussion going about having exploring this direction be a goal for Fedora Workstation. I'd also like to invite people to work with me on figuring out a solid developer story: how we can make Atomic Workstation an even more friendly, flexible and robust way to develop server and desktop software than what we have currently?

1 0

Workstation WG Recap 2015-Jul-06
by Michael Catanzaro 06 Jul '15

06 Jul '15

Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2015-07 -06/workstation.2015-07-06-13.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2015-07 -06/workstation.2015-07-06-13.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2015-07 -06/workstation.2015-07-06-13.00.log.html Present: Michael Catanzaro, Matthias Clasen, Rex Dieter, Christian Schaller Regrets: Paul Frields, Kalev Lember Missing: Ryan Lerch, Jens Petersen, Owen Taylor =============================== #fedora-meeting: Workstation WG =============================== Meeting started by mcatanzaro at 13:00:32 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-07 -06/workstation.2015-07-06-13.00.log.html . Meeting summary --------------- * Roll call! (mcatanzaro, 13:00:45) * DisabledRepos and Software Center (mcatanzaro, 13:05:59) * LINK: https://lists.fedoraproject.org/pipermail/devel/2015-July/211915.html (mcatanzaro, 13:06:38) * LINK: https://git.gnome.org/browse/gnome -software/tree/data/modulesets/system.xml <-- there is the "definition" (mcatanzaro, 13:28:51) * IDEA: We need a better definition for the set of software that is considered System Applications by GNOME Software. (mcatanzaro, 13:31:18) * IDEA: Any .repo files for Coprs that are installed by default in Fedora Workstation with enabled_metadata=1 should not point to Coprs that contain packages provided by Fedora, unless that repository contains only leaf packages. (mcatanzaro, 13:35:51) * AGREED: Any .repo files for Coprs that are installed by default in Fedora Workstation with enabled_metadata=1 should not point to Coprs that contain packages provided by Fedora, unless that repository contains only leaf packages. (mcatanzaro, 13:39:37) * How will Workstation use xdg-app? (mcatanzaro, 13:40:39) * ACTION: rdieter to respond to devel@ thread regarding enabled_metadata for coprs. (mcatanzaro, 13:57:34) Meeting ended at 13:59:50 UTC. Action Items ------------ * rdieter to respond to devel@ thread regarding enabled_metadata for coprs. Action Items, by person ----------------------- * rdieter * rdieter to respond to devel@ thread regarding enabled_metadata for coprs. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mcatanzaro (54) * mclasen_ (32) * rdieter (17) * cschalle (13) * zodbot (5) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

multiple languages in fedora workstation?
by kendell clark 06 Jul '15

06 Jul '15

hi all This may have been covered here before, and if so I apologize for the mess. I've been getting a couple of blind users who switch over from windows to fedora, or at least, they say they will. But they speak multiple languages, and usually want to have gnome shell and apps displayed in their native language. So I went and attempted to find out how this is done. Here is what I've found, and it's puzzling. According to gnome's docs, you simply go into the region and language control center applet, highlight the language you want to use, and press enter. If the language isn't in the list you're supposed to find a "..." button to open a list of languages to pick from. On my fedora install, there are only two items in the list. English US, and an item that's silent. Orca says nothing but I think it's that "..." button the docs were talking about. Instead of taking me to a list, it closes the language dialog with no effect. I know how locales on the command line are supposed to work, you've got two files in /etc that control this. Locale.gen, which controls what languages are available to the system. I chose german and french, utf8, just to experiment with. Then there's locale.conf which controls the currently active language. You simply export a new language into this file and the language is supposed to change. Example, export lang=en_UK.utf-8 > /etc/locale.conf." Is this what gnome's language control center item does? I'm hearing a lot about these "language packs" in gnome's documentation, but no matter how I search, dnf, software, I can't find one. Anyone got any ideas? After I added french and german in locale.gen, or rather, uncommented them and ran locale-gen, the languages immediately showed up in the language list, but pressing enter on them didn't change the language. I'm hoping it's something obvious, such as you needing to log out and back in for the new language to take effect. If not, this is probably a bug in gnome and I need to report it. Thanks for reading Kendell clark

3 16

Call for agenda for Workstation WG meeting 2015-July-06
by Michael Catanzaro 04 Jul '15

04 Jul '15

Next meeting is Monday, 2015-July-06 at 1300 UTC/9:00am US-EDT. Agenda additions are welcome. I have only item again: * How will Workstation use xdg-app? WG members, please take a look at this draft proposal from the Environments and Stacks group, where xdg-app is mentioned several times, before the meeting: https://fedoraproject.org/wiki/Env_and_Stack s/Projects/PackageReviewProcessRedesign

2 2

No extra-backgrounds for Fedora 22
by Heiko Adams 03 Jul '15

03 Jul '15

Hi, just a short question: Did I miss something or are there (currently) no extra-backgrounds for Fedora 22 (something like f22-backgrounds-extras) in the repos? -- Regards, Heiko Adams

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 2015