Planet Bluesabre

All the latest from Xfce, Xubuntu, & Friends.

atril (1.24.1-0ubuntu1) hirsute

  • New upstream maintenance release.

xfce4-systemload-plugin 1.3.1 released

  • Update README.md
  • Update and sort the list of authors
  • Add a simple network bandwidth monitor (uses libgtop as a fallback)
  • Remove 4-valued history
  • Fix initial progress bar value
  • Fix system-monitor-command setting (Fixes #15)
  • Distinguish uptime from the appearance of a digital real-time clock
  • Replace "Options" with "Label" in the properties dialog
  • Finish porting to xfconf
  • Update docs URL
  • Code cleanups
  • Translation Updates: Bulgarian, Chinese (China), Chinese (Taiwan), Hebrew, Italian, Japanese, Norwegian Bokmål, Polish, Portuguese, Portuguese (Brazil), Slovak, Spanish, Swedish

thunar 4.17.1 released

Development release on the master branch.

One reason to do the next development release was, to get early testers for the changes on the shortcuts-view (unified context menu). Though the release as well ships various fixes, some smaller features and translation updates:

  • Use a more specific device eject label (Issue #153)
  • Reload current directory before selecting new files (Issue #524)
  • Shortcuts view: Open new folder after creation
  • ThunarLauncher: Dont expose "select files" closure
  • Use thunar-menu and launcher in shortcuts view (Issue #198)
  • thunar-launcher: Send signal when device operation is started/finished
  • Removed 'the root folder has no parent' dialog box
  • tree-view: Hide menu-item "properties" for unmounted devices
  • Regression: Missing "mount"/"unmount" on tree-view devices
  • thunar-launcher: unpack g_value with correct call
  • Remove watches on shortcuts (Issue #513) (Issue #47)
  • Regression: Select copied files after copy operation (Issue #520)
  • Reintroduce alternative zoom shortcuts (Issue #514)
  • Prevent hangup if a copy task that is blocked is resumed (Issue #467)
  • Improve comments in "thumbnail_needs_frame"
  • Improve device unmount messages (Issue #516)
  • Regression: Allow custom image files for UCA icons (Issue #517)
  • Dont merge folders when creating copy with same name (Issue 491)
  • Fix incorrect return value in scroll event handler (Issue #512)
  • Use wording "queued" instead of "frozen" for jobs (Issue #511)
  • Revamp documentation to modernize/uniformize accross components
  • Remove tray icon and related methods (Issue #495)
  • Regression: Skip app info updates on sendto actions (Issue #502)
  • Regression: Toggle menu visibility on F10 if menu hidden (Issue #498)
  • thunar-launcher: Unify way to set selected device/location/files
  • thunar-launcher: Keep ref on ThunarDevice while poking
  • thunar-launcher: Provide service to open locations (bookmarks)
  • Regression: "Shift" + "Select Trash in menu" has to trigger delete
  • Translation Updates: Basque, Bulgarian, Chinese (China), Czech, Dutch, Estonian, Finnish, French, Galician, German, Greek, Hebrew, Italian, Japanese, Korean, Norwegian Bokmål, Occitan (post 1500), Persian (Iran), Portuguese, Portuguese (Brazil), Serbian, Spanish, Swedish, Turkish, Uyghur

thunar 4.16.6 released

A bugfix and translation release on the 4.16 branch. Here the changes:

  • Reload current directory before selecting new files (Issue #524)
  • tree-view: Hide menu-item "properties" for unmounted devices
  • Removed 'the root folder has no parent' dialog box
  • Revamp documentation to modernize/uniformize accross components
  • Remove watches on shortcuts (Issue #513) (Issue #47)
  • Translation Updates: Finnish, Occitan

xfce4-systemload-plugin (1:1.2.4-1ubuntu1) devel

  • Merge with Debian unstable. Remaining Ubuntu changes:
    • Add epoch.

gimp (2.10.22-3) unstable

  • debian/control.in: Add graphviz to the dependencies. Some optional functionality of libgegl used in gimp now requires the dot executable shipped in the graphviz package (Closes: #985317)
  • debian/patches/02_hurd_ftbfs.patch: Fix FTBFS on hurd-i386. Thanks to Svante Signell svante.signell@gmail.com (Closes: #934077)

xfdashboard 0.9.1 released

xfdashboard-0.9.1 "Gradients! Whoohoooo!" was released on 2021-03-19.

This is a development release.

  • New feature: Move XfdashboardApplication out of library libxfdashboard into application xfdashboard and turn libxfdashboard into a complete library
  • New feature: Implemented a new color class XfdashboardGradientColor which support solid colors (single colors) and path gradients. Path gradient will follow a path (the outline) and draw a gradient orthogonal with color stops along this path.
  • New feature: Outlines (through XfdashboardoutlineEffect) do now use the new XfdashboardGradientColor to support the usual solid colors as befeofre as well as a new path gradient.
  • Changed default theme to make use of new path gradients at outlines.
  • Removed all xfdashboard__get_default() function to access single instances of the subsystems/component, like plugins manager etc., as these single instances should now to access through XfdashboardCore and its xfdashboard_core_get_(…) functions
  • Dropped support of Xfconf legacy (versions below 4.13.0) because of new XfdashboardSettings and XfdashboardPluginSettings object. Therefore also the dependency on dbus-glib was dropped which was need for Xfconf legacy.
  • Smaller bug-fixes
  • Clean-ups
  • More API documentation
  • Updated localizations: bg, de, es, eu, fr, he, it, ja, nb, pl, sr, zh_CN

xfdashboard (0.8.1-0ubuntu1) devel

  • d/watch: Only track stable releases.
  • New upstream version 0.8.1.

Stable Release Updates on Xubuntu

Stable Release Updates on Xubuntu

From the moment an Ubuntu release (and flavors) reaches Final Freeze until the release is end-of-life (EOL), updates are released following the "stable release update" procedure, or SRU. This process is documented on the Ubuntu Wiki. However, it can be intimidating for new and long-time contributors and also confusing for users. I'd like to explain this process from a Xubuntu perspective.

We currently have two packages going through the SRU procedure for Xubuntu 20.04 and 20.10. After you've read this article, consider checking them out and helping with verification.

Stable Release Update Procedure

  1. Identify the "why"
  2. Create or update bug reports
  3. Package and upload the fixes for each release
  4. Wait for the SRU team to review and accept the upload
  5. SRU Verification
  6. Wait for the SRU team to release the package to the -updates pocket

Identify the "why"

A common misconception about stable Ubuntu releases is that all bug fixes and new releases (small and large) will arrive via an update. There is not an automatic process for these updates to land in a stable release. Further, any fixes and new features have to be documented and tested according to the procedure above. As you might imagine, this can be a massive time sink.

Stable release updates specific to Xubuntu will generally be limited to high-impact bugs:

  • Security vulnerabilities
  • Severe regressions
  • Bugs that directly cause a loss of user data
  • External changes that cause the current version to no longer work

If an update meets these requirements, it is eligible to be updated with a Stable Release Update. Lower impact bugs will generally not be considered for SRU, but may be fixed in the -backports pocket or the Xubuntu QA Staging PPA.

Create or update bug reports

If the bugs being fixed have already been reported on Launchpad, they will need to be updated with the SRU template. Other bugs and new features present in an upload should have new bug reports opened. Due to the time-based nature of landing a fix and following the SRU process, it can be a significant setback to have to start over, so more information is better than less. When in doubt, fill it out.

The standard SRU template typically includes the following sections: Impact, Test Plan, Where problems could occur (formerly Regression Potential), and Other Info. These sections help others who may not be completely familiar with the software or bug to be able to test it, and demonstrates that the upload and its regression potential has been sufficiently considered.

Once the bug reports are ready, the packages can be prepared and uploaded.

Package and upload the fixes for each release

The first packaging-related step for a Stable Release Update is ensuring the fix is already released on the current development release. This may not always be applicable, but applies more often than not. Once the fix is verified in the development release, packages can be prepared for each affected stable release.

The packages are prepared with each bug fix linked in the Debian changelog. This will automatically update the affected bugs with status updates and tags and progress the bug status from In Progress to Fix Committed, and later to Fix Released. The packages are then uploaded to the -proposed pocket and Xubuntu SRU Staging PPA.

Wait for the SRU team to review and accept the upload

The Ubuntu SRU team is a small and busy one! Sometimes, it may take a few days for the team to review and accept the upload to the -proposed pocket. Once the package has been accepted, this starts the 7-day clock. Even after verification, a package upload must wait a minimum of 7 days before it is accepted into the -updates pocket.

SRU verification

SRU verification can be completed by any Launchpad user, and is recommended for getting a fix released to the -updates pocket sooner. Following the test cases documented on each bug report...

  • If the fix is sufficient and there's no regression, replace the verification-needed-release tag with verification-done-release. Add a comment describing the steps taken to verify the package.
  • If the fix is insufficient or there are regressions introduced, replace the verification-needed-release tag with verification-failed-release. Add a comment describing steps taken and issues encountered.

An update is considered verified if it has at least two positive and no negative testimonials. If you're affected by a bug that is going through SRU verification, please join in and provide your feedback on the fix.

Wait for the SRU team to release the package to the -updates pocket

Once an uploaded package has met the 7-day minimum wait and has been verified, it is eligible to be reviewed and released by the SRU team. Again, this can sometimes take more than 7 days, but if it seems to be running unusually long, add a comment (but please don't spam us) on the bug report to check in.

Finally, updates are phased, which means that a release package update may not show for a few days. Assuming there are no significant regressions that cause the update to be halted, the update should be available soon. Please be patient and respect that this process is designed to keep your computer running smoothly.

Wrapping Up

While not an exciting topic, I hope this helped to provide some insight into the inner workings of a stable Xubuntu release. Let me know if you have any questions or if I got something wrong. If you're working on another Ubuntu flavor or derivative, what's the post-development release process look like for your team?

First Steps with elementary Development

First Steps with elementary Development

Nearly two weeks have passed since I announced that I would be exploring development on elementary OS. I had more positive feedback than I expected, so thanks everybody for your awesome support! Since the announcement, I've been getting my feet wet with a few different elementary-related projects, and I think I'm starting to get the hang of things.

Wingpanel Ayatana Indicator

I've long been a fan of indicators, the modern replacement for Systray icons. Fewer apps are using Systray these days, and it has been deprecated across several desktops and toolkits. Replacing the Systray are AppIndicators (of the Ubuntu and Ayatana variety) and StatusNotifierItems. These have pretty wide support and are commonly used by messaging apps (Discord, Slack, Telegram) and cloud syncing apps (Dropbox, pCloud, SyncThing).

Adding support for elementary 6 "Odin"

Odin Support by bluesabre · Pull Request #16 · Lafydev/wingpanel-indicator-ayatana
This branch adds support for elementary 6 Odin and updates the Debian packaging to a recent standard. Since this branch updates the dependencies to the latest Wingpanel and Granite, it's not co...
First Steps with elementary Development

With a few development library updates, the existing version of the indicator did not support the upcoming Odin release. After a bit of hacking and experimentation, I got the package working fully. Check out the above pull request in case you need to get your indicator fix. In a less useful update, I also refreshed the packaging for elementary 5 "Hera".

Files: Tabular numbers in the file transfer dialog

Use tabular numbers in file transfer dialog · Issue #1567 · elementary/files
Problem When a file is being transferred, the string showing the progress jitters all over the place due to the differing widths of the numbers. progress.mp4 Proposal We use tabular numbers in the ...
First Steps with elementary Development

I found this issue while browsing the Bitesize Issues found in the Desktop Development section of elementary's Get Involved page. Tabular numbers would prevent the file transfer dialog from jumping around, which seemed like a nice improvement. With the referenced code example, I was able to quickly identify the needed changes and get my hands dirty with a bit of Vala. After a code review and a small tweak, my pull request was merged!

Wingpanel Sound Indicator

After browsing the various projects and open issues, I became interested in hacking on the Wingpanel Sound Indicator. On the Xfce side, I've maintained the Xfce PulseAudio Plugin and Parole Media Player for quite some time and have some relevant experience to apply with MPRIS and DBus.

Fixing Spotify's missing artwork

Spotify album art stopped showing · Issue #145 · elementary/wingpanel-indicator-sound
I don’t really know why, but about a week ago the sound indicator stopped showing the album art from the currently playing music. But still works fine on notifications for example.
First Steps with elementary Development

When I'm at my computer, I've always got Spotify playing in the background. Having the album artwork in the sound indicator is a nice touch, so I wanted to dig in and see if I could land a fix. Using DFeet, I was able to get the URL Spotify was sending, found it was returning a 404 response, and ultimately came across this post on the Spotify Community about the invalid URL.

I threw together a simple pull request to replace the invalid URL with a currently known working one (Vala makes this super simple) and sent it along. A couple of the elementary developers quickly responded with some valid feedback, including the simple fact that Spotify needs to fix their own app. If any Spotify developers are reading... please? :)

Bluetooth audio devices listed as music players

Bluetooth audio device listed as music player? · Issue #89 · elementary/wingpanel-indicator-sound
One of my bluetooth headphones is listed as if it's a music player in the sound indicator: It's also listed as monitor by PulseAudio volume control: But, my other bluetooth device is also l...
First Steps with elementary Development

The Wingpanel Sound Indicator conveniently shows available media players, phones, and other devices that can be controlled via MPRIS. A device I didn't expect to see in the list was my Bluetooth headphones! Unsurprisingly, the media controls didn't have any effect on my headphones.

First Steps with elementary Development
One of these things is not like the other.

I did some more digging in DFeet, but the most useful property I could find was that this player uses the audio-card icon. I tracked down the icon-related code in bluez and used that as the basis for a new issue:

org.bluez.MediaPlayer1 interface available for bluetooth headphones · Issue #106 · bluez/bluez
The org.bluez.MediaPlayer1 interface seems to be made available for bluetooth headphones, including my "Air by AfterShokz". However, this interface doesn't do anything and doesn't...
First Steps with elementary Development

Here's hoping that one can get fixed upstream! If not, I'll continue exploring options for hiding this device in the Sound Indicator.

What's next?

I'm having fun exploring the elementary code and issue trackers, and I think I'll be able to make some meaningful contributions to be project. I may spend a bit more time on the Wingpanel Sound Indicator before getting more out of my comfort zone with some larger projects. I've also got some updates coming for Xubuntu in the next couple of days, so watch my blog and Twitter for updates.

In case you'd like to join in, I recommend checking out the Get Involved page for ways to contribute. Additionally, elementary announced yesterday that they did not get accepted into the Google Summer of Code this year, but shared a list of potential projects to work on. There's some pretty substantial projects listed here, so if you're looking for something to do, this seems like a good opportunity.