mGBA | Game Boy Emulation on Linux
openSUSE Tumbleweed – Review of the week 2021/09
Dear Tumbleweed users and hackers,
This week has proven to be challenging for Tumbleweed. We have built and tested 6 snapshots, and only 2 of them were of sufficient quality to send out to the users. Of course, that means our QA infrastructure is well suited in protecting you, the users, from running into trouble – and that is the best thing we can show with this.
The two snapshots published were 0227 and 0302, containing these interesting changes:
- NetworkManager 1.30 – with WPA3 support
- The YaST stack update, as recently announced by the YaST team
- Mozilla Firefox 86.0
- Mozilla Thunderbird 78.8.0
- KDE Plasma 5.21.1
- Dracut 053
- krb5 1.19.1
- pipewire 0.3.22: pipewire-pulseaudio should mostly be able to replace PulseAudio
- podman 3.0.1
A big chunk of what was announced last week was thus delivered, a few things are still on the todo – together with a few new things:
- Linux kernel 5.11.2
- openssl 1.1.1i, based on centralized crypto-policies package
- KDE Plasma 5.21.2
- glibc fix for our i586 users
- GCC 11 as the default compiler
openSUSE Leap 15.3 Reaches Beta Build Phase
openSUSE Leap has entered into the beta release phase today for its 15.3 minor version.
This openSUSE Leap 15.3 version is a solidified release that focuses more on the building of the distribution rather than refreshing the distribution’s packages, but there are some significant changes to the distribution.
Many of the packages will remain the same as those in openSUSE Leap 15.2 with a bit of hardware enablement and security backports. An updated version of glibc brings some Power10 support and the Xfce desktop users will have the new 4.16 version. The distribution also gains adds s390x architecture.
The biggest change for this release is how Leap is built and its relationship with SUSE Linux Enterprise. Leap transitioned to a new way of building openSUSE Leap releases in the fall of 2020 through a prototype project called Jump. The Jump prototype was used as a proof of concept, but no longer exists; it did prove to work at building a distribution and bringing the code streams of both openSUSE Leap and SLE closer together. The proof of concept was implemented for building the release of openSUSE Leap 15.3 as seen in the beta release today. Building Leap on top of binary packages from SLE, which was part of the rationale for the Jump prototype, allows for easy development on a community release to be put into production on an enterprise release should the need arise.
The changes make the migration from openSUSE Leap 15.3 to SLE 15 Service Pack 3 practically instantaneous and there are no socket or virtual machine limitations. A little more than 50 packages are not identical with SLE, but these are mostly branding, patterns and openSUSE branding packages.
Entering this beta phase, testers are encouraged to test the migration from Leap to SLE. People testing the beta are encouraged to record their Leap Beta testing efforts on the following spreadsheet: https://docs.google.com/spreadsheets/d/1AGKijKpKiJCB616-bHVoNQuhWHpQLHPWCb3m1p6gXPc/edit#gid=801313279
Leap beta testers have an option to receive a T-shirt, so make sure to fill in all the proper information and bug reports to get one. Then send an email to ddemaio (at) opensuse.org with your address, size and name corresponding to the spreadsheet. Please make the subject title “beta test t-shirt”.
Bugs should be reported on openSUSE’s bugzilla and if any are found on SLE should be reported to SUSE’s bugzilla products for desktop, server and High Availability.
Leap has a rolling development model during both its Alpha and Beta phases. After the gold master and Public Availability of Leap is released, the rolling development model stops; the release then shifts into a supported release model with maintenance and security updates until its End of Life (EOL). Leap has an extended life cycle greater than 12 months per release. Leap ideal for desktop and server environments.
There are no concrete milestones in the Leap rolling development model. As bugs are fixed and new packages introduced or excluded, snapshots of the latest beta phase builds will be released once they pass openQA testing; this will take place over the next few months as the road map shows openSUSE Leap 15.3 will be have a Release Candidate in late April and the Gold Master on May 21, which will be follow by a public release on June 2. The documentation and translations deadline is May 14.
Architectures available for testing include x86_64, aarch64, PowerPC and s390x. People interested in armv7 and other architectures should read the announcement about openSUSE Step.
Those interested in beta testing images for openSUSE Leap 15.3 Windows Subsystem for Linux can contact the Leap release manager Luboš Kocman or the factory mailing list.
Jitsi: Turning off Automatic Gain Control
TL;DR
Operating systems let you customize the sensitivity of the microphone allowing you to suppress environmental noise such as keyboard strokes. Video conferences software unfortunately tends to override such settings using autogain making your customization void. While some video conferencing tools let you control autogain via the settings, Jitsi does not have such an option.
However, you can use https://your.jitsi.server/someroom#config.disableAGC=true when joining your Jitsi meetings to disable autogain and have more control over your microphone.
Digest of YaST Development Sprint 118
It has been three weeks since the previous development report from the YaST Team. That’s one week more than our usual cadence, since most of the team was booked during four days in an internal SUSE workshop. But fear no more, we are back and loaded with news as usual. This time we bring:
- Support to enable and configure SELinux during installation
- A revamped interface for configuring wireless network devices
- Usability improvements in several areas
- A new “hidden level” in the installer with advanced tools ;-)
You may know that both the SUSE and openSUSE families of operating systems include container-oriented members, namely openSUSE MicroOS and SLE Micro. In order to make them even more awesome, we got the request to make possible to propose and configure the usage of Security-Enhanced Linux, more widely known as SELinux, during the (auto)installation. This is a complex change affecting several parts of YaST and various versions of (open)SUSE, but you can get a good overview in the description of this pull request which includes some screenshots that may be worth a thousand words. Right now, the feature may look different on each one of the distributions due to the different state of SELinux on them. While in SLE Micro the new setting is visible during installation and activated at its more restrictive level, in others it may look more permisive or even not be presented at all. We expect things to consolidate during the upcoming weeks.
And talking about things that take their time, for a long time we had wanted to improve the usability of the configuration of wireless network adapters. Finally we found the time to reorganize the corresponding tab in the YaST Network module, improving the mechanism to select a wireless network and automatically pre-filling as much information as possible. You can see the result in the following animation and in the detailed pull request with the usual before-and-after screenshots.
That’s not the only usability improvements we implemented during this sprint. Now the Partitioner offers more useful information about file-systems that need to be unmounted in advance and presents a more sensible initial state for the collapsable branches in its tables. YaST Network permits to tweak the virt bridge interface during manual installation and reports AutoYaST errors more nicely. Last but not least in the usability field, we improved how long texts are managed and presented in most YaST pop-up dialogs.
If you are still not impressed with all the new things this sprint brought, we can give you a sneak peak on something we have been preparing lately to give power-users more… er… power. ;-) As you all know, YaST is already a pretty advanced installer offering many options. And it’s very configurable so it can be tweaked to behave differently depending on the distribution, the product or the system role selected by the user. But believe it or not, we still face situations in which we would like to configure the installer even more during its execution to overcome some obstacle found in a very special scenario or just for debugging purposes. How do we plan to do it? Meet the new YaST installation console, available through the even newer installer configuration screen!
While we dive into the beta phase of openSUSE Leap 15.3 and SLE-15-SP3, the YaST Team will focus during the next weeks in fixing the bugs found by the testers of those upcoming distributions, which implies we cannot give you a fixed date for the next development report, but it will be for sure during March. Meanwhile, stay tuned and do not hesitate to report any significant bug you can find in YaST or in openSUSE in general. See you soon(ish)!
Call for Papers Open for openSUSE Conference
The call for papers for the openSUSE Virtual Conference is open!
The call for papers is open until May 4. This leaves a little more than 60 days to submit a proposal. The dates of the conference are scheduled for June 18 - 20. Registration for the conference has also begun.
Presentations can be submitted for the following length of time:
- Lightning Talks (15 mins)
- Normal Talk (30 mins)
- Long Talk (45 mins)
- Workshop (1 hour)
The following tracks are listed for the conference:
- Cloud and Containers
- Community
- Embedded Systems and Edge Computing
- New Technologies
- Open Source
- openSUSE
The conference already has two sponsors with Fedora and SUSE. Companies interested in sponsoring the event can view the sponsorship prospectus on the project’s wiki page.
Volunteers who would like to help the Program Committee and/or the Organizing Team can email ddemaio@opensuse.org.
LCD Chalkboard Smart Sign, Raspberry Pi Powered
Revisiting Html in Java
Some time ago I wrote a post about creating an embedded dsl for Html in Java. Sadly, it was based on an abuse of lambda name reflection that was later removed from Java.
I thought I should do a followup because a lot of people still visit the old article. While it’s no longer possible to use lambda parameter names in this way, we can still get fairly close.
The following approach is slightly less concise. That said, it does have some benefits over the original:
a) You no longer need to have parameter name reflection enabled at compile time.
b) The compiler can check your attribute names are valid, and you can autocomplete them.
What does it look like?
html(
head(
title("Hello Html World"),
meta($ -> $.charset = "utf-8"),
link($->{ $.rel=stylesheet; $.type=css; $.href="/my.css"; }),
script($->{ $.type= javascript; $.src="//benjiweber.co.uk/some.js"; })
),
body(
div($-> $.cssClass = "article",
a($-> $.href="https://benjiweber.com/",
span($->$.cssClass="label", "Click Here"),
img($->{$.src="//benjiweber.co.uk/htmldsl2.png"; $.width=px(25); $.height=px(25); })
),
p(span("some text"), div("block"))
)
)
)
This generates the following html
Hello Html World
You get nice autocompletion, and feedback if you specify inappropriate values:
You’ll also get a helping hand from the types to not put tags in inappropriate places:

Generating Code
As it’s Java you can easily mix other code to generate markup dynamically:
assertEquals(
"""
Paragraph one
Paragraph two
Paragraph three
""".trim(),
html(
head(
meta($ -> $.charset = "utf-8")
),
body(
Stream.of("one","two","three")
.map(number -> "Paragraph " + number)
.map(content -> p(content))
)
).formatted()
);
And the code can help you avoid injection attacks by escaping literal values:
assertEquals(
"""
<script src="attack.js"></script>
""".trim(),
html(
head(
meta($-> $.charset = "utf-8")
),
body(
p("")
)
).formatted()
);
How does it work?
There’s only one “trick” here that’s particularly useful for DSLs. Using the Parameter Objects pattern from my lambda type references post.
The lambdas used for specifying the tag attributes are “aware” of their own types. And capable of instantiating the configuration they specify.
When we call
meta($ -> $.charset="utf-8")
We make a call to
default Meta meta(Parameters params, Tag... children) { … }
The lambda specifying the attribute config is structurally equivalent to the Parameters<Meta> type. This provides a get() function that instantiates an instance of Meta, and then passes the new instance to the lambda function to apply the config.
public interface Parameters extends NewableConsumer {
default T get() {
T t = newInstance();
accept(t);
return t;
}
}
Under the hood the newInstance() method uses reflection to examine the SerializedLambda contents and find the type parameter (in this case “Meta”) before instantiating it.
You can follow the code or see the previous post which explains it in a bit more detail.
Add Mixins
It’s helpful to use interfaces as mixins to avoid having to have one enormous class with all the builder definitions.
public interface HtmlDsl extends
Html.Dsl,
Head.Dsl,
Title.Dsl,
Meta.Dsl,
Link.Dsl,
Script.Dsl,
Body.Dsl,
Div.Dsl,
Span.Dsl,
A.Dsl,
P.Dsl,
Img.Dsl {}
Each tag definition then contains its own builder methods. We compose them together into a single HtmlDsl interface for convenience. This saves having to import hundreds of different methods. By implementing the Dsl interface a consumer gets access to all the builder methods.
Show me the code
It’s all on github. I’d start from the test examples. Bear in mind that it’s merely a port of the old proof of concept to a slightly different approach. I hope it helps illustrate the technique. It’s in no way attempting to be a complete implementation.
This approach can also be useful as an alternative to the builder pattern for passing a specification or configuration to a method. There’s another example on the type references article.
What else could you use this technique for?
The post Revisiting Html in Java appeared first on Benji's Blog.
Kraft Version 0.96
Ich freue mich, heute das Release Version 0.96 von Kraft herauszugeben. Die neue Version kann über die Homepage heruntergeladen werden.
Kraft 0.96 ist ein Bugfix Release, das einige kleine Fehler der Version 0.95 behebt. Insbesondere betrifft das das in 0.95 eingeführte neue PDF-Rendering mit Weasyprint.
Es gibt auch ein paar kleine neue Funktionen: Im Dokument Editor kann per Hinzufügen-Knopf nun auch eine neue Posten-Vorlage hinzugefügt werden. Außerdem werden in Folgedokumenten die im Vorgängerdokument eingetragenen Kopf- und Fußtexte kopiert, wenn die Standard-Texte für den neuen Dokumenttyp nicht gesetzt sind. Wichtig dabei: Kraft verwendet den Kopftext mit dem Namen „Standard“ als Standardtext, ebenso bei Fußtexten.
Weiterhin viel Erfolg mit Kraft!

