GTK+ issues breaking openQA tests
by Adam Williamson
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
8 years, 8 months
improving the appstream metadata
by kendell clark
-----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-----
8 years, 8 months
Planning for an "Atomic Workstation"
by Owen Taylor
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?
8 years, 8 months
Workstation WG Recap 2015-Jul-06
by Michael Catanzaro
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
8 years, 8 months
multiple languages in fedora workstation?
by kendell clark
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
8 years, 8 months
No extra-backgrounds for Fedora 22
by Heiko Adams
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
8 years, 8 months