Anaconda wishlist
by Michael Catanzaro
Hi,
I put together a desired installation experience wishlist. Let's
discuss and consider forwarding this to the Anaconda developers as a
request.
* Remove the timezone selection spoke. This spoke is redundant with
gnome-initial-setup.
* Remove or simplify the network configuration spoke. In the live
installer, this spoke allows setting only the system hostname, but it
follows different rules for setting the hostname than GNOME/systemd.
The spoke should either follow hostnamed's rules for pretty hostnames
(i.e. allows capital letters, spaces, etc. without any complaint), or
the spoke should be removed. If we keep it, it should allow the user
to set a "computer name" (avoiding technical terminology like
"hostname") and should not include the phrase "network configuration."
* Remove root password configuration. It's confusing how this is
different from the user's admin account password. Advanced users can
set a root password after installation if desired.
* Remove user account creation. This is redundant with gnome-initial
-setup.
* Remove hub and spokes: simply go straight to keyboard layout
selection after language selection, then from there to disk layout,
optionally from there to the hostname panel, and then to the
installation progress panel. This last panel will need a bit of a
redesign, since it will be pretty empty otherwise.
Clearly this is mostly a list of things to remove, rather than things
to add. The goal is to make installation as simple and easy as
possible.
Changes to gnome-initial-setup: Skip language and keyboard layout
selection in user creation mode. These panels cannot reasonably be
removed from Anaconda, so we should use them only in existing user
mode (when a new user account is created after installation). They're
redundant in user creation mode.
This proposal leaves the disk layout spoke untouched, which is the
most confusing portion of the installation experience, but it's more
than enough changes for one release already.
Thoughts?
7 years, 10 months
Significant drop in ABRT reports in F22
by Jiri Eischmann
Hi,
I regularly go through most frequent problems reported to ABRT retrace
server because it helps me prioritize bugs in Fedora that are assigned
to my team.
I've noticed a significant drop in number of reports in Fedora 22.
It's just two weeks before the final release when many early adopters
are already running F22, but the difference in number of reports from
F21 and F22 is huge: 64373:904.
12 days before F21 was released, we collected 16081 reports from this
version. That's almost 18x more. I don't think we're experiencing such
a huge drop in adoption, so I investigated more.
I found out several things which I think are a cause of this:
1) I upgraded my machine, and the new Problem Reporting in Privacy
Settings is set not to do automatic reporting, completely ignoring my
settings in ABRT from F21.
2) I checked settings in ABRT and automatic settings was enabled, so I
thought something was broken because my crashes were not reported
automatically. Then (with the help of Jakub Filak) I found out that
this had been overridden by the new settings in Privacy.
3) Users are no longer asked if they want to enable automatic
reporting when the first crash happens. So unless despite complete
lack of any hints they find their way into Privacy settings their
crashes are not reported. I can no longer even make ureports manually
by clicking on Report in notifications. To report it, I need to do the
full BZ report.
With such a decrease in number of reports, ABRT is much less useful to
developers and I think we should fix it:
* privacy settings should reflect my settings from ABRT after upgrade.
* settings in ABRT and Control Center should be in sync, I understand
that the Privacy is master settings overriding app's settings, but
there is only one app reporting and it's very confusing for users.
* users should be asked if they want to enable automatic reporting
after the first crash like in the last.
Jiri
7 years, 10 months
root login via gdm
by Pete Travis
At one time, one could not log in to a GNOME session on Fedora as the
root account. Now, you can, out of the box. For me, this seems like
less of a "getting in the user's way" thing, and more of a common sense
default security policy - especially given all the work done to make
things work smoothly with polkit. Am I missing something? If not, what
about going back to blocking root login to desktop environments?
--
-- Pete
7 years, 10 months
Re: VSYNC problems on Fedora 21/22 and Intel HD graphics...
by drago01
On Wed, May 27, 2015 at 10:01 PM, Chris Wilson <chris(a)chris-wilson.co.uk> wrote:
> On Wed, May 27, 2015 at 03:37:29PM -0400, Alex G.S. wrote:
>> Hello,
>> First of all I love the new GNOME 3.16 release. The notifications and
>> system tray icons (in the left) are great and productivity boosters.
>> However, I'm having some issues with Intel HD graphics on X11 that make
>> things very difficult. Though these problems are solved by the Wayland
>> session it's still too unstable for me to use in production as a
>> day-to-day desktop.
>> Hardware:
>> Intel® Core™ i5-4200M CPU @ 2.50GHz × 4
>> Intel® Haswell Mobile (HD 4600, i965)
>> GNOME:
>> Version 3.16.2
>> Kernel:
>> 4.0.4-301.fc22.x86_64
>> Problem:
>> [1]https://bugzilla.gnome.org/show_bug.cgi?id=741376
>> At work I use two external monitors in addition to the laptop screen.
>> VSYNC often breaks when using either SNA or UXA at random intervals. It
>> also breaks also when I fullscreen any application in any monitor. Even
>> when I force VSYNC in both xorg.conf and drirc it doesn't seem to help.
>> These are configurations for reference:
>> /etc/environment:
>> CLUTTER_VBLANK=True
>> /etc/X11/xorg.conf.d/20-intel.conf
>> Section "Device"
>> Identifier "Intel Graphics"
>> Driver "intel"
>> Option "AccelMethod" "sna"
>> Option "TearFree" "true"
>> Option "SwapbuffersWait" "true"
>
> Try Option "DRI" "2" in conjunction to the above.
We no longer default to DRI3 in F22.
7 years, 10 months
Fedora runtimes and sandboxed desktop applications
by Alexander Larsson
I'm working on an application sandboxing system called xdg-app, and
the surrounding echo-system. I won't go into details, but there are
some links to technical details at the end of the mail[1]. The basic
idea is that we have two sources (both ostree trees), one called the
runtime (/usr), and one called the app (/app), which get combined in a
container-like environment at launch time by xdg-app, with configurable
degrees of sandboxing. There is also some interaction with the host
system so that installed desktop files show up in the shell and dbus
session services from apps work.
xdg-app has two major goals, the first is to allow applications to run
in a sandboxed environment with minimal access to the host. The second
is to allow third parties to create and distribute applications that
run on all distributions (and the sandboxing helps making this less
risky). To facilitate and test this I've also created an upstream
gnome runtime[2] that gnome applications can chose to use. I'm also
working on various Portal APIs[3] that allow sandboxed applications to
safely interact with the system.
But, third party applications are a long way off in the future, and so
are sandboxed applications (which need not only a fleshed out set of
sandbox APIs, but also modifications to individual apps). In the
meantime it is still interesting to run bundled applications. For
instance in the context of an Atomic-based Fedora Workstation (with
readonly /usr), or if you want to run older or newer versions of
applications than your distribution is shipping.
It would make a lot of sense to use the existing packages in Fedora
for this. And in order to kickstart discussions about this I've
created an initial sample of a possible Fedora runtime using
rpm-ostree and the Fedora 22 repositories:
https://github.com/alexlarsson/fedora-runtime
Building this produces a repo with the main runtime
(org.fedoraproject.Platform) and a sdk runtime (org.fedoraproject.Sdk)
which has some additional tools for app creation and debugging. It
also builds .Var subruntimes that contain /var with the rpm db
for use when building apps. The current package set is mostly based on
what is in the gnome one, so don't consider this official in any way.
These runtimes are made to work with xdg-app 0.3.0 which are now in
updates-testing for F21 and F22. You also need rpm-ostree from git
master for the container support to build the fedra runtime.
In order to test the runtime I've also created a firefox application
bundle. Unfortunately it requires some hacks in order to be relocated
to /app, and to work as a bundle. However, it works pretty well,
running somewhat contained with only access to the Downloads xdg
directory and with ~/.mozilla being redirected to the per-app
persistant data directory (~/.var/app/org.fedoraproject.firefox). Note
however, that I would not consider this properly sandboxed, as it uses
X11 for rendering, which is not very secure.
The scripts to build the firefox bundle is here:
https://github.com/alexlarsson/fedora-apps
I've also put up a xdg-app repository so that you can easily test this:
(Run these commands as non-root, due to the --user args)
xdg-app add-remote --user --no-gpg-verify fedora http://people.redhat.com/~alexl/repo
xdg-app install-runtime --user fedora org.fedoraproject.Platform 22
xdg-app install-app --user fedora org.fedoraproject.firefox
xdg-app run org.fedoraproject.firefox
Once installed the desktop file will be exported to the session, so
you should also be able to launch it from the shell. In theory this
should work on any distro, but I've only tried it on F21.
The question is, would the Fedora project be interested in supplying
and maintaining a Fedora runtime like this, which allows us (and
others) to create applications using the fedora base. And if we do,
exactly what should be considered part of the basic platform.
Defining a platform requires a lot of care. It is a balance between
wanting as much as possible in it to share more maintainance and
updates and make it easier to write apps and on the other hand trying
to keep the basic platfrom small, maintained and of high quality. The
ABI requirements for a platform is a bit different than a regular
distro. The goal is to allow apps built against a particular platform
to run for years to come, so it should only do security and very
important bugfix updates, and *never* break ABI. On the other hand,
its easy to break ABI in a later version of the runtime, because they
are parallel installed. This is somewhat different than our current
updates which revs libraries during the distro lifetime as long as it
also updates all users of it.
An added complexity is that anything in the runtime that relies on
some kind of IPC to the host (say the pulseaudio client libraries, or
something that uses a dbus interface on the host) requires the host
side of that IPC to remain available and backwards compatible in
future versions of the distro, so we should err on exposing a minimal
set of IPC.
There is also some changes that may be required in the distro to keep
unnecessary dependencies out of the runtime. For instance anything
related to hardware or system initialization is completely
unnecessary. Luckily much of this is being fixed by similar needs from
docker already.
One thing that is different from docker however, is that we generally
want translations/locales in the runtime. But these are pretty large,
so we want to handle them in a smart way. xdg-app has a feature that
allows splitting a runtime into a base and a set of optional
extensions that are mounted in the sandbox only when they are
installed. I use this in the gnome runtime to split out each
locale. Unfortunately Fedora uses a single large locale-archive file
for its locales, so its hard to do that. This needs some research to
figure out how to do properly.
There are also some custom configuration that a runtime needs. For
instance, the build script for the fedora runtime above drops in a new
fontconfig file that adds a /app/share/fonts fontdir for app-bundled
fonts and configuration to include the host fonts (which xdg-app
exposes in /run/host/fonts). This would be nicer if this was just a
fontconfig subpackage we could pull in, and I'm sure there are more
similar configuration options that would be needed.
Creating applications from fedora packages is a bit more
complicated. The primary reason is that they need to be relocated to
/app. In the hacky script above I just extract the rpm contents to
/app and then rewrite some rpaths and shell scripts. A less hacky
approach is to rebuild the rpms with a different rpm %_prefix macro,
or to use relocatable rpms. It is not really significantly different
from creating rpms to use in software collections though, so we have
some experience with this.
Packaging an application also requires some changes other than the
relocatability itself. First of all, all "exported" files from an
application (such as icons, desktop files, dbus service files, or
other files that are read from outside the app itself) must have the
application id (which is a dbus/java-style reverse dns name) as a
filename prefix. This is both for avoiding conflicts, and for security
reasons, see [4]. However, it wouldn't necessarily be a problem if we
just did such changes on the regular fedora packages too, as a regular
fedora packaging policy.
One issue is that as third party packagers of applications we should
not use the "official" app ids for our builds, as they would conflict
with upstream doing their own release. So, our package of
org.gnome.gedit should probably be called org.fedoraproject.gedit,
which may require some minor tweaks to the build (for instance, this
affects the dbus name the app uses for dbus activated desktop files,
as well as the name of the desktop file itself).
There are clearly a lot of details here, but I'll stop here and throw
this out as the start of a discussion. I'll gladly reply to any
questions people may have.
[1] More information:
My devconf talk: https://www.youtube.com/watch?v=t-2a_XYJPEY
gnome wiki: https://wiki.gnome.org/Projects/SandboxedApps
xdg-app code: https://github.com/alexlarsson/xdg-app
[2] Announcement of gnome runtime:
https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-build...
[3] https://wiki.gnome.org/Projects/SandboxedApps/DocumentPortal
https://wiki.gnome.org/Projects/SandboxedApps/Sandbox
[4]
https://mail.gnome.org/archives/gnome-os-list/2015-February/msg00009.html
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alexander.larsson(a)gmail.com
He's a war-weary Republican vampire hunter on a search for his missing
sister. She's a ditzy winged queen of the dead with the power to see
death. They fight crime!
7 years, 10 months
New Member of List
by William Best
Hello,
My name is William Best. I am not sure if this is the right group to join
for how I would like to contribute.
My passion/career involves helping people with developmental disabilities
get better access to technology. Over the past year or so, I have been
experimenting with different Linux distributions to come up with a
low-cost, stable, and robust solution for the disabled people I work with.
I really like Fedora the best out of the bunch for a variety of reasons.
My goal is to help get features/apps that would help disabled people access
technology in a better way.
Let me know if I am in the right group for this.
Thanks!
~William Best
7 years, 10 months
wired networking should work by default, even if not connected at install time
by Chris Murphy
https://bugzilla.redhat.com/show_bug.cgi?id=963952
The gist of this bug is, if the user installs Fedora and doesn't have
(wired) ethernet connected at the time of installation, onboot=no and
therefore on any subsequent boot, the network does not come up. A
separate GNOME bug is that even if the user manually turns on that
wired connection, it isn't a sticky setting. So networking is off
again the next reboot. The trick is to find the totally obscure and
buried option for the wired device to connect automatically.
This bug doesn't piss me off the way it did back in 2013 when I filed
it, because I know the work around. But this is still a Top 10 Most
Asinine Bug. Amusingly, wireless connections don't have this behavior,
even though they're in the realm of 8000% more risky even when making
a manual+conscious connection. Whereas when I take a physical plug and
stick it into the jack, it's a considerable WTF moment when that
connection doesn't work until I intervene further, and doesn't work
yet again on a reboot until I intervene yet again.
I can kinda sorta almost understand server folks differing on this
(even though I find it specious for various reasons) but Workstation
really shouldn't behave this way. It is not an easy work around, at
all, when the user doesn't don't know about it. And in no sane world
should they need to know about it. And even when they do know about
it, it's always a *sigh* "oh yes, that" moment. So from every
perspective I see it as a negative and no benefit.
Thanks,
--
Chris Murphy
7 years, 10 months
Re: VSYNC problems on Fedora 21/22 and Intel HD graphics...
by Alex G.S.
>
> Let's actually look at what debug information is available then rather
> than just flailing in the dark here. The journal since booting should
> help see where the lookups are coming from, at least let me know how the
> system is configured.
What's the best way to capture a log and where should I upload it to?
On Wed, May 27, 2015 at 4:43 PM, Chris Wilson <chris(a)chris-wilson.co.uk>
wrote:
> On Wed, May 27, 2015 at 04:28:33PM -0400, Alex G.S. wrote:
> > > Try Option "DRI" "2" in conjunction to the above.
> > It worked momentarily but GNOME Shell locked up and crashed when I
> had an
> > application (Remmina) fullscreen in of the monitors. This happens
> very
> > frequently in my experience. GNOME just seems unstable on Intel HD
> 4600.
> > I even tried adding the following to my boot parameters but it didn't
> > change anything:
> > i915.semaphores=1
>
> Let's actually look at what debug information is available then rather
> than just flailing in the dark here. The journal since booting should
> help see where the lookups are coming from, at least let me know how the
> system is configured.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
7 years, 10 months
VSYNC problems on Fedora 21/22 and Intel HD graphics...
by Alex G.S.
Hello,
First of all I love the new GNOME 3.16 release. The notifications and
system tray icons (in the left) are great and productivity boosters.
However, I'm having some issues with Intel HD graphics on X11 that make
things very difficult. Though these problems are solved by the Wayland
session it's still too unstable for me to use in production as a day-to-day
desktop.
Hardware:
Intel® Core™ i5-4200M CPU @ 2.50GHz × 4
Intel® Haswell Mobile (HD 4600, i965)
GNOME:
Version 3.16.2
Kernel:
4.0.4-301.fc22.x86_64
Problem:
https://bugzilla.gnome.org/show_bug.cgi?id=741376
At work I use two external monitors in addition to the laptop screen.
VSYNC often breaks when using either SNA or UXA at random intervals. It
also breaks also when I fullscreen any application in any monitor. Even
when I force VSYNC in both xorg.conf and drirc it doesn't seem to help.
These are configurations for reference:
/etc/environment:
CLUTTER_VBLANK=True
/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
Option "TearFree" "true"
Option "SwapbuffersWait" "true"
EndSection
/etc/drirc
<device screen="0" driver="i965">
<application name="Default">
<option name="force_s3tc_enable" value="true" />
<option name="no_rast" value="false" />
<option name="always_flush_batch" value="false" />
<option name="always_flush_cache" value="false" />
<option name="shader_precompile" value="true" />
<option name="hiz" value="true" />
<option name="clamp_max_samples" value="-1" />
<option name="bo_reuse" value="1" />
<option name="allow_glsl_extension_directive_midshader"
value="false" />
<option name="force_glsl_extensions_warn" value="false" />
<option name="disable_throttling" value="false" />
<option name="disable_glsl_line_continuations" value="false" />
<option name="disable_blend_func_extended" value="false" />
<option name="vblank_mode" value="3" />
</application>
I even have a GNOME extension I created that autoloads the following GNOME
JS function:
Meta.disable_unredirect_for_screen(global.screen)
This still doesn't help at all. There is a bug report for this item and
has been confirmed but I haven't heard anything and status is still NEW and
not yet confirmed. Please, any help on this would be appreciated. Things
like this should just work out of the box especially on Intel HD graphics.
This is a bewildering problem as this is my work machine and I may end up
switching to a Mac or Ubuntu Unity if this cannot be fixed.
Thank you!
Best,
Alex
7 years, 10 months
Workstation WG Recap 2015-May-27
by Paul W. Frields
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2015-05-27/workstation.20...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2015-05-27/workstation.20...
Log: http://meetbot.fedoraproject.org/fedora-meeting/2015-05-27/workstation.20...
* * *
==================================================
#fedora-meeting: Workstation WG (special timeslot)
==================================================
Meeting started by stickster at 15:00:01 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2015-05-27/workstation.20...
.
Meeting summary
---------------
* Roll call (stickster, 15:00:08)
* Special time slot (stickster, 15:03:18)
* This slot will not be repeated; next meeting is Monday 2015-Jun-08
at 1300 UTC (stickster, 15:03:38)
* F23/24 plans (stickster, 15:04:02)
* LINK: https://fedorahosted.org/council/ticket/27 (stickster,
15:04:43)
* IDEA: Can we work toward a better upgrade story in F23/24
(stickster, 15:26:58)
* ACTION: mcatanzaro to propose update to PRD to clarify that
developer focus does not compromise the goal to be a "polished and
user friendly system that can appeal to a wide general audience"
(mcatanzaro, 15:31:10)
* LINK:
https://lists.fedoraproject.org/pipermail/desktop/2015-May/012065.html
(mcatanzaro, 15:33:13)
* LINK: https://fedoraproject.org/wiki/Workstation/Tasklist
(stickster, 15:55:27)
* LINK: https://fedoraproject.org/wiki/Workstation/Tasklist
(stickster, 15:55:47)
* many people who could work on F23 improvements are bound up on
immediate RHEL work (stickster, 15:56:34)
* ACTION: mclasen will also review foregoing task list to see what's
already up that could be completed for F23 (stickster, 15:56:42)
* LINK:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/...
(mclasen, 15:58:45)
* ACTION: stickster pull together tasks from mclasen + update +
anaconda requests into Council report for F23/24 (stickster,
15:59:29)
* ACTION: stickster Set up whenisgood for WG + anaconda folks to
discuss requests (stickster, 16:09:46)
* stickster will carry over agenda items from mcatanzaro list so we
can pick up at next meeting (stickster, 16:11:59)
* Next meeting: 2015-Jun-08 UTC 1300 (stickster, 16:12:11)
Meeting ended at 16:12:17 UTC.
Action Items
------------
* mcatanzaro to propose update to PRD to clarify that developer focus
does not compromise the goal to be a "polished and user friendly
system that can appeal to a wide general audience"
* mclasen will also review foregoing task list to see what's already up
that could be completed for F23
* stickster pull together tasks from mclasen + update + anaconda
requests into Council report for F23/24
* stickster Set up whenisgood for WG + anaconda folks to discuss
requests
Action Items, by person
-----------------------
* mcatanzaro
* mcatanzaro to propose update to PRD to clarify that developer focus
does not compromise the goal to be a "polished and user friendly
system that can appeal to a wide general audience"
* mclasen
* mclasen will also review foregoing task list to see what's already
up that could be completed for F23
* stickster pull together tasks from mclasen + update + anaconda
requests into Council report for F23/24
* stickster
* stickster pull together tasks from mclasen + update + anaconda
requests into Council report for F23/24
* stickster Set up whenisgood for WG + anaconda folks to discuss
requests
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (99)
* mclasen (33)
* mcatanzaro (31)
* cschalle (15)
* otaylor (14)
* dcantrell (13)
* kalev (9)
* zodbot (8)
* jwb (8)
* nirik (2)
* rdieter (1)
* pingou (1)
* Kellin (1)
* 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
7 years, 10 months
