23 May 2019

feedFedora People

Remi Collet: PHP extensions status with upcoming PHP 7.4

With PHP 7.4 entering stabilization phase, time to check the status of most commonly used PHP extensions (at least, the ones available in my repository).

Here is the (not yet) exhaustive list.

1. Compatible

The last published version is compatible

# Name Version State
ahocorasick 0.0.6 OK
amqp 1.9.4 OK
apcu 5.1.17 OK
apcu_bc 1.0.5 OK
apfd 1.0.1 OK
ast 1.0.1 OK
base58 0.1.3 OK
bitset 3.0.1 OK
brotli 0.7.0 OK
couchbase 2.6.0 OK
dio 0.1.0 OK
ds 1.2.9 OK
event 2.5.0 OK
fann 1.1.1 OK
gearman 2.0.5 OK
geoip 1.1.1 OK
horde_lz4 1.0.10 OK
igbinary 3.0.1 OK
inotify 2.0.0 OK
json_post 1.0.1 OK
krb5 1.1.2 OK
libvirt 0.5.4 OK
lzf 1.6.7 OK
mailparse 3.0.3 OK
maxminddb 1.4.1 OK
memcache 4.0.3 OK
memcached 3.1.3 OK
mongodb 1.6.0alpha1 OK
msgpack 2.0.3 OK
phpiredis 1.0.0 OK
pcov 1.0.3 OK
pq 2.1.5 OK
propro 2.1.0 OK
psr 0.6.1 OK
radius 1.4.0b1 OK
raphf 2.0.0 OK
redis 4.3.0 OK
rpminfo 0.2.1 OK
rrd 2.0.1 OK
selinux 0.4.2 OK
smbclient 1.0.0 OK
ssdeep 1.1.0 OK
ssh2 1.1.2 OK
stomp 1.2.10 OK
timecop 2.0.2 Some failed tests since 7.2 (related to timelib changes)
uuid 1.0.4 OK
xattr 1.3.0 OK
xmldiff 1.1.2 OK
yac 2.0.2 OK
yaml 2.0.4 OK
zstd 0.7.3 OK

2. Work in progress

These extensions have been fixed upstream (or PR are available) but no official release.

# Name Version State
cassandra 1.3.2 Fixed by PR #126 and PR #132, awaiting review
interbase 1.0.0-dev Dropped from 7.4, not released yet
oauth 2.0.4-dev Fixed upstream
solr 2.4.0 Fixed upstream (still pending for 7.3)
sphinx 1.4.0-dev Fixed upstream (still pending for 7.0)
zip 1.15.5-dev Fixed upstream
zmq 1.1.3 Fixed upstream

3. Not compatible for now (only from 7.3 compatible extensions)

# Name Version State
cmark 1.1.0 Segfault
http 3.2.0 Segfault
uopz 6.0.1 Don't build
xdebug 2.7.2 Not supported

4. Conclusion

Too soon for a statement, alpha1 is not yet released.

Last updated on May 23th 2019

23 May 2019 11:44am GMT

Fedora Community Blog: Shaily and Zubin: Building CI pipelines and helping testers

Fedora Summer Coding 2019

This post is the third introduction to the Fedora Summer Coding interns Class of Summer 2019. In this interview, we'll meet Shaily Sangwan and Zubin Choudhary, who are both working on projects to improve quality assurance processes in the Fedora community.

Shaily Sangwan: CentOS CI User Frontend

<figure class="alignright is-resized">Shaily Sangwan: Selected for CentOS CI user front-end for Google Summer of Code 2019 with Fedora Project<figcaption>Shaily Sangwan</figcaption></figure>

Shaily Sangwan (shaily) is working to create a user front-end for CentOS CI. This project involves building a web app to replace the current user on-boarding flow for ci.centos.org. She was selected for Google Summer of Code 2019.

We asked Shaily a few questions as she prepares for her next three months working with Brian Stinson and Siddharth Vipul, her mentors for the summer.

Tell us a bit about yourself!

I'm a graduate student in Political Science at Delhi University, India. Fun fact - I have previously worked with Fedora Project during Outreachy Round 15 in 2017-18.

How did you hear about GSoC?

Since GSoC is usually conducted in parallel with Outreachy, I had heard about it during my last internship, which in turn I had read about on Quora.

What caught your attention about Fedora? How does it align with your personal interests?

I learned a great deal about writing good quality code while working on Fedora Hubs, so Fedora was at the top of my list in choosing an organization to work with during GSoC. This project aligns well with my personal interests since I get to develop an application from scratch that is meant to serve a large number of users on completion.

What are you looking forward to most during this GSoC round?

I want to use this opportunity in learning how to build and deploy web apps using CI/CD and organize deployments using container run-times like Docker and Kubernetes. While my focus was earlier on learning the building blocks for these applications, now after adequate experience in this domain, I want to explore how they are deployed to production in a scalable manner.

Where do you see yourself after you complete this GSoC round?

After completing this project, I want to work in a role that involves taking more responsibility around the end to end development of web apps.

Who is your favorite Marvel superhero / superheroine?

Thanos. 🙂

Anything you want to add?

I wish there was a community meetup for Fedora interns and mentors, maybe at Flock 2019!

Editor's note: Starting last year, Flock features a Summer Coding Project Showcase. More details will come soon. Hope to see you at Flock, Shaily!

Zubin Choudhary: Fedora Gooey Karma

Zubin Choudhary (imzubin/iamzubin) is working on Fedora Gooey Karma. This is a GUI client for the Fedora Quality Assurance (QA) team for testing and reviewing package updates. He was selected for Google Summer of Code 2019.

We asked Zubin a few questions as he prepares for his next three months working with Sumantro Mukherjee, his mentor for the summer.

Tell us a bit about yourself!

I'm a computer science student from India, there's not much anyone cannot guess about me after talking to for like 5 minutes.

How did you hear about GSoC?

I was looking for summer internships and stumbled upon GSoC.

What caught your attention about Fedora? How does it align with your personal interests?

Once you switch to Linux, there's no turning back. Contributing to a huge Linux community like Fedora is something anyone would do to give back to the community.

What are you looking forward to most during this GSoC round?

Making some good contacts, a great product, getting stuck and finding a solution.

Where do you see yourself after you complete this GSoC round?

FLOCK conference! I haven't planned anything about my future, let's see where GSoC takes me. 🙂

Who is your favorite Marvel superhero / superheroine?

Our friendly neighborhood spider guy.

Thanks and good luck to Shaily and Zubin as they begin their project work next week!

The post Shaily and Zubin: Building CI pipelines and helping testers appeared first on Fedora Community Blog.

23 May 2019 8:00am GMT

22 May 2019

feedFedora People

Hans de Goede: Better support for running games under Wayland (with GNOME3/mutter as compositor)

First of all I do not want people to get their hopes up about $subject of this blogpost. Improving gaming support is a subjects which holds my personal interest and it is an issue I plan to spend time on trying to improve. But this will take a lot of time (think months for simple things, years for more complex things).

As I see it there are currently 2 big issues when running games under Wayland:

1. Many games show as a smal centered image with a black border (letterbox) around the image when running fullscreen.

For 2D games this is fixed by switching to SDL2 which will transparently scale the pixmap the game renders to the desktop resolution. This assumes that 2D games in general do not demand a lot of performance and thus will not run into performance issues when introducing an extra scaling step. A problem here is that many games still use SDL1.2 (and some games do not use SDL at all).

I plan to look into the recently announced SDL1.2 compatibility wrapper around SDL2. If this works well this should fix this issue for all SDL1.2 2D games, by making them use SDL2 under the hood.

For 3D games this can be fixed by rendering at the desktop resolution, but this might be slow and rendering at a lower resolution leads to the letterbox issue.

Recently mutter has has grown support for the WPviewport extension, which allows Wayland apps to tell the compositor to scale the pixmap the app gives to the compositor before presenting it. If we add support to SDL2's Wayland backend for this then, this can be used to allow rendering 3D apps at a lower resolution and still have them fill the entire screen.

Unfortunately there are 2 problems with this plan:


  1. SDL2 by default uses its x11 backend, not its wayland backend. I'm not sure what fixes need to be done to change this, at a minimum we need a fix at either the SDL or mutter side for this issue, which is going to be tricky.
  2. This only helps for SDL2 apps, again hopefully the SDL1.2 compatibility wrapper for SDL2 can help here, at least for games using SDL.

2. Fullscreen performance is bad with many games.

Since under Wayland games cannot change the monitor resolution, they need to either render at the full desktop resolution, which can be very slow; or they render at a lower resolution and then need to do an extra scaling step each frame.

If we manage to make SDL2's Wayland backend the default and then add WPviewport support to it then this should help by reducing an extra memcpy/blit of a desktop-sized pixmap. Currently what apps which use scaling do is:


  1. render lower-res-pixmap;
  2. scale lower-res-pixmap to desktop-res-pixmap
  3. give desktop-res-pixmap to the compositor;
  4. compositor does a hardware blit of the desktop-res-pixmap to the framebuffer.

With viewport support this becomes:


  1. render lower-res-pixmap;
  2. give low-res-pixmap to the compositor;
  3. compositor uses hardware to do a scaling blit from the low-res-pixmap to the desktop-res framebuffer

Also with viewport support, the compositor could in the case of there only being the one fullscreen app even keep the framebuffer in lowres and use a hardware scaling drm-plane to send the low-res framebuffer scaled to desktop-res to the output while only reading the low-res framebuffer from memory saving a ton of memory bandwidth. But this optimization is going to be a challenge to pull off.

22 May 2019 4:44pm GMT