This bug prevents FAW from starting the desktop environment.
If you want Atomic Workstation for F28 beta then that bug needs
to be fixed ASAP. It would be a shame to miss this opportunity
from a marketing perspective.
I'm seeing seemingly unusually slow downloads with an ostree repo that
I don't see with koji when downloading ISOs. It starts around 8-9MB/s
but quickly tanks to well below 1MB/s while still receiving objects.
This smells like ISP traffic shaping but I don't know why that would
be the case or how to prove it. Whereas koji ISO (and dnf rpm)
downloads consistently remain in the 8-9MB/s range.
[root@localhost sysroot]# ostree --repo=/ostree/repo pull
GPG: Verification enabled, found 1 signature:
Signature made Sat 24 Mar 2018 04:12:34 PM MDT using RSA key ID
Good signature from "Fedora 27 <fedora-27(a)fedoraproject.org>"
Receiving objects: 13% (11760/87920) 118.0 kB/s 172.4 MB
I'm not sure how long this will take, maybe 10 hours or 10 days. The
-v flag doesn't present the URL being used. For delta downloads this
probably isn't such a big deal, but for an initial download it's a
So I kicked off adding 3rd party applications to Fedora Workstation 28, by
submitting two tickets proposing NVidia driver and Steam.
There are basically two pages to look at:
And the practical guide for proposing an application at:
The second link includes a proposal template for adding apps. The vehicle
for proposing applications is the working group pagure instance.
I would recommend people to go over the requirements and work with 3rd
parties to propose further applications to include. We accept package
proposals that are either in RPM or Flatpak format.
Also we have a detailed howto created for how to create your repository
technically ready for inclusion in Fedora, but it needs a little more work
to get online, but Paul Frields is working on that and hopefully we will
get it resolved soon.
On Mon, Mar 19, 2018 10:47:37 +0100, Kalev Lember wrote:
> Thanks for starting the discussion, Ankur! I was just about to send a
> request for testing to the test list.
Ah - sorry. I was slightly overzealous here XD
> More replies in-line down below:
> On 03/18/2018 01:28 PM, Ankur Sinha wrote:
> > - Clicking "enable" should tell the user what repositories were made
> > available for activation. Open up the "software sources" dialogue
> > straight-away, maybe?
> Good point. I'll talk to aday (gnome-software designer) and discuss
> this. We were polishing the new software repositories dialog a lot, but
> the notification that appears on the overview page didn't get that much
> love. I'll see what we can do; maybe just disable the notification for now.
Would it also be possible to use a different term than "Third
party repositories" in the software repositories dialogue? What's
happening now is that the repositories from the
fedora-workstation-repositories package come under "Third party
repositories" accompanied by the notice on how some of these may be
proprietary, and other third party repositories that users may have
enabled themselves, such as Adobe/Dropbox/RPMFusion are coming up
in a separate section. This isn't quite intuitive---it almost gives one
the feeling that the latter are not "third party".
> > - The "find out more" link goes to the wikipedia page on properietary
> > software, which is frankly useless. The Fedora Forbidden items would
> > be a better page. I would think the Forbidden Items page should
> > require a section explaining what Gnome-software is doing here. The
> > ideal scenario would be a special page that describes the individual
> > repositories that are included in the fedora-workstation-repositories
> > package. It should be a page that clearly speaks about free-software,
> > and Fedora's commitment to it. I.e., it must educate users about the
> > matter, and say "if you must use software that is not free/open
> > source, you can do so here."
> Yes, we are supposed to get a new docs page for this. I'll talk to
> mattdm and see how far we are with this. I'll make sure we update the
> link before pushing it out to stable.
I see this is up at the moment. It isn't updated, though (A ticket has
been filed for Nvidia repositories etc already but I didn't want to update
the page myself because I'm not completely sure of the complete process
at the moment)
I would really like whatever page we link to to have a clear, end-user
targeted summary of free software and our commitment to it right at the
top, and then possibly a rationale as to why we're making it easy for
users to install some very commonly used proprietary software to improve
I think this is an excellent opportunity to explain to end-users the
importance of free-software, and let them make an informed decision on
whether they want to use this set of proprietary software even if we're
giving them easy access to it.
(I do expect some will query why all of RPMFusion cannot be included, so
maybe that will need to be addressed in short too.)
> > - And of course, can RPMFusion repositories be included here too if
> > we're happy to include Google's software?
> Please open a ticket on https://pagure.io/fedora-workstation -- I don't
> know the exact process how to add new repos, but I believe opening a
> ticket there would be a start.
Yeh. I'm following the discussion on the Nvidia ticket now:
> > I didn't want to comment on the update. Where would the right place to
> > discuss this be?
> desktop(a)lists.fedoraproject.org please.
Lovely. I've (re-)subscribed to the list and am sending my reply there
too, so that this thread can continue there.
One last thing: I'm not too well versed with how the Changes process
works, but shouldn't this quite major new feature be announced to the
community similar to the other changes?
Ankur Sinha "FranciscoD"
I'd like to have GTK tests with koji and rpmbuild but I cannot get the focus-in event during the koji build.
I referred the wiki page.
Added BuildRequires of xorg-x11-server-Xvfb and gtk3-devel in my spec file.
Added the run program in %check in my spec file.
+gcc -o test %SOURCE1 `pkg-config --cflags --libs gtk+-3.0` -g
Do you have any ideas?
I added the following test code.
-------- >8 ===============
#define TEST_STR "test"
entry_focus_in_event_cb (GtkEntry *entry,
gtk_entry_set_text (entry, TEST_STR);
buffer_inserted_text_cb (GtkEntryBuffer *buffer,
const gchar *chars,
g_assert_cmpstr (chars, ==, TEST_STR);
main (int argc, char* argv)
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
box = gtk_box_new (GTK_ORIENTATION_VERTICAL, 0);
gtk_container_add (GTK_CONTAINER (window), box);
entry = gtk_entry_new ();
g_signal_connect (G_OBJECT (entry), "focus-in-event",
G_CALLBACK (entry_focus_in_event_cb), NULL);
buffer = gtk_entry_get_buffer (GTK_ENTRY (entry));
g_signal_connect (G_OBJECT (buffer), "inserted-text",
G_CALLBACK (buffer_inserted_text_cb), NULL);
gtk_container_add (GTK_CONTAINER (box), entry);
------------- >8 ======================
I think this is really important so I created a standalone thread for this.
Currently the system auto-suspends immediately after an app releases an
idle lock, if the lock duration was longer than the suspend timeout. So
e.g. after having watched a TV series episode in a movie player, or in a
The bugs reports are here:
This is very user unfriendly. However, I don't think it constitutes a
blocker from QA point of view, it's just a very annoying default behavior.
So, I'm writing this mail so that it doesn't slip your attention, and
because Fedora Workstation SIG is the body to decide whether we want to
release F28 in this state or not.
As a personal opinion, I think this was rather quickly committed without
really thinking deep about the side-effects or testing it in a real-world
usage for some time (this bug is a clear demonstration of that). I'd rather
have this disabled for F28 and announced as a change for F29, so that we
can properly test all the corner cases in advance and try to fix them. For
example, has anyone tested:
a) whether downloading files in Firefox will inhibit suspend or the
downloads will be aborted during progress?
b) whether DNF inhibits suspend during operation or $scary_consequences?
c) whether Rhythmbox inhibits suspend when playing music?
d) whether gnome-disks inhibits suspend while operating on devices (e.g.
writing a disk clone, or checking SMART)?
e) whether Pitivi inhibits suspend while rendering video?
f) whether Nautilus inhibits suspend while copying files (possibly to even
a remote location)?
All of these should inhibit suspend, but not idle. And there's surely so
many more. This change would be an ideal candidate for a test day. Of
course, we can still do it in this cycle, but the time is running short and
I'm very skeptical that the app authors will be able to fix the apps in
What is the opinion of Fedora Workstation SIG?