Agreguesi i feed

Octave is a numerical computing environment largely compatible with MATLAB. As free software, Octave runs on GNU/Linux, macOS, BSD, and Windows. At the 2019 Snapcraft Summit, Mike Miller and Jordi Gutiérrez Hermoso of the Octave team worked on creating an Octave snap in stable and beta versions for the Snap Store. 

As Mike and Jordi explained, “Octave is currently packaged for most of the major distributions, but sometimes it’s older than we would like.” The goal of the Octave snap was to allow users to easily access the current stable release of the software, independently of Linux distribution release cycles. A snap would also let them release Octave on distributions not covered so far.

Before starting with snaps, Octave depended on distribution maintainers, including those of CentOS, Debian, Fedora, and Ubuntu, for its binary packaging. With snaps, the situation has improved. The Octave team can now push out a release as soon as it ready for users eager to get it now, while other more conservative users wait for more traditional packages from their distribution. Mike and Jordi envisioned this to be the biggest benefit of coming to the Summit and creating an Octave snap.

They also foresee a reduction in the amount of maintenance needed, using one package across many Linux distributions. The Snap Store will help users discover Octave easier while the Octave homepage will also feature snaps as a download option.

Nevertheless, there was a learning curve: “We’re more used to Debian packaging, and snap packaging has different quirks that we’re not used to,” comments Jordi. In the first day of their snap creation, it took time to set up the environment and getting an initial build to work. “Time was needed for recompiling Octave each time with fixes for re-testing, as the application is large and has many dependencies, all of which must be compiled,” explains Mike. 

The Octave team used Multipass on Linux to help build their snap and found that they “didn’t even notice it was there” for the most part. As Mike explains, “I had no issues other than a couple of teething problems due to the large build that Octave requires. However, after a little bit of digging in the documentation and asking the right people this was soon solved.”  

Advice that they would pass on to others about using snaps is to avoid thinking that they are the same as containers. Mike and Jordi speak from experience because they started with this preconception as they explain, “this made it difficult because everything we did in the build environment had to be readjusted once we wanted to go into the runtime environment. We had to change the paths of everything.” Some functions that happened automatically in other packaging methods, like including libraries according to dependencies, must also be done manually for snaps.

Coming to an event like the Summit is another tip that they would give to would-be snap developers. As Mike and Jordi put it, “reading the documentation and doing this ourselves would have taken longer than having everyone here. The fact we can just walk around and say hey, how do we do this and get that help.”

Install Octave as a snap here.

The post Octave turns to snaps to reduce dependency on Linux distribution maintainers appeared first on Ubuntu Blog.

Illustration by Guweiz

As I entered the Facility, I could see Nicole sitting on a folding chair and tapping away frantically on her Gemini PDA, in what looked like a very temporary desk setup.

“That looks very uncomfortable!” I remarked.

She didn’t reply, but I didn’t expect a reply. She was clearly too busy and in a rush to get stuff done. Why all the clickety-clack, wasn’t the phone team around, just inside? Oh, she must be dealing with suppliers.

I moved past the tiny entrance lobby and into a slightly larger mess hall where I saw a bunch of people spread around the room, near tables hugging the walls, and having a gathering that seemed a bit like a hackfest “breakroom” discussion, with various people from the outside. At one of the tables, over what seemed like a grid of brainstorming papers, I saw Kat, who was busy with three other people, planning some sort of project sprint.

“Are you using Scrum?” I prompted.

“I am, but I don’t think they are” she answered, heads down in preparation work to assemble a team.

While I was happy to see her familiar face, her presence struck me as odd; what would Kat, a Collabora QA team lead, be doing managing community folks on-site at a Purism facility in California? I would have thought Heather (Purism’s phone project manager) would be around, but I didn’t see her or other recognizeable members of the team. Well, probably because I was just passing through a crowd of 20 people spread on tables around a lobby area—a transitional space—set up as an ad-hoc workshop. One of the walls had big windows that let me see into a shipping area and actual meeting rooms. I went to the meeting rooms.

As I entered a rectangular, classroom-like area, I found a hackfest—or rather a BoF session—taking place. In one of the table rows, I was greeted by Zeeshan Ali and Christian Hergert, who were having some idle chat.

As I shook their hands I said, “Hello old friends! Long time no see! Too bad this isn’t real.”

“How do you know this is not real?” Christian replied.

I slapped myself in the face, loudly, a couple of times. “Well,” I said, “even though these slaps feel fairly real, I’m pretty sure that’s just my mind playing a trick on me.”

I knew I was inside a mind construct, because I didn’t know the purpose of my visit nor how I’d got here… I knew I didn’t have the luxury to be flying across the continent on my own to leisurely walk into a hackfest I had no preparation for, and I knew Purism weren’t the ones paying for my trip: they no longer were my client since my last visit at the beginning of the summer.

Christian & Zeeshan were still looking at me, as if waiting to confirm I was lucid enough.

“The matrix isn’t that good,” I sighed.

A couple of seconds later, my eyes opened and I woke up. Looking at the bedside clock, it was 4:45 AM.

“Ugh, I hate to be right sometimes.”

Epilogue

It had been quite a long time since I last had a lucid dream, so I jotted this one down for further analysis. After all, good ol’ Sigmund always said,

“The interpretation of dreams is the royal road to a knowledge of the unconscious activities of the mind.”

…and lo, the dream I had that night was very much fashioned upon the context I have found myself in recently. Having been recently freed from an all-consuming battlefront, I can now take a step back to reposition myself, clear the fog and enjoy the summer after the last seven months of gray and gloomy weather. The coïncidences and parallels to be drawn—between the weather, this dream, and reality—are so many, it’s uncanny.

It is much like a reawakening indeed.

As I looked at all this today, I thought it would make a great introduction for me to resume blogging more regularly. And, well, it’s a fun story to share.

Resurfacing

This summer, as I now have some “personal R&D” time for the first time in many years, I am taking the opportunity to get back on track regarding many aspects of my digital life:

• sorting out and cleaning up data from various projects;
• getting back to “Inbox Zero”;
• upgrading my software & personal systems;
• reviewing my processes & tools for greater efficiency and effectiveness;
• taking care of my web infrastructure and online footprint.

As part of this R&D phase, I hope to drain the swamp and start blogging again. Here’s the rough roadmap of what I plan to be writing about:

1. a statement of availability for hire (or as a friend once said to me in 2014 on the verge of a crowdfunding campaign: “Where have all the cowboysgood managers gone?“);
2. a retrospective on “What the hell have I been up to for the last few years”;
3. maybe some stories of organizations outside GNOME or the IT industry, for variety;
4. lifehacks and technical discoveries I’ve found in that time;
5. personal productivity tips & food for thought.

If I get to #3, 4, 5 in the coming months, I’ll consider that pretty good. And if there’s something you’d really like to see me write about in particular, feel free to contact me.

The post Awakening from the lucid dream appeared first on The Open Sourcerer.

The Dell Wireless 5821e module is a Qualcomm SDX20 based LTE Cat16 device. This modem can work in either MBIM mode or QMI mode, and provides different USB layouts for each of the modes. In Linux kernel based and Windows based systems, the MBIM mode is the default one, because it provides easy integration with the OS (e.g. no additional drivers or connection managers required in Windows) and also provides all the features that QMI provides through QMI over MBIM operations.

The firmware update process of this DW5821e module is integrated in your GNU/Linux distribution, since ModemManager 1.10.0 and fwupd 1.2.6. There is no official firmware released in the LVFS (yet) but the setup is completely ready to be used, just waiting for Dell to publish an initial official firmware release.

The firmware update integration between ModemManager and fwupd involves different steps, which I’ll try to describe here so that it’s clear how to add support for more devices in the future.

1) ModemManager reports expected update methods, firmware version and device IDs

The Firmware interface in the modem object exposed in DBus contains, since MM 1.10, a new UpdateSettings property that provides a bitmask specifying which is the expected firmware update method (or methods) required for a given module, plus a dictionary of key-value entries specifying settings applicable to each of the update methods.

In the case of the DW5821e, two update methods are reported in the bitmask: “fastboot” and “qmi-pdc“, because both are required to have a complete firmware upgrade procedure. “fastboot” would be used to perform the system upgrade by using an OTA update file, and “qmi-pdc” would be used to install the per-carrier configuration files after the system upgrade has been done.

The list of settings provided in the dictionary contain the two mandatory fields required for all devices that support at least one firmware update method: “device-ids” and “version”. These two fields are designed so that fwupd can fully rely on them during its operation:

• The “device-ids” field will include a list of strings providing the device IDs associated to the device, sorted from the most specific to the least specific. These device IDs are the ones that fwupd will use to build the GUIDs required to match a given device to a given firmware package. The DW5821e will expose four different device IDs:
  • “USB\VID_413C“: specifying this is a Dell-branded device.
  • “USB\VID_413C&PID_81D7“: specifying this is a DW5821e module.
  • “USB\VID_413C&PID_81D7&REV_0318“: specifying this is hardware revision 0x318 of the DW5821e module.
  • “USB\VID_413C&PID_81D7&REV_0318&CARRIER_VODAFONE“: specifying this is hardware revision 0x318 of the DW5821e module running with a Vodafone-specific carrier configuration.
• The “version” field will include the firmware version string of the module, using the same format as used in the firmware package files used by fwupd. This requirement is obviously very important, because if the format used is different, the simple version string comparison used by fwupd (literally ASCII string comparison) would not work correctly. It is also worth noting that if the carrier configuration is also versioned, the version string should contain not only the version of the system, but also the version of the carrier configuration. The DW5821e will expose a firmware version including both, e.g. “T77W968.F1.1.1.1.1.VF.001” (system version being F1.1.1.1.1 and carrier config version being “VF.001”)
• In addition to the mandatory fields, the dictionary exposed by the DW5821e will also contain a “fastboot-at” field specifying which AT command can be used to switch the module into fastboot download mode.

2) fwupd matches GUIDs and checks available firmware versions

Once fwupd detects a modem in ModemManager that is able to expose the correct UpdateSettings property in the Firmware interface, it will add the device as a known device that may be updated in its own records. The device exposed by fwupd will contain the GUIDs built from the “device-ids” list of strings exposed by ModemManager. E.g. for the “USB\VID_413C&PID_81D7&REV_0318&CARRIER_VODAFONE” device ID, fwupd will use GUID “b595e24b-bebb-531b-abeb-620fa2b44045”.

fwupd will then be able to look for firmware packages (CAB files) available in the LVFS that are associated to any of the GUIDs exposed for the DW5821e.

The CAB files packaged for the LVFS will contain one single firmware OTA file plus one carrier MCFG file for each supported carrier in the give firmware version. The CAB files will also contain one “metainfo.xml” file for each of the supported carriers in the released package, so that per-carrier firmware upgrade paths are available: only firmware updates for the currently used carrier should be considered. E.g. we don’t want users running with the Vodafone carrier config to get notified of upgrades to newer firmware versions that aren’t certified for the Vodafone carrier.

Each of the CAB files with multiple “metainfo.xml” files will therefore be associated to multiple GUID/version pairs. E.g. the same CAB file will be valid for the following GUIDs (using Device ID instead of GUID for a clearer explanation, but really the match is per GUID not per Device ID):

• Device ID “USB\VID_413C&PID_81D7&REV_0318&CARRIER_VODAFONE” providing version “T77W968.F1.2.2.2.2.VF.002”
• Device ID “USB\VID_413C&PID_81D7&REV_0318&CARRIER_TELEFONICA” providing version “T77W968.F1.2.2.2.2.TF.003”
• Device ID “USB\VID_413C&PID_81D7&REV_0318&CARRIER_VERIZON” providing version “T77W968.F1.2.2.2.2.VZ.004”
• … and so on.

Following our example, fwupd will detect our device exposing device ID “USB\VID_413C&PID_81D7&REV_0318&CARRIER_VODAFONE” and version “T77W968.F1.1.1.1.1.VF.001” in ModemManager and will be able to find a CAB file for the same device ID providing a newer version “T77W968.F1.2.2.2.2.VF.002” in the LVFS. The firmware update is possible!

3) fwupd requests device inhibition from ModemManager

In order to perform the firmware upgrade, fwupd requires full control of the modem. Therefore, when the firmware upgrade process starts, fwupd will use the new InhibitDevice(TRUE) method in the Manager DBus interface of ModemManager to request that a specific modem with a specific uid should be inhibited. Once the device is inhibited in ModemManager, it will be disabled and removed from the list of modems in DBus, and no longer used until the inhibition is removed.

The inhibition may be removed by calling InhibitDevice(FALSE) explicitly once the firmware upgrade is finished, and will also be automatically removed if the program that requested the inhibition disappears from the bus.

4) fwupd downloads CAB file from LVFS and performs firmware update

Once the modem is inhibited in ModemManager, fwupd can right away start the firmware update process. In the case of the DW5821e, the firmware update requires two different methods and two different upgrade cycles.

The first step would be to reboot the module into fastboot download mode using the AT command specified by ModemManager in the “at-fastboot” entry of the “UpdateSettings” property dictionary. After running the AT command, the module will reset itself and reboot with a completely different USB layout (and different vid:pid) that fwupd can detect as being the same device as before but in a different working mode. Once the device is in fastboot mode, fwupd will download and install the OTA file using the fastboot protocol, as defined in the “flashfile.xml” file provided in the CAB file:

<parts interface="AP"> <part operation="flash" partition="ota" filename="T77W968.F1.2.2.2.2.AP.123_ota.bin" MD5="f1adb38b5b0f489c327d71bfb9fdcd12"/> </parts>

Once the OTA file is completely downloaded and installed, fwupd will trigger a reset of the module also using the fastboot protocol, and the device will boot from scratch on the newly installed firmware version. During this initial boot, the module will report itself running in a “default” configuration not associated to any carrier, because the OTA file update process involves fully removing all installed carrier-specific MCFG files.

The second upgrade cycle performed by fwupd once the modem is detected again involves downloading all carrier-specific MCFG files one by one into the module using the QMI PDC protocol. Once all are downloaded, fwupd will activate the specific carrier configuration that was previously active before the download was started. E.g. if the module was running with the Vodafone-specific carrier configuration before the upgrade, fwupd will select the Vodafone-specific carrier configuration after the upgrade. The module would be reseted one last time using the QMI DMS protocol as a last step of the upgrade procedure.

5) fwupd removes device inhibition from ModemManager

The upgrade logic will finish by removing the device inhibition from ModemManager using InhibitDevice(FALSE) explicitly. At that point, ModemManager would re-detect and re-probe the modem from scratch, which should already be running in the newly installed firmware and with the newly selected carrier configuration.

                                        

Pitivi is an open source video editing software for Linux. It provides creatives with a simple and elegant interface to edit and bring their videos to realisation. As with every other great software, Pitivi’s development community is always striving to add newer and better features. This year I participated in the Google Summer of Code to add the ‘Nesting’ Feature to the platform. I am currently working on this with my mentor Thiblahute Saunier. In this blog I chart out our current progress and the future tasks at hand.

Nesting Clips:

With nesting users can combine a series of sequences into a master clip. This master clip can be edited on like a normal clip, while simultaneously providing users the ability to go into the master clip’s timeline and make changes. This will help them to organise the timeline, enable re-usability of sequences and provide a richer user experience. 

Nesting in Adobe Premiere Pro

(Here is a link to better understand Nesting: https://www.youtube.com/watch?v=A8Aw53JBLZY )

For the past weeks we have been working on the back-end, Gstreamer Editing Services(GES) to implement nesting of clips in a timeline. Earlier with ges-launch-1.0 we could create a timeline, load several clips to it with +clip , add effects to them +effect, set it’s property etc, now with ges-launch-1.0 .xges file can be used as source and nested timelines can be created.

(Here is a link to ges-launch-1.0 documentation: https://gstreamer.freedesktop.org/documentation/tools/ges-launch.html?gi-language=c#)

So while nesting in Pitivi, the idea is to create a new timeline, copy and paste the selected clips in this timeline, remove them from the main timeline and finally add the new timeline to the main timeline.

Now .xges file can be used as source and nested timelines can be created. So while nesting in Pitivi the idea is to create a new timeline, copy and paste the selected clips in this timeline, remove them from the main timeline and finally add the new timeline to the main timeline.

Testing:

gst-validate-launcher is used to create test suites to test the behavior of the created pipelines and test the user actions as described in the .scenario files.

(Here is the link to gst-validate-launcher documentation: https://gstreamer.freedesktop.org/documentation/gst-devtools/gst-validate-launcher.html?gi-language=c )

I have been busy implementing tests and writing scenarios for nesting. The test suite is working properly. For playback.nested tests, ges-launch-1.0 +clip is used to add the .xges file to the timeline instead of -l. Thanks to Thiblahute, most of the tests are passing successfully. So now ‘gst-validate-launcher ges’ generates and runs through the tests for Nesting.

The scenarios seek on nested timelines and check whether the outputted frame is correct. To be specific, they load a clip, serialize it in a .xges file, resulting in a nested timeline. It then loads the .xges file, seeks and checks the frame while moving them around in the layers and adding effects to the nested timeline. Basically, they emulate a user’s actions. Currently I am wrapping up a few scenarios.

The journey ahead:

The next part of the project will involve in the implementation and user interface of nesting in Pitivi. I had some ideas about the interface which I suggested in my proposal but we will be having rigorous discussions and decide the final interface.

My experience working in Pitivi:

In the past few weeks I’ve learnt and improved a lot. In the beginning I was a bit reserved and shy to tell my problems but after talking and getting to know my mentor, I think I’ve overcome that fear. The guidance of my mentor has been crucial in this journey. Until now he has done all of the heavy-lifting for the back-end all the while helping me to get up to speed. Hopefully now I will be able to take the reins and at the same time be able to learn more from him. I look forward to an amazing summer and the work we have in front of us.

What are constraints

At its most basic, a constraint is a relation between two values. The relation
can be described as a linear equation:

target.attribute = source.attribute × multiplier + constant

For instance, this:

Can be described as:

blue.start = red.end × 1.0 + 8.0

Or:

• the attribute, “start”, of the target, “blue”, which is going to be set by the constraint; this is the left hand side of the equation
• the relation between the left and right hand sides of the equation, in this case equality; relations can also be greater than or equal to,
  and less than or equal to
• the attribute, “end”, of the source, “red”, which is going to be read by the constraint; this is the right hand side of the equation
• the multiplier, “1.0”, applied to the attribute of the source
• the constant, “8.0”, an offset added to the attribute

A constraint layout is a series of equations like the one above, describing all the relationships between the various parts of your UI.

It’s important to note that the relation is not an assignment, but an equality (or an inequality): both sides of the equation will be solved in a way that satisfies the constraint; this means that the list of constraints can be rearranged; for instance, the example above can be rewritten as:

red.end = blue.start × 1.0 - 8.0

In general, for the sake of convenience and readability, you should arrange your constraints in reading order, from leading to trailing edge, from top to bottom. You should also favour whole numbers for multipliers, and positive numbers for constants.

Solving the layout

Systems of linear equations can have one solution, multiple solutions, or even no solution at all. Additionally, for performance reasons, you don’t really want to recompute all the solutions every time.

Back in 1998, the Cassowary algorithm for solving linear arithmetic constraints was published by Greg J. Badros and Alan Borning, alongside its implementation in C++, Smalltalk, and Java. The Cassowary algorithm tries to solve a system of linear equations by finding its optimal solution; additionally, it does so incrementally, which makes it very useful for user interfaces.

Over the past decade various platforms and toolkits started providing layout managers based on constraints, and most of them used the Cassowary algorithm. The first one was Apple’s AutoLayout, in 2011; in 2016, Google added a ConstraintLayout to the Android SDK.

In 2016, Endless implemented a constraint layout for GTK 3 in a library called Emeus. Starting from that work, GTK 4 now has a GtkConstraintLayout layout manager available for application and widget developers.

The machinery that implements the constraint solver is private to GTK, but the public API provides a layout manager that you can assign to your GtkWidget class, and an immutable GtkConstraint object that describes each constraint you wish to add to the layout, binding two widgets together.

Guiding the constraints

Constraints use widgets as sources and targets, but there are cases when you want to bind a widget attribute to a rectangular region that does not really draw anything on screen. You could add a dummy widget to the layout, and then set its opacity to 0 to avoid it being rendered, but that would add unnecessary overhead to the scene. Instead, GTK provides GtkConstraintGuide, and object whose only job is to contribute to the layout:

In the example above, only the widgets marked as “Child 1” and “Child 2” are going to be visible, while the guide is going to be an empty space.

Guides have a minimum, natural (or preferred), and maximum size. All of them are constraints, which means you can use guides not just as helpers for alignment, but also as flexible spaces in a layout that can grow and shrink.

Describing constraints in a layout

Constraints can be added programmatically, but like many things in GTK, they can also be described inside GtkBuilder UI files, for convenience. If you add a GtkConstraintLayout to your UI file, you can list the constraints and guides inside the special “<constraints>” element:

<object class="GtkConstraintLayout"> <constraints> <constraint target="button1" target-attribute="width" relation="eq" source="button2" source-attribute="width" /> <constraint target="button2" target-attribute="start" relation="eq" source="button1" source-attribute="end" constant="12" /> <constraint target="button1" target-attribute="start" relation="eq" source="super" source-attribute="start" constant="12" /> <constraint target="button2" target-attribute="end" relation="eq" source="super" source-attribute="end" constant="-12"/> </constraints> </object>

You can also describe a guide, using the “<guide>” custom element:

<constraints> <guide min-width="100" max-width="500" /> </constraints> Visual Format Language

Aside from XML, constraints can also be described using a compact syntax called “Visual Format Language”. VFL descriptions are row and column oriented: you describe each row and column in the layout using a line that visually resembles the layout you’re implementing, for instance:

|-[findButton]-[findEntry(<=250)]-[findNext][findPrev]-|

Describes an horizontal layout where the findButton widget is separated from the leading edge of the layout manager by some default space, and followed by the same default amount of space; then by the findEntry widget, which is meant to be at most 250 pixels wide. After the findEntry widget we have some default space again, followed by two widgets, findNext and findPrev, flush one against the other; finally, these two widgets are separated from the trailing edge of the layout manager by the default amount of space.

Using the VFL notation, GtkConstraintLayout will create all the required constraints without necessarily having to describe them all manually.

It’s important to note that VFL cannot describe all possible constraints; in some cases you will need to create them using GtkConstraint’s API.

Limits of a constraint layout

Constraint layouts are immensely flexible because they can implement any layout policy. This flexibility comes at a cost:

• your layout may have too many solutions, which makes it ambiguous and unstable; this can be problematic, especially if your layout is very complex
• your layout may not have any solution. This is usually the case when you’re not using enough constraints; a rule of thumb is to use at least two constraints per target per dimension, since all widgets should have a defined position and size
• the same layout can be described by different series of constraints; in some cases it’s virtually impossible to say which approach is better, which means you will have to experiment, especially when it comes to layouts that dynamically add or remove UI elements, or that allow user interactions like dragging UI elements around

Additionally, at larger scales, a local, ad hoc layout manager may very well be more performant than a constraint based one; if you have a list box that can grow to an unknown amount of rows you should not replace it with a constraint layout unless you measure the performance impact upfront.

Demos

Of course, since we added this new API, we also added a few demos to the GTK Demo application:

The constraints demo window, as part of the GTK demo application.

As well as a full constraints editor demo:

A screenshot of the GTK constraints editor demo application, showing the list of UI elements, guides, and constraints in a side bar on the left, and the result on the right side of the window More information

• The Cassowary constraint solving toolkit, which links the various papers and implementations.
• Emeus, a Cassowary implementation for GTK 3

I am preparing the 2.46.0 librsvg release. This will no longer have the rsvg-view-3 program.

History of rsvg-view

Rsvg-view started out as a 71-line C program to aid development of librsvg. It would just render an SVG file to a pixbuf, stick that pixbuf in a GtkImage widget, and show a window with that.

Over time, it slowly acquired most of the command-line options that rsvg-convert supports. And I suppose, as a way of testing the Cairo-ification of librsvg, it also got the ability to print SVG files to a GtkPrintContext. At last count, it was a 784-line C program that is not really the best code in the world.

What makes rsvg-view awkward?

Rsvg-view requires GTK. But GTK requires librsvg, indirectly, through gdk-pixbuf! There is not a hard circular dependency because GTK goes, "gdk-pixbuf, load me this SVG file" without knowing how it will be loaded. In turn, gdk-pixbuf initializes the SVG loader provided by librsvg, and that loader reads/renders the SVG file.

Ideally librsvg would only depend on gdk-pixbuf, so it would be able to provide the SVG loader.

The rsvg-view source code still has a few calls to GTK functions which are now deprecated. The program emits GTK warnings during normal use.

Rsvg-view is... not a very good SVG viewer. It doesn't even start up with the window scaled properly to the SVG's dimensions! If used for quick testing during development, it cannot even aid in viewing the transparent background regions which the SVG does not cover. It just sticks a lousy custom widget inside a GtkScrolledWindow, and does not have the conventional niceties to view images like zooming with the scroll wheel.

EOG is a much better SVG viewer than rsvg-view, and people actually invest effort in making it pleasant to use.

Removal of rsvg-view

So, the next version of librsvg will not provide the rsvg-view-3 binary. Please update your packages accordingly. Distros may be able to move the compilation of librsvg to a more sensible place in the platform stack, now that it doesn't depend on GTK being available.

What can you use instead? Any other image viewer. EOG works fine; there are dozens of other good viewers, too.

Some good news for anyone who might read this. In the Canonical desktop team we’re hiring a new Software Engineer.

More details in the job description, but if you’re looking for an opportunity that lets you:

• work remotely
• work on GNOME and related desktop technologies (both upstream and downstream!)
• help to ship a solid Ubuntu every 6 months
• work with smart people
• have the opportunity to travel to, and present at, conferences and internal events

then please apply. You do not need to already be a GNOME or a Ubuntu/Debian expert to apply for this position – you’ll be given a mentor and plenty of time and support to learn the ropes.

Please feel free to contact me on IRC (Laney on all the best networks) / email (iain.lane@canonical.com) / Telegram (@lan3y) if you’re considering an application and you’d like to chat about it.