Feeds

With yesterdays release of Debian 12 Bookworm, I am happy to know the the interactive application firewall OpenSnitch is available for a wider audience. I have been running it for a few weeks now, and have been surprised about some of the programs connecting to the Internet. Some programs are obviously calling out from my machine, like the NTP network based clock adjusting system and Tor to reach other Tor clients, but others were more dubious. For example, the KDE Window manager try to look up the host name in DNS, for no apparent reason, but if this lookup is blocked the KDE desktop get periodically stuck when I use it. Another surprise was how much Firefox call home directly to mozilla.com, mozilla.net and googleapis.com, to mention a few, when I visit other web pages. This direct connection happen even if I told Firefox to always use a proxy, and the proxy setting is ignored for this traffic. Other surprising connections come from audacity and dirmngr (I do not use Gnome). It took some trial and error to get a good default set of permissions. Without it, I would get popups asking for permissions at any time, also the most inconvenient ones where I am in the middle of a time sensitive gaming session.

I suspect some application developers should rethink when then need to use network connections or DNS lookups, and recommend testing OpenSnitch (only apt install opensnitch away in Debian Bookworm) to locate and report any surprising Internet connections on your desktop machine.

At the moment the upstream developer and Debian package maintainer is working on making the system more reliable in Debian, by enabling the eBPF kernel module to track processes and connections instead of depending in content in /proc/. This should enter unstable fairly soon.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

We're happy to announce the release of Debian 12, codenamed bookworm!

Want to install it? Choose your favourite installation media and read the installation manual. You can also use an official cloud image directly on your cloud provider, or try Debian prior to installing it using our "live" images.

Already a happy Debian user and you only want to upgrade? You can easily upgrade from your current Debian 11 "bullseye" installation; please read the release notes.

Do you want to celebrate the release? We provide some bookworm artwork that you can share or use as base for your own creations. Follow the conversation about bookworm in social media via the #ReleasingDebianBookworm and #Debian11Bookworm hashtags or join an in-person or online Release Party!

People are working quietly, cross-checking, reading back steps and running individual steps - we're really almost there for the install media.

Just had a friendly, humorous meal out by the barbeque in Sledge's garden. It's been quite a long day but we're just finished.

All this and then we'll probably have the first point release for Bookworm 12.1 in about a month. That will contain some few fixes which came in at the last minute and any other issues we've found today.

BOOKWORM IS HERE!!

Now that Debian 12 has been released with proprietary firmwares on the official media, non-optional merged-/usr and systemd adopted by everybody, I want to take a moment to list, not without some pride, a few things that I was right about over the last 20 years:

• Distribution of proprietary firmwares (#33, #40, #114)
• udev
• systemd (#454)
• merged-/usr

Accepting the obvious solution about firmwares took 18 years. My work on the merged-/usr transition started in 2014, and the first discussions about replacing sysvinit are from 2011. The general adoption of udev (and dynamic device names, and persistent network interface names...) took less time in comparison and no large-scale flame wars, since people could enable it at their own pace. But it required countless little debates in the Debian Bug Tracking System: I still remember the people insisting that they would never use this newfangled dynamic /dev/, or complaining about their beloved /dev/cdrom symbolic link and persistent network interface names.

So follow me for more rants about inevitable technologies.

DrupalCon Pittsburgh Recap mherchel Sat, 06/10/2023 - 11:37

I've released version 1.1.19 of plocate; this was mostly to get compatibility with liburing 2.4 out the door. The fix (an external contribution; thanks!) had lingered in git for a while, but evidently, onw it's reached distributions and more people were starting to notice.

On a related notice, the user base seems to be growing, and also changing a bit. I usually say that as an open-source maintainer, what you want isn't users; you want patches. Users generally come with questions and bugs, and you don't really care that much about the latter because they didn't affect you and you feel like you have an obligation to fix it.

In the early days of plocate, what I'd get was indeed patches; not that many and none large, but the ones that I'd get would be high-quality fixes by way of git-send-email that I could just apply and get on with my day. This is the ideal situation. But as time now goes by, I tend to get more and more requests and/or complaints and/or people who haven't actually read the manual; e.g., a common case is how btrfs subvolumes as configured on some distributions trips up updatedb's bind mount detection (because btrfs subvolumes are indeed implemented by bind mounts, and since you can use subvolumes for pretty much everything, it's impossible to know which ones should be included and which ones should not). Another increasingly common case is people who have unusual local setups that they want large plocate changes for. Some of them go away when I try to explain that implementing their changes are nontrivial (sometimes highly so), some don't. I interpret this as plocate slowly reaching mass market status, to the degree any Linux command-line tool can be said to have that.

plocate has long been a “finished” product; it does basically what mlocate does, just much faster, and that's it. I don't intend to do more with it except fixes, unless I hit on something that really annoys me again, and I don't really think a lot of things need to be done within that framework either. So congrats, I'm the owner of a dead program that only now gets users, who discovered that the product exists way too late to actually influence its direction. It's nice to be an open-source maintainer =)

 Most of the install images for Debian media have now been tested.

Various folk are now testing the live media.

We have been joined by a couple of people in IRC who have also done a few tests.

Useful things to note :)

The release name is Bookworm *not* Bookwork.

Debian 13 will be Trixie when it gets here: testing will be re-enabled shortly.

The release notes detail the changes in /etc/apt/sources.list to accommodate the changes to non-free-firmware but also see also Sources List on the Debian wiki.

As many users have noticed, our 23.04.0 release didn’t go as smoothly as planned. Several major regressions affected the release, resulting in a poor user experience. We are well aware that most users want stability above all else, and with our growing user base we really need to improve on that front.

So for Kdenlive 23.08, we plan to focus only on bug reporting and regression testing to avoid repeating the mistakes of the 23.04 release. Our intention is to improve our test suite, and also to create a repository of sample project files, with automated scripts that open the files, render them, and compare the results to a reference render.

This should allow us to catch regressions and be much safer when releasing a new version with major changes, as was the case with nested timelines in 23.04.0.

It’s also important to realize that Kdenlive relies on dozens of other projects and libraries, and that some of the recent problems were caused by upstream or downstream issues, so don’t blame us for everything :).

Regarding our fundraising

Here is the first report on what we are doing with the money and what is planned for the future.

We are very happy with the success of the campaign and will try to report every 4 months on what we have achieved with the money raised. At first, not everything went as planned. The reorganisation of the Kdenlive maintainer ‘s schedule to have more time for Kdenlive is not going as fast as hoped, so he is still in a transition period. This will change by the end of the year, with the goal of having a healthier weekly schedule with two full days dedicated to Kdenlive instead of the current one day plus all available spare time.

The figures

As of mid-February 2023, we had received 677 donations totalling: €23,170.
Platform and processing fees were €1,067 €, and €4,420 € (20 %) will go to KDE to cover infrastructure, maintenance and support costs. This leaves €17,683 € for Kdenlive development.
€3000 has already been used to help fund the first achievement (see below).

The first achievements

Thanks to these donations, the Kdenlive maintainer started to work a bit more on Kdenlive and we delivered the first goal of the fundraiser: support for nested timelines!

Next steps

When our testing has improved, we will start working on improving the effects workflow and increasing the global performance of the application.

Join us

Kdenlive is an open source project, you can help us in many ways. You can join our Matrix development channel, help with documentation or send us your (hopefully) success stories with Kdenlive!

The post Kdenlive news and fundraising report appeared first on Kdenlive.

 We've all met up in Cambridge - so there's an egw_, amacater, kibi who has travelled over to join us, Isy, RattusRattus and Sledge mostly sat round a table. The usual number of laptops, three monitors, Rattus' tower machine.

Network running well and we're all ready to go, I think - there's normally a flurry of activity to get things started then a wait for a while for the first images

Coffee and tea at the ready - bacon sandwiches are on the way

[And the build process is under way - and smcv has joined us]

I’m happy to announce the 1.1 release of Arianna. Arianna is a small ePub reader application I started with Niccolo some time ago. Like most of my open source applications, it is built on top of Qt and Kirigami.

Arianna is both an ePub viewer and a library management app. Internally, Arianna uses Baloo to find your existing ePub files in your device and categorize them.

New features

Arianna can now display the table of content of a book. This supports complex hierarchies of headings.

A table of content displayed as a right sidebar with a tree structure

Arianna now provides you with the metadata about your books.

Dialog showing the title, author, description, license information about a book

Additionally, you can now disable the reading progress on the library page if it distracts you.

Bug fixes

You can now read books without requiring an internet connection. We also fixed various crashes happening when indexing your books.

Get Involved

If you are interested in helping, don’t hesitate to reach out in the Arianna matrix channel (#arianna:kde.org) and I will be happy to guide you.

I also regularly post about my progress on Arianna (and other KDE apps) on my Mastodon account, so don’t hesitate to follow me there ;) We also now have an official Mastodon account for Arianna @arianna@kde.social.

And in case you missed it, as a member of KDE’s fundraising working group, I need to remind you that KDE e.V., the non-profit behind the KDE community accepts donations.

Packager section

You can find the package on download.kde.org and it has been signed with my GPG key.

While most of the effort around the transition to Qt 6 and KDE Frameworks 6 (KF6) is probably going into Plasma currently, there are still a number of lose ends to tie up in Frameworks itself as well. The below is far from a comprehensive overview of that though, it’s merely a few things I have been involved with recently.

KTextTemplate

During the 5 era we relied on the text-template engine Grantlee in several places (e.g. KHelpCenter, KDevelop, KDE PIM). In the 6 era this will now live on as KTextTemplate as part of KDE Frameworks.

The final bits for this, the formal review process and the actual move of the repository, have now been done as well.

Going forward this will mean one dependency release cycle less to deal with for consumers, and a faster and more predictable way to get upstream fixes rolled out.

Barcode generator API

The barcode generation API in Prison used to have a factory method returning an abstract base class pointer. That requires manual memory management for consumers, and it leaks implementation details which limit us in evolving the API without ABI breaks.

As the base class isn’t really useful for inheriting externally we can just as well move that part to the private class and only expose a value-type like object to the outside.

The corresponding change has landed, an API improvement on top of that is still awaiting review. Once that is in we can port consumers and remove the old API.

Unit conversion online updates

The KUnitConversion framework provides - hardly surprising - ways to convert values of different units. In most cases those are fixed conversion rates, but there is also support for currency conversions, and not all of those are static.

KUnitConversion therefore downloads current conversions rates, when needed and at most once a day. The problem here however is that this happens behind a seemingly synchronous API. That’s not only bad for being potentially blocking, it’s also prone to nasty reentrancy problems which we have recently seen in form of deadlocks in QML code calling into KUnitConversion.

To address this, there now is a proposed change moving this to an explicit and asynchronous API. This requires consumers to trigger the currency conversion table update themselves. That’s a bit more work, but it makes the actual conversion API much more predictable.

KIO HTTP

KIO has its own HTTP implementation, dating back to the early 2000s where this was mainly intended for browser use and the security and privacy threat level wasn’t quite what it is today. Since then the world has changed, KIO’s HTTP is nowadays no longer used by web browsers but rather for API calls. At the same time the HTTP standard has evolved considerably, from new security features such as HSTS to entirely new protocol versions.

For KIO this means we’d like to get rid of our own implementation of HTTP, replacing it with something that already supports HSTS, HTTP/2, etc. QNetworkAccessManager would be the first choice there, as we already use that in many other places anyway.

On the way towards that we have meanwhile removed support for implicit cookie handling, the QNAM to KIO bridge and obsolete SSL settings.

Co-installability

Co-installability with KF5, ie. the ability to install both KF5 and KF6 in the same prefix at the same time is one of the few hard release blockers, and something that’s being worked on since the beginning. In most cases it’s unfortunately more complicated than just renaming an install location, all consumers need to be adjusted as well and sometimes it simply makes no sense to duplicate a file or program.

Runtime components add even more complexity to that, here we also need look at what should only exist once (and thus needs to retain compatibility of e.g. D-Bus interfaces) and what should be duplicated (and thus must not conflict on D-Bus service names etc).

Sometimes we get lucky and things can be dropped entirely, the above mentioned KIO changes should also help with removing remaining conflicts around cookie storage.

Every week some of those issues get resolved, but there’s still some work remaining. We unfortunately lost the Neon-based install conflict checker tool, on its last run it still showed about 500 conflicting files. Many of those have the same root cause though, so there’s a lot fewer actual issues.

Okular

Not strictly a Frameworks topic, but nevertheless somewhat related is porting Okular away from KJS and KHTML. Those are gone in KF6, and Okular is one of their remaining users, and a particular complex and important one.

KJS is used for scripting in PDF files. The official specification for the PDF JS API has a whopping 700+ pages, even with Okular only implementing parts of that not a small task. The security implications of this and a limited amount of test documents don’t help either, but fortunately Okular has a decent unit test coverage for this. So we now have a pending merge request replacing the use of KJS with QJSEngine.

I also looked into replacing KHTML with Qt WebEngine, despite Albert telling me it’s not possible. Turns out he was right. Unlike most other KHTML users we have, Okular doesn’t use KHTML to render content directly to the screen, but to render tiles into an image. Technically that can be done with Qt WebEngine as well, however with two limitations:

• The QWebEngineView needs to be visible for this to work.
• We don’t know for sure when the content is ready to be rendered.

Either one of those could be worked around with some nasty hacks probably, but I haven’t found a way to overcome both at the same time.

So how do we proceed here? There’s two options:

• It was mentioned that there is some ongoing work in Qt in support of compile-time SVG rendering using Qt WebEngine that might face the same problem, and thus might result in a viable solution for Okular as well.
• KHTML is used in Okular for rendering CHM files. Given that is a somewhat rare format nowadays, it might be possible to move that functionality to a standalone app instead. There we can then use Qt WebEngine to render the output directly, bypassing this problem entirely. Albert has started such an app already even.

How you can help

The above are just a few examples of things being done and still needing to be done.

If you want to participate, here are the most important coordination and communication channels:

• There’s a weekly call on meet.kde.org every Tuesday at 17:00 CEST. Topics are prepared here.
• For general communication there’s the kde-frameworks-devel mailing list and the #kde-devel channel on Matrix.
• The KF6 workboard has the overview of Frameworks tasks and their status, and same for the Plasma 6 workboard.

This week Plasma 6 underwent some major refactoring to the fundamental Plasma widget APIs to modernize them and make it harder to introduce errors when developing new widgets. Since almost everything in Plasma is a widget, this necessitated a lot of changes and QA. After a month of work, it’s now done! The user-facing side is nil (ideally nobody will notice anything), but there are some changes that developers will need to be aware of to port their widgets. Most widgets already needed to be ported anyway due to Qt changes, but hopefully this won’t add much else. A porting guide has already been written and can be found here. This work was done by Marco Martin, with me providing QA support.

On that subject, we got a lot more organized about Plasma 6 this week. We now centrally track status on a new wiki page that shows the outstanding issues and notable changes. I’m starting to feel like I see a light at the end of the tunnel! While I’ve had to use the X11 Plasma 6 session because the Wayland one is still a bit too unstable for me to feel productive, the X11 session now feels barely buggier than the Plasma 5 X11 session. It’s really quite nice at this point.

This came up in the comment threads of last week’s post, but the more people test and contribute to Plasma 6, the better the final release will be. Neon Unstable now offers Plasma 6 by default, making it a good testing platform for the adventurous. Especially if you have a heavily customized setup or use exotic hardware, please try it out and submit bug reports! Make sure to apply the “qt6” keyword to them.

User Interface Improvements

Many significant UI improvements to Skanpage, including drag-and-drop page re-ordering, better keyboard shortcuts, and better error reporting (Someone going by the pseudonym “John Doe”, Skanpage 23.08. Link)

Okular no longer bugs you when you save a document that was deleted on disk; it simply re-saves it as instructed (me: Nate Graham, Okular 23.08. Link)

The context menu actions of the Dictionary Widget are now more relevant and have icons (Laurent Montel, Plasma 6.0. Link):

Significant Bugfixes

(This is a curated list of e.g. HI and VHI priority bugs, Wayland showstoppers, major regressions, etc.)

KRunner no longer sometime crashes when trying to calculate certain math expressions, or simply when typing numbers in general (Max Ramanouski, Plasma 5.27.6. Link)

The final change just went in for making sure that Discover always gets the version numbers right for updatable Flatpak apps (Ismael Asensio, Plasma 5.27.6. Link)

When using a fractional scale factor in the Plasma Wayland session, you should no longer see line glitches all over the place (Matthias Dahl, Plasma 5.27.6. Link)

Fixed the “Add New Page” dialog in System Monitor to not be visually broken when using a language with longer translated strings than English (me: Nate Graham, Plasma 5.27.6. Link)

In the Plasma Wayland session, when adding a second keyboard layout, the Keyboard layout System Tray icon now appears immediately (Marco Martin, Plasma 6.0. Link)

Other bug-related information of interest:

• 3 Very high priority Plasma bugs (same as last week). Current list of bugs
• 55 15-minute Plasma bugs (up from 52 last week). Current list of bugs
• 70 KDE bugs of all kinds fixed this week. Full list of bugs

Automation & Systematization

Overhauled the documentation about Plasma styles to be more up-to-date and accurate (Thiago Sueto, link)

Web presence

KDE’s growing assortment of “KDE for” pages has gotten a snazzy new landing page, and now it’s a top-level link over at kde.org (Carl Schwan):

On top of that, there’s a new page: “KDE for Activists“, showcasing how KDE’s privacy-conscious communication can help you organize for what you believe in (Carl Schwan):

Note that this is a value-neutral statement; you can use KDE software to organize for whatever cause you believe in, no matter where on the political spectrum you consider yourself. Our software is neutral; it’s people who choose to use it for their purposes, and how. KDE software is used in homes, schools, businesses, news organizations, local governments, and, believe it or not, on both sides of the Russian invasion of Ukraine. People can take sides, but our software does not, so let’s try to keep the political battles out of the comments section of this post. Thanks everyone.

…And everything else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

If you’re a developer, please please please start living on a Plasma 6 session (not just building Plasma 6 stuff on top of Plasma 5) and fixing the bugs that you encounter. Plasma 6 is usable for daily driving, and I’m doing so, but it’s still very much in an alpha state and in need of work to make it releaseable.

If you’re an adventurous user, you can also use Plasma 6 with Neon Unstable. If you do so, make sure to submit bug reports for any problems you encounter, and apply the “qt6” keyword to them.

Otherwise, visit https://community.kde.org/Get_Involved to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

And finally, KDE can’t work without financial support, so consider making a donation today! This stuff ain’t cheap and KDE e.V. has ambitious hiring goals. We can’t meet them without your generous donations!

Contributing to Debian is part of Freexian’s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

/usr-merge, by Helmut Grohne, et al

Towards the end of April, the discussion on DEP 17 on debian-devel@l.d.o initiated by Helmut Grohne took off, trying to deal with the fact that while Debian bookworm has a merged /usr, files are still being distributed to / and /usr in Debian binary packages, and moving them currently has some risk of breakage. Most participants of the discussion agreed that files should be moved, and there are several competing design ideas for doing it safely.

Most of the time was spent understanding the practical implications of lifting the moratorium and moving all the files from / to /usr in a coordinated effort. With help from Emilio Pozuelo Monfort, Enrico Zini, and Raphael Hertzog, Helmut Grohne performed extensive analysis of the various aspects, including quantitative analysis of the original file move problem, analysis of effects on dpkg-divert, dpkg-statoverride, and update-alternatives, analysis of effects on filesystem bootstrapping tools. Most of the problematic cases spawned plausible workarounds, such as turning Breaks into Conflicts in selected cases or adding protective diversions for the symbolic links that enable aliasing.

Towards the end of May, Andreas Beckmann reported a new failure scenario which may cause shared resources to inadvertently disappear, such as directories and even regular files in case of Multi-Arch packages, and our work on analyzing these problems and proposing mitigations is on-going.

While the quantitative analysis is funded by Freexian, we wouldn’t be here without the extensive feedback and ideas of many voluntary contributors from multiple areas of Debian, which are too many to name here. Thank you.

Preparing for the tox 4 transition, by Stefano Rivera

While Debian was in freeze for the bookworm release, tox 4 has landed in Debian experimental, and some packages are starting to require it, upstream. It has some backwards-incompatible behavior that breaks many packages using tox through pybuild. So Stefano had to make some changes to pybuild and to many packages that run build-time tests with tox. The easy bits of this transition are now completed in git / experimental, but a few packages that integrate deeply into tox need upstream work.

Debian Printing, by Thorsten Alteholz

Just before the release of Bookworm, lots of QA tools were used to inspect packages. One of these tools found a systemd service file in a wrong directory. So, Thorsten did another upload of package lprint to correct this.

Thanks a lot to all the hardworking people who run such tools and file bugs.

Thorsten also participated in discussions about the new Common Printing Dialog Backends (CPDB) that will be introduced in Trixie and hopefully can replace the current printing architecture in Forky.

Miscellaneous contributions

• DebConf 23 preparations by Stefano Rivera. Some work on the website, video team planning, accounting, and team documentation.
• Utkarsh Gupta started to prep the work on the bursary team’s side for DC23.
• Stefano spun up a website for the Hamburg mini-DebConf so that the video team could have a machine-readable schedule and a place to stream video from the event.
• Santiago Ruano Rincón reviewed and sponsored four python packages of a prospective Debian member.
• Helmut Grohne supported Timo Roehling and Jochen Sprickerhof to improve cross building in 15 ROS packages.
• Helmut Grohne supported Jochen Sprickerhof with diagnosing an e2fsprogs RC bug.
• Helmut Grohne continued to maintain rebootstrap and located an issue with lto in gcc-13.
• Anton Gladky fixed some RC-Bugs and uploaded a new stravalib python library.

Saturday, 10 June 2023

KDE today announces the release of KDE Frameworks 5.107.0.

KDE Frameworks are 83 addon libraries to Qt which provide a wide variety of commonly needed functionality in mature, peer reviewed and well tested libraries with friendly licensing terms. For an introduction see the KDE Frameworks release announcement.

This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.

New in this version Baloo

• Use common helper for Property/JSON conversion
• Don't install D-Bus interfaces without BUILD_INDEXER_SERVICE
• [IdTreeDB] Consolidate put/del into common set
• Cleanup some leftover stale code
• [balooshow] Improve display of property and plaintext terms

KConfigWidgets

• KColorSchemeMenu: Remove accelerator markers from scheme name
• Give KColorSchemeMenu namespace a short description
• Fixup: Pass scheme name - not path - to KColorSchemeManager::indexForScheme
• Split menu creating functionality out of KColorSchemeManager

KCoreAddons

• use fcntl to fix macOS compile

KDELibs 4 Support

• kssl: Update for LibreSSL 3.7

KDocTools

• Add Arabic Support

KFileMetaData

• Cleanup property name/id mapping test
• Add method to export list of all Property names
• Reduce PropertyInfo construction overhead
• Add benchmark for PropertyInfo instantiation

KHolidays

• Significantly speed up HolidayRegion::defaultRegionCode()

KIconThemes

• KIconTheme: allow to also fallback to Breeze-dark when set through QPA

KImageFormats

• pcx: multiple fixes (2)
• Avoid unnecessary conversions
• RGB/SGI writer: fix alpha detection and image limit size
• TGA writer: fix alpha detection and performance improvements
• pcx: multiple fixes
• PCX: Fix reading of the extended palette (bug 463951)

KIO

• Deprecate KIO::AccessManager and related classes
• Enable thumbnail caching if thumbnail directory is on an encrypted volume (bug 443806)
• KdirLister: update symlink dir content on file removal (bug 469254)
• Polish menu before creating platform window

Kirigami

• ActionTextField: Disable shortcut for invisible and disabled text fields
• BasicListItemTest: Guard against nullable background in ScrollView
• Fix tst_basiclistitem_tooltip
• Make it possible to disable BasicListItem tooltip
• Fix almost all links in the KF5 Kirigami docs
• Fix painting of non-symbolic icons which are fallbacks for symbolic (bug 451538)

KItemModels

• Preserve numeric sort roles as well

KNewStuff

• Remove KF5TextWidgets remnants

KParts

• PartLoader::createPartInstanceForMimeType(): Avoid compiler detected null pointer access

KTextEditor

• Fix incorrect lineHeight for drag pixmap (bug 468196)

Prison

• Add EAN13 support
• Factor out code for interfacing with ZXing for barcode generation

Security information

The released code has been GPG-signed using the following key: pub rsa2048/58D0EE648A48B3BB 2016-09-05 David Faure faure@kde.org Primary key fingerprint: 53E6 B47B 45CE A3E0 D5B7 4577 58D0 EE64 8A48 B3BB

Bleach is deprecated, here's how to come close to replicating bleach.clean() using the nh3 version of .clean().

import nh3 def clean_string(string: str) -> str: # The arguments below being passed to `nh3.clean()` are # the default values of the `bleach.clean()` function. return nh3.clean( string, tags={ "a", "abbr", "acronym", "b", "blockquote", "code", "em", "i", "li", "ol", "strong", "ul", }, attributes={ "a": {"href", "title"}, "abbr": {"title"}, "acronym": {"title"}, }, url_schemes={"http", "https", "mailto"}, link_rel=None, )

The big difference is unlike the safing of HTML done by bleach, nh3 removes the offending tags altogether. Read the comments below to see what this means.

Results:

>>> input_from_user = """<b> <img src=""> I\'m not trying to XSS you <a href="https://example.com">Link</a> </b>""" >>> >>> # By default, bleach version safes the HTML >>> # rather than remove the tags altogether. >>> bleach.clean(input_from_user) '<b>&lt;img src=""&gt;I\'m not trying to XSS you <a href="https://example.com">Link</a></b>' >>> >>> # In contrast, nh3 removes the offending tags entirely >>> # while also preserving whitespace. >>> clean_string(input_from_user) '<b>\n\nI\'m not trying to XSS you <a href="https://example.com">Link</a>\n</b>'

Advantages of switching to nh3 are:

1. nh3 is actively maintained, bleach is officially deprecated.
2. I believe the nh3 technique of stripping tags rather than allowing safing is more secure. The idea of safing is great, but I've always wondered if a creative attacker could find a way to exploit it. So I think it is better to remove the offending tags altogether.
3. The preservation of whitespace is really useful for preserving content submitted in a textarea. This is especially true for Markdown content.
4. nh3 is a binding to the rust-ammonia project. They claim a 15x speed increase over bleach's binding to the html5lib project. Even if that is a 3x exaggeration, that's still a 5x speed increase.

A long time ago, before the pandemic, I bought a Librem 5 phone from Purism. I also moved home since then, and sadly my phone was sleeping peacefully in a box in the garage since I moved.

When I was in Hamburg last month, I saw how great Mobian and Phosh was coming along, and this inspired me to go dig up the Librem 5 which was about 2 Debian releases behind, and upgrade it to the latest and greatest version.

I followed the instruction on the Debian wiki, and after some stumbles, managed to flash it with the latest Mobian image:

It’s still a big bulky phone, but Phosh has really come a long way and the phone feels so much more responsive and usable now. It’s also the first time I tried out the new GNOME Console app (I hope they consider taking some features from JuiceSSH so that it’s easier to run apps like mc and irssi on the phone).

Next up I want to try out some progressive web apps and also check what the latest state of emulating Android apps is. I’ve also been meaning to follow some GTK tutorials, and trying out some ideas on a mobile device motivates me a bit more to do that.

It’s really impressive the large amount of work people put into making Debian and a mobile GNOME experience work so well on a phone! Good job to everyone who contributes to this eco-system!

Towards the end of 2011 (in the depths of Covid…), I started thinking about adding a code of conduct to my open source software projects. Github recommends adding one, somewhat similiar to how they recommend including a software license.

In trying to pick a code of conduct (for my projects), it seems helpful to remember the “community”, as such, is often basically me, short (in length) is generally better, and just about anything can be weaponized by bad faith actors.

The Most Basic: Troll Banning

I suppose the most basic form of a code of conduct is just have a (written) policy to ban any trolls, or “Don’t be a jerk!”. It seems almost ridiculous that you would have to spell this out. But, I suppose as you start dealing with a wider array of people, it’s helpful to outline what behaviour isn’t appreciated (e.g. “Doing X makes you a jerk; don’t do it!”).

The Most Complex: Corporate Codes of Conduct

When searching Google for examples of codes of conduct, the corporate variety was by far the most common that came up; one could argue this is the “true” definition of the term. These tend to be very legalistic (being written by the legal department), very long (often hundreds of pages), and often very complex. But I don’t need all that: I’m don’t need to deal with travel reimbursements, I don’t need to deal with conflicts of interest, etc. I doubt anyone want to contribute a small fix to my software projects will read something that long, and I don’t want to spend the next three months (or three years!) writing something like this either.

The Most Common: The Contributor Code of Conduct

The Contributor Code of Conduct (aka the “Contributor Covenant”) is probably the most commonly used Code of Conduct for software projects and seems to have the largest mindshare; to some extent, it feels like the injunction to “add a code of conduct” is an injunction to bind yourself and your project by the Contributor Code of Conduct, whether you adopt that specific code or not.

It is among the three codes of conduct suggested by GitHub1, although the three of them seem similiar in nature. One of the three actually says the “primary goal of {COMMUNITY_NAME} is to be inclusive to the largest number of contributors, with the most varied and diverse backgrounds possible.”2…and I’m not sure that’s a useful goal for any (functional) group. For example, if you take any marketing, they will suggest having a “target audience” or an ideal customer to possition your project for. As a practical matter, if everyone is accepted, what is the common goal or purpose to hold the group together? As you deal with others, it’s fairly obvious that some people are more productive contributors, and some are more excited about the project; both things that I feel should be encouraged.

For me, the goal is to actually have a working piece of software, for me first of all. I don’t see how these codes of conduct help make that a reality.

The SQLite Option: The Benedictine Code

Presumably other (software/open source) codes of conduct have been developed (though none seem particularly popular), but one of the most interesting (to me) is the story of SQLite and their Code of Conduct adopted from the Benedictine Code. SQlite, for various corporate contracts, was asked to link to their project’s code of conduct, which at the time they lacked. Looking around, they decided to adopt the Benedictine Code, specifically Chapter 4. This Chapter is a list of 73 tools for good works and was originally written for the Benedictine monks ca. 530AD, and has been a foundation of their Order since. In reading through the list, it felt more like what I myself was looking for. In particular, it seems to focus almost entirely on the actions I want to see in the community.

There has been much critism leveled of it, mostly seeming to center on its religious nature. I don’t feel the Code itself is particularly religious, although it was written for a group of religious believers who are trying to better live their (shared) faith. Personally, it seems that some people mistake the mention of religion as implying that the text is a religious text, when it more often that the writers lived in a religious society (such as in this case). Perhaps the right response to these critisms is to request that other codes of conduct add religious identity and religious expression to their list of prohitied discrimination grounds (to mirror the current listing of “gender, gender identity, and gender expression”); often enough, religious people are asked to keep their faith out of sight as a condition of having it at all. Although the principals at SQLite do seem to be religious, they have also been clear that your (personal) religion will not bar you from participating in the project: in their introduction they explain that you are not required believe, agree with, or even accept the Code to participate in the project.

Another complaint has been that it doesn’t lay out an enforcement mechanism. Except that it does, asking that those who have failed to live up to the ideals of the Code to be extended grace; for a first pass of many issues, this seems a reasonable response.

And the mention of chastity seems like a brillant way of heading off the sexual harassment and assult concerns that can be the most impactful for a community to protect against.

For Me

For my projects, I’ll be using a version of the Benedictine Code. It seems short enough that people may actually read it, it promotes the things I want to see in the community (rather than just being a list of horrible things people might do to each other), and its references to grace seem like a decent response to the misunderstanding most commonly encountered. Here’s the text:

Code of Conduct Purpose

The Founder of this project, and all of the current developers at the time when this document was composed, have pledged to govern their interactions with each other and with the larger this project’s user community in accordance with the “instruments of good works” from chapter 4 of The Rule of St. Benedict (hereafter: “The Rule”). This code of ethics has proven its mettle in thousands of diverse communities for over 1,500 years, and has served as a baseline for many civil law codes since the time of Charlemagne.

Scope of Application

No one is required to follow The Rule, to know The Rule, or even to think that The Rule is a good idea. The Founder of this project believes that anyone who follows The Rule will live a happier and more productive life, but individuals are free to dispute or ignore that advice if they wish.

The Founder of this project and all current developers have pledged to follow the spirit of The Rule to the best of their ability. They view The Rule as their promise to all project users of how the developers are expected to behave. This is a one-way promise, or covenant. In other words, the developers are saying: “We will treat you this way regardless of how you treat us.”

The Rule

1. First of all, love the Lord God with your whole heart, your whole soul, and your whole strength.
2. Then, love your neighbor as yourself.
3. Do not murder.
4. Do not commit adultery.
5. Do not steal.
6. Do not covet.
7. Do not bear false witness.
8. Honor all people.
9. Do not do to another what you would not have done to yourself.
10. Deny oneself in order to follow Christ.
11. Chastise the body.
12. Do not become attached to pleasures.
13. Love fasting.
14. Relieve the poor.
15. Clothe the naked.
16. Visit the sick.
17. Bury the dead.
18. Be a help in times of trouble.
19. Console the sorrowing.
20. Be a stranger to the world’s ways.
21. Prefer nothing more than the love of Christ.
22. Do not give way to anger.
23. Do not nurse a grudge.
24. Do not entertain deceit in your heart.
25. Do not give a false peace.
26. Do not forsake charity.
27. Do not swear, for fear of perjuring yourself.
28. Utter only truth from heart and mouth.
29. Do not return evil for evil.
30. Do no wrong to anyone, and bear patiently wrongs done to yourself.
31. Love your enemies.
32. Do not curse those who curse you, but rather bless them.
33. Bear persecution for justice’s sake.
34. Be not proud.
35. Be not addicted to wine.
36. Be not a great eater.
37. Be not drowsy.
38. Be not lazy.
39. Be not a grumbler.
40. Be not a detractor.
41. Put your hope in God.
42. Attribute to God, and not to self, whatever good you see in yourself.
43. Recognize always that evil is your own doing, and to impute it to yourself.
44. Fear the Day of Judgment.
45. Be in dread of hell.
46. Desire eternal life with all the passion of the spirit.
47. Keep death daily before your eyes.
48. Keep constant guard over the actions of your life.
49. Know for certain that God sees you everywhere.
50. When wrongful thoughts come into your heart, dash them against Christ immediately.
51. Disclose wrongful thoughts to your spiritual mentor.
52. Guard your tongue against evil and depraved speech.
53. Do not love much talking.
54. Speak no useless words or words that move to laughter.
55. Do not love much or boisterous laughter.
56. Listen willingly to holy reading.
57. Devote yourself frequently to prayer.
58. Daily in your prayers, with tears and sighs, confess your past sins to God, and amend them for the future.
59. Fulfill not the desires of the flesh; hate your own will.
60. Obey in all things the commands of those whom God has placed in authority over you even though they (which God forbid) should act otherwise, mindful of the Lord’s precept, “Do what they say, but not what they do.”
61. Do not wish to be called holy before one is holy; but first to be holy, that you may be truly so called.
62. Fulfill God’s commandments daily in your deeds.
63. Love chastity.
64. Hate no one.
65. Be not jealous, nor harbor envy.
66. Do not love quarreling.
67. Shun arrogance.
68. Respect your seniors.
69. Love your juniors.
70. Pray for your enemies in the love of Christ.
71. Make peace with your adversary before the sun sets.
72. Never despair of God’s mercy.

(The header image is “St. Benedict delivering his Rule to St. Maurus and other monks of his order”, from a manuscript from Monastery of St. Gilles in Nîmes, France, dated 1129. The image is copied from Wikipedia Commons )

1. the Contributor Covent, the Django Code of Conduct and the Citizen Code of Conduct are the three codes of conduct, from GitHub’s Open Source Guide. ↩

2. “Purpose” (the first section) of the Citizen Code of Conduct ↩

We’re excited to announce that the June 2023 release of the Python and Jupyter extensions for Visual Studio Code are now available!

This release includes the following announcements:

• Test Discovery and Execution Rewrite
• Run Python File in Dedicated Terminal
• Preview: Intellisense support for overloaded operators
• Configurable indexing limits with Pylance

If you’re interested, you can check the full list of improvements in our changelogs for the Python, Jupyter and Pylance extensions.

Test Discovery and Execution Rewrite

This month, we are beginning the roll out of our testing rewrite behind an experimental feature. This rewrite redesigns the architecture behind test discovery and execution for both unittest and pytest in the extension. While it does not provide any additional functionality exposed to the user, it provides a faster and more stable experience, and opens up new functionality opportunities moving forward. The rewrite will be rolled out behind the experimental "pythonTestAdapter" flag, which you can opt into with "python.experiments.optInto" in your settings.json. Eventually, we plan to remove the setting and adopt this new architecture. If you have any comments or suggestions regarding this experiment or rewrite, please share them in the vscode-python repo.

Run Python File in Dedicated Terminal

UPDATE (13 June 2023) – This feature has been rolled back due to a bug tracked by vscode-python#21393.

The Python extension will now create a new terminal for each file you run using the run button in the top right corner of the editor or the Python: Run Python File in Terminal command. This also means the Python extension will keep using this file’s “dedicated” terminal every time you re-run the file.

Any time you wish to run the same file in a separate terminal, you can run select Python: Run Python File in Dedicated Terminal under the run button menu.

 

Preview: IntelliSense support for overloaded operators with Pylance

Overloaded operators allow you to redefine the behavior of built-in operators for your custom objects or data types. When using the latest pre-release version of the Pylance extension, you are now able to use IntelliSense to explore and utilize overloaded operators with ease and efficiency.

This functionality provides code completion, parameter information, and signature help for overloaded operators, whether you’re working with mathematical vectors, complex numbers, or any other custom classes.

Configurable indexing limits with Pylance

There’s a new Pylance setting that allows you to configure the file count limit for indexing: "python.analysis.userFileIndexingLimit", which is set to 2000 by default. This setting can be particularly helpful when you’re working with very large projects and are willing to compromise performance for an enhanced IntelliSense experience.

Other Changes and Enhancements

We have also added small enhancements and fixed issues requested by users that should improve your experience working with Python and Jupyter Notebooks in Visual Studio Code. Some notable changes include:

• New experimental createEnvironment.contentButton setting to disable the Create Environment button in dependency files (vscode-python#21212)
• Detect installed packages in the selected environment (vscode-python#21231)
• New python.analysis.inlayHints.callArgumentNames setting to enable inlay hints for call argument names with Pylance

We would also like to extend special thanks to this month’s contributors:

• @PeterjClaw Disable “snippers” expansion in Jedi LSP (vscode-python#21194)
• @JonathanRayner Add option for pyenv interpreters when creating environments with venv (vscode-python#21219)
• @cpinamtz Fix typo in a type declaration of MultiStepInput module (vscode-python#21156)
• @cpinamtz Insert debug configuration function on every quick pick item (vscode-python#21165)
• @cpinamtz Add more coverage to utils function (vscode-python#21026)
• @cpinamtz Remove IS_WINDOWS constant in favor of PlatformService (vscode-python#21157)

Try out these new improvements by downloading the Python extension and the Jupyter extension from the Marketplace, or install them directly from the extensions view in Visual Studio Code (Ctrl + Shift + X or ⌘ + ⇧ + X). You can learn more about Python support in Visual Studio Code in the documentation. If you run into any problems or have suggestions, please file an issue on the Python VS Code GitHub page.

The post Python in Visual Studio Code – June 2023 Release appeared first on Python.

Hello Guix!

I'm Sarthak and I'll be working on implementing Parameterized Packages for GNU Guix as a Google Summer of Code intern under the guidance of Pjotr Prins and Gábor Boskovits.

What are Parameterized Packages?

One of the many advantages of free software is the availability of compile-time options for almost all packages. Thanks to its dedication to building all packages from source, Guix is one of the few GNU/Linux distributions that can take advantage of these compile-time features; in fact, many advanced users such as those using Guix on High-Performance Computing Systems and new ISAs like RISC-V have already been doing this by utilizing a feature known as Package Transformations.

Parameterized Packages are a new type of package transformations that will be able to tweak an even wider array of compile-time options, such as removing unused dependencies or building a package with support for just a specific locale. These will have a wide variety of applications, ranging from High-Performance Computing to Embedded Systems and could also help tackle a few of Guix's issues like large binary sizes and dense dependency graphs.

What would these look like?

The syntax for parameterized packages is still under heavy deliberation, however the final syntax will have the following features:

• Maintainers will be able to specify what combinations of parameters a package supports, along with a default configuration of parameters for a given package.
• Users will be able to pass parameters they want enabled or disabled through --with-parameters which will then get validated against the valid combinations specified by maintainers before being run
• For a given package and a given set of parameters, only those in the package's parameter specification will be used
• Users will be able to specify a global parameter transform that will apply to all packages. Packages will be built with the default configuration if the global transform creates an invalid configuration.

Potential Problems with ParameterizationCombinatorial Explosion of Variants

One of the biggest and most obvious issues with parameters is the combinatorial explosion of package variants they will create. One way to address this is to use tools to calculate and regulate allowed complexity; one such tool could be a function that takes a parameter combination specification and returns the number of variants it could create.

Increase in Maintenance Required

Another concern is that this will lead to an increase in the workload of maintainers, who have been generously volunteering their time and have a lot of work as is. Hence, we will be treating parameters the same way we have been treating other package transformations- they are not expected to be stable, and should be used at the user's discretion.

Availability of Substitutes for Variants

Lastly, parameterization could lead to an exponential increase in the number of substitutes build farms will have to create, and thus as such there are only plans on building substitutes for default and very popular parameter combinations.

Other topics under discussion

Some of the other points of discussion with respect to parameters are

• Scope: Parameterization has a very wide and overarching scope, and it would be useful to have guidelines in place for when a particular property should be considered for parameterization
• Syntax: There are many proposed syntax designs for parameterization, and more are welcome! The final syntax will most probably be an amalgamation of the best parts of all proposed designs.
• Substitutes: There is a lot of discussion on exactly what parameter combinations should be considered for substitutes; while it is obvious that it won't be possible to build all combinations, some important combinations can and should be considered for having substitutes built. We could perhaps have a separate category of parameter combinations that would both receive substitutes and support, and make these combinations discoverable through the UI. Another suggestion is to have user-run channels for specific build combinations, like for example there could be a RISC-V specific channel supplying substitutes for the users running RISC-V.

If you would like to join the discussion, check out this mailing list discussion about this project, and also have a look at the original thread about parameterization.

Conclusion

Parameters hold the potential to greatly increase Guix's flexibility, but will also lead to greater complexity. In my opinion, Guix is uniquely positioned to take full advantage of the customizability provided by compile-time options while also enjoying relative stability thanks to its transactional nature.

About Me

I'm a student studying Mathematics and ECE at BITS Pilani, and I love computers and free software. I am the president of my university's equivalent of a Free Software Advocacy Group, and I am also one of the system administrators for my university's High-Performance Computing System. As an advocate for free software and a Lisp user, I naturally fell in love with GNU Guix when I discovered it. I have also used Gentoo for some time in the past, which motivated me to try and bring something similar to USE flags to Guix. You can find my blog at blog.lispy.tech, where I will be frequently posting updates about the project.

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, AArch64 and POWER9 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

Extended End-of-Life Timeline for Drupal 7