Most recent items from Ubuntu feeds:
Ubuntu Insights: Ubuntu Desktop Weekly Update: June 23, 2017 from Planet Ubuntu

We’ve migrated ubuntu-session to a new unity-session package. This means that the default session is GNOME Shell and people can install Unity 7 and it’s related packages via unity-session. The migration is working well so far, but we still have some more work to do in order to make sure everything “just works”.
We’re now working on the update-manager UI to add the list of kernel CVEs which are handled by the LivePatch service and a brief description of each.
We’ve done more work on getting desktop themes working better with Snaps. We’re documenting the problems we’ve encountered and are creating some sample Snaps help with making the improvements we need.
We completed our review of the desktop test plan this week and have set our priorities for this cycle. This will cover installation, upgrades, some core application smoke tests, suspend/resume, Network Manager and translations. We will be publishing a blog on how you can get involved next week.
A new version of PulseAudio is in Xenial proposed (version 1:8.0-0ubuntu3.3). This brings fixes for Bluetooth A2DP audio devices. We’d appreciate testing and feedback.
Updated Chromium beta to 60.0.3112.32, dev to 61.0.3128.3.
Video Acceleration
We’ve got hardware accelerated video decoding working in a Proof-Of-Concept using a GStreamer and VA-API pipeline. The result is 3% CPU usage to play an h264 4K 60FPS video on Haswell. 4K h265 HEVC is also playable but requires a Skylake or later processor. This wiki page has been updated with information about how to try it yourself:

about 8 hours ago

Adam Stokes: conjure-up dev summary for week 25 from Planet Ubuntu

With conjure-up 2.2.2 out the door we bring a whole host of improvements!

sudo snap install conjure-up --classic

Improved Localhost

We recently switched over to using a bundled LXD and with that change came a few hiccups in deployments. We've been monitoring the error reports coming in and have made several fixes to improve that journey. If you are one of the ones unable to deploy spells please give this release another go and get in touch with us if you still run into problems.


Our biggest underlying technology that we utilize for deployments is Juju. Version 2.2.1 was just released and contains a number of highly anticipated performance improvements:

frequent database writes (for logging and agent pings) are batched to significantly reduce database I/O
cleanup of log noise to make observing true errors much easier
status history is now pruned whereas before a bug prevented that from happening leading to unbounded growth
update-status interval configurable (this value must be set when bootstrapping or performing add-model via the --config option; any changes after that are not noticed until a Juju restart)
debug-log include/exclude arguments now more user friendly (as for commands like juju ssh, you now specify machine/unit names instead of tags; "rabbitmq-server/0" instead of "unit-rabbitmq-server-0".

Capturing Errors

In the past, we’ve tracked errors the same way we track other general usage metrics for conjure-up. This has given us some insight into what issues people run into, but it doesn’t give us much to go on to fix those errors. With this release, we’ve begun using the open source Sentry service ( to report some more details about failures, and it has already greatly improved our ability to proactively fix those bugs.

Sentry collects information such as the conjure-up release, the lxd and juju version, the type of cloud (aws, azure, gce, lxd, maas, etc), the spell being deployed, the exact source file and line in conjure-up where the error occurred, as well as some error specific context information, such as the reason why a controller failed to bootstrap.

As with the analytics tracking, you can easily opt out of reporting via the command line. In addition to the existing --notrack option, there is now also a --noreport option. You can now also set these option in a ~/.config/conjure-up.conf file. An example of that file would be:

notrack = true
noreport = true


Our next article is going to cover the major features planned for conjure-up 2.3! Be sure to check back soon!

about 8 hours ago

Ubuntu Podcast from the UK LoCo: S10E16 – Enthusiastic Woozy Route - Ubuntu Podcast from Planet Ubuntu

This week Mark goes camping, we interview Michael Hall from Endless Computers, bring you another command line love and go over all your feedback.

It’s Season Ten Episode Sixteen of the Ubuntu Podcast! Alan Pope, Mark Johnson, Martin Wimpress and Joey Sneddon are connected and speaking to your brain.
In this week’s show:

We discuss what we’ve been upto recently:

Mark has been camping in the New Forest.

We interview Michael Hall about Endless Computers.

We share a Command Line Lurve:

nmon – nmon is short for Nigel’s performance Monitor

And we go over all your amazing feedback – thanks for sending it – please keep sending it!

This weeks cover image is taken from Wikimedia.

That’s all for this week! If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

Join us in the Ubuntu Podcast Chatter group on Telegram

about 12 hours ago

Jonathan Riddell: ISO Image Writer from Planet Ubuntu

ISO Image Writer is a tool I’m working on which writes .iso files onto a USB disk ready for installing your lovely new operating system.  Surprisingly many distros don’t have very slick recommendations for how to do this but they’re all welcome to try this.
It’s based on ROSA Image Writer which has served KDE neon and other projects well for some time.  This adds ISO verification to automatically check the digital signatures or checksums, currently supported is KDE neon, Kubuntu and Netrunner.  It also uses KAuth so it doesn’t run the UI as root, only a simple helper binary to do the writing.  And it uses KDE Frameworks goodness so the UI feels nice.
First alpha 0.1 is out now.
Download from
Signed by release manager Jonathan Riddell with 0xEC94D18F7F05997E. Git tags are also signed by the same key.
It’s in KDE Git at kde:isoimagewriter and in, please do try it out and report any issues.  If you’d like a distro added to the verification please let me know and/or submit a patch. (The code to do with is a bit verbose currently, it needs tidied up.)
I’d like to work out how to make AppImages, Windows and Mac installs for this but for now it’s in KDE neon developer editions and available as source.

1 day ago

Colin King: Cyclic latency measurements in stress-ng V0.08.06 from Planet Ubuntu

The stress-ng logoThe latest release of stress-ng contains a mechanism to measure latencies via a cyclic latency test.  Essentially this is just a loop that cycles around performing high precisions sleeps and measures the (extra overhead) latency taken to perform the sleep compared to expected time.  This loop runs with either one of the Round-Robin (rr) or First-In-First-Out real time scheduling polices.The cyclic test can be configured to specify the sleep time (in nanoseconds), the scheduling type (rr or fifo),  the scheduling priority (1 to 100) and also the sleep method (explained later).The first 10,000 latency measurements are used to compute various latency statistics:mean latency (aka the 'average')modal latency (the most 'popular' latency)minimum latencymaximum latencystandard deviationlatency percentiles (25%, 50%, 75%, 90%, 95.40%, 99.0%, 99.5%, 99.9% and 99.99%latency distribution (enabled with the --cyclic-dist option)The latency percentiles indicate the latency at which a percentage of the samples fall into.  For example, the 99% percentile for the 10,000 samples is the latency at which 9,900 samples are equal to or below.The latency distribution is shown when the --cyclic-dist option is used; one has to specify the distribution interval in nanoseconds and up to the first 100 values in the distribution are output.For an idle machine, one can invoke just the cyclic measurements with stress-ng as follows: sudo stress-ng --cyclic 1 --cyclic-policy fifo \--cyclic-prio 100 --cyclic-method --clock_ns \--cyclic-sleep 20000 --cyclic-dist 1000 -t 5 stress-ng: info: [27594] dispatching hogs: 1 cyclic stress-ng: info: [27595] stress-ng-cyclic: sched SCHED_FIFO: 20000 ns delay, 10000 samples stress-ng: info: [27595] stress-ng-cyclic: mean: 5242.86 ns, mode: 4880 ns stress-ng: info: [27595] stress-ng-cyclic: min: 3050 ns, max: 44818 ns, 1142.92 stress-ng: info: [27595] stress-ng-cyclic: latency percentiles: stress-ng: info: [27595] stress-ng-cyclic: 25.00%: 4881 us stress-ng: info: [27595] stress-ng-cyclic: 50.00%: 5191 us stress-ng: info: [27595] stress-ng-cyclic: 75.00%: 5261 us stress-ng: info: [27595] stress-ng-cyclic: 90.00%: 5368 us stress-ng: info: [27595] stress-ng-cyclic: 95.40%: 6857 us stress-ng: info: [27595] stress-ng-cyclic: 99.00%: 8942 us stress-ng: info: [27595] stress-ng-cyclic: 99.50%: 9821 us stress-ng: info: [27595] stress-ng-cyclic: 99.90%: 22210 us stress-ng: info: [27595] stress-ng-cyclic: 99.99%: 36074 us stress-ng: info: [27595] stress-ng-cyclic: latency distribution (1000 us intervals): stress-ng: info: [27595] stress-ng-cyclic: latency (us) frequency stress-ng: info: [27595] stress-ng-cyclic: 0 0 stress-ng: info: [27595] stress-ng-cyclic: 1000 0 stress-ng: info: [27595] stress-ng-cyclic: 2000 0 stress-ng: info: [27595] stress-ng-cyclic: 3000 82 stress-ng: info: [27595] stress-ng-cyclic: 4000 3342 stress-ng: info: [27595] stress-ng-cyclic: 5000 5974 stress-ng: info: [27595] stress-ng-cyclic: 6000 197 stress-ng: info: [27595] stress-ng-cyclic: 7000 209 stress-ng: info: [27595] stress-ng-cyclic: 8000 100 stress-ng: info: [27595] stress-ng-cyclic: 9000 50 stress-ng: info: [27595] stress-ng-cyclic: 10000 10 stress-ng: info: [27595] stress-ng-cyclic: 11000 9 stress-ng: info: [27595] stress-ng-cyclic: 12000 2 stress-ng: info: [27595] stress-ng-cyclic: 13000 2 stress-ng: info: [27595] stress-ng-cyclic: 14000 1 stress-ng: info: [27595] stress-ng-cyclic: 15000 9 stress-ng: info: [27595] stress-ng-cyclic: 16000 1 stress-ng: info: [27595] stress-ng-cyclic: 17000 1 stress-ng: info: [27595] stress-ng-cyclic: 18000 0 stress-ng: info: [27595] stress-ng-cyclic: 19000 0 stress-ng: info: [27595] stress-ng-cyclic: 20000 0 stress-ng: info: [27595] stress-ng-cyclic: 21000 1 stress-ng: info: [27595] stress-ng-cyclic: 22000 1 stress-ng: info: [27595] stress-ng-cyclic: 23000 0 stress-ng: info: [27595] stress-ng-cyclic: 24000 1 stress-ng: info: [27595] stress-ng-cyclic: 25000 2 stress-ng: info: [27595] stress-ng-cyclic: 26000 0 stress-ng: info: [27595] stress-ng-cyclic: 27000 1 stress-ng: info: [27595] stress-ng-cyclic: 28000 1 stress-ng: info: [27595] stress-ng-cyclic: 29000 2 stress-ng: info: [27595] stress-ng-cyclic: 30000 0 stress-ng: info: [27595] stress-ng-cyclic: 31000 0 stress-ng: info: [27595] stress-ng-cyclic: 32000 0 stress-ng: info: [27595] stress-ng-cyclic: 33000 0 stress-ng: info: [27595] stress-ng-cyclic: 34000 0 stress-ng: info: [27595] stress-ng-cyclic: 35000 0 stress-ng: info: [27595] stress-ng-cyclic: 36000 1 stress-ng: info: [27595] stress-ng-cyclic: 37000 0 stress-ng: info: [27595] stress-ng-cyclic: 38000 0 stress-ng: info: [27595] stress-ng-cyclic: 39000 0 stress-ng: info: [27595] stress-ng-cyclic: 40000 0 stress-ng: info: [27595] stress-ng-cyclic: 41000 0 stress-ng: info: [27595] stress-ng-cyclic: 42000 0 stress-ng: info: [27595] stress-ng-cyclic: 43000 0 stress-ng: info: [27595] stress-ng-cyclic: 44000 1 stress-ng: info: [27594] successful run completed in 5.00s Note that stress-ng needs to be invoked using sudo to enable the Real Time FIFO scheduling for the cyclic measurements.The above example uses the following options:--cyclic 1starts one instance of the cyclic measurements (1 is always recommended) --cyclic-policy fifo use the real time First-In-First-Out scheduling for the cyclic measurements --cyclic-prio 100 use the maximum scheduling priority  --cyclic-method clock_nsuse the clock_nanoseconds(2) system call to perform the high precision duration sleep --cyclic-sleep 20000 sleep for 20000 nanoseconds per cyclic iteration --cyclic-dist 1000 enable latency distribution statistics with an interval of 1000 nanoseconds between each data point. -t 5run for just 5 secondsFrom the run above, we can see that 99.5% of latencies were less than 9821 nanoseconds and most clustered around the 4880 nanosecond model point. The distribution data shows that there is some clustering around the 5000 nanosecond point and the samples tail off with a bit of a long tail.Now for the interesting part. Since stress-ng is packed with many different stressors we can run these while performing the cyclic measurements, for example, we can tell stress-ng to run *all* the virtual memory related stress tests and see how this affects the latency distribution using the following: sudo stress-ng --cyclic 1 --cyclic-policy fifo \ --cyclic-prio 100 --cyclic-method clock_ns \ --cyclic-sleep 20000 --cyclic-dist 1000 \ --class vm --all 1 -t 60s ..the above invokes all the vm class of stressors to run all at the same time (with just one instance of each stressor) for 60 seconds.The --cyclic-method specifies the delay used on each of the 10,000 cyclic iterations used.  The default (and recommended method) is clock_ns, using the high precision delay.  The available cyclic delay methods are:clock_ns (use the clock_nanosecond() sleep)posix_ns (use the POSIX nanosecond() sleep)itimer (use a high precision clock timer and pause to wait for a signal to measure latency)poll (busy spin-wait on clock_gettime() to eat cycles for a delay.All the delay mechanisms use the CLOCK_REALTIME system clock for timing.I hope this is plenty of cyclic measurement functionality to get some useful latency benchmarks against various kernel components when using some or a mix of the stress-ng stressors.  Let me know if I am missing some other cyclic measurement options and I can see if I can add them in.Keep stressing and measuring those systems!

1 day ago

Dustin Kirkland: My Meetup Slides: Deploy and Manage Kubernetes Clusters on Ubuntu in the Oracle Cloud from Planet Ubuntu

Thank you to Oracle Cloud for inviting me to speak at this month's CloudAustin Meetup hosted by Rackspace.I very much enjoyed deploying Canonical Kubernetes on Ubuntu in the Oracle Cloud, and then exploring Kubernetes a bit, how it works, the architecture, and a simple workload within.  I'm happy to share my slides below, and you can download a PDF here: Canonical Kubernetes on the Oracle Cloud (1) from Dustin Kirkland If you're interested in learning more, check out:The upstream documentation for installing Kubernetes on Ubuntu: can also get $300 free credit on Oracle Cloud, you can watch our Kubernetes webinar series: was a great audience, with plenty of good questions, pizza, and networking!I'm pleased to share my slide deck here.Cheers,Dustin

1 day ago

James Page: Ubuntu OpenStack Pike Milestone 2 from Planet Ubuntu

The Ubuntu OpenStack team is pleased to announce the general availability of the OpenStack Pike b2 milestone in Ubuntu 17.10 and for Ubuntu 16.04 LTS via the Ubuntu Cloud Archive.
Ubuntu 16.04 LTS
You can enable the Ubuntu Cloud Archive for OpenStack Pike on Ubuntu 16.04 LTS installations by running the following commands:
sudo add-apt-repository cloud-archive:pike
sudo apt update
The Ubuntu Cloud Archive for Pike includes updates for Barbican, Ceilometer, Cinder, Congress, Designate, Glance, Heat, Horizon, Ironic, Keystone, Manila, Murano, Neutron, Neutron FWaaS, Neutron LBaaS, Neutron VPNaaS, Neutron Dynamic Routing, Networking OVN, Networking ODL, Networking BGPVPN, Networking Bagpipe, Networking SFC, Nova, Sahara, Senlin, Trove, Swift, Mistral, Zaqar, Watcher, Senlin, Rally and Tempest.
We’ve also now included GlusterFS 3.10.3 in the Ubuntu Cloud Archive in order to provide new stable releases back to Ubuntu 16.04 LTS users in the context of OpenStack.
You can see the full list of packages and versions here.
Ubuntu 17.10
No extra steps required; just start installing OpenStack!
Branch Package Builds
If you want to try out the latest master branch updates, or updates to stable branches, we are maintaining continuous integrated packages in the following PPA’s:
sudo add-apt-repository ppa:openstack-ubuntu-testing/newton
sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
sudo add-apt-repository ppa:openstack-ubuntu-testing/pike
bear in mind these are built per-commitish (30 min checks for new commits at the moment) so ymmv from time-to-time.
Reporting bugs
Any issues please report bugs using the ‘ubuntu-bug’ tool:
sudo ubuntu-bug nova-conductor
this will ensure that bugs get logged in the right place in Launchpad.
Still to come…
In terms of general expectation for the OpenStack Pike release in August we’ll be aiming to include Ceph Luminous (the next stable Ceph release) and Open vSwitch 2.8.0 so long as the release schedule timing between projects works out OK.
Any finally – if you’re interested in the general stats – Pike b2 involved 77 package uploads including new 4 new packages for new Python module dependencies!
Thanks and have fun!

1 day ago

Meerkat: The state of IMEs under Linux from Planet Ubuntu

Input Method Editors, or IMEs for short, are ways for a user to input text in another, more complex character set using a standard keyboard, commonly used for Chinese, Japanese, and Korean languages (CJK for short). So in order to type anything in Chinese, Japanese, or Korean, you must have a working IME for that language.
Quite obviously, especially considering the massive userbase in these languages, it’s crucial for IMEs to be quick and easy to setup, and working in any program you decide to use.
The reality is quite far from this. While there are many problems that exist with IMEs under Linux, the largest one I believe is the fact that there’s no (good) standard for communicating with programs.
IMEs all have to implement a number of different interfaces, the 3 most common being XIM, GTK (2 and 3), and Qt (3, 4, and 5).
XIM is the closest we have to a standard interface, but it’s not very powerful, the pre-editing string doesn’t always work properly, isn’t extensible to more advanced features, doesn’t work well under many window systems (in those I’ve tested, it will always appear at the bottom of the window, instead of beside the text), and a number of other shortcomings that I have heard exist, but am not personally aware of (due to not being one who uses IMEs very often).
GTK and Qt interfaces are much more powerful, and work properly, but, as might be obvious, they only work with GTK and Qt. Any program using another widget toolkit (such as FLTK, or custom widget toolkits, which are especially prevalent in games) needs to fall back to the lesser XIM interface. Going around this is theoretically possible, but very difficult in practice, and requires GTK or Qt installed anyways.
IMEs also need to provide libraries for every version of GTK and Qt as well. If an IME is not updated to support the latest version, you won’t be able to use the IME in applications using the latest version of GTK or Qt.
This, of course, adds quite a large amount of work to IME developers, and causes quite a problem with IME users, where a user will no longer be able to use an IME they prefer, simply because it has not been updated to support programs using a newer version of the toolkit.
I believe these issues make it very difficult for the Linux ecostructure to advance as a truly internationalized environment. It first limits application developers that truly wish to honor international users to 2 GUI toolkits, GTK and Qt. Secondly, it forces IME developers to constantly update their IMEs to support newer versions of GTK and Qt, requiring a large amount of effort, duplicated code, and as a result, can result in many bugs (and abandonment).
I believe fixing this issue would require a unified API that is toolkit agnostic. There’s 2 obvious ways that come to mind.

A library that an IME would provide that every GUI application would include
A client/server model, where the IME is a server, and the clients are the applications

Option #1 would be the easiest and least painful to implement for IME developers, and I believe is actually the way GTK and Qt IMEs work. But there are also problems with this approach. If the IME crashes, the entire host application will crash as well, as well as the fact that there could only be one IME installed at a time (since every IME would need to provide the same library). The latter is not necessarily a big issue for most users, but in multi-user desktops, this can be a big issue.
Option #2 would require more work from the IME developers, juggling client connections and the likes (although this could be abstracted with a library, similar to Wayland’s architecture). However, it would also mean a separate address space (therefore, if the IME crashes, nothing else would crash as a direct result of this), the possibility for more than one IME being installed and used at once, and even the possibility of hotswapping IMEs at runtime.
The problem with both of these options is the lack of standardization. While they can adhere to a standard for communicating with programs, configuration, dealing with certain common problems, etc. are all left to the IME developers. This is the exact problem we see with Wayland compositors.
However, there’s also a third option: combining the best of both worlds in the options provided above. This would mean having a standard server that will then load a library that provides the IME-related functions. If there are ever any major protocol changes, common issues, or anything of the likes, the server will be able to be updated while the IMEs can be left intact. The library that it loads would be, of course, entirely configurable by the user, and the server could also host a number of common options for IMEs (and maybe also host a format for configuring specific options for IMEs), so if a user decides to switch IMEs, they wouldn’t need to completely redo their configuration.
Of course, the server would also be able to provide clients for XIM and GTK/Qt-based frontends, for programs that don’t use the protocol directly.
Since I’m not very familiar with IMEs, I haven’t yet started a project implementing this idea, since there may be challenges about a method like this that might have already been discussed, but that I’m not aware of.
This is why I’m writing this post, to hopefully bring up a discussion about how we can improve the state of IMEs under Linux :) I would be very willing to work with people to properly design and implement a better solution for the problem at hand.

2 days ago

Brian Murray: Getting information about LP bugs with lots of duplicates from Planet Ubuntu

The other day some of my fellow Ubuntu developers and I were looking at bug 1692981 and trying to figure out what was going on. While we don’t have an answer yet, we did use some helpful tools (at least one of which somebody hadn’t heard of) to gather more information about the bug.
One such tool is lp-bug-dupe-properties from the lptools package in Ubuntu. With this it is possible to quickly find out information about all the duplicates, 36 in this case, of a bug report. For example, if we wanted to know which releases are affected we can use:
lp-bug-dupe-properties -D DistroRelease -b 1692981
LP: #1692981 has 36 duplicates
Ubuntu 16.04: 1583463 1657243 1696799 1696827 1696863 1696930 1696940
1697011 1697016 1697068 1697099 1697121 1697280 1697290 1697313 1697335
1697356 1697597 1697801 1697838 1697911 1698097 1698100 1698104 1698113
1698150 1698171 1698244 1698292 1698303 1698324 1698670 1699329
Ubuntu 16.10: 1697072 1698098 1699356
While lp-bug-dupe-properites is useful, in this case it’d be helpful to search the bug’s attachments for more information. Luckily there is a tool, lp-grab-attachments (also part of lptools), which will download all the attachments of a bug report and its duplicates if you want. Having done that you can then use grep to search those files.
lp-grab-attachments -dD 1692981
The ‘-d’ switch indicates I want to get the attachments from duplicate bug reports and the ‘-D’ switch indicates that I want to have the bug description saved as Description.txt. While saving the description provides some of the same capability as lp-bug-dupe-properties it ends up being quicker. Now with the attachments saved I can do something like:
for desc in $(find . -name Description.txt); do grep "dpkg 1.18.[4|10]" $desc;
dpkg 1.18.4ubuntu1.2
dpkg 1.18.10ubuntu2
dpkg 1.18.10ubuntu1.1
dpkg 1.18.4ubuntu1.2

and find out that a variety of dpkg versions are in use when this is encountered.
I hope you find these tools useful and I’d be interested to hear how you use them!

2 days ago

Paul White: Some random notes on losing my broadband connection from Planet Ubuntu

I first started using Ubuntu just a few weeks after Lucid Lynx was released and have used Ubuntu, Kubuntu, Xubuntu, Lubuntu and Ubuntu GNOME since then. Towards the end of 2016 I took early retirement and decided to curtail some of my Ubuntu related activities in favour of some long abandoned interests which went back to the 1960s. Although I had no intention of spending every day sat in front of a computer screen I still wished to contribute to Ubuntu but at a reduced level. However, recent problems relating to my broadband connection, which I am hoping are now over, prompted me to look closely at how I could continue to contribute to Ubuntu if I lost my "always on" internet.ProblemsThanks to my broadband provider, whose high profile front man sports a beard and woolly jumpers, my connection changed from being one that was "always on" to one that was "usually off". There's a limit to how many times I'm prepared to reboot my cable modem on the advice of the support desk, be sent unnecessary replacement modems because the one I'm using must be faulty, to allow engineers into my home to measure signal levels, and be told the next course of action will definitely get my connection working only to find that I'm still off-line the next day and the day after. I kept asking myself: "Just how many engineers will they need to send before someone successfully diagnoses the problem and fixes it?"Mobile broadbandMuch of my recent web browsing, on-line banking, and updating of my Xubuntu installations has been done with the aid of two iPhones acting as access points while connected to the 3 and EE mobile networks. It was far from being an ideal situation, connection speeds were often very low by today's standards but "it worked" and the connections were far more reliable than I thought that they would be. A recent test during the night showed a download speed on a 4G connection to be comparable to that offered by many other broadband providers. But downloading large Ubuntu updates took a long time especially during the evening. As updating the pre-installed apps on a smart phone can quickly use up one's monthly data allowance I made myself aware of where I could find local Wi-Fi hotspots to make some of the important or large phone updates and save some valuable bandwidth for Ubuntu. Interestingly with the right monthly plan and using more appropriate hardware than a mobile phone, I could actually save some money by switching from cable to mobile broadband although I would definitely miss my 100Mb/s download speed that is most welcome when downloading ISO images or large Ubuntu updates.ISO testingUnfortunately these problems, which lasted for over three weeks, meant that I had to cease ISO testing due to the amount of data I would need to download several times each week. I had originally intended to get a little more involved with testing of the development release of Xubuntu during the Artful cycle but those plans were put on hold while I waited for my broadband connection to be restored and deemed to be have been fixed permanently. During this outage I still managed to submit a couple of bug reports and comment on a few others but my "always on" high speed connection was very much missed.Connection restored!How I continue with Ubuntu long-term will now depend on the reliability of my broadband connection which does seem to have now been restored to full working order. I'm finalising this post a week after receiving yet another visit from an engineer who restored my connection in just a matter of minutes. Cables had been replaced and signal levels had been measured and brought to within the required limits. Apparently the blame for the failure of the most recent "fix" was put solely on one of his colleagues who I am told failed to correctly join two cables together. In other words, I wasn't actually connected to their network at all. It must have been so very obvious to my modem/router which sat quietly in the corner of the room forever looking to connect to something that it just could not find and yet was unable to actually tell me so. If only such devices could actually speak....

3 days ago

Mathieu Trudel: Netplan by default in 17.10 from Planet Ubuntu

Friday, I uploaded an updated nplan package (version 0.24) to change its Priority: field to important, as well as an update of ubuntu-meta (following a seeds update), to replace ifupdown with nplan in the minimal seed.What this means concretely is that nplan should now be installed by default on all images, part of ubuntu-minimal, and dropped ifupdown at the same time.For the time being, ifupdown is still installed by default due the way debootstrap generates the very minimal images used as a base for other images -- how it generates its base set of packages, since that depends only on the Priority: field of packages. Thus, nplan was added, but ifupdown still needs to be changed (which I will do shortly) to disappear from all images.The intent is that nplan would now be the standard way of configuring networks. I've also sent an email about this to ubuntu-devel-announce@.I've already written a bit about what netplan is and does, and I have still more to write on the subject (discussing syntax and how to do common things). We especially like how using a purely declarative syntax makes things easier for everyone (and if you can't do what you want that way, then it's a bug you should report).MaaS, cloud-init and others have already started to support writing netplan configuration.The full specification (summary wiki page and a blueprint reachable from it) for the migration process is available here.While I get to writing something comprehensive about how to use the netplan YAML to configure networks, if you want to know more there's always the manpage, which is the easiest to use documentation. It should always be up to date with the current version of netplan available on your release (since we backported the last version to Xenial, Yakkety, and Zesty), and accessible via:man 5 netplanTo make things "easy" however, you can also check out the netplan documentation directly from the source tree here:'s also a wiki page I started to get ready that links to the most useful things, such as an overview of the design of netplan, some discussion on the renderers we support and some of the commands that can be used.We even have an IRC channel on Freenode: #netplanI think you'll find that using netplan makes configuring networks easy and even enjoyable; but if you run into an issue, be sure to file a bug on Launchpad here:

3 days ago

Simon Raffeiner: My Ubuntu for mobile devices post mortem analysis from Planet Ubuntu

Now that Ubuntu phones and tablets are gone, I would like to offer my thoughts on why I personally think the project failed and what one may learn from it.

3 days ago

Jeremy Bicha: GNOME Tweak Tool 3.25.3 from Planet Ubuntu

Today I released the second development snapshot (3.25.3) of what will be GNOME Tweak Tool 3.26.
I consider the initial User Interface (UI) rework proposed by the GNOME Design Team to be complete now. Every page in Tweak Tool has been updated, either in this snapshot or the previous development snapshot.
The hard part still remains: making the UI look as good as the mockups. Tweak Tool’s backend makes this a bit more complicated than usual for an app like this.
Here are a few visual highlights of this release.
The Typing page has been moved into an Additional Layout Options dialog in the Keyboard & Mouse page. Also, the Compose Key option has been given its own dialog box.

Florian Müllner added content to the Extensions page that is shown if you don’t have any GNOME Shell extensions installed yet.

A hidden feature that GNOME has had for a long time is the ability to move the Application Menu from the GNOME top bar to a button in the app’s title bar. This is easy to enable in Tweak Tool by turning off the Application Menu switch in the Top Bar page. This release improves how well that works, especially for Ubuntu users where the required hidden appmenu window button was probably not pre-configured.

Some of the ComboBoxes have been replaced by ListBoxes. One example is on the Workspaces page where the new design allows for more information about the different options. The ListBoxes are also a lot easier to select than the smaller ComboBoxes were.

For details of these and other changes, see the commit log or the NEWS file.
GNOME Tweak Tool 3.26 will be released alongside GNOME 3.26 in mid-September.

4 days ago

Marco Trevisan (Treviño): GNOME Fractional (and multi-monitor) Scaling Hackfest, the report from Planet Ubuntu

As previously announced, few days ago I attended the GNOME Fractional Scaling Hackfest that me and Red Hat‘s Jonas Ådahl organized at the Canonical office in Taipei 101.
Although the location was chosen mostly because it was the one closest to Jonas and near enough to my temporary place, it turned out to be the best we could use, since the huge amount of hardware that was available there, including some 4k monitors and HiDPI laptops.
Being there also allowed another local Caonical employee (Shih-Yuan Lee) to join our efforts!
As this being said I’ve to thank my employer, for allowing me to do this and for sponsoring the event in order to help making GNOME a better desktop for Ubuntu (and not only).
Going deeper into the event (for which we tracked the various more technical items in a WIP journal), it has been a very though week, hard working till late while trying to look for the various edge cases and discovering bugs that the new “logically sized” framebuffer and actors were causing.
In fact, as I’ve already quickly explained, the whole idea is to paint all the screen actors at the maximum scale value across the displays they intersect and then using scaled framebuffers when painting, so that we can redefine the screen coordinates in logical pixels, more than using pixel units. However, since we want to be able to use any sized element scaled at (potentially any) fractional value, we might incur in problems when eventually we go back to the pixel level, where everything is integer-indexed.
We started by defining the work items for the week and setting up some other HiDPI laptops (Dell XPS 15 and XPS 13 mostly) we got from the office with jhbuild, then as you can see we defined some list of things to care about:

Supporting multiple scaling values: allowing to scale up and down (< 1.0) the interface, not only to well-known value, but providing a wider range of floats we support
Non-perfect-scaling: covering the cases in which the actor (or the whole monitor) when scaled up/down to a fractional level has not anymore a pixel-friendly size, and thus there are input and outputs issues to handle due to rounding.
GNOME Shell UI: the shell StWidget‘s need to be drawn at proper resource scaling value, so that when they’re painted they won’t look blurred.
Toolkit supports: there are some Gtk issues when scaling more than 2x, while Qt has support for Fractional scaling.
Wayland protocol improvements: related to the point above we might define a way to tell toolkits the actual fractional scaling value, so that they could be scaled at the real value, instead of asking them to scale up to the upper integer scaling level. Also when it comes to games and video players, they should not be scaled up/down at all.
X11 clients: supporting XWayland clients

What we did
As you see the list of things we meant to work or plan was quite juicy, so more than enough for one week, but even if we didn’t finish all the tasks (despite the Super-Joans powers :-)), we have been able to start or address the work for most of them so that we’ll know what to work on for the next weeks.
Scaling at 1.25x
As a start, we had to ensure mutter was supporting various scaling values (including the ones < 1.0), we decided (this might change, but given the Unity experience, it proved to work well) to support 8 intermediate values per integer, from 0.5 to 4.0. This, as said, would lead to troubles when it comes to many resolutions (as you see in the board picture, 1280×720 is an example of a case that doesn’t work well when scaled at 1.5 for instance). So we decided to make mutter to expose a list of supported scaling values per each mode, while we defined an algorithm to compute the closest “good” scaling level to get a properly integer sized logical screen.
This caused a configuration API change, and we updated accordingly gnome-settings-daemon and gnome-control-center adding also some UI changes to reflect and control this new feature.
Not only, the ability of having such fractional values, caused various glitches in mutter, mostly related to the damage algorithm, which Jonas refactored. Other issues in screenshots or gnome-shell fullscreen animations have also been found and fixed.
Speaking of Gnome Shell toolkit, we started some work to fix the drawing of cairo-based areas, while I had already something done for labels, that needs to be tuned. Shih-Yuan fixed a scaling problem of the workspace thumbnails.
On toolkits support, we didn’t do much (a part Gnome Shell) as Gtk problem is not something that affects us much in normal scenarios yet, but still we debugged the issue, while it’s probably a future optimization to support fractional-friendly toolkits using an improved wayland protocol. Instead it’s quite important to define a such protocol for apps that don’t need to be scaled, such as games, but in order to do it we need feedback from games developers too, so that we can define it in the best way.
Not much has been also done in XWayland world (right now everything is scaled to the required value by mutter, but the toolkit  will also use scale 1, which would lead to some blurred result), but we agreed that we’d probably need to define an X11 protocol for this.
We finally spent some time for defining an algorithm for picking the preferred scaling per mode. This is a quite controversial aspect, and anyone might have their ideas on this (especially OEMs), so far we defined some DPI limits that we’ll use to evaluate weather a fractional scaling level has to be done or not: outside these limits (which change depending we’re handling a laptop panel or an external monitor [potentially in a docked setup]) we use integer scaling, in between them we use instead proportional (fractional) values.
One idea I had was to see the problem the other way around and define instead the physical size (in tenth of mm) we want for a pixel at least to be, and then scale to ensure we reach those thresholds instead of defining DPIs (again, that physical size should be weighted for external monitors differently, though). Also, hardware vendors might want to be able to tune these defaults, so one idea was also to provide a way for them to define defaults by panel serial.
In any case, the final and most important goal, to me, is to provide defaults that guarantee usable and readable HiDPI environments, so that people would be able to use gnome-control-center and adjust these values if needed.
And I think could be quite also quite useful to add to the gnome-shell intro-wizard an option to chose the scaling level if an high DPI monitor is detected.
For this reason, we also filled this wiki page, with display technical infos for all the hardware we had around, and we encourage you to do add your infos (if you don’t have write access to the Wiki, just send it to us).

What to do
As you can see in our technical journal TODO, we’ve plenty of things to do but the main thing is currently fixing the Shell toolkit widgets, while going through various bugs and improving the XWayland clients situation. Then there multiple optimizations to do at mutter level too.
When we ship
Our target is to get this landed by GNOME 3.26, even if this might be under an experimentalgsettings key, as right now the main blocker is the X11 clients support.
How to help
The easiest thing you can do is help testing the code (using jhbuild build gnome-shell with a config based on this) should be enough), also filling the scale factor tests wiki page might help. If you want to get involved with code, these are the git branches to look at.
Read More
You can read a more schematic report that Jonas wrote for this event on the gnome-shell mailing list.
It has been a great event, we did and discussed about many things but first of all I’ve been able to get more closely familiar in the GNOME code with who has wrote most of it, which indeed helped.
We’ve still lots of things to do, but we’re approaching to a state that would allow everyone to get differently scaled monitors at various fractional values, with no issues.
Our final board
Check some other pictures in my flickr gallery
Finally, I’ve to say thanks a lot to Jonas who initially proposed the event and, a part being a terrific engineer, has been a great mate to work and hang out with, making me discover (and survive in) Taipei and its food!

4 days ago