List of Qt/Qt5 packages for Fedora WS
by Lukáš Tinkl
Hi,
based on request of cschaller, I'm sending the proposed list of Qt/Qt5
packages to be included in Fedora Workstation:
qt
qt-x11
qt-settings
qt5-qtbase
qt5-qtimageformats
qt5-qtsvg
qt5-qtx11extras
qt5-qtxmlpatterns
qt5-qtdeclarative
qt5-qtquickcontrols
qt5-qtdoc
qt5-qtconnectivity
qt5-qtmultimedia
qt5-qtgraphicaleffects
(you can see the dep chain of qt5 packages here:
https://fedoraproject.org/wiki/KDE_updates)
--
Lukáš Tinkl <ltinkl(a)redhat.com>
Senior Software Engineer - KDE desktop team, Brno
KDE developer <lukas(a)kde.org>
Red Hat Inc. http://cz.redhat.com
8 years, 6 months
Gnome 3.14 copr on F20
by Ankur Sinha
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
8 years, 7 months
Multibooting UX, how well it ought to work
by Chris Murphy
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.html
https://bugzilla.redhat.com/show_bug.cgi?id=825236
https://bugzilla.redhat.com/show_bug.cgi?id=964828
https://bugzilla.redhat.com/show_bug.cgi?id=1048999
https://bugzilla.redhat.com/show_bug.cgi?id=1010704
Thanks,
Chris Murphy
8 years, 7 months
Introduction, Documenting Workstation
by Pete Travis
-----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-----
8 years, 8 months
Workstation status and TODOs
by Josh Boyer
Hi All,
We have just less than 3 months before the F21 Alpha change deadline
comes. That means that now is the time to get going in earnest on
making sure we have all the things we want lined up for the initial
release of Workstation done. Matthias and Christian have done a great
job of getting us started, and have gotten some major Changes
approved. The GNOME 3.12 rebase was accepted, and the enabling of
SCLs should go over fairly well once the questions are addressed.
So what is left? Off the top of my head I can think of:
1) Getting the kickstart for Workstation cleaned up with the
appropriate package lists (I'd be willing to get this rolling)
2) Integrating KDE into the above in whatever form we work out with the KDE team
3) KDE variant of Adwaita theme
4) Firewall/firewalld integration issues
5) Installation and compose methods work with rel-eng (live image
default, but install tree necessary for compose. PXE/netboot iso?
etc)
I'm sure I'm missing a few things here. Please chime in with what I'm
forgetting. In short, there's more than enough work to go around.
Lastly, we've been rather quiet as a WG as of late. The Cloud WG is
going through a confirmation process with their members to make sure
people are still interested and willing to do work. That's not a bad
idea for ourselves. WG members, please take the time to reply with
whether or not you wish to remain a WG member.
As an aside, much of the "heavy lifting" in terms of process is done
for this release. The PRD and Tech Specs have been approved, and the
initial round of Changes are submitted. Not being overly familiar
with the underlying code in much of the DE stacks, my participation
has been limited mostly to those kinds of process things. I think we
still have some discussions to have on process and interactions with
other groups, but I thought I would double check that the WG feels I'm
doing a decent job representing them in this capacity. I'm happy to
continue to pitch in where I can, but if the WG feels they'd be better
served by someone else as the FESCo liaison, please speak up.
josh
8 years, 8 months
Curating the metadata in the Software application
by Ryan Lerch
IMHO, Software is a very important application in the Workstation
concept, however much of the appdata needs refinement and curation to
make it even more useful to Fedora Workstation users.
What it be a good idea to start up a team of some sort to start up this
process?
A little unsure of the best way to approach improving this part of the
Workstation for our users.
cheers,
ryanlerch
8 years, 8 months
Re: Multibooting UX, how well it ought to work
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/27/2014 11:30 AM, Simo Sorce wrote:
> On Thu, 2014-06-26 at 18:51 -0600, Chris Murphy wrote:
>> 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.
>
> To be honest I do not see any need whatsoever for multibooting in
> the Server case.
>
> So whatever abilities the Workstation WG want will be sufficient
> IMO.
I will second this. Dual-booting is not particularly valuable in our
case. People doing migrations are generally doing staged upgrades in a
testing environment first.
Now, there's certainly an argument to be made for a robust rollback
mechanism, but that's a different topic (and one we will probably
explore with Project Atomic in Fedora 22).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOtkWkACgkQeiVVYja6o6MX7ACfU4ulkBM5dRueulEKKsUA2SRs
cOcAnjzpu5ctpX4RfXxoQjwb+sXgNSHJ
=2QSK
-----END PGP SIGNATURE-----
8 years, 9 months
Initial very rough Workstation release criteria draft
by Adam Williamson
Hi, folks! Continuing to work on release criteria revision for
Fedora.next / Fedora 21 (and getting a bit behind :<), I have a very
rough working draft for Workstation:
https://fedoraproject.org/wiki/User:Adamwill/Draft_workstation_release_cr...
for now, Alpha, Beta and Final are together. So far I have not added any
new criteria, but I've taken a rough shot at splitting out the existing
criteria that seem either only applicable to the Workstation product, or
that would clearly benefit from a Workstation-specific variant, and
simplifying them appropriately. Mainly that means we don't have to fudge
around as much with generic wording when we're talking about the
Workstation product and not about "release blocking desktops" in
particular.
Next step would be to add new criteria where appropriate to reflect the
tech spec; I'll try and take a look at that tomorrow.
Probably useful to know for reference and comparison that the current
working Server draft is at
https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria , and the Cloud draft (by Mike Ruckman) at https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Relea... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Releas... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Relea... .
I am still thinking about how we go about presenting the entire
collection of criteria for Fedora 21 as a whole - we need to somehow
present criteria that apply pretty cleanly to all the supported
deliverables, ones that apply to more than one but not all, ones that
apply to just one, ones that *sort of* apply to multiple deliverables
but clearly need to be tweaked slightly for each deliverable they apply
to, and criteria for non-Product supported deliverables (at least KDE,
which we've explicitly decided is not a Product but *is* release
blocking for F21). It's a bit of a puzzle, and I'm trying to think it
through as I work on the Product drafts. So I'm hoping I'll be able to
present a Grand Plan draft of the combined presentation some time
shortly after we finish deciding at least on the broad shape of the
criteria we want to apply to each deliverable. If anyone has helpful
thoughts beyond the prior discussion on this, please do send 'em in!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 9 months
Tasklist for the Fedora Workstation
by Christian Schaller
Hi everyone,
As we are ramping up the development effort around the workstation we wanted to help increase transparency and enable more community participation in the Fedora Workstation
effort by providing a more detailed view of the various tasks underway as derived from the more high level PRD and Technical Specification documents. You can find the current
version of the tasklist here - http://fedoraproject.org/wiki/Workstation - but we hope to expand on it in the coming days and weeks to be even more comprehensive and also include more explanations around the motivation for each task.
The list enumerates the various efforts that is being undertaken around the Fedora Workstation effort and also puts a name next to many of the items.
If you are interested in helping out with any of these efforts please get in touch by reaching out either to the Working group board members or to
the people listed next to the tasks in question. For those of you not familiar with the working group we have contact information and board membership information
available on this page:
http://fedoraproject.org/wiki/Workstation
If you are getting this email you probably already know about the mailing list, but the working group can also be reached on IRC on #fedora-workstation on freenode.
Looking forward to discussing our plans with both new and old contributors to the workstation product effort.
Feel free to ask questions about the various tasks as I realize that the list is quite low on detail atm., and not all items might be self explanatory and as mentioned we do hope to add more detailed information to each item in the next few days.
Sincerely,
Christian Schaller
8 years, 9 months
A bit more about default apps for Workstation
by Diogo Campos (cadastros)
Hi,
First I would suggest that we make sure that Workstation comes with a
preinstalled backup app (I say this because Fedora 20 does not). If
there is not one already, I vote for "Deja-Dup".
Another thing: now that we have California (calendar app), GNOME
Contacts (contacts app), Bijiben (notes app) and GTG (tasks app), is
time to preinstall Geary instead of Evolution. Right?
8 years, 9 months
