Alternatively, after adding the PPA, replace ’cosmic’ with ’bionic’ in the sources list, as the package for Bionic currently appears to install and work in Cosmic just fine (from my brief testing).

The release of WordPress 5.0 brought up an issue with the use of gutenberg_parse_blocks() in aesop.php: apparently for WP versions with Gutenberg integrated, parse_blocks() should be used instead of gutenberg_parse_blocks(), otherwise a fatal error occurs when Gutenberg tries to redefine WP_Block_Parser_Block.

You can reproduce this even with Twenty Nineteen, by adding <?php $blocks = gutenberg_parse_blocks( $post->post_content ); ?> to header.php.

Replacing gutenberg_parse_blocks() calls with parse_blocks() seems to work around the issue (for me at least), and the issue here, if any, is apparently just one of confusion: renaming the function broke backwards compatibility, but since gutenberg_parse_blocks() is still defined, instead of a ”Call to undefined function” you get this attempt to redefine WP_Block_Parser (via inclusion of parser.php), resulting in the ”name is already in use”.

I’ve hit an issue, which I believe I’ve now isolated to have come from upgrading fontconfig (and related packages) from 2.12.6-0ubuntu2 to 2.12.6-0ubuntu2.3 from -proposed: if I start Firefox and afterwards start Gparted or Synaptic, Firefox starts eating up all of my CPU. Eventually all letters in the Gparted/Synaptic UI turn into boxes.

Syslog typically then says something like below:

Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: failed to create cairo scaled font, expect ugly output. the offending font is ’DejaVu Sans 11′
Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: font_face status is: out of memory
Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: scaled_font status is: out of memory
Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: shaping failure, expect ugly output. shape-engine=’PangoFcShapeEngine’, font=’DejaVu Sans 11′, text=’Päivitä’
Dec 4 13:41:51 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:51.007: failed to create cairo scaled font, expect ugly output. the offending font is ’DejaVu Sans 11’
Dec 4 13:41:51 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:51.007: font_face status is: out of memory
Dec 4 13:41:51 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:51.007: scaled_font status is: out of memory

The computer has 32 GB of memory and there’s plenty still usable when this occurs, so the OOM seems incorrect to me.

To be sure, I rolled back entirely from -proposed (which caused the issue to go away), then re-enabled -proposed and upgraded just fontconfig, and the issue reappeared.

”Using the occ command” documents using versions:cleanup either globally or for specific users, with example invocations for both cases. However, said examples are identical in the current revision:

This example deletes all versions for all users:

sudo -u www-data php occ versions:cleanup
Delete all versions
Delete versions for users on backend Database

[…]

You can delete versions for specific users in a space-delimited list:

sudo -u www-data php occ versions:cleanup
Delete versions of   freda
Delete versions of   molly

Unless I’m misinterpreting this, the latter example should have the space-delimited list of users following the invocation, like so:

sudo -u www-data php occ versions:cleanup freda molly

So I did a little more digging, and found that this actually first cropped up in Ubuntu 17.10.

I then ran mozregression (back on 18.04, my main desktop) and here’s what it found:

7:12.48 INFO: Last good revision: 64bab5cbb9b63808d04babfbcfba3175fd99f69d (2017-10-25)
7:12.48 INFO: First bad revision: aa958b29c149a67fce772f8473e9586e71fbdb46 (2017-10-26)
7:12.48 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=64bab5cbb9b63808d04babfbcfba3175fd99f69d&tochange=aa958b29c149a67fce772f8473e9586e71fbdb46

After that ”There are no build artifacts on inbound for these changesets (they are probably too old).”

As this was my first time ever using mozregression, I have no idea how useful that was, but if there’s some way I can narrow this down further, I’d be happy to.

Adrian: Thanks for taking a look! I’m using Ubuntu 18.04, and that appears to be crucial here: I created a 16.04 VM, installed all in-release updates (including Firefox 63), and just as you, was unable to reproduce the issue. I then upgraded the VM to 18.04 and the bug immediately manifested again.

Thanks Olivier, I’ve now added the link to my upstream report.

I first reported this against 62 in Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1798103

Firefox was since updated to 63 in Ubuntu and the issue remains.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

1. Open `about:config`, find `layout.css.devPixelsPerPx` and change the value from default (-1.0) to 1.2.
2. Open a view-source view with long lines: `view-source:https://www.youtube.com/user/10asti10`
3. hit Ctrl+f, search for rss
4. using the LMB, try selecting some text, then copy and paste it somewhere

Actual results:

After step 3, the highlighted text on the page is not ”rss”. The highlight doesn’t even adhere to letter widths (screenshot 1).

After step 4, the pasted text is not even close to what you’ve selected to copy.

Expected results:

For the search to hightlight an occurence of ”rss”, and for the pasted text to correspond to what I’ve selected from the view-source view.