AC3 support in Fedora
by Christian Schaller
Hi everyone,
I am happy to let everyone know that we got clearance today to start offering support for the AC3 audio codec in Fedora.
Wim Taymans is currently looking into getting the right implementations chosen and packaged. We will also try to reach out to
some of the 3rd party packagers out there to avoid the kind of conflicts we had with the mp3 package initially. The goal is to have it ready for Fedora 26. Wrote a blog entry about it with some more details here: https://blogs.gnome.org/uraeus/2017/03/22/another-media-codec-on-the-way/
Christian
7 years, 1 month
[Fwd: [marketing] #help: Sorting through Fedora 26 talking points]
by Jiri Eischmann
The marketing team needs help with Fedora 26 talking points. I've
started writing content for the Workstation section. Feel free to add
new features that have some significance for the users.
Jiri
-------- Přeposlaná zpráva --------
Od: Justin W. Flory <jflory7(a)gmail.com>
Reply-to: Fedora Marketing mailing list
<marketing(a)lists.fedoraproject.org>
Komu: Fedora Marketing team <marketing(a)lists.fedoraproject.org>
Předmět: [marketing] #help: Sorting through Fedora 26 talking points
Datum: Tue, 07 Mar 2017 14:25:00 +0000
Archived-at:
<https://lists.fedoraproject.org/archives/list/marketing@lists.fedorapr
oject.org/message/GMMJGWSB4MRXXWLB72VBN6GLHWUWGSMS/>
> Hey all,
>
> Eduardo and I are in the Marketing meeting this morning and we're
> trying
> to get an idea about what needs to happen in order to get a first
> deliverable in time for the Fedora 26 Alpha. We decided to separate
> the
> long-term vision of audience-based talking points to Fedora 27 and
> beyond, as we're not confident we will be able to do that and still
> have
> a deliverable product this release.
>
> The task we needed help with was to go through the existing Fedora 26
> Talking Points wiki page we have now to trim down some of the massive
> content we have there now.
>
> https://fedoraproject.org/wiki/Fedora_26_talking_points
>
> Ideally, it would help to narrow it down to some of the most
> "interesting" or "valuable" points that have a general interest to a
> broad audience of users. As an example, you can see our talking
> points
> for Fedora 25:
>
> https://fedoraproject.org/wiki/Fedora_25_talking_points
>
> Neither Eduardo or myself are going to have time to get this done in
> the
> next week, but this will help move us forward to begin reaching out
> to
> WGs and SIGs to collect info and bullets specific to the editions.
> Would
> anyone be able to help out with this?
>
> Thanks! If you have any questions, please feel free to ask here. :)
>
> --
> Cheers,
> Justin W. Flory
> jflory7(a)gmail.com
>
> _______________________________________________
> Fedora Marketing mailing list -- marketing(a)lists.fedoraproject.org
> To unsubscribe send an email to marketing-leave(a)lists.fedoraproject.o
> rg
7 years, 1 month
Fwd: GSOC: Introduction
by Mayank Verma
---------- Forwarded message ----------
From: Mayank Verma <mayank.verma048(a)gmail.com>
Date: Mon, Mar 20, 2017 at 9:48 PM
Subject: GSOC: Introduction
To: summer-coding(a)lists.fedoraproject.org
Hi everyone,
I'm Mayank Verma, 2nd year CS student at Dayananda Sagar College of
Engineering, Bangalore, India.
I'd like to contribute to the Fedora community by developing a new
application that eases migration from an old system to a new one with the
help of an external HDD as swapping internal hard disks is not something
that every user is capable of. Currently, nearly all articles available on
the web explain achieving this task using CLI. However, to be truly
user-friendly I'd like to create a GUI utility for this that handles nearly
all errors without user intervention.
I'm interested in pursuing on this idea, as I've myself spent days in
migrating my Fedora installation (LVM Live Migration) from my old notebook
to a new one due to errors that I've encountered during the process
including:
1. Complexity in booting from external HDD due to incompatibility between
GPT and MBR partitioning schemes when the internal HDD is GPT while
external HDD is MBR.
2. Additional complexity when your Fedora partition is luks encrypted.
3. Corruption of GRUB, Fstab and other configurations during the
migration process.
4. Potential driver conflicts (especially proprietary ones like Nvidia).
I'm fairly good at programming in C, C++, Java and Python.
*I'd like to know how to find mentors who might be interested in my project
idea so that I can discuss my idea in detail.*
My FAS id: mayankverma048
Github: https://github.com/mayank-verma048
7 years, 1 month
Proposed beta blockers
by Silvia Sanchez
Hello everyone,
From our last meetings in the QA team we have a bug that is proposed
as blocker but we can't decide if yes or no. We would like the
input from the internationalization and desktop teams.
The log of the meeting is here: https://meetbot.fedoraproject.org/fedor
a-blocker-review/2017-02-13/f26-blocker-review.2017-02-13-18.01.html
And the aforementioned bug is here: https://bugzilla.redhat.com/show_b
ug.cgi?id=1405539
Thank you very much for your time, we're looking forward to know
your thoughts.
Cheers,
Sylvia
7 years, 1 month
Minimal grub after a kernel update with gnome-software
by Sébastien Wilmet
Hi,
I have this critical problem with Fedora (F22, F23, F24 and F25):
https://bugzilla.redhat.com/show_bug.cgi?id=1227736
I get a minimal grub each time there is a kernel update and the updates
are done with gnome-software. When that happens, I need to boot from a
live DVD and reinstall grub.
`dnf upgrade` works fine.
It happens on different hardware, and it doesn't happen only to me.
I would be happy to provide more information in bugzilla, but nobody
replied since a long time.
Thanks,
Sébastien
7 years, 1 month
Workstation WG meeting recap 2017-Mar-13
by Paul W. Frields
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-03-13/workstation...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2017-03-13/workstation...
Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-03-13/workstation...
NOTE: I failed to capture an #agreed outcome on the BZ 1405539
discussion. The WG members present agreed, -1 on making this a
blocker for F26 Alpha.
* * *
=================================
#fedora-meeting-2: Workstation WG
=================================
Meeting started by stickster at 13:00:14 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-03-13/workstation...
.
Meeting summary
---------------
* Roll call (stickster, 13:00:19)
* Late breaking question on list for blocker bug (stickster,
13:05:51)
* BZ 1405539 (stickster, 13:06:05)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1405539
(stickster, 13:06:07)
* ACTION: mclasen discuss this bug with plymouth + other devs to see
if we have some reasonable way of mitigating or alerting
(stickster, 13:26:29)
* AGREED: juhp team to assist and possibly own (TBD) (stickster,
13:27:54)
* Workstation branding (stickster, 13:28:10)
* LINK: https://fedoraproject.org/wiki/Workstation/Branding
(stickster, 13:30:26)
* ACTION: stickster finalize a group and initial meetup time (either
on IRC or some other venue) (stickster, 13:36:07)
* Atomic Host based Workstation (stickster, 13:45:21)
Meeting ended at 13:57:14 UTC.
Action Items
------------
* mclasen discuss this bug with plymouth + other devs to see if we have
some reasonable way of mitigating or alerting
* stickster finalize a group and initial meetup time (either on IRC or
some other venue)
Action Items, by person
-----------------------
* mclasen
* mclasen discuss this bug with plymouth + other devs to see if we
have some reasonable way of mitigating or alerting
* stickster
* stickster finalize a group and initial meetup time (either on IRC or
some other venue)
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (75)
* mclasen (29)
* juhp (22)
* mcatanzaro (17)
* cschalle (15)
* zodbot (10)
* rdieter_work (0)
* ryanlerch (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
7 years, 1 month
WG meeting call for agenda Mon 2017-Mar-13
by Paul W. Frields
If you have additions or corrections for this agenda, please send by
the end of this weekend. Our meeting will be held as usual on Monday,
2017-March-13 at 1400 UTC (09:00 US Eastern).
* Workstation Branding -- need to pull this back on traack (stickster,
mclasen) (will limit to 15 min!)
* Atomic Host based Workstation next steps to align better with
Colin's ostree work
I didn't add the hexchat question here -- it seems like WG members are
well aligned that shipping xchat in the Workstation makes less sense
now. Whether that means retirement or something else is not vital for
us to settle in a meeting.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
7 years, 1 month
Atomic Workstation next steps
by Owen Taylor
I had a long discussion yesterday with Colin about some of the pain
points that are causing him to currently have a separate atomic-
workstation build on the Centos infrastructure, and what we can do to
address those and consolidate back to the Fedora infrastructure.
The long term goal we have is getting to the point where someone who is
moderately adventuresome can consume Fedora Atomic Workstation in a
rolling fashion - every week a new version of Atomic Workstation shows
up with whatever minor or major updates are considered stable, and if
something breaks, rpm-ostree offers the ability to roll back.
For Atomic Host, they offer this experience based on the *last* stable
release of Fedora - so when a new release of OpenShift or atomic-cli
happens, they rebase it in f25, and then the f25-based Atomic Host
image is updated. This provides something much more stable than basing
their releases on Rawhide, because only a fraction of the packages get
updated .
But we can't literally follow this model for workstation, because we
can't make that conceptual separation between the stable base and the
stuff that is updated - kernel, systemd, NetworkManager, gnome-shell
all have roughly the same status. The best separation we have for
Workstation is operating system vs. apps, and Flatpak is the route
forward to allow people to try out new apps on a stale base.
So what we converged on is to concentrate for now on making consuming
Rawhide via ostree better - once we get experience there, we can see
whether a *separate* rolling-but-stable stream might make sense and try
to convince the wider Fedora project about that.
I've listed some goals below, trying to order them from things that
are just a bit more than configuration changes, to things that require
a bit of implementation and development, to thing that are major
changes to how we work in Fedora.
Goal 1 (immediate)
==================
Have the ostree of at least the rawhide version of the ostree for
Fedora Workstation ("Fedora Atomic Workstation") rebuild more than once
a day. Right now fixing a problem with the ostree image is painful,
since either you have to set up a local build environment, or you can
test one change a day.
My understanding is that the way that this was resolved for Fedora
Atomic Host was that the compose for Fedora Atomic Host was separated
from the main compose, and the Atomic Host compose gets run in a cron
job every fifteen minutes or so (presumably throttling on the
completion of the last compose?)
Ways of proceeding:
* Have a separate "Fedora Atomic Workstation" compose copied from
however the Fedora Atomic Host compose is done.
* Run the entire Fedora Rawhide compose process out of a cron job,
like the Fedora Atomic Host compose. This would likely require us to
remove Rawhide from the mirrored set, but mirroring Rawhide doesn't
seem important - it is presumably a tiny portion of overall Fedora
bandwidth usage.
* Run just the *workstation* Fedora Rawhide compose out of a cron job
- I don't know how separable one edition is from the overall process.
Goal 2 (immediate)
================
Have a branch for the ostree repository for Fedora Workstation rawhide
that updates once a week rather than with every compose. This could be:
* Simply done at a fixed time
* Gated based on a human (possibly looking at the results of automated
tests)
* Gated automatically based on tests
We'd also want to make sure that there are install ISOs of these tags -
we possibly could only build ISOs when a tag is made to speed up the
continuous ostree compose process.
Goal 3 (short-term)
===================
Have tests that run automatically on the workstation ostree
repositories.
Goal 4 (short-term)
===================
Have some way to cherry pick selected security fixes and do an async-
update of the once-a-week tag. This would involve some sort of snap-
shot of the state of the koji tag used to build that version that could
then be cloned and updated with newer versions.
Goal 5 (longer-term)
====================
Extend the continuous build process to also apply to to bodhi-managed
distributions whether released (like f25) or unreleased (like f26).
ostree branches corresponding to updates and updates-testing would be
built continuously for testing purposes and automated tests would be
run against them.
Goal 6 (longer-term)
====================
Have a way of doing development branches (corresponding roughly to
side-tags in Koji) so that someone working on the next version of GNOME
or systemd can land changes and get them run through CI without
breaking people following rawhide.
Goal 7 (future)
===============
Have a "rolling stable" stream of Fedora that gets major updates not on
a six-month-tempo, but after those changes have seen testing in
Rawhide. We already treat the kernel like this.
7 years, 1 month
