Re: Considering GNOME 3.12 as an F20 update - brightness problems
by Jorick Astrego
On Thu, 2014-04-17 at 12:00 +0000,
desktop-request(a)lists.fedoraproject.org wrote:
> I've hit another annoying problem. I cannot change brightness level.
> The
> Fn keys don't work at all, when changing it in the user menu or power
> management settings it changes the backlight randomly in one of ten
> attempts. Moreover indicator in the user menu always shows zero level
> of
> backlight.
> I always blamed drivers or something lower in the graphics stack for
> this. But it works perfectly in KDE and I can also change backlight
> with
> xbacklight or xrandr.
> I'm using up-to-date Fedora 20+GNOME 3.12 Copr on Lenovo X240.
> Anyone has hit the same problem?
> BTW the more I'm using GNOME 3.12 the more I think it's not ready for
> the prime time. I'd rather wait for fixing releases.
>
> Jiri
I fixed this on mij Lenovo bij adding << Option "RegistryDwords"
"EnableBrightnessControl=1" >> to /etc/X11/xorg.conf in the "Device"
section:
Section "Device"
Identifier "Videocard0"
Driver "nvidia"
Option "RegistryDwords" "EnableBrightnessControl=1"
EndSection
Kind regards,
Jorick Astrego
Netbulae B.V.
10 years
Re: fedora.next workstation "stable"
by Jorick Astrego
On Thu, 2014-04-17 at 12:00 +0000,
desktop-request(a)lists.fedoraproject.org wrote:
> Right. I could have worded my post more clearly, I suppose, but it was
> intended for the audience that was reading at the time, and there's an
> implicit assumption behind it: this is really not a Fedora-level
> issue,
> it's an upstream ecosystem one. Both the choices Fedora had were bad
> ones: stick with a rapidly decaying and ancient Bluetooth stack, or
> update it and lose some useful features. Those were literally Fedora's
> only choices. Either would have made someone unhappy.
>
> I'm hopeful we can get the necessary buy-in from various folks to have
> slightly higher basic functionality requirements for Fedora
> Workstation
> than we did for the desktop under the ancien regime, but "working high
> bitrate Bluetooth audio" is probably beyond the level of 'things we're
> likely to block the release on' still. I recognize that it's somewhat
> annoying if you've just bet the farm on it, but we have practical
> considerations to bear in mind too - we don't have infinite
> development
> resources we can throw around to fix upstream problems.
As I said, I'm not really here to bash anyone and I understand your
position. We do appreciate all the work people put into Fedora.
But I really want to help fix things, is there anything except writing
code I can do to help fix things? (writing code is sadly not one of my
talents :-) We're willing to put some decent testing time and QA into
it.
Is there already upstream code in Rawhide?
Jorick Astrego
Netbulae B.V.
10 years
Considering GNOME 3.12 as an F20 update
by Matthias Clasen
Hey,
so the time has come to consider this - thanks to the great work of
Richard and Kalev on the copr, we have a set of 3.12 packages that have
already received fairly wide testing.
But we should be careful, so I want to ask for concrete problem reports
with the copr packages, besides dependency problems caused by the
parallel nature of the copr itself.
Did any of your gnome-shell extensions break ?
Did you experience crashes or other serious problems with applications ?
If so, please let us know on the desktop list. If I don't hear of major
problems by next week, I'll file a Fesco ticket to ask for an exception.
Matthias
10 years
fedora.next workstation "stable"
by Jorick Astrego
Hi,
After listening to the Fedora.Next discussion @ FOSDEM2014 I have been
looking forward to a more stable Fedora workstation that we can actually
use reliably.
I've read up about it and it would be nice to have working development
tools but one of the things I haven't heard people talking about is how
Fedora.next will enable people to actually use it for work.
Currently I have been bit by removal of the bluetooth HSP/HFP Profile
(https://bugzilla.redhat.com/show_bug.cgi?id=1045548). I just purchased
all new plantronics headsets for our developers that used to work
perfectly in Fedora 18 and now I can just throw them away.
Answers like these make me wonder if running Fedora will be sustainable,
we have to work on these systems and if I have to dual boot Windows to
make a skype call; it would be better to run ubuntu.
From: Adam Williamson <awilliam <at> redhat.com>
Subject: Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
Newsgroups: gmane.linux.redhat.fedora.devel
Date: 2014-01-23 23:16:09 GMT (10 weeks, 3 days, 10 hours and 37
minutes ago)
On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote:
> > As a side note, it also needs to be discussed how such a key feature of
> > the bluetooth stack could go unnoticed through QA, and how to avoid this
> > from happening again.
>
> Indeed. I wondered the same myself.
I'm somewhat cheered that our product has apparently reached the quality
level where people consider a Bluetooth audio profile to be a 'key
feature', but so far as our QA standards are concerned, it ain't.
This didn't really 'pass unnoticed' through QA. I noticed it, and was
supremely unconcerned. Yes, if you depend on this specific feature it
sucks, but it's hardly unusual for some specific feature of something or
other to break between Fedora releases. It's a thing that happens, and
as I'm on record as arguing in more extensive and generic terms, the
nature of Fedora as a project would need to change quite a lot before we
decided we were a project where stuff like this didn't sometimes break.
--
Adam Williamson
Fedora QA Community Monkey
I don't want to be bashing anyone and we would like to help out with Fedora workstation testing things through. But is there any point in investing a lot of time when the QA people don't care about an OS that you can actually use.
Kind regards,
Jorick Astrego
10 years
Re: External websites and Fedora's Foundations
by Rex Dieter
On 04/11/2014 09:01 AM, Eric H. Christensen wrote:
> On Fri, Apr 11, 2014 at 09:42:02AM -0400, Matthew Miller wrote:
>> ... Therefore, I'd like to appeal
>> to our Friends foundation. I hope we can find a middle ground instead of
>> staking out extreme positions.
>
> Coming to the middle, I'd like to suggest what I suggested in yesterday's meeting (which was completely ignored).
>
> Gnome could use a menu in the 'All Settings' menu that would allow users to add their own links as well as add some predefined links (such as Google apps and Facebook). These would be disabled by default but the user could easily activate them and include them on their system.
It wasn't ignored. In fact, that was close to what I had suggested too,
and I was (and am) in favor of it. However, it seemed us 2 were the
only ones in favor it, and at least 2 explicitly mentioning being
against that (iirc)
In the spirit of Matthew's post, something that I appealed for in the
meeting was that each board member try to outline as best the could what
positions they could support as well as those they could not. Given
something like that, one can try to formulate something that has a
chance of getting some semblance of consensus support/approval. Worst
case, it would help identify that there is not any potential to reach a
consensus.
-- Rex
10 years
External websites and Fedora's Foundations
by Matthew Miller
I think that we all agree that if we prominently feature links to websites
(in this case, to web-based applications) in Fedora, it should be done with
the purpose of advancing Fedora's mission. Everyone has that goal, and just
a different vision of what gets us there. (In case you haven't been
following along, the discussion is about the new feature showing web links
in Gnome Shell searches and in Software. This gets special attention because
Fedora and Gnome do have close brand associations, and Gnome has been
selected as the primary environment for Fedora Workstation.)
I see two different positions on how to decide on what to include in order
to have desired effect. Some are advocating including only links to services
that run on free and open source software (or, in a softer form, sites which
promote and advocate such software and content); the link with the mission
is obvious: we're directly promoting the things we stand for. Others
advocate including links based on quality, popularity, and usefulness; by
making a better experience for users of these services, Fedora becomes more
popular and free and open software spread more widely overall.
Fedora has always had a strong free and open software stance. It's one of
our core values, but we aren't absolutists; we include, for example,
non-free binary firmware. Here, the discussion isn't about including
anything non-free directly, and the Fedora Project Board today decided that
that the distinction between software included in Fedora and software from
external sources must be kept clear in the user interface. That means, users
will easily be able to tell that they're using something on the web _from_
Fedora, not something we've added _to_ Fedora. And the basic fact is that we
already have plenty of examples of software which makes use of non-free
third-party web services in the distribution, from Firefox's use of Google
search to various Twitter clients to bindings to various web service APIs.
So, from one point of view, there's nothing new here. However, I think it is
also fair to say that the new Gnome features bring a special prominence to
the selected links — that's the point, after all.
I think it would be helpful if the Board would provide specific
clarification on this issue and how it relates to our Freedom foundation,
but I also want to recognize that everyone involved is passionate about
getting there, and that we're having a conversation about the best means,
not differing end goals.
Although the Board meeting yesterday didn't reach a conclusion, it doesn't
seem likely that there will be a strong statement banning links to services
like those in the current appstream metadata. Therefore, I'd like to appeal
to our Friends foundation. I hope we can find a middle ground instead of
staking out extreme positions. Recognizing that we all want Freedom to win,
I'd like to find a group of people willing to work on a set of criteria
involving both the quality and popularity metrics _and_ metrics involving
commitment to and use of free and open software and content. These people
would work as contributors to the "appstream-extras" data used in Fedora,
upstream if possible. The decisions will ultimately be somewhat subjective,
but informed by the basic criteria set forth in line with our mission and
values, promoting both Freedom and Features in Fedora.
I think we can do this together. Who is interested in making it happen?
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
10 years
F21 changes for the workstation: firewall
by Matthias Clasen
In order to get us going on actual development for the first iteration
of the Workstation in F21, I've filed a first change request:
https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall
I think this reflects the discussion around firewalls we had back in
February.
Feedback welcome.
While writing this up, I've reviewed the default-enabled services on the
current desktop spin. In general, things look pretty good to me. A few
things I wondered about:
- Why does cups end up running when I boot in a vm that certainly has no
printer connected ?
- Do we want fedora-readonly included ? This is coming from the
readonly-root feature, but it is off by default, and don't think it is a
tested configuration, so who knows if it works. And we're probably not
going to turn it on for the Workstation
- What is fedora-configure, and why is it installed ? It seems to be a
complicated way of triggering 'system reconfiguration' which in this
case means running a shell script as a systemd service, which in turn
runs /usr/bin/firstboot. Since /usr/bin/firstboot has been replaced by
anacondas initial-setup, I can only conclude that this functionality is
also unused, untested and not working, and should probably be removed.
Matthias
10 years
arm support of workstation product
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
I noticed that in the hardware supported in the tech specs says 64 bit
only. I believe that in the f21 time frame we should be able to
integrate etnaviv [1][2] and be able to offer a viable arm based
option. note that arm ships in two formats, disk image that's ready to
run and install tree. there is no support to run anaconda and do a
liveinstall type install. For some possible systems putting the image
onto a sdcard and running will be fine. But for some others there may
be a desire to install onto a hard drive to use.
I personally believe that it is a viable target.
Dennis
[1] https://github.com/laanwj/etna_viv
[2] https://plus.google.com/+ArndBergmann/posts/bjja7uW9vA4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJTGgdfAAoJEH7ltONmPFDR5kcQAKqL85+d0TAKA7umDpmmi6pH
6wx60mgWjH5TM4v2fbbqKBA8kL8RF8040liQHCrCYD0zwFE9NIquPL6pxgyDouGX
Xaq6F+mQ0UQHitVC2cvrTAFAeygoW41JGL6WvYMApTg86HnCW+mNE/EdzhOKCCUU
A59UBwLONc5HJ2ei7oAmyxjxqbPiWzzmh9kGUKmU+HQ1yXNi7p/cVl7GXUuMvbiW
PPvJw53osnvu1gz9AArRC9ZWJEtaByDCM5hm5EKZQUOCwN27SQ9d114mClRrZRJi
NDUtPzGuuk2c0MdVpE/W4fUd5NLjsuAaDxrRHRTrdwKcKi+sDrXnOiui2wBDdVzV
qx+YbJRsWB1DBOuTMCheX2ZYipoqx8a4VWXP6nf7lyiowwzlEIyQDZ15s1CvDK9Q
j25doND/XImXPFcu7FVy8GBfw/yUr3FBPxlarXRruEH0/za7f5I4pw8NKUtMLtAl
p1Wc4u54P1UjbZpXsNAQzZTS7Us0rl3Q8I06mQW+NqBadWNqWIXarzsftBx5xsdS
xRRiC0aP6Na0m0W6jXNH07/gT6iQdPeY+D5T0bpyOzgxbdifigCDcQZpe18LyDtL
95bW7Q9S5f+3P9m31VBGEwLcvHPzYgDpZ8RRF2yK1PMXDXitFItOSg3fp330BtGk
Ne1ETUEAS4zCoW6Fd+cM
=5Sr6
-----END PGP SIGNATURE-----
10 years
