Planet GNOME

It’s been four months since I announced Epiphany Technology Preview — which I’ve been using as my main browser ever since — and five months since I announced the availability of a stable channel via Flatpak. For the most part, it’s been a good experience. Having the latest upstream development code for everything is wonderful and makes testing very easy. Any user can painlessly download and install either the latest stable version or the bleeding-edge development version on any Linux system, regardless of host dependencies, either via a couple clicks in GNOME Software or one command in the terminal. GNOME Software keeps it updated, so I always have a recent version. Thanks to this, I’m often noticing problems shortly after they’re introduced, rather than six months later, as was so often the case for me in the past. Plus, other developers can no longer complain that there’s a problem with my local environment when I report a bug they can’t reproduce, because Epiphany Technology Preview is a canonical distribution environment, a ground truth of sorts.

There have been some rough patches where Epiphany Technology Preview was not working properly — sometimes for several days — due to various breaking changes, and the long time required to get a successful SDK build when it’s failing. For example, multimedia playback was broken for all of last week, due to changes in how the runtime is built. H.264 video is still broken, since the relevant Flatpak extension is only compatible with the 3.28 runtime, not with master. Opening files was broken for a while due to what turned out to be a bug in mutter that was causing the OpenURI portal to crash. I just today found another bug where closing a portal while visiting Slack triggered a gnome-shell crash. For the most part, these sorts of problems are expected by testers of unstable nightly software, though I’m concerned about the portal bugs because these affect stable users too. Anyway, these are just bugs, and all software has bugs: they get fixed, nothing special.

So my impression of Flatpak is still largely positive. Flatpak does not magically make our software work properly in all host environments, but it hugely reduces the number of things that can go wrong on the host system. In recent years, I’ve seen users badly break Epiphany in various ways, e.g. by installing custom mimeinfo or replacing the network backend. With Flatpak, either of these would require an incredible amount of dedicated effort. Without a doubt, Flatpak distribution is more robust to user error. Another advantage is that we get the latest versions of OS dependencies, like GStreamer, libsoup, and glib-networking, so we can avoid the many bugs in these components that have been fixed in the years since our users’ LTS distros froze the package versions. I appreciate the desire of LTS distros to provide stability for users, but at the same time, I’m not impressed when users report issues with the browser that we fixed two years ago in one dependency or another. Flatpak is an excellent compromise solution to this problem: the LTS distro retains an LTS core, but specific applications can use newer dependencies from the Flatpak runtime.

But there is one huge downside to using Flatpak: we lose crash reports. It’s at best very difficult — and often totally impossible — to investigate crashes when using Flatpak, and that’s frankly more important than any of the gains I mention above. For example, today Epiphany Technology Preview is crashing pretty much constantly. It’s surely a bug in WebKit, but that’s all I can figure out. The way to get a backtrace from a crashing app in flatpak is to use coredumpctl to manually dump the core dump to disk, then launch a bash shell in the flatpak environment and manually load it up in gdb. The process is manual, old-fashioned, primitive, and too frustrating for me by a lot, so I wrote a little pyexpect script to automate this process for Epiphany, thinking I could eventually generalize it into a tool that would be useful for other developers. It’s a horrible hack, but it worked pretty well the day I tested it. I haven’t seen it work since. Debuginfo seems to be constantly broken, so I only see a bunch of ???s in my backtraces, and how are we supposed to figure out how to debug that? So I have no way to debug or fix the WebKit bug, because I can’t get a backtrace. The broken, inconsistent, or otherwise-unreliable debuginfo is probably just some bug that will be fixed eventually (and which I half suspect may be related to our recent freedesktop SDK upgrade. Update: Alex has debugged the debuginfo problem and it looks like that’s on track to be solved), but even once it is, we’re back to square one: it’s still too much effort to get the backtrace, relative to developing on the host system, and that’s a hard problem to solve. It requires tools that do not exist, and for which we have no plans to create, or even any idea of how to create them.

This isn’t working. I need to be able to effortlessly get a backtrace out of my application, with no or little more effort than running coredumpctl gdb as I would without Flatpak in the way. Every time I see Epiphany or WebKit crash, knowing I can do nothing to debug or investigate, I’m very sorely tempted to switch back to using Fedora’s Epiphany, or good old JHBuild. (I can’t promote BuildStream here, because BuildStream has the same problem.)

So the developer experience is just not good, but set that aside: the main benefits of Flatpak are for users, not developers, after all. Now, what if users run into a crash, how can they report the bug? Crash reports are next to useless without a backtrace, and wise developers refuse to look at crash reports until a quality backtrace has been posted. So first we need to fix the developer experience to work properly, but even then, it’s not enough: we need an automatic crash reporter, along the lines of ABRT or apport, to make reporting crashes realistically-achievable for users, as it already is for distro-packaged apps. But this is a much harder problem to solve. Such a tool will require integration with coredumpctl, and I have not the faintest clue how we could go about making coredumpctl support container environments. Yet without this, we’re asking application developers to give up their most valuable data — crash reports — in order to use Flatpak.

Eventually, if we don’t solve crash reporting, Epiphany’s experiment with Flatpak will have to come to an end, because that’s more important to me than the (admittedly-tremendous) benefits of Flatpak. I’m still hopeful that the ingenuity of the Flatpak community will find some solutions. We’ll see how this goes.

I bought my old Lenovo Thinkpad X1 Carbon (1st gen.) when I entered grad school for my Master's program, in 2012. And after six years, the Thinkpad still ran well, but it was getting old, so I figured it was time for a change. I went back and forth about what kind of system should replace my laptop. I don't travel that much, so I figured a desktop would be better. And I could get a bigger screen.

After going back and forth on the decision, I decided to get a laptop. I don't often travel with a laptop, but when I do, I prefer to use my primary system so I don't have to keep things synced. Of course, I wanted my system to run Linux. Purism is aimed at the Linux laptop market, and I wanted to support that. So I bought a Librem 13.

I've had it now for about a week, and I love it now. But I'll be honest, I didn't love it right out of the box. I'd like to note two issues for folks who are thinking about getting a Librem laptop, so you aren't surprised like I was.

1. The backslash key sends the wrong key codeThe Purism laptop uses a keyboard that sends the wrong key code for the backslash key (\). The "shift" on this key is the pipe symbol (|). So you know, you need these. Try running any commands at the Linux command line, and you'll quickly run into a problem where you can't send the output of one program into another program. You need the pipe for that. Or try escaping a character at the command line, or in program code. You need the backslash for that.

This is a known issue on the Librem. Every other keyboard known to man gets this right, but I guess Purism used a different keyboard.

To fix, you need to set setkeycodes 56 43 to reset the correct key codes for that key system-wide. To make the fix permanent, create a new /etc/rc.d/rc.local file that is mode 750 and has these lines:

#!/bin/bash
setkeycodes 56 43
exit 0

Here's the file entry:

-rwxr-x---. 1 root root 37 May 22 18:50 /etc/rc.d/rc.local

This fixes the problem each time the system boots. You don't need to do anything at the user level. Note that I have my Librem connected to an external display, and I'm using an external keyboard and mouse. This key code fix doesn't impact backslash or pipe on my external keyboard, so I'm good there.2. The Intel video card gives serious video flickerWhen I first booted the Librem, it was using the pre-installed PureOS Linux distribution. I played with it for a while, then decided I'd rather run the Fedora Linux distribution that I'm used to. But after I'd re-installed, I quickly realized I had a problem. The laptop screen would flicker at random times.

Ah well, I figured. This is a driver issue, just do an update. Except that every time I ran an update, the laptop display went to sleep. Very annoying. In the end, I had to boot into run level 3, and run the update from text mode. The screen still flickered once in a while, but not as badly, and the display didn't go to sleep.

It turns out that this is also a known issue. Some users reported that using i915.enable_rc6=0 as a kernel option will prevent or reduce the issue. Or you can try i915.enable_psr=0. But on my Librem, neither seemed to completely fix the problem. I still get flicker on the laptop display. I'm not sure what kernel settings Purism used in the pre-installed PureOS Linux, since I wiped that when I re-installed with Fedora Linux.

The problem is likely caused in the Intel i915 power management driver. Also reported as Constant display flicker after i915 is initialised. For the Librem suggested fix, see Troubleshooting > Screen Flickering.

Interestingly, I don't get this problem when I'm using only the external display. I mentioned that I have my Librem connected to an external display, and I'm using an external keyboard and mouse. I set GNOME to only use the external display. I can still see the laptop's screen flicker at the graphical login screen (on the laptop display), but once GNOME switches to the external display, the laptop's display turns off so the problem doesn't seem to get triggered.With those two fixes in place (rc.local, and using an external display) I'm very happy with my Librem 13. I'm effectively using it as a desktop computer. I'm hoping there's a fix for the i915 video by the time I take my next trip in October, or I'll be very unhappy.

If you know of a better solution for the i915 display flicker problem, please let me know in the comments.

Update (6/6/18): I'm still having the screen flicker problem. I reached out to Purism via Twitter, and they asked that I open a support case, which I have. They've seen this on some machines.

Update (6/9/18): I shipped back my Librem 13 today. I feel better knowing this is a hardware issue that others have seen, and that it's fixable.

Before jumping right into the Five or More implementation plan and details, I would like to keep you updated with the progress made thus far.

I started working on some project-related tasks during the community bonding period, to cover up for the upcoming exam and research session and any other time frame in which I might not be as active as I would like to. Also, during this period, I had a previously announced one week trip, which kept me from working more on the project.

I began by reading the Vala tutorial; I considered this was a very important first step as I have to first be aware of all the capabilities of the language before being able to put them to good use in porting Five or More to Vala.

In order to practice a bit with Vala and Gtk+, I proceeded to set up a basic project in GNOME Builder. I encountered a couple of problems, out of which one was solved by updating to the latest Builder available on flathub, and the other one led to opening an issue on the gnome-builder GitLab repository. The two experiments I worked on mostly revolved around analysing the code generated by GNOME Builder as best practices starting template, and can be found on my GitHub repository. While working on the two simple apps, I also used Glade to better understand how the UI templates work and the GtkInspector tool to analyse them. I plan on doing more such experiments in the future, while working on the migration of Five or More to Vala, and add them to the previously mentioned repository.

Now moving onto the implementation plan for Five or More, as mentioned in my previous blog post, I would like to split the development process in a series of steps, working on one component at a time; this will allow me to test each new component after integration and fix issues in a timely manner, and also to better track the progress. I agreed with my mentor, Robert Roth, on following a top down approach, which essentially means that I will be starting with porting the topmost component, the application itself, and then progress towards the more complex tasks, such as implementing the game grid.

I will first create a second src folder (e.g. src-vala) where I will work on the Vala code, since I plan on maintaining a functional C version in the repository, until the port is complete. This way, I can easily ensure both the C and the Vala versions have the same set of features and the functionality remains the same.

Then, I intend to create a basic Vala app and window based on the template generated by GNOME Builder, only using the UI file that already exists in the Five or More repository. If everything goes as planned, I will start adding one component at a time in the short run, starting with the application menu, the callbacks for the UI buttons, the preferences window, the score and the preview widgets, and lastly, the game area.

Only after I’m done replicating the existing functionality, I will take into account adding new features such as the ones mentioned in the previous post, namely sound, gamepad support or design changes.

Suggestions and feedback are highly appreciated, especially in the early stages of development, so don’t hesitate to leave me a comment or contact me via the channels provided.

Can you spot what that is?

For the past couple of weeks, Builder from git-master has come with a new gnome-builder-clang subprocess. Instead of including libclang in the UI process, we now proxy all of that work to the subprocess. This should have very positive effect on memory usage within the UI process. It will also simplify the process of using valgrind/ASAN and obtaining useful results. In the future, we’ll teach the subprocess supervisor to recycle subprocesses if they consume too much memory.

That is rather important because compilers wreak havoc on the memory allocator. However, it presents a series of challenges too.

Once you move all of that stuff out of process you need to find an efficient way to communicate between processes. The design that I came up with is plain GVariant messages delivered over a stdin/stdout pipe to the subprocess. This is very similar to the Language Server Protocol but lets us cheat in an important way.

We sometimes need to pass large messages between processes including changes to unsaved buffers or completion results. Clang prefers to do client-side filtering of completion results so the list often includes some 25,000+ results. Not exactly the type of thing you want to parse into lots of tiny json objects and strings. By using GVariant as our message format we ensure that we only have a single memory allocation for the entire result set (and can use C strings embedded in the variant too!).

By altering some of our APIs to use interfaces like GListModel we end up more lazy in terms of object creation, use less memory, and fragment significantly less. One area this will be changing in the near future is our new completion engine. It is based on what we learned about other async APIs in Builder along with using GListModel for efficiency.

One thing that is not well known is that g_variant_get_child_value() is O(1) due to how arrays are laid out in GVariant. This couples well with g_list_model_get_item().

This has been a big step forward, but there is more to do.

tl;dr: Use gss_service_hold() and gss_service_release() from libgsystemservice.

Automatically shutting down daemons when not in use is in vogue, and a good way of saving resources quite easily (if the service’s startup/shutdown costs are low).

libgsystemservice can do this for you automatically, if your code is based on GssService, or if you want to port over to it (which should be fairly straightforward for simple services). It supports inactivity timeouts by default; just call gss_service_hold() when you start doing some activity, and gss_service_release() when you stop.

(Also, look, it’s neat that you can generate documentation and automatically publish it from your master branch using GitLab CI!)

Thanks to the work of Christoph Reiter, GLib has had continuous integration builds on Windows (using MinGW32/MSYS2) for a week or two now. Furthermore, he’s added code coverage support, so we can easily see how our code coverage is changing over time. Thanks Christoph!

I am incredibly happy because of three big things that are going on in librsvg right now:

1. Paolo Borelli finished porting all the CSS properties to Rust. What was once a gigantic RsvgState struct in C is totally gone, along with all the janky C code to parse individual properties. The process of porting RsvgState to Rust has been going on since about two months ago, and has involved many multi-commit merge requests and refactorings. This is a tremendous amount of really good work! The result is all in Rust now in a State struct, which is opaque from C's viewpoint. The only places in C that still require accessors to the State are in the filter effects code. Which brings me to...

2. Ivan Molodetskikh, my Summer of Code student, submitted his first merge request and it's merged to master now. This ports the bookkeeping infrastructure for SVG filters to Rust, and also the feOffset filter is ported now. Right now the code doesn't do anything fancy to iterate over the pixels of Cairo image surfaces; that will come later. I am very happy that filters, which were a huge barrier, are now starting to get chipped away into nicer code.

3. I have started to move librsvg's old representation of CSS properties into something that can really represent properties that are not specified, or explicitly set to inherit from an SVG element's parent, or set to a normal value. Librsvg never had a representation of property values that actually matched the SVG/CSS specs; it just knew whether a property was specified or not for an element. This worked fine for properties which the spec mandates that they should inherit automatically, but those that don't, were handled through special hacks. The new code makes this a lot cleaner. It should also make it easier to copy Servo's idioms for property inheritance.

Three weeks ago I blogged about how to get rid of non-free Google services and moving to free software on my Android phone. I’ve got a lot of feedback via email, lwn, and Google+, many thanks to all of you for helpful hints! As this is obviously important to many people, I want to tie up some lose ends and publish the results of these discussions.

Alternative apps and stores

• Yalp is a free app that is able to search, install, and update installed apps from the Google Play Store. It doesn’t even need you to have a Google account, although you can use it to install already paid apps (however, you can’t buy apps within Yalp). I actually prefer that over uptodown now.

• I moved from FreeOTP to AndOTP. The latter offers backing up your accounts with password or GPG encryption, which is certainly much more convenient than what I’ve previously been doing with noting down the accounts and TOTP secrets in an encrypted file on my laptop.

• We often listen to internet radio at home. I replaced the non-free ad-ware TuneIn with Transistor, a simple and free app that even has convenient launcher links for a chosen station, so it’s exactly what we want. It does not have a builtin radio station list/search, but if you care about that, take a look at RadioDroid (but that doesn’t have the convenient quick starters).

Transport

In this area the situation is now much happier than my first post indicated. As promised I used trainline.eu for booking some tickets (both for Deutsche Bahn and also on Thalys), and indeed this does a fine job. Same price, European rebate cards like BahnCard 50 are supported, and being able to book with a lot of European train services with just one provider is really neat. However, I’m missing a lot of DB navigator’s great features: realtime information and alternatives, seat selection, car position indicator, regional tariffs, or things like “Länderticket”.

Fortunately it turns out that DB Navigator works just great with a trick: Disable the “Karte anzeigen” option in the menu, and it will immediately stop complaining about missing Play Services after each action. Also, logging in with your DB account never finishes, but after terminating and restarting the app you are logged in and everything works fine. That might be a “regular” bug or just a side effect without Play Services.

Wrt. rental bikes: citybik.es is an awesome project and freely available API that shows available bikes on a map all over Europe. The OpenBikeSharing uses that on Android. That plus the ordinary Nextbike app works well enough.

microG

A lot of people pointed out microG as a free implementation of Google Play Service APIs. Indeed I did try this even before my first blog post; but I didn’t mention it as I wanted to find out which apps actually need this API.

Also, this really appears to be something for the daunting: On my rooted Nexus 4 with LineageOS I didn’t get it to work, even after installing the handful of hacks that you need for signature spoofing; and I daresay that on a standard vendorized installation without root/replaced bootloader it’s outright impossible.

Fortunately there are LineageOS builds with microG included, which gets you much further. But even with that e. g. location still does not work out of the box, but one needs to hunt down and install various providers. I’ve heard from several people that they use this successfully, but as this wasn’t the point of my exercise I just gave up after that.

A really useful piece of functionality of Play Services is tracking and remote-controlling (lock, warn tone, erase) lost or stolen phones. With having backup, encryption and proper locking, a stolen phone is not the end of the world, but it’s still relatively important for me (even though I never had to actually use it yet). The only alternative that I found is Cerberus which looks quite comprehensive. It’s not free though (neither as in beer nor in speech), so unless you particularly distrust Google and are not a big company, it might just be better to keep using Play Services for this functionality.

Calendar and Contacts

I’m really happy with DAVDroid and radicale after using them for over a month. But most people don’t have a personal server to run these. etesync looks like an interesting alternative which provide the hosting for you for five coffees a year, and also offer (free) self-hosting for those who can and want to.

Let's say you decide that you'd like to see what some other processes on your system are doing to a subtree of the file system. You don't want to have to change how those processes work -- you just want to see what files those processes create and delete.

One approach would be to just scan the file-system tree periodically, enumerating its contents. But when the file system tree is large and the change rate is low, that's not an optimal thing to do.

Fortunately, Linux provides an API to allow a process to receive notifications on file-system change events, called inotify. So you open up the inotify(7) manual page, and are greeted with this:

With careful programming, an application can use inotify to efficiently monitor and cache the state of a set of filesystem objects. However, robust applications should allow for the fact that bugs in the monitoring logic or races of the kind described below may leave the cache inconsistent with the filesystem state. It is probably wise to do some consistency checking, and rebuild the cache when inconsistencies are detected.

It's not exactly reassuring is it? I mean, "you had one job" and all.

Reading down a bit farther, I thought that with some "careful programming", I could get by. After a day of trying, I am now certain that it is impossible to build a correct recursive directory monitor with inotify, and I am not even sure that "good enough" solutions exist.

pitfall the first: buffer overflow

Fundamentally, inotify races the monitoring process with all other processes on the system. Events are delivered to the monitoring process via a fixed-size buffer that can overflow, and the monitoring process provides no back-pressure on the system's rate of filesystem modifications. With inotify, you have to be ready to lose events.

This I think is probably the easiest limitation to work around. The kernel can let you know when the buffer overflows, and you can tweak the buffer size. Still, it's a first indication that perfect is not possible.

pitfall the second: now you see it, now you don't

This one is the real kicker. Say you get an event that says that a file "frenemies.txt" has been created in the directory "/contacts/". You go to open the file -- but is it still there? By the time you get around to looking for it, it could have been deleted, or renamed, or maybe even created again or replaced! This is a TOCTTOU race, built-in to the inotify API. It is literally impossible to use inotify without this class of error.

The canonical solution to this kind of issue in the kernel is to use file descriptors instead. Instead of or possibly in addition to getting a name with the file change event, you get a descriptor to a (possibly-unlinked) open file, which you would then be responsible for closing. But that's not what inotify does. Oh well!

pitfall the third: race conditions between inotify instances

When you inotify a directory, you get change notifications for just that directory. If you want to get change notifications for subdirectories, you need to open more inotify instances and poll on them all. However now you have N2 problems: as poll and the like return an unordered set of readable file descriptors, each with their own ordering, you no longer have access to a linear order in which changes occurred.

It is impossible to build a recursive directory watcher that definitively says "ok, first /contacts/frenemies.txt was created, then /contacts was renamed to /peeps, ..." because you have no ordering between the different watches. You don't know that there was ever even a time that /contacts/frenemies.txt was an accessible file name; it could have been only ever openable as /peeps/frenemies.txt.

Of course, this is the most basic ordering problem. If you are building a monitoring tool that actually wants to open files -- good luck bubster! It literally cannot be correct. (It might work well enough, of course.)

reflections

As far as I am aware, inotify came out to address the needs of desktop search tools like the belated Beagle (11/10 good pupper just trying to get his pup on). Especially in the days of spinning metal, grovelling over the whole hard-drive was a real non-starter, especially if the search database should to be up-to-date.

But after looking into inotify, I start to see why someone at Google said that desktop search was in some ways harder than web search -- I mean we all struggle to find files on our own machines, even now, 15 years after the whole dnotify/inotify thing started. Part of it is that the given the choice between supporting reliable, fool-proof file system indexes on the one hand, and overclocking the IOPS benchmarks on the other, the kernel gave us inotify. I understand it, but inotify still sucks.

I dunno about you all but whenever I've had to document such an egregious uncorrectable failure mode as any of the ones in the inotify manual, I have rewritten the software instead. In that spirit, I hope that some day we shall send inotify to the pet cemetery, to rest in peace beside Beagle.

The All Systems Go! 2018 Call for Participation is Now Open!

The Call for Participation (CFP) for All Systems Go! 2018 is now open. We’d like to invite you to submit your proposals for consideration to the CFP submission site.

The CFP will close on July 30th. Notification of acceptance and non-acceptance will go out within 7 days of the closing of the CFP.

All topics relevant to foundational open-source Linux technologies are welcome. In particular, however, we are looking for proposals including, but not limited to, the following topics:

• Low-level container executors and infrastructure
• IoT and embedded OS infrastructure
• BPF and eBPF filtering
• OS, container, IoT image delivery and updating
• Building Linux devices and applications
• Low-level desktop technologies
• Networking
• System and service management
• Tracing and performance measuring
• IPC and RPC systems
• Security and Sandboxing

While our focus is definitely more on the user-space side of things, talks about kernel projects are welcome, as long as they have a clear and direct relevance for user-space.

For more information please visit our conference website!

How it all began

It was October and I had no idea what open source was. My friend Sagar who was a GSoC’17 student encouraged me to get into open source starting with DigitalOcean’s Hacktoberfest. I was still new to open source but the beauty of tools like Git and concept of people all over the world contributing to their favourite softwares and projects attracted me towards it, but it wasn’t till late January that I actually started properly contributing to an org.

I had chosen GNOME.

Within just a few days, I fell in love with the simplicity of the code and the very supportive community of GNOME. My mentors, Ardien Plazas and Abhinav Singh were especially helpful and helped me get on track, by closely watching them handle the code with utmost care and simplicity, it quickly began apparent to me that more than developing a software, they were developing an art. I promptly began to understand the codebase and fix bugs as fast as I could. Encouraged by my friend, Sagar and already in love with GNOME Games, I applied for GSoC.

Now, GNOME had chosen me.

I am grateful for this oppurtunity that GNOME has provided me. My project will be, segregating games and displaying metadata. I am very excited to spend my summers with GNOME and certainly hope to learn a lot in the process.

Keep following for more updates regarding the development of my project and an exciting summer with GNOME!

Earlier this month, a few of us from Collabora, Olivier Crête, Nicolas Dufresne, George Kiagiadakis and I attended the GStreamer Spring Hackfest in Lund, Sweden. Hosted by Axis Communications (who uses GStreamer in their surveillance cameras for many years now), it was a great opportunity for the GStreamer community to touch base and work on open bugs and pet projects.



While I've been involved in the GStreamer project in the past, it was my first GStreamer hackfest. While a lot was achieved during the event, the most exciting outcomes were no doubt the closing of more than 350 bugs, and the agreement on a transition plan to move to GitLab.

Overall, the hackfest was very productive, with each member of our team managing to progress in their list of tasks while all taking part in bug triaging & cleaning in preparation of moving GStreamer's issue tracking to GitLab.

George spent time working on improving the new library API that is needed to introduce support for the non-interleaved audio layout, discussed a gst-rtsp-server issue with the Axis team, and merged all qt-gstreamer patches that were lying around in bugzilla and resolved all reported bugs, then declared it as unmaintained.

For his part, Nicolas participated in the planar audio format and split field interlaced video support work, started looking at adding per element latency tracing to GStreamer's existing latency tracer, and also discussed GStreamer CI, which will also move to GitLab to be able to run on pull requests also.

Olivier, during the first day, focused on the collective effort of reviewing all of the open bugs, managing to close a number of them while confirming and commenting on others. He also merged some outstanding patches he had (stay tuned for more details on those), and forward ported gst-validate for Android with the goal of running the CI on Android. He also merged a series of patches that enable bitcode embedding on the iOS target with the eventual goal of supporting tvOS as well.

As for myself, I mainly worked on (or rather started to work on) split-field interlacing support in GStreamer, adding relevant formats and modes in the GStreamer video library. In addition, as a Meson developer (Nirbheek Chauhan) was present, I took the opportunity to discuss with him the last bit of porting build system of Geoclue to Meson, a side project I've been working on. It helped me get it done faster but also helped Nirbheek find some issues in Meson and fix them!

All in all, my first GStreamer hackfest was an awesome experience (even though I was not feeling well). It was also very nice to hangout and socialize with old and new friends in the GStreamer community after a long time. Many thanks again to Axis for hosting us in their offices! See you at the GStreamer Conference this fall!

With Xamarin.Forms 3.0 in addition to the many new feature work that we did, we have been doing some general optimizations across the board, from compile times to startup times and wanted to share some recent results on the net effect on one of our larger sample apps.

These are the results when doing a cold start for the SmartHotel360 application on Android when compiled for 32bits (armeabi-v7a) on a Google Pixel (1st gen).

Release Release/AOT Release/AOT+LLVM Forms 2.5.0 6.59s 1.66s 1.61s Forms 3.0.0 3.52s 1.41s 1.38s

This is independent of the work that we are doing to improve Android's startup speed, that both brings additional benefits today, and will bring additional benefits in the future.

One of the areas that we are investing on for Android is to remove any dynamic code execution at startup to integrate with the Java runtime, instead all of this is being statically computed, similar to what we are doing on Mac and iOS where we completely eliminated reflection and code generation from startup.