Olissipo

A maintainer's anouncement when it was uploaded to unstable/Sid

Plasma 6.5 uploaded to unstable and building. Most common architectures are already there and more niche ones are coming.

https://deb.li/plasma

Expect the migration to testing/forky somewhere next week.

I checked the packages and they have all migrated to 6.5, as of today.

You can now jump to a CSS custom property's definition from within the var() function in style rules.

On clicking the arrow here:

You get jumped to where it's defined, and it's briefly highlighted.

The events tooltip in the Inspector now shows a badge besides custom events, making it easier to differentiate them from built-in events.

I think it's the "User-defined" badges I circled:

Full release notes

I'm posting this in case it helps anyone, but also for a sanity check (anyone has a better solution?).

My issue - using 3rd party packages and SCSS (and the solution in the docs)

Using Bootstrap as an example:

Running php bin/console importmap:require bootstrap doesn't import SCSS.

The easy provided alternative is installing as Composer package with composer require twbs/bootstrap, and importing the SCSS from there. This happens to work for Bootstrap, but may not be an option for others (there may not be a composer package)

My alternative

CSS

1. Install (at least these) third party packages using npm like usual.
2. In the app's SCSS file, import using the relative path to the node_modules's bootstrap: @import '../../../node_modules/bootstrap/scss/bootstrap';

JS

3. In config/packages/asset_mapper.yaml add the path specifically for the third-party package to be included. My file is looking like this:

framework:
    asset_mapper:
        # The paths to make available to the asset mapper.
        paths:
            - assets/
            - node_modules/bootstrap/dist/js
        excluded_patterns:
            - 'assets/styles/scss/**/*'
        missing_import_mode: strict

when@prod:
    framework:
        asset_mapper:
            missing_import_mode: warn

4. In importmap.php add the path ( and with entrypoint set to true). This only works because of the previous step.

return [
    'app' => [
        'path' => './assets/app.js',
        'entrypoint' => true,
    ],
    // ...
    'bootstrap' => [
        'path' => './node_modules/bootstrap/dist/js/bootstrap.bundle.min.js',
        'entrypoint' => true,
    ],
];

5. Import in the template as usual

{% block importmap %}
    {{ importmap([
        'bootstrap',
        'app',
    ]) }}
{% endblock %}

June 17, 2025

• 13:30–19:00 CET/CEST
• 07:30–13:00 EST/EDT
• 11:30–17:00 UTC

My TLDR is:

• Their team was using PHP

• Before doing a complete re-write they evaluated other languages

• Rust ruled out due to cost/benefit, being the fastest in the list, but also the most complex

• PHP kept as the main language because:

  • The ecosystem is mature
  • The PHP/Symfony (and Roadrunner) stack meets their high-performance needs

• Inertia: their team "already had extensive experience" in it

• They already integrated Go in some microservices

• They aren't locked to PHP, and will continue to evaluate these programming languages and others

Twig 3.15 was released a few weeks ago and includes an impressive list of new features and improvements. This two-part blog post highlights the most important ones.

Edit: Part 2

The Debian Long Term Support (LTS) Team hereby announces that Debian 10 "buster" support will reach its end-of-life on June 30, 2024, nearly five years after its initial release on July 6th, 2019.

Starting in July, Debian will not provide further security updates for Debian 10. A subset of "buster" packages will be supported by external parties. Detailed information can be found at Extended LTS.

The Debian LTS Team will prepare afterwards the transition to Debian 11 "bullseye", the current oldstable release. Thanks to the combined effort of different teams including the Security Team, the Release Team, and the LTS Team, the Debian 11 life cycle will also encompass five years. To make the life cycle of Debian releases easier to follow, the related Debian teams have agreed on the following schedule: three years of regular support plus two years of Long Term Support. The LTS Team will take over support from the Security and the Release Teams on August 14, 2024, three years after the initial release on August 14, 2021. The final point update release for "bullseye" will be published soon after the final Debian 11 Security Advisory (DSA) will be issued.

Debian 11 will receive Long Term Support until August 31, 2026. The supported architectures remain amd64, i386, arm64 and armhf.