Hi,
I just read Matthais' post on the planet and couldn't wait to try out
the new *shiny* gnome packages from the 3.14 copr. Unfortunately, there
seem to be some breakages:
dnf --refresh --best update gives me:
Error: nothing provides gnome-shell >= 3.13.2 needed by
gnome-shell-extension-common-3.13.2-2.fc20.noarch. nothing provides
gnome-shell >= 3.13.2 needed by
gnome-shell-extension-common-3.13.2-2.fc20.noarch. package
NetworkManager-l2tp-0.9.8.6-1.fc20.x86_64 requires ppp = 2.4.5, but none
of the providers can be installed. package
evolution-data-server-3.12.3-1.fc20.x86_64 requires
libgdata.so.13()(64bit), but none of the providers can be installed.
package gnome-shell-3.12.2-1.fc20.x86_64 requires
libmutter-wayland.so.0()(64bit), but none of the providers can be
installed. package gnome-shell-3.12.2-1.fc20.x86_64 requires
libmutter-wayland.so.0()(64bit), but none of the providers can be
installed. package NetworkManager-l2tp-0.9.8.6-1.fc20.x86_64 requires
ppp = 2.4.5, but none of the providers can be installed
Omitting the --best flag doesn't work either. It wants to reinstall
evolution-data-server and errors out saying:
Error: Transaction check error:
package evolution-data-server-3.12.3-1.fc20.x86_64 is already
installed
I was on the 3.12 copr already.
Thanks for putting up the new copr!
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG

This is largely directed to the WG, as a request to clarify a part of the workstation product tech spec. It relates to a thread on the anaconda list regarding os-prober, and a thread on this list regarding release criteria, both of which are referenced below.
I am cross posting to the server@ list as well, while they don't have a dual-boot requirement in their spec it stands to reason the ability to dual-boot Fedora Server/CentOS/RHEL version n and n+1 could come in handy when doing migrations while still having a fall back position. Perhaps replies should drop the other cross posting since the requirements for the two products are different? But I leave up to the person replying to decide.
The WorkstationTechnical Spec says:
"One aspect of storage configuration that will be needed is support for dual-boot setups (preserving preexisting Windows or OS X installations), since e.g. students may be required to run software on those platforms for their coursework."
1a. Does preserve preexisting include providing a working menu entry in the boot manager (e.g. in the GRUB menu)?
1b. Or is it sufficient to just preserve the installation data — meaning it's permissible for its bootability to be either non-obvious or broken?
2. If the answer to 1a. is yes, and 1b. is no, does this dual-boot requirement apply to both BIOS and UEFI?
3. If resources cannot meet the dual-boot requirement by ship time, should the installer inform the user that their previous installation will be preserved but may not be bootable?
4. Why is the preservation of an existing Linux OS, including a previous Fedora, not explicit in the spec? Should it be?
The answers to the above will help determine the scope of QA testing in this area, and avoid lengthy debate during blocker meetings. Maybe it'll provide some kick in the pants for old bugs with unimplemented solutions. Or maybe it will make it clear that the UX in this area doesn't need improvement and therefore effort testing and developing can be better spent elsewhere. So in any case, clarification will be helpful.
References:
"grub2, 30_os-prober, os-prober: A Proposal"
https://www.redhat.com/archives/anaconda-devel-list/2014-June/msg00020.html
Initial very rough Workstation release criteria draft
https://lists.fedoraproject.org/pipermail/desktop/2014-June/009931.htmlhttps://bugzilla.redhat.com/show_bug.cgi?id=825236https://bugzilla.redhat.com/show_bug.cgi?id=964828https://bugzilla.redhat.com/show_bug.cgi?id=1048999https://bugzilla.redhat.com/show_bug.cgi?id=1010704
Thanks,
Chris Murphy

I recently blogged on the Fedora Magazine about the awesome addition of
the Solarized colour schemes in GEdit and GNOME-terminal in workstation
[1]. And a commenter on that post asked the question: why not make it
default?
Since terminal ships with the dark GTK theme turned on, we could set the
default color scheme there to Solarized Dark, and for gedit (that uses
the light GTK theme by default), enable Solarized Light by default.
cheers,
ryanlerch
[1] -
http://fedoramagazine.org/fedora-21-will-feature-solarized-color-schemes-...

Do we have any pending Workstation features that are preconditioned on
btrfs being usable? My understanding is that there's now nobody at Red
Hat working on the kernel code, so I'm a bit concerned that we could end
up in a situation where features are blocked indefinitely waiting for an
upstream with little interest in desktop functionality.
--
Matthew Garrett | mjg59(a)srcf.ucam.org

Hi.
I just realized we have a NetworkManager-config-connectivity-fedora
package. Installing this package will enable NetworkManager captive portal
detection by default, which allows improving user experience when
connecting to a captive portal.
We should install this by default on Workstation.
Any objections?
--
-Elad Alfassa.

On Jul 23, 2014, at 3:52 PM, Colin Walters <walters(a)verbum.org> wrote:
> Hi,
>
> Trying to get ahead of the Change process this time =)
>
> I'd like to move Atomic under the Server WG as I feel it's a more
> appropriate home for Fedora 22, with the increased scope to bare metal
> installation. (Really it crosses both as Atomic should run in all the
> clouds that mainline does, but I see Cloud as a specialization of Server
> personally)
>
> I started a Change page here:
>
> https://fedoraproject.org/wiki/Changes/Atomic_Server
>
> Comments (and improvements to the Change proposal) are appreciated.
Is the eventual idea that Fedora Atomic will be a separate product, or will it be a sub-product/variant of Server (or Server and Cloud) that merely differs in how it gets updated?
Where does this leave the Roller Derby project? Does it merge with Fedora Atomic, or does it go away, or does it leverage a dnf plug-in approach in contrast to an rpm-ostree approach?
Where does this leave Workstation? Its PRD lists a "Better upgrade/rollback control" requirement. And its tech spec says "gnome-software will use PackageKit with the hawkey backend". Since Server PRD and TC don't have an equivalent to this, it's curious that the one project explicitly intended to do what the Workstation PRD requires, is moving under the Server umbrella.
Chris Murphy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I'm acquainted with many of you already, but an introduction seems
fitting anyway. I've been involved with the project for a few years now,
primarily on the Docs team but also some light packaging and lately
light infrastructure things. I live in Montana, US, where the population
density is almost as low as the temperature. I work for a small
government agency doing user and systems support.
Why should you care? Well, the Docs team reached a decision this last
weekend to proactively work with the Product WGs to assess documentation
needs. I volunteered to liaison with the Workstation team. As we
approach the release cycle, I'd like everyone to keep documentation in
mind and the discussion open about not only implementation, but how to
represent that implementation to the users. An undocumented feature
isn't featured :)
I'm looking forward to working with everyone, perhaps saying hello at
the next meeting - there are meetings, right? - and developing a
presentation of the Workstation Product that shows off the capabilities
and character of your work.
- --
- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode
- immanetize(a)fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTNW1PAAoJEL1wZM0+jj2Zos4H/37WaPQMRumzi766cXv6x3mb
ADJuFmZ+mZwosTynurCAKG5p8PczOHKhRrZNslf9nFNx4dczc94QJFlO7hPOq3Mr
WOzkSn6pUXppukAd6UxX7qAjtrNomYCM8kDlmyK+ArZmVbo78O2IppeSwZk4R/tJ
ILnktcYl4sXJjlOrA28X5uiZ0dvreuZPBT+UsiDZHVvFBQfaYqjUKIioW/R4wQYp
FoFvLbXe2XCn609LuHl0TcEP9DIwd2ShKROqw2fhXXSPe4jWWwkm0+FktwEKAt46
DqKBpIZeeIIZfiKXRPS6CCGNOULboepDKj+7RfqmtrjUIqdPQZ4ZP+Hdr1vSC3M=
=G3EO
-----END PGP SIGNATURE-----

PS> I Posted this to the devel mailing list a while back and was told
to post here instead;
---------------
Removing Bloat from the next Live CD (Desktop) :
I have noticed alot of packages are included in the Live CD which are
not really used by users who only speak English.
I think it really makes sense to split the Live CD into 2 versions.
The default version will be for English only.
The second Live CD (not the default) will be English + international
languages support.
=============
Here are the packages which I believe can be removed without any
adverse effects:
ibus
ibus-chewing
ibus-gtk2
ibus-gtk3
ibus-hangul
ibus-kkc
ibus-libpinyin
ibus-m17n
ibus-rawcode
ibus-setup
ibus-wayland
libchewing
libpinyin
libpinyin-data
opencc
lohit-assamese-fonts
lohit-bengali-fonts
lohit-devanagari-fonts
lohit-gujarati-fonts
lohit-kannada-fonts
lohit-malayalam-fonts
lohit-oriya-fonts
lohit-punjabi-fonts
lohit-tamil-fonts
lohit-telugu-fonts
jomolhari-fonts
vlgothic-fonts
cjkuni-uming-fonts
wqy-zenhei-fonts
thai-scalable-fonts-common
thai-scalable-waree-fonts
smc-fonts-common
smc-meera-fonts
sil-abyssinica-fonts
sil-mingzat-fonts
sil-nuosu-fonts
sil-padauk-fonts
nhn-nanum-fonts-common
nhn-nanum-gothic-fonts
paratype-pt-sans-fonts
google-noto-sans-lisu-fonts
google-noto-sans-mandaic-fonts
google-noto-sans-meeteimayek-fonts
google-noto-sans-tagalog-fonts
google-noto-sans-tai-tham-fonts
google-noto-sans-tai-viet-fonts
khmeros-base-fonts
lklug-fonts
paktype-naqsh-fonts
tabish-eeyek-fonts
If you know a package I may have missed above please let me know.
Thanks.