The openSUSE.Asia Summit is an annual openSUSE conference in Asia and a great opportunity for contributors and enthusiasts from Asia to come together and meet face-to-face. The event focuses primarily on the openSUSE distribution, its applications for personal and enterprise use, and open source culture.

In its quest to spread openSUSE throughout Asia, openSUSE.Asia Summit Organization Committee seeks out local communities to rise to the challenge of organizing an excellent openSUSE event in 2025. The committee stands ready to assist you throughout the process.

Here is the date you need to take notes:

• Oct. 1: Deadline for application
• Nov. 3: Presentation at openSUSE.Asia Summit 2024
• Dec. 23: Announcement of the following host

We will invite you to our regular online meetings so that you can experience and learn how to organize the event. Furthermore, we will ask you to present your proposals at the next summit in Tokyo, Japan.

The submitted proposals are to be reviewed by the organization committee. During the review, the committee might have additional questions and requests.

How to Submit?

Please email your proposal to both summit@lists.opensuse.org and opensuseasia-summit@googlegroups.com. Because the former address does not allow attachments, you need to upload your proposal somewhere and share the link to it.

The proposal should contain:

• Venue
• How to reach your city and venue
• Budget Estimation
  • Conference Venue
  • T-shirt
  • Tea break, Lunch, Dinner, Conference Tour, etc.
• Introduction to your community who will organize the summit

Please refer to openSUSE.Asia Summit Tips for Organizers before writing your proposal.

We are looking forward to hearing from you soon!

A new major version of Leap Micro is now available!  Leap Micro 6.0 images can be found at get.opensuse.org.

Leap Micro 6.0 uses a brand-new codebase, comes with plenty of new appliances and, for the first time, enters images for public cloud.

About Leap Micro

Leap Micro 6.0 is a rebranded SUSE Linux Enterprise Micro 6.0 which is an ultra-reliable container and Virtual Machine host by SUSE. Leap Micro is released twice a year and has support over two releases.

Leap Micro 5.4 is now EOL

With the release of Leap Micro 6.0, Leap Micro 5.4 reaches End Of Life; users will no longer receive maintenance updates and are advised to upgrade.

More conservative users can stay on Leap Micro 5.5, which will receive updates until the release of Leap Micro 6.1.

Understanding Image variants

All of Leap and SLE Micro generally come in two variants either Base or Default.

Both Base and Default have a container stack, but only the Default variant has the Virtual Machine stack.

If you do not plan to use VMs and you care for space, then the Base might be a variant just for you. 

All of our images offered at get-o-o are the Default ones (VMs+containers) as we expect they’re suitable for most users.

All appliances including Base variants (without virtualization stack) can be downloaded directly from https://download.opensuse.org/distribution/leap-micro/6.0/appliances/

Explaining individual appliances

A general recommendation for everyone use is the self-install image. It’s a bootable image with a quick wizard that writes the preconfigured image to your drive and grows the root partition. This process from boot takes about 5 minutes.

The preconfigured image is a raw bootable image you can manually write/dd to the disk or SD card. Images can be configured via Ignition/Combustion or will default to the jeos-firsboot wizard.

We have a Real-time image with kernel-rt, qcow image for KVM, VMWare image, and a brand new raw image with Full Disk Encryption.

Users who want to try our FDE image within a VM will need to make sure that they’re using emulated tpm-2 chip and UEFI. This can be achieved easily with virt-manager.

SLE Micro 6.0 dropped the traditional installer in favor of self-install media, therefore Leap Micro 6.0 doesn’t have it either.

The new Packages image is not a bootable media. This is just an image with an offline repository in case you need it.

Leap Micro 6.0 comes for the first time also with Public Cloud Images.

Images will soon be available with all major public cloud providers. 

Upgrading from 5.X

A recommendation is to make a clean install since this is a brand-new major version.

For those who’d like to try migration, please follow the upgrade guide.

Release Notes

Users can refer to SLE Micro 6.0 Release notes.

Leap Micro 6.0 uses openSUSE-repos for repository management. It is highly recommended to pay attention to this detail, especially for those who migrate. Here is an article explaining how openSUSE repos work.

Leap Micro 6.0 has no longer a dedicated SLE update repo. This has been merged into the main repository.

Last week I had the opportunity to speak at KCD Italy, a Kubernetes Community Days event. I delivered a talk titled “How to leverage and extend CEL for your cluster security”. The talk gives an overview about the Common Expression Language (CEL), Kubernetes ValidatingAdmissionPolicy, and Kubewarden.

While the talk has been delivered in Italian, the slides are in English and can be found here.

Since a few weeks ago, librsvg is now in oss-fuzz — Google's constantly-running fuzz-testing for OSS projects — and the crashes have started coming in. I'll have a lot more to say soon about crashes in Cairo, which is where the majority of the bugs are so far, but for now I want to tell you about a little bug I just fixed.

The fuzzer found a memory leak that happens when librsvg tries to parse an invalid XML document that has definitions for XML entities — the things that you normally reference like &foo; in the middle of the XML.

For example, this invalid document causes librsvg to leak:

<!DOCTYPEY[<!ENTITY a ''

Valgrind reports this:

$ valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
...
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==3750== 
==3750== HEAP SUMMARY:
==3750==     in use at exit: 78,018 bytes in 808 blocks
==3750==   total heap usage: 1,405 allocs, 597 frees, 205,161 bytes allocated
==3750== 
==3750== 247 (144 direct, 103 indirect) bytes in 1 blocks are definitely lost in loss record 726 of 750
==3750==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3750==    by 0x4BD857F: xmlCreateEntity (entities.c:158)
==3750==    by 0x4BD932B: xmlNewEntity (entities.c:451)
==3750==    by 0x2EBC75: rsvg::xml::xml2_load::sax_entity_decl_cb (xml2_load.rs:152)
==3750==    by 0x4BED6D8: xmlParseEntityDecl (parser.c:5647)
==3750==    by 0x4BEF4F3: xmlParseMarkupDecl (parser.c:7024)
==3750==    by 0x4BEFB95: xmlParseInternalSubset (parser.c:8558)
==3750==    by 0x4BF50E9: xmlParseDocument (parser.c:11072)
==3750==    by 0x2ED266: rsvg::xml::xml2_load::Xml2Parser::parse (xml2_load.rs:466)
==3750==    by 0x4A8C49: rsvg::xml::XmlState::parse_from_stream::{{closure}} (mod.rs:628)
==3750==    by 0x2ACA92: core::result::Result<T,E>::and_then (result.rs:1316)
==3750==    by 0x34D4E2: rsvg::xml::XmlState::parse_from_stream (mod.rs:627)
==3750== 
==3750== LEAK SUMMARY:
==3750==    definitely lost: 144 bytes in 1 blocks
==3750==    indirectly lost: 103 bytes in 3 blocks
==3750==      possibly lost: 0 bytes in 0 blocks
==3750==    still reachable: 73,947 bytes in 746 blocks
==3750==         suppressed: 0 bytes in 0 blocks

Let's see what happened.

The code in question

Even after the port to Rust, librsvg still uses libxml2 for parsing XML. So, librsvg has to deal with raw pointers incoming from libxml2 and it must do their memory management itself, since the Rust compiler doesn't know what to do with them automatically.

Librsvg uses the SAX parser, which involves setting up callbacks to process events like "XML element started", or "an entity was defined".

If you have a valid document that has entity definitions like these:

<!ENTITY foo "#aabbcc">
<!ENTITY bar "some text here">

Then libxml2's SAX parser will emit two events to instruct your code that it should define entities, one for foo and one for bar, with their corresponding content. Librsvg stores these in a hash table, since it has to be able to retrieve them later when the SAX parser requests it. In detail, libxml2 requires that you create an xmlEntityPtr by calling xmlNewEntity() and then keep it around.

xmlEntityPtr xmlNewEntity (xmlDocPtr      doc,
                           const xmlChar *name,
                           int            type,
                           const xmlChar *ExternalID,
                           const xmlChar *SystemID,
                           const xmlChar *content);

Later, you must free each of your stored entities with xmlFreeNode() (it supports different data types, including entities), or if you are using libxml2 2.12.0 or later, with xmlFreeEntity().

void xmlFreeNode (xmlNodePtr node);
void xmlFreeEntity (xmlEntityPtr entity);

Librsvg creates a SAX parser from libxml2, calls it to do the parsing, and then frees the entities at the end. In the following code, XmlState is the struct that librsvg uses to hold the temporary state during parsing: a partially-built XML tree, some counters on the number of loaded elements, the current element being processed, things like that. The build_document() method is called at the very end of XmlState's lifetime; it consumes the XmlState and returns either a fully-parsed and valid Document, or an error.

struct XmlState {
    inner: RefCell<XmlStateInner>,  // the mutable part

    // ... other immutable fields here
}

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    // ... a few fields for the partially-built XML tree, current element, etc.
    document_builder: DocumentBuilder,

    // Note that neither XmlStateInner nor Xmlstate implement Drop.
    //
    // An XmlState is finally consumed in XmlState::build_document(), and that
    // function is responsible for freeing all the XmlEntityPtr from this field.
    //
    // (The structs cannot impl Drop because build_document()
    // destructures and consumes them at the same time.)
    entities: HashMap<String, XmlEntityPtr>,
}

impl XmlState {
    fn build_document(
        self,
        stream: &gio::InputStream,
        cancellable: Option<&gio::Cancellable>,
    ) -> Result<Document, LoadingError> {
        // does the actual parsing with a libxml2 SAX parser
        self.parse_from_stream(stream, cancellable)?;

        // consume self, then consume inner, then consume document_builder by calling .build()
        let XmlState { inner, .. } = self;
        let mut inner = inner.into_inner();

        // Free the hash of XmlEntityPtr.  We cannot do this in Drop because we will
        // consume inner by destructuring it after the for() loop.
        for (_key, entity) in inner.entities.drain() {
            unsafe {
                xmlFreeNode(entity);
            }
        }

        let XmlStateInner {
            document_builder, ..
        } = inner;
        document_builder.build()
    }
}

There are many Rust-isms in this code.

• After doing the actual parsing with parse_from_stream(), self is destructured to consume it and extract its inner field, which is the actual mutable part of the XML loading state.

• The code frees each xmlEntityPtr stored in the hash table of entities.

• The inner value, which is an XmlStateInner, is destructured to extract the document_builder field, which gets asked to .build() the final document tree.

Where's the bug?

The bug is in this line at the beginning of the build_document() function:

        self.parse_from_stream(stream, cancellable)?;

The ? after the function call is to return errors to the caller. However, if there is an error during parsing, we will exit the function here, and it will not have a chance to free the values in the key-value pairs among the entities ! Memory leak!

This code had already gone through a few refactorings. Initially I had an impl Drop for XmlState which did the obvious thing of freeing the entities by hand:

impl Drop for XmlState {
    fn drop(&mut self) {
        unsafe {
            let mut inner = self.inner.borrow_mut();

            for (_key, entity) in inner.entities.drain() {
                // entities are freed with xmlFreeNode(), believe it or not
                xmlFreeNode(entity);
            }
        }
    }
}

But at one point, I decided to clean up the way the entire inner struct was to be handled, and decided to destructure it at the end of its lifetime, since that made the code simpler. However, destructuring an object means that you cannot have an impl Drop for it, since then some fields are individually moved out and some are not during the destructuring. So, I changed the code to free the entities directly into build_document() as above.

I missed the case where the parser can exit early due to an error.

The Rusty solution

Look again at how the entities hash table is declared in the struct fields:

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    entities: HashMap<String, XmlEntityPtr>,
}

That is, we are storing a hash table with raw pointers in the value part of the key-value pairs. Rust doesn't know how to handle those external resources, so let's teach it how to do that.

The magic of having an impl Drop for a wrapper around an unmanaged resource, like xmlEntityPtr, is that Rust will automatically call that destructor at the appropriate time — in this case, when the hash table is freed.

So, let's use a wrapper around XmlEntityPtr, and add an impl Drop for the wrapper:

struct XmlEntity(xmlEntityPtr);

impl Drop for XmlEntity {
    fn drop(&mut self) {
        unsafe {
            xmlFreeNode(self.0);
        }
    }
}

And then, let's change the hash table to use that wrapper for the values:

    entities: HashMap<String, XmlEntity>,

Now, when Rust has to free the HashMap, it will know how to free the values. We can keep using the destructuring code in build_document() and it will work correctly even with early exits due to errors.

Valgrind's evidence without the leak

# valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
==5855== Memcheck, a memory error detector
==5855== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==5855== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==5855== Command: ./target/debug/rsvg-convert leak.svg
==5855== 
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==5855== 
==5855== HEAP SUMMARY:
==5855==     in use at exit: 77,771 bytes in 804 blocks
==5855==   total heap usage: 1,405 allocs, 601 frees, 205,161 bytes allocated
==5855== 
==5855== LEAK SUMMARY:
==5855==    definitely lost: 0 bytes in 0 blocks
==5855==    indirectly lost: 0 bytes in 0 blocks
==5855==      possibly lost: 0 bytes in 0 blocks
==5855==    still reachable: 73,947 bytes in 746 blocks
==5855==         suppressed: 0 bytes in 0 blocks

Moral of the story

Resources that are external to Rust really work best if they are wrapped at the lowest level, so that destructors can run automatically. Instead of freeing things by hand when you think it's right, let the compiler do it automatically when it knows it's right. In this case, wrapping xmlEntityPtr with a newtype and adding an impl Drop is all that is needed for the rest of the code to look like it's handling a normal, automatically-managed Rust object.

Dear Tumbleweed users and hackers,

It’s the week before openSUSE Conference, when all through the world, contributors get ready to travel. People might be busy with their final preparations to meet at the conference next week, and prepare their slides for the talks, but nothing can stop them from keeping Tumbleweed rolling. This week, we have received 5 snapshots (0613, 0614, 0617, 0618, and 0619)

The most relevant updates included were:

• libxml 2.12.8
• Ruby 3.3.3
• VLC 3.0.21, see http://www.videolan.org/security/sb-vlc3021.html
• Mesa 24.0.9, 24.1.0 & 24.1.1: Mesa 24 brought some graphical glitches on AMD/.ATI graphic cards, which we could not catch in openQA. A (mostly) fixed version was published in the update channel to shorten the time)
• Mozilla Firefox 127.0
• KDE Gear 24.05.1
• Linux kernel 6.9.4 & 6.9.5

Staging projects are currently testing the integration of these changes:

• KDE Plasma 6.1
• NodeJS 22.3.0
• Perl 5.40.0
• transactional-update: enable soft reboot; see https://microos.opensuse.org/blog/2024-06-13-soft-reboot/
• Pytest 8.2
• dbus-broker: some networking issue after upgrades left to work out
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

With all this, I am looking forward to seeing many of you at the openSUSE conference in Nuremberg next week!

Leap 15.6 install media were refreshed to address an issue with old secure boot signing key for ppc64le and s390x.

Refreshed images from Leap 15.6 Build 710.3 are already available for download at get.opensuse.org. So now you can enjoy installation with secure boot on more exotic architectures.

Happy Hacking!

_{^{(Image made with DALL-E)}}

Here is a little gift for the weekend. openSUSE Leap Micro 6.0 RC is now available! Images can be found at get.opensuse.org.

The main difference from Beta is a working upgrade path from 5.5 and slightly smoother upgrade support to commercial products. So let’s test it out.

Upgrade instructions

I’d personally recommend a clean install, especially in between major versions on a system that can be redeployed with self-install within 2 minutes. At the same time, the online upgrade takes longer. Another aspect to consider is that we don’t have a developed migration test suite for online migration, unlike for Leap 15.X.

The easiest way to test the upgrade would be in a VM. Get Leap micro 5.5 images from get.opensuse.org and ensure you have all updates applied via transactional-update.

I’d recommend upgrading to 6.0 via SSH or console instead of cockpit, as the service might stop responding. Upgrade instructions and known issues are captured in the SDB:System_upgrade_to_LeapMicro_6.0 wiki page.

Make sure to check known issues before proceeding.

Documentation

Please refer to SLE Micro 6.0 documentation including Release notes.

Reporting Issues

Please refer to the Leap Micro section in our Submitting bug reports page.

Next steps

Leap Micro 6.0 GA can be expected before oSC2024 next week.

openSUSE Leap Micro 6.0 Beta is now available! We expect that it will very quickly transition to RC and GA as the infra readiness advances. Leap Micro 6.0 Beta images can be found at get.opensuse.org or directly at download.opensuse.org.

About Leap Micro

Leap Micro 6.0 is a rebranded SUSE Linux Enterprise Micro 6.0 which is an ultrareliable container and VM host by SUSE. This is the first publicly released product based on the fresh code base “SUSE Linux Framework One” (previously known as ALP).

Leap Micro 6.X is available for x86_64 and aarch64, released every 6 months, and supported until the next-next release is out. That means that Leap Micro 6.0 will become EOL once Leap Micro 6.2 gets released.

All pieces related to Rancher and Elemental are purposely excluded from Leap Micro 6.X as SLE Micro for Rancher is free for use without any subscription within Rancher deployments.

No more traditional installer

Leap Micro 6.X is deployed via self-install image which writes a preconfigured image to the disk and enlarges root partition. Users can use combustion, ignition or default to the jeos-firstboot wizard to do the initial setup of the system.

Do not get mistaken by the availability of openSUSE-Leap-Micro-6.0-*.iso is not installable. We refer to the image as a Packages image, which is basically an offline repository on a DVD.

New FDE, VMWare, and Cloud images

Aside from the self-install image Micro 6.0 comes with qcow, Full Disk Encryption, and RealTime images. All images can be found at download.opensuse.org

For the first time Leap Micro 6.X has also cloud-init therefore shortly after the release we will also have cloud images available on GCP, Azure, and AWS.

Changes to the product building

Leap Micro 6.X is using the new product composer instead of the old product builder. This allowed us to consume update-info from the newly designed maintenance workflow of SLE Micro 6.0 and was preferred by the openSUSE maintenance team.

Changes to the repositories and maintenance workflow

Leap Micro 5.X users receive all updates released for relevant SLE Micro version via a repository named repo-sle-update. This particular repository no longer exists in Leap Micro 6.X.

Instead, the repo-main repository will contain all released updates for the relevant version of SUSE Linux Micro to date.

Please note that the repository path slightly changed too, we’ll ensure that migration via transactional-update shell followed by zypper dup –releaser 6.0 works via compatibility symlinks on download server.

New way of managing repository definitions

openSUSE-repos is not new to our users, however, for the first time, openSUSE Leap Micro 6.0 deployments come with openSUSE-repos preinstalled. openSUSE repos uses a local RIS service that easily lets us maintain repository definitions with a package update.

Users migrating from 5.5/5.4 releases are advised to install zypper in openSUSE-repos to ensure they have up-to-date repository paths.

Documentation

Please refer to SLE Micro 6.0 documentation including Release notes.

Reporting Issues

Please refer to the Leap Micro section in our Submitting bug reports page.

Next steps

Missing maintenance setup was a long-term blocker for the transition out from Alpha, otherwise, the distribution itself is stable and feature-full. Now that we have it, we need to polish some remaining infrastructure issues and users can expect a release within the next few days. Ideally before oSC2024 next week.