desktop April 2014

desktop@lists.fedoraproject.org

42 participants
26 discussions

Re: Considering GNOME 3.12 as an F20 update - brightness problems
by Jorick Astrego 22 Apr '14

22 Apr '14

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.

3 2

Re: fedora.next workstation "stable"
by Jorick Astrego 18 Apr '14

18 Apr '14

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.

3 2

Considering GNOME 3.12 as an F20 update
by Matthias Clasen 17 Apr '14

17 Apr '14

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

14 26

fedora.next workstation "stable"
by Jorick Astrego 17 Apr '14

17 Apr '14

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

3 3

Re: External websites and Fedora's Foundations
by Rex Dieter 11 Apr '14

11 Apr '14

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

2 2

External websites and Fedora's Foundations
by Matthew Miller 11 Apr '14

11 Apr '14

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!"

1 0

F21 changes for the workstation: firewall
by Matthias Clasen 09 Apr '14

09 Apr '14

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

6 7

arm support of workstation product
by Dennis Gilmore 07 Apr '14

07 Apr '14

-----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-----

8 18

Re: Considering GNOME 3.12 as an F20 update
by Ankur Sinha 05 Apr '14

05 Apr '14

On Fri, 2014-04-04 at 17:55 +0200, Michal Schmidt wrote: > I had the same problem. It turned out I was missing the glib2 package > update from the COPR. The reason was that I had both glib2.x86_64 and > glib2.i686 installed, but I only enabled the x86_64 COPR. dnf silently > skipped updating the package due to this problem. We noticed this. Richard updated the install instructions to include both repos: http://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ If using dnf, please use the --best flag. Otherwise, dnf simply skips broken packages without reporting any errors. Adam added a note to the updates-testing guide: https://fedoraproject.org/wiki/QA:Updates_Testing -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

1 0

F21 change for the Workstation: software collections
by Matthias Clasen 04 Apr '14

04 Apr '14

I expect this one to be more fun: https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collecti… Christian, I'm not actually 100% sure about some of the details in here, would be good to proof-read this (together with Radek?) before I push this to the change wrangler.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop April 2014