desktop December 2013

desktop@lists.fedoraproject.org

32 participants
15 discussions

Fedora.next Product Branding
by Ryan Lerch 23 May '14

23 May '14

*This is sent with my Fedora Design Team hat on* With the creation of 3 products for Fedora, the Fedora Design Team anticipates manynewquestions aroundFedora'sbrand. As the main caretakers of the Fedora brand, weare going to have to figure these things out within the next few months. For example, the Design Team is starting to think about how to answer these types of questions: • Should each product have its own logo? or • Can you add our product to the Fedora website? or • Can you make our product its own website? (How should we represent these products on the website? Should we allow products to have their own separate websites?) To start off the rebranding discussion, the Fedora Design Teamhas4 basic questions for each of the 3 product-focused working groups to answer: (1) What problem does your product solve, in one sentence? (2) Who is the target audience for your product, in one sentence? (3) List at least 5 products that successfully target the same target audience you are after. (4) List at least 5 products that try to solve the same problem. We are reaching out to each group individually to ask that you discuss these questions and come back to us with answers by Wednesday, December 4th2013. cheers, ryanlerch

5 8

Workstation PRD approval
by Josh Boyer 16 Jan '14

16 Jan '14

Hi All, We have just shy of 6 calendar weeks until the PRD for Workstation is due (Jan 13). However, with the holidays likely eating up a good chunk of that it's realistically closer to a month. We've had 5 revisions of the PRD Christian has drafted so far, with some good feedback along the way. I don't think we're going to be able to specifically list everyone's personal favorite use case in the PRD itself, but the use cases we have should cover a broad set of people already. I suggested moving the multiple-monitor and many terminal windows items under e.g. the Corporate developer user case and that should at least meet much of the technical requirements for Sysadmins too (at least to start). Ideally, I'd like to get a final PRD draft sent and approved by the WG before the holiday break. That would give FESCo plenty of time for review, and would allow us to get started in January on the next item, which is a list of changes the WG would need from existing Fedora to accomplish the PRD goals. I suspect that is going to take a significant amount of work to settle, and the more time we have the better. If there are critical changes you think are needed for the PRD, please speak up now and list them. That is particularly true for any of the WG members. We can evaluate them as they come in. Thanks. josh

10 39

Updated Fedora Workstation PRD draft
by Christian Schaller 15 Jan '14

15 Jan '14

Hi everyone, First of all apologize for this taking so long, I ended up traveling non-stop for some time visiting some of Red Hats desktop customers. While not directly tied to the work of this working group I do hope to take some of the lessons learned from those meetings with me into the future work of the working group. Anyway I tried editing the PRD a bit based on the feedback we got on the first draft. I tried to make a few items a bit clearer and also to include spelling fixes contributed and so on. We probably want to do another WG meeting soon to discuss next steps. Feel free to let me know if I forgot to include some important feedback or if further clarifications are needed. Christian

29 126

Unannounced soname bump: tracker
by Adam Williamson 07 Jan '14

07 Jan '14

Sigh. Yes, another of these. On 2013-12-18, tracker was bumped to 0.7.0: http://koji.fedoraproject.org/koji/buildinfo?buildID=485698 the sonames of libtracker-extract, libtracker-miner and libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without announcement, and without all dependent packages being successfully rebuilt. At least the following still depend on the old sparql library: bijiben-0:3.11.1-1.fc21.x86_64 brasero-0:3.11.3-1.fc21.x86_64 grilo-plugins-0:0.2.9-2.fc21.x86_64 media-explorer-0:0.4.4-5.fc21.x86_64 rygel-tracker-0:0.21.1-1.fc21.x86_64 I'll see if I can get any of them rebuilt. What does it take for people to handle soname bumps properly? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 6

FESCo decision on 3rd party repositories
by Josh Boyer 02 Jan '14

02 Jan '14

Hi All, At the FESCo meeting today, the following things were decided on 3rd party repositories. Some of this is specific to COPRs because those are an odd case of 3rd party repositories. 1) COPRs can provide RPMS with .repo files in them because Red Hat is the provider and assumes liability, but those cannot be included in the main Fedora repos per FESCo decree. 2) COPR repos may be searched for applications to install as long as the user is explicitly asked to enable the copr before installing packages from them. 3) General 3rd party repositories cannot be searched or enabled due to liability concerns. (NOTE: "searched" in 2 and 3 was intended to cover searching by software. Clearly users can manually search for anything.) 4) FESCo is okay with pointing to specific free software repositories in the same way as COPR repos if they are approved by FESCo and Fedora Legal. They are not limited in the criteria that they can choose to apply. 5) For non-free sofware repositories, FESCo is not changing exisiting policy. Non-free software repositories are not allowed. Permission to make these discoverable via searching software would require a change in policy from the Fedora Board. In short, this means products can request approval of specific 3rd party free software repositories. If approved, they can include their contents along with COPR repos in application searches a user does and offer to install them with a warning that they come from a 3rd party, non-Fedora repo. Repositories containing non-free software cannot be enabled by default or made discoverable through software. josh

7 13

why some intel 5100 agn can not work on fedora20, Suggest the driver can be added in the next kernel.
by sword rong 29 Dec '13

29 Dec '13

-- swordrong(a)gmail.com swordrong(a)163.com

2 1

F20 offline updates: way too frequent
by Michael Catanzaro 29 Dec '13

29 Dec '13

Since upgrading to Fedora 20, I've been prompted to restart and install updates nearly every day. This seems non-ideal. (Or pick your favorite loaded term: absurd, crazy, insane, ....) It'd be nice to have a gnome-settings-daemon update that significantly increases the default time between updates. (I'm thinking weekly.) I know checking for updates is handled differently in Fedora 21: this email is only about Fedora 20. Michael

7 13

Unannounced ABI change without soname bump in libevdev-0.6 in Rawhide (and F19 and F20...) breaks GNOME, probably other consumers
by Adam Williamson 27 Dec '13

27 Dec '13

Time for another PSA... It appears libevdev 0.6 breaks the library's ABI without bumping the soname (and without an announcement here or anywhere else I can find, but an ABI change without an soname bump is just flat out wrong whether announced or not). 0.6 was sent to Rawhide, F19 and F20 simultaneously. The ABI change breaks GNOME in F20 and Rawhide (because clutter was using the calls that disappeared in the 0.6 build): undefined symbol: LIBEVDEV_READ_NORMAL (/lib/libclutter-1.0.so.0) undefined symbol: LIBEVDEV_READ_SYNC (/lib/libclutter-1.0.so.0) Dec 26 02:02:34 pressanykey gnome-session[1320]: gnome-shell: symbol lookup error: /lib64/libclutter-1.0.so.0: undefined symbol: LIBEVDEV_READ_NORMAL Reported as https://bugzilla.redhat.com/show_bug.cgi?id=1046426 . Rebuilding clutter is not trivial at present, and in fact builds of clutter appear to fail on this same libevdev issue. So right now, GNOME in Rawhide is broken if you install libevdev 0.6, and this monkey doesn't feel comfortable trying to fix it (I don't want to start randomly whacking things in clutter's code to try and make it build against the new libevdev). I recommend not installing this build, and downgrading to 0.5 if you currently have 0.6 installed. If anyone from the desktop team is able to get together with Peter and resolve this SNAFU for Rawhide ASAP, that'd be great, though I realize we're all supposed to be on vacation. Happily, the update for F20 has already been negative-karma'ed out of existence, and the F19 update is well on its way there. Take note, those who say the update karma system is useless: without it, we would likely have broken the world's F20 systems shortly after release...(F19's clutter doesn't seem to use libevdev so GNOME on F19 doesn't break, apparently, but the libevdev update still shouldn't go out). http://koji.fedoraproject.org/koji/buildinfo?buildID=486593 (Rawhide) https://admin.fedoraproject.org/updates/FEDORA-2013-23934/libevdev-0.6-1.fc… (F20) https://admin.fedoraproject.org/updates/FEDORA-2013-23961/libevdev-0.6-1.fc… (F19) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 2

Live image / DVD package set merge
by Adam Williamson 17 Dec '13

17 Dec '13

Hi, folks. So as a quick test of the DVD / live package set stuff, I just built an F21 live image from fedora-live-desktop.ks - rather than fedora-livecd-desktop.ks . Even with absolutely no tweaks or optimization, it comes out at the huge size of...1.2GB. So I think it's entirely feasible to bump the size target to 2GB, drop fedora-livecd-desktop.ks entirely, and just build from fedora-live-desktop.ks, giving the live image the same package set as DVD. We wouldn't wind up with a crazy huge image or anything, and we'd have lots of space inside the size target and not have to worry about that problem. There are certainly optimizations possible; if we did this, we could focus more on optimizing things in comps. One obvious one is the dep chain that pulls in perl. fedora-livecd-desktop.ks drops 'linux-atm' from the live image to prevent perl getting pulled in and save space. In comps, linux-atm comes in via the 'dial-up' group. So an obvious tweak there is to move 'dial-up' from being a default group for GNOME to being an optional group - this makes sense anyway, I think. People who still use dial-up or plug directly into a PPPoATM modem or something can select the group easily enough, everyone else doesn't get useless stuff. If any of the other package drops on the live image make sense to preserve for a larger live image and DVD install, we can look at how to implement them in comps (ideally). If people are interested in this I can come up with a concrete proposal pretty fast, I think. Even with the whole three-product thing rolling along, I think it makes sense to do this, since it wouldn't be particularly difficult and would simplify things a lot; I think it's possible that the 3 product stuff gets pushed out to F22, and if that happens, it'd be nice not to have fuss about the size limit and differences between DVD and live installs for F21 testing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

5 11

Small proposal (for a better acceptance of the PRD).
by Diogo Campos 16 Dec '13

16 Dec '13

Hi, I'm just a random user who cares (and uses) Fedora and GNOME. I have been following this mailing list out of curiosity and noticed that great people with the same (or similar) views are walking in circles about the section "Target Audience" of the PRD. Therefore, I would propose only an organizational (and aesthetics) change that, I hope, could finally make everyone happy (or, at least, comfortable). The change would be, more or less, as follows: [...] TARGET AUDIENCE 1 - General User. (put a professional description here - it is basically the person who wants a system that just works well in their device, and allows him to do all kinds of things: job, hobby, entertainment, etc). 1.1 - Developer. (this substitutes the current "General" paragraph - just copy almost the same description from PRD) 1.1.1 - Student Developer. (copy the description from PRD) 1.1.2 - Independent developer. (copy the description from PRD) 1.1.3 - Small Company Developer. (copy the description from PRD) 1.1.4 - Large Organization Developer. (copy the description from PRD) [Remove the "Other Users" section from PRD - cause it should now fit in the "General User" section] [...] I am also sending an attached (amateur) illustration in order to make the understanding of this change more visual - give a look. I think this illustration (after improved, of course) can perhaps be included in the PRD for the same purpose. if I misunderstood some part, please correct me, and adapt the proposal. If all this is just bullshit, please just ignore me. Hope it helps.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop December 2013