coredumpctl integration for F25
by Michael Catanzaro
Hi,
Currently we have coredumpctl installed by default, but it doesn't work
because core dumps are consumed by ABRT instead. I'd like to get
coredumpctl working out-of-the-box. We can do this by changing our
systemd presets [1] to disable abrt-ccpp.service.
ABRT will continue to function thanks to the ABRT developers' work on
coredumpctl integration via abrt-vmcore.service. There is a somewhat-
reduced feature set, but I've been running this for several months
happily and I haven't noticed any issues; my crashes are being reported
to FAF, and I can manually report to Bugzilla. See [2] for details.
This might be slightly controversial for two reasons. First, the big
change here is that core dumps will appear in the magical and super-
awesome coredumpctl tool in addition to ABRT, but would no longer be
created in the cwd when ulimit is set appropriately (we would need to
feature that in the release notes). This aligns us with upstream
systemd behavior, but diverges from Debian and Ubuntu, which still
create the old-style coredumps in the cwd. Second, my understanding is
that the ABRT developers prefer to improve abrt-cli and tell people to
use that rather than coredumpctl. But as coredumpctl is very mature
(nicer) and cross-distro so it gets many more contributors, I
definitely prefer to instruct people to use coredumpctl instead for
C/C++ crashes.
We could totally do this change for F24 as well as it should be just a
one-line change, but in the spirit of beta freeze I figure it's
probably best left for F25.
Michael
[1] https://pagure.io/fedora-release/blob/master/f/90-default.preset
[2] https://github.com/abrt/abrt/issues/1108
6 years, 7 months
Another round of default app discussion
by Michael Catanzaro
Hi,
Recently the Workstation working group agreed to match the GNOME apps
we install by default in Fedora with upstream GNOME's core apps. We
will by default sync our default apps to upstream's, and make
exceptions only for exceptional reasons if when proposed on this list.
This adds a bit more cement to our status as the best GNOME
distribution with minimal divergence from upstream.
I worked upstream with designers and release team to move many
desirable apps into core, to better match what we're currently shipping
in Fedora. I also created a gnome-incubator metamodule upstream, which
is where we'll put apps that we want to be core apps by design, but
which we recognize are not yet ready to be installed by default in
distributions. Currently that is home to bijiben, gnome-boxes, gnome-
calendar, gnome-dictionary, gnome-music, and gnome-photos.
Here is how we currently diverge from the new upstream recommendations:
Apps missing from Fedora: epiphany, gnome-logs
Extra apps in Fedora: bijiben, evolution, gnome-boxes, shotwell, rhythmbox
I see little value in discussing Epiphany again right now. Let's make an exception for that.
I have added Logs in Fedora just now, as I expect that will be uncontroversial and I don't see any value in diverging from upstream here.
Bijiben is just not very good yet, and it's not under active
development. There's no good reason for us to diverge from upstream
here, and I expect it will be uncontroversial, so I've dropped it.
I guess Evolution might be controversial; I use it religiously, and
many of you probably do too. But the user interface is complex and
confusing; users should not be exposed to this by default, barring
drastic UI changes that are outside the scope of the Evolution project.
Evolution is a great mail client for power users, but I'm confident
that the average user will be better off with webmail services; folks
who want a desktop client can simply install one, after all. We intend
to replace it with GNOME Mail eventually, but nobody has started
developing it yet. I propose we drop Evolution, but I have not done so
yet, pending further discussion.
Boxes has too many serious bugs right now, so it cannot go into gnome-
core yet, but we intend it to eventually. Since this is a significant
application, I have not yet removed it from our default install,
pending further discussion. My main concern is that it would look odd
for us to remove such a significant app from the default install, then
bring it back in a year or two. On the other hand, users won't notice a
thing unless they make a habit of reinstalling Fedora, and it's not
good to include apps we can't fully recommend. It's not clear to me
what choice is best here.
I propose we make temporary exceptions to keep Shotwell and Rhythmbox, until their intended replacements, Photos and Music, move into
upstream's GNOME core moduleset. That will very likely happen for
Photos for F25. I'm less certain about Music.
Michael
6 years, 8 months
More test coverage for Boxes
by Jiri Eischmann
Hi,
Boxes is the pre-installed solution for VMs on Workstation, but it
doesn't get as much attention as it should.
Currently development composes of F24 don't even work in Boxes on F23,
so users who'd like to test F24 in the default VM app are out of luck.
It clearly violates one of the release criteria:https://fedoraproject.o
rg/wiki/Fedora_24_Beta_Release_Criteria#Guest_on_current_stable_release
The problem is that even though Boxes is the default VM app in
Workstation it's not among recommended Fedora virtualization tools the
criteria is referring to: https://fedoraproject.org/wiki/Getting_starte
d_with_virtualization
Fedora QA also use solely virt-manager and they only test Boxes from
time to time to make sure the basic functionality works.
Boxes have been here for some time, it's our default solution, we
should make sure it's the best working desktop VM on Fedora and work
with Fedora QA on ways to improve the test coverage. I think we should
start with adding Boxes to recommended virt tools. Does anyone have an
idea if it needs to go through some committee or is it just "go ahead
and edit" wiki page?
Jiri
7 years
The status of Fedora Media Writer (was LiveUSB Creator)
by Martin Bříza
Hi,
I was asked to come here and write a few words about the status of the new
Fedora Media Writer for Fedora, in a few major points for now. I haven't
read through the full meeting log yet so more stuff can follow down the
thread.
== Mac OS X Support
I was not able yet to build a working .app package with the LiveUSB
Creator for Mac. I have used probably every tool there is to freeze Python
scripts while using direct Qt installs, Macports and Homebrew. Usually I
hit issues either with missing dynamic library or broken QML imports. That
means there's not a problem with the code itself but with the way how to
distribute a usable package to the users.
If there is anyone looking to help me on that, I have uploaded just a
basic source code package to [1]. It's just a simple PyQt5/QML application
with just two source files but fundamentally the same as the FMW.
For now, I hope a Python3 port (yes, it's still Python2) will resolve
this. An other option is just to ditch the horrible Python mess and
rewrite the whole tool to a saner language that's actually portable.
== Design
I heard there are some raised voices regarding the design of the
application, that it's not the same as the design on gnome-design-team's
github. While there are some differences, I think they are mostly the same.
The main difference now is that now you can choose your achitecture with a
radiobox set in the main window below the name of your chosen Fedora
flavor instead of a small popup.
If you're concerned with the lack of headerbar usage, that's because the
app is written in Qt - there's no direct support for putting anything into
the header bar.
== Windows Support
Current plan is to distribute the application as a .exe installer created
using NSI. Either the installer or the application (or both?) will have to
be signed using a code signing certificate which we currently don't have
but can be obtained for I think 14 euros per year for open source
projects. As mentioned in the meeting yesterday, due to a communication
hiccup between me and releng, I expected I will be the one building and
signing the Windows package.
Now we're trying to resolve this with dgilmore. Currently it seems we'll
have to have a Windows machine running the builds or use upstream binary
packages in Wine because it's not possible to just compile upstream Python
using MinGW - it'd have to be heavily patched with some shady patches
lying on random peoples' blogs.
For future releases, it would be good to provide this as a single
self-extracting interpreter, though - in a similar way Windows installer
itself does it.
That's about it for now. I guess there will be questions and I'm here to
answer them.
Martin
[1] https://mbriza.fedorapeople.org/pythontest.tar.gz
7 years, 1 month
Re: [Test-Announce] Fedora 24 Candidate Beta-1.2 Available Now!
by Adam Williamson
On Fri, 2016-04-29 at 15:13 -0400, Joerg Lechner wrote:
> Hi,
> it's curious. There seem to be another problem. I have documented it
> in 6 screenshots, my technical English is not so perfect to explain
> the situation clearly in words. The behaviour after installation is
> the same without updates or after dnf update. In screenshot 1 and 2
> You see what happens during completion of installation after the
> first reboot. The entry of the pw is unsuccessful, no connection to
> wifi possible. In screenshots 4,5 and 6 I am using the way via the
> network icon, if I click i.e on the wifi name the situation is the
> same as in screenshots 1 and 2 - no connection to wifi possible. The
> only way to connect is clicking on the "circle with the gear-wheel in
> it", then another window with saying wpa2.... opens, entering in this
> window the pw, connection to wifi is ok. Known problem? Bug?
> Kind regards
If I'm understanding correctly, when you try to set the wifi passphrase
via GNOME Initial Setup (the wizard that pops up on first boot / login)
or directly from the Shell overview, you get a Shell overlay dialog
(like in screenshot 2), and that doesn't work, you don't get connected.
Right? But if you go into nm-connection-editor and enter the passphrase
there - that's where you are in screenshot 6 - it works. Right?
If I've got all that right, I think you should file a bug on GNOME
Shell, and I will see if I can reproduce it here too. Thanks!
CCing desktop@ for info.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 1 month
Progress on graphical upgrade?
by Michael Catanzaro
One of the major new features we've planned is graphical upgrades from
F23->F24.
This hasn't landed in F23 yet, so it's not yet testable. Could we have
a progress update on this? Does it work reliably? The plan was to
prepare Software 3.20 as an update for F23; is that going to happen?
Will there be some way to opt-in to a test upgrade before F24 has been
released, so beta testers can test it? It would be a shame if beta
testers all upgrade with dnf instead, so we miss out on testing for
this.
Michael
7 years, 1 month
Workstation WG meeting recap 2016-Apr-27
by Paul W. Frields
Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2016-04-27/workstation.2...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2016-04-27/workstation.2...
Log: https://meetbot.fedoraproject.org/fedora-meeting/2016-04-27/workstation.2...
* * *
===============================
#fedora-meeting: Workstation WG
===============================
Meeting started by stickster at 14:00:00 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2016-04-27/workstation.2...
.
Meeting summary
---------------
* Roll call (stickster, 14:00:04)
* Approve release blocking deliverables (stickster, 14:04:59)
* LINK:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/...
(stickster, 14:05:02)
* AGREED: Release deliverable list looks fine, +7 / -0. (stickster,
14:14:27)
* ACTION: stickster update the ticket at
https://fedorahosted.org/workstation/ticket/9 (stickster, 14:15:20)
* Third party software policy draft (stickster, 14:15:30)
* LINK:
https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
(stickster, 14:15:59)
* ACTION: stickster Add back in provision on third party repositories
not breaking Fedora dependency chains (stickster, 14:18:24)
* stickster realizes the approval fo the draft to go to Council should
have been noted a while back. (stickster, 14:36:28)
* AGREED: Draft can go to council regardless of further xdg-app
discussion, since that aspect is obviously still in motion (+7/-0)
(stickster, 14:37:13)
* xdg-app runtimes (stickster, 14:37:21)
* IDEA: otaylor - we either (A) point people at Fedora-hosted,
Fedora-based runtime; (B) point people at freedesktop.org-hosted,
Fedora-based runtime; (C) give an option for people to do either (A)
or a freedesktop.org-hosted, non-Fedora-based runtime (stickster,
14:38:49)
* stickster moved mcatanzaro's suggestion out to the text as well, as
noted on list (stickster, 14:45:46)
* ACTION: otaylor to research what it would mean to have a
freedesktop.org hosted runtime based on Fedora; what the policies
would be around it, what buy-in we would need, etc, and will report
back to the working group (otaylor, 14:49:28)
* ACTION: stickster condense notes in wiki and clarify otaylor is
researching this part (stickster, 14:50:35)
* mclasen + otaylor meeting with rel-eng on Thu 2016-Apr-28 to discuss
building xdg-apps (stickster, 14:52:07)
* ACTION: stickster to move ahead with relaying draft to council after
clarifying other wiki bits noted above (stickster, 14:52:42)
* Open floor (stickster, 14:53:38)
Meeting ended at 14:56:57 UTC.
Action Items
------------
* stickster update the ticket at
https://fedorahosted.org/workstation/ticket/9
* stickster Add back in provision on third party repositories not
breaking Fedora dependency chains
* otaylor to research what it would mean to have a freedesktop.org
hosted runtime based on Fedora; what the policies would be around it,
what buy-in we would need, etc, and will report back to the working
group
* stickster condense notes in wiki and clarify otaylor is researching
this part
* stickster to move ahead with relaying draft to council after
clarifying other wiki bits noted above
Action Items, by person
-----------------------
* otaylor
* otaylor to research what it would mean to have a freedesktop.org
hosted runtime based on Fedora; what the policies would be around
it, what buy-in we would need, etc, and will report back to the
working group
* stickster condense notes in wiki and clarify otaylor is researching
this part
* stickster
* stickster update the ticket at
https://fedorahosted.org/workstation/ticket/9
* stickster Add back in provision on third party repositories not
breaking Fedora dependency chains
* stickster condense notes in wiki and clarify otaylor is researching
this part
* stickster to move ahead with relaying draft to council after
clarifying other wiki bits noted above
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (86)
* cschalle (34)
* mclasen (21)
* otaylor (19)
* zodbot (17)
* rdieter (13)
* mcatanzaro (11)
* ryanlerch (9)
* linuxmodder (1)
* jkurik (1)
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
