FLOSS Project Planets

The Free Software Foundation (FSF), a Massachusetts 501(c)(3) charity with a worldwide mission to protect computer user freedom, seeks a motivated and talented individual, if possible Boston-based, to be our full-time outreach and communications coordinator.

Join the FSF and friends on Friday, January 19, from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

Let’s go for my web review for the week 2024-02.

Where have all the websites gone?

Tags: tech, web, blog, culture

This is in part why I started my web review… maybe I should start a kind of blogroll, or maybe have links to websites I like straight on my front page.

https://www.fromjason.xyz/p/notebook/where-have-all-the-websites-gone/

The browsers biggest TLS mistake

Tags: tech, browser, tls, security

Some of that certificate chain validation is troublesome… in Chrome based browsers it’s even truly insane.

https://blog.benjojo.co.uk/post/browsers-biggest-tls-mistake

This holographic camera turns any window into an invisible camera | Digital Camera World

Tags: tech, surveillance

What could possibly go wrong? Panopticon 2.0 here we come.

https://www.digitalcameraworld.com/news/this-holographic-camera-turns-any-window-into-an-invisible-camera

Outlook is Microsoft’s new data collection service | Proton

Tags: tech, microsoft, windows, email, surveillance

Looks like Microsoft is really catching up fast for its surveillance apparatus to be on par with Google and Meta.

https://proton.me/blog/outlook-is-microsofts-new-data-collection-service

Meta ignores the users’ right to easily withdraw consent

Tags: tech, law, facebook, surveillance, attention-economy

Very welcome complaont, Meta is trying to workaround the GDPR to increase paid accounts. Can only hope they get fined and that this shady practice disappear (they’re not the only ones doing this).

https://noyb.eu/en/meta-ignores-users-right-easily-withdraw-consent

Messengers performance - Grafana

Tags: tech, messaging, battery, android

If you’re wondering where your battery power goes… this is a nice list of measures for various clients on Android. It looks like XMPP is still hard to beat.

https://decentim.grafana.net/public-dashboards/92602d3a4aa842ce97812d310077691d?orgId=1

How I pwned half of America’s fast food chains, simultaneously

Tags: tech, security

A not so gentle reminder that you shouldn’t get sloppy in the security practices of your services.

https://mrbruh.com/chattr/

SSH-Snake: Automatic traversal of networks using SSH private keys

Tags: tech, ssh, security, tools

Fascinating script which jumps over SSH servers in several hops and replicates itself without a file upload.

https://joshua.hu/ssh-snake-ssh-network-traversal-discover-ssh-private-keys-network-graph

SSH based comment system

Tags: tech, ssh, blog

Very funny hack for a blog comment system.

https://blog.haschek.at/2023/ssh-based-comment-system.html

Automate your outgoing webmentions

Tags: tech, self-hosting, blog, webmention

Looks like a nice way to ease the use of webmentions. Also comes with a command line option not relying on third party hosted service apparently.

https://webmention.app/

Visualizing ext4

Tags: tech, filesystem

Fascinating exploration of the patterns visible inside ext4 filesystems.

https://buredoranna.github.io/linux/ext4/2020/01/09/ext4-viz.html

A tool for exploring each layer in a docker image

Tags: tech, docker, tools

Looks like an interesting tool if you’re dealing with docker image. This kind of analysis is definitely missing from docker itself.

https://github.com/wagoodman/dive

Do we think of git commits as diffs, snapshots, and/or histories?

Tags: tech, git, version-control, teaching

So, which team are you on when you think about commits in Git?

https://jvns.ca/blog/2024/01/05/do-we-think-of-git-commits-as-diffs–snapshots–or-histories/

Statically enforcing frozen data classes in Python | Redowan’s Reflections

Tags: tech, python, type-systems

Interesting trick even though I always cringe at such difference of behavior between runtime and “compile” time.

https://rednafi.com/python/statically_enforcing_frozen_dataclasses/

Python 3.13 gets a JIT

Tags: tech, python, jit, optimization

Want to better understand the JIT approach introduced in Python 3.13, this is a good little article. This JIT is a first step towards more optimizations.

https://tonybaloney.github.io/posts/python-gets-a-jit.html

Vcc - the Vulkan Clang Compiler

Tags: tech, shader, vulkan, c++

Interesting proof of concept to compile C++ into shaders. This reminds CUDA a bit without being tied to a given GPU brand.

https://shady-gang.github.io/vcc/

Tidy First? | Henrik Warne’s blog

Tags: tech, refactoring, craftsmanship, book

Review of the newest book from Kent Beck, I’ll probably check it out and read it.

https://henrikwarne.com/2024/01/10/tidy-first/?

Are any of your features the steak on the menu? | nicole@web

Tags: tech, product-management

Interesting metaphor regarding that feature you have because it is expected but otherwise doesn’t quote work.

https://ntietz.com/blog/the-steak-on-the-menu/

How to make your team read your mind - by Anton Zaides

Tags: tech, management

Interesting approach for a manager to give transparency and to clarify expectations.

https://zaidesanton.substack.com/p/how-to-make-your-team-read-your-mind

My Diverse Hiring Playbook - Jacob Kaplan-Moss

Tags: tech, hr, hiring

Good list of tips and ideas. This is not necessarily as easy as it sounds. The lack of good metrics doesn’t help (totally understandable though, privacy first).

https://jacobian.org/2024/jan/4/diverse-hiring-playbook/

Bye for now!

Version 0.0.16 of RcppSpdlog is now on CRAN and will be uploaded to Debian. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn more at the nice package documention site.

This releases updates the code to the version 1.13 of spdlog which was release this morning.

The NEWS entry for this release follows.

Changes in RcppSpdlog version 0.0.16 (2024-01-12)

• Upgraded to upstream releases spdlog 1.13.0

Courtesy of my CRANberries, there is also a diffstat report. More detailed information is on the RcppSpdlog page, or the package documention site.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

An new version 0.2.6 of the random-number generator tester RDieHarder (based on the DieHarder suite developed / maintained by Robert Brown with contributions by David Bauer and myself along with other contributors) is now on CRAN (and to the day year after the previous release).

This release contains changes to printf format strings to avoid new warnings on Windows. No functional changes have been made.

Thanks to CRANberries, you can also look at the most recent diff to the previous release.

If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

We’re pleased to announce the release of KDSoap version 2.2.0, an update that brings new enhancements to improve both the general build system and client-side functionality.

What is KDSoap?

KDSoap, a SOAP (“Simple Object Access Protocol“) component rooted in Qt, serves as an essential tool for both client-side and server-side operations. Tailored for C++ programmers using Qt, it not only facilitates the creation of client applications for web services but also empowers developers to seamlessly build web services without requiring additional components like dedicated web servers. For further details on KDSoap, visit here.

What’s New in KDSoap Version 2.2.0?

Build System Co-installability: The buildsystem now supports the co-installability of Qt 5 and Qt 6 headers. Qt 6 headers are installed into their dedicated subdirectory. This ensures compatibility with client code and allows co-installation with Qt 5.

Client-Side:

• WS-Addressing Support: The new release adds KDSoapClientInterface::setMessageAddressingProperties(). This addition enables the use of WS-Addressing support specifically with WSDL-generated services.
• SOAP Action Requirement Removal: KDSoap no longer requires a SOAP action for writing addressing properties.

WSDL Parser / Code Generator Changes:

Enhanced -import-path Support: Notable changes have been made to the WSDL parser and code generator, impacting both client and server sides. The update improves -import-path support by incorporating the import path in more areas within the code. This refinement enhances the overall functionality of the parser and code generator.

These updates collectively contribute to a more streamlined and efficient experience for KDSoap users, addressing specific issues and introducing valuable features to facilitate seamless integration with Qt-based applications. For detailed information and to explore these enhancements, we refer to the KDSoap documentation accompanying version 2.2.0 on GitHub.

How to Get Started with KDSoap Version 2.2.0?

For existing users, upgrading to the latest version is as simple as downloading the new release from the GitHub page. If you are new to KDSoap, we invite you to explore its capabilities and discover how it can streamline your web service development process.

As always, we appreciate your feedback and contributions to make KDSoap even better. Feel free to reach out to us with any questions, suggestions or bug reports on our GitHub repository.

Thank you for choosing KDSoap, and happy coding!

About KDAB

If you like this article and want to read similar material, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post KDSoap 2.2.0 Released appeared first on KDAB.

Do you need to transfer an extensive data collection for a science project? What's the best way to send executable code over the wire for distributed processing? What are the different ways to serialize data in Python? Christopher Trudeau is back on the show this week, bringing another batch of PyCoder's Weekly articles and projects.

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

Back in April, we wrote to the community about our concerns for the future of the open source ecosystem generally and CPython and PyPI specifically if the European Cyber Resilience Act (CRA) were to pass in the form that had been shared. At the time, we were worried that in the course of providing software for anyone to use, analyze or change that the PSF and/or the Python community might become legally responsible for security issues in the products that are built with the code components that we are providing for free. We asked for increased clarity, specifically:

“Language that specifically exempts public software repositories that are offered as a public good for the purpose of facilitating collaboration would make things much clearer. We'd also like to see our community, especially the hobbyists, individuals and other under-resourced entities who host packages on free public repositories like PyPI be exempt.”

The good news is that CRA text* changed a lot between the time the open source community – including the PSF – started expressing our concerns and the Act’s final text which was cemented on December 1st. That text introduces the idea of an “open source steward.”

“'open-source software steward’ means any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products;” (p. 76)

Furthermore, the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

“More specifically, for the purpose of this Regulation and in relation to the economic operators referred therein, to ensure that there is a clear distinction between the development and the supply phases, the provision of free and open-source software products with digital elements that are not monetised by their manufacturers is not considered a commercial activity.” (p. 10)

So are we totally done paying attention to European legislation? Ah, while it would be nice for the Python community to be able to cross a few things off our to-do list, that’s not quite how it works. Firstly, the concept of an “open source steward” is a brand new idea in European law. So, we will be monitoring the conversation as this new concept is implemented or interacts with other bits of European law to make sure that the understanding continues to reflect the intent and the realities of open source development. Secondly, there are some other pieces of legislation in the works that may also impact the Python ecosystem so we will be watching the Product Liability Directive and keeping up with the discussion around standard-essential patents to make sure that the effects on Python and open source development are intentional (and hopefully benevolent, or at least benign.) 

Thank you to Open Forum Europe (OFE) — especially Ciarán O’Riordan – for bringing the FOSS community together to share our thoughts on how the proposed text would affect open source, thinking about how the goals of the proposed act might be achieved without unintentionally creating a chilling effect for open source and communicating those ideas to legislators. OFE’s work to coordinate our efforts certainly made it easier for the PSF’s concerns to be heard and I’m fairly certain it made it easier for legislators to assess and consider impacts to the open source ecosystem when we were able to speak with one voice. 

*The entire Regulation is published here, if you want to dive into the text more deeply.

Are you working on a Drupal website and being tormented by a storm of issues? If the answer is yes, just know that you are not alone. Anyone who offers Drupal development services, be it a Drupal development company or an individual freelancer, encounters these issues during the development, deployment, or maintenance stage. 

Now, is your mind being boggled by the question, “Then, how do they manage to sail through the challenges they come across?” The answer lies in some sureshot debugging techniques that help in eradicating any issues you encounter while building or working on a Drupal site. 

Explore Novicell's groundbreaking journey harnessing Drupal 10's power to revolutionize high-traffic websites, featuring the success story of kino.dk. Discover how they achieved 100% uptime and unparalleled performance.

When working on big Python projects or trying to organize your code better, you need to know how to bring in code from other Python files. This is called “importing,” and it’s a crucial skill for reusing code and keeping things neat. In this guide, we’ll explore different ways to import another Python file into […]

The post How to Import Another Python File appeared first on TechBeamers.

Search API Field Token module functionality has been merged in Search API 8.x-1.30, and the Search API Field Token module reached End-of-life on 30 November 2023

Release 0.6.34 of the digest package arrived at CRAN today and has also been uploaded to Debian already.

digest creates hash digests of arbitrary R objects. It can use a number different hashing algorithms (md5, sha-1, sha-256, sha-512, crc32, xxhash32, xxhash64, murmur32, spookyhash, blake3, and crc32c), and ebales easy comparison of (potentially large and nested) R language objects as it relies on the native serialization in R. It is a mature and widely-used package (with 63.8 million downloads just on the partial cloud mirrors of CRAN which keep logs) as many tasks may involve caching of objects for which it provides convenient general-purpose hash key generation to quickly identify the various objects.

(Oh and we also just passed the 20th anniversary of the initial CRAN upload. Time flies, as they say.)

This release contains small (build-focussed) enhancements contributed by Michael Chirico, and another set of fixed for printf format warnings this time on Windows.

My CRANberries provides a summary of changes to the previous version. For questions or comments use the issue tracker off the GitHub repo.

If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Like each month, have a look at the work funded by Freexian’s Debian LTS offering.

Debian LTS contributors

In December, 18 contributors have been paid to work on Debian LTS, their reports are available:

• Abhijith PA did 7.0h (out of 7.0h assigned and 7.0h from previous period), thus carrying over 7.0h to the next month.
• Adrian Bunk did 16.0h (out of 26.25h assigned and 8.75h from previous period), thus carrying over 19.0h to the next month.
• Bastien Roucariès did 16.0h (out of 16.0h assigned and 4.0h from previous period), thus carrying over 4.0h to the next month.
• Ben Hutchings did 8.0h (out of 7.25h assigned and 16.75h from previous period), thus carrying over 16.0h to the next month.
• Chris Lamb did 18.0h (out of 18.0h assigned).
• Emilio Pozuelo Monfort did 8.0h (out of 26.75h assigned and 8.25h from previous period), thus carrying over 27.0h to the next month.
• Guilhem Moulin did 25.0h (out of 18.0h assigned and 7.0h from previous period).
• Holger Levsen did 5.5h (out of 5.5h assigned).
• Jochen Sprickerhof did 0.0h (out of 0h assigned and 10.0h from previous period), thus carrying over 10.0h to the next month.
• Lee Garrett did 0.0h (out of 25.75h assigned and 9.25h from previous period), thus carrying over 35.0h to the next month.
• Markus Koschany did 35.0h (out of 35.0h assigned).
• Roberto C. Sánchez did 9.5h (out of 5.5h assigned and 6.5h from previous period), thus carrying over 2.5h to the next month.
• Santiago Ruano Rincón did 8.255h (out of 3.26h assigned and 12.745h from previous period), thus carrying over 7.75h to the next month.
• Sean Whitton did 4.25h (out of 3.25h assigned and 6.75h from previous period), thus carrying over 5.75h to the next month.
• Sylvain Beucler did 16.5h (out of 21.25h assigned and 13.75h from previous period), thus carrying over 18.5h to the next month.
• Thorsten Alteholz did 14.0h (out of 14.0h assigned).
• Tobias Frost did 10.25h (out of 12.0h assigned), thus carrying over 1.75h to the next month.
• Utkarsh Gupta did 18.75h (out of 11.25h assigned and 13.5h from previous period), thus carrying over 6.0h to the next month.

Evolution of the situation

In December, we have released 29 DLAs.

A particularly notable update in December was prepared by LTS contributor Santiago Ruano Rincón for the openssh package. The updated produced DLA-3694-1 and included a fix for the Terrapin Attack (CVE-2023-48795), which was a rather serious flaw in the SSH protocol itself. The package bluez was the subject of another notable update by LTS contributor Chris Lamb, which resulted in DLA-3689-1 to address an insecure default configuration which allowed attackers to inject keyboard commands over Bluetooth without first authenticating.

The LTS team continues its efforts to have a positive impact beyond the boundaries of LTS. Several contributors worked on packages, preparing LTS updates, but also preparing patches or full updates which were uploaded to the unstable, stable, and oldstable distributions, including: Guilhem Moulin’s update of tinyxml (uploads to LTS and unstable and patches submitted to the security team for stable and oldstable); Guilhem Moulin’s update of xerces-c (uploads to LTS and unstable and patches submitted to the security team for oldstable); Thorsten Alteholz’s update of libde265 (uploads to LTS and stable and additional patches submitted to the maintainer for stable and oldstable); Thorsten Alteholz’s update of cjson (upload to LTS and patches submitted to the maintainer for stable and oldstable); and Tobias Frost’s update of opendkim (sponsor maintainer-prepared upload to LTS and additionally prepared updates for stable and oldstable).

Going beyond Debian and looking to the broader community, LTS contributor Bastien Roucariès was contacted by SUSE concerning an update he had prepared for zbar. He was able to assist by coordinating with the former organization of the original zbar author to secure for SUSE access to information concerning the exploits. This has enabled another distribution to benefit from the work done in support of LTS and from the assistance of Bastien in coordinating the access to information.

Finally, LTS contributor Santiago Ruano Rincón continued work relating to how updates for packages in statically-linked language ecosystems (e.g., Go, Rust, and others) are handled. The work is presently focused on more accurately and reliably identifying which packages are impacted in a given update scenario to enable notifications to be published so that users will be made aware of these situations as they occur. As the work continues, it will eventually result in improvements to Debian infrustructure so that the LTS team and Security team are able to manage updates of this nature in a more consistent way.

Thanks to our sponsors

Sponsors that joined recently are in bold.

• Platinum sponsors:
  • TOSHIBA (for 100 months)
  • Civil Infrastructure Platform (CIP) (for 68 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 111 months)
  • Linode (for 105 months)
  • Babiel GmbH (for 94 months)
  • Plat’Home (for 94 months)
  • University of Oxford (for 50 months)
  • Deveryware (for 37 months)
  • VyOS Inc (for 32 months)
  • EDF SA (for 21 months)
• Silver sponsors:
  • Domeneshop AS (for 115 months)
  • Nantes Métropole (for 109 months)
  • Univention GmbH (for 101 months)
  • Université Jean Monnet de St Etienne (for 101 months)
  • Ribbon Communications, Inc. (for 95 months)
  • Exonet B.V. (for 85 months)
  • Leibniz Rechenzentrum (for 79 months)
  • CINECA (for 68 months)
  • Ministère de l’Europe et des Affaires Étrangères (for 62 months)
  • Cloudways by DigitalOcean (for 52 months)
  • Dinahosting SL (for 50 months)
  • Bauer Xcel Media Deutschland KG (for 44 months)
  • Platform.sh SAS (for 44 months)
  • Moxa Inc. (for 38 months)
  • sipgate GmbH (for 35 months)
  • OVH US LLC (for 33 months)
  • Tilburg University (for 33 months)
  • GSI Helmholtzzentrum für Schwerionenforschung GmbH (for 25 months)
  • Soliton Systems K.K. (for 22 months)
• Bronze sponsors:
  • Evolix (for 116 months)
  • Seznam.cz, a.s. (for 116 months)
  • Intevation GmbH (for 113 months)
  • Linuxhotel GmbH (for 113 months)
  • Daevel SARL (for 111 months)
  • Bitfolk LTD (for 110 months)
  • Megaspace Internet Services GmbH (for 110 months)
  • Greenbone AG (for 109 months)
  • NUMLOG (for 109 months)
  • WinGo AG (for 109 months)
  • Ecole Centrale de Nantes - LHEEA (for 105 months)
  • Entr’ouvert (for 100 months)
  • Adfinis AG (for 97 months)
  • GNI MEDIA (for 92 months)
  • Laboratoire LEGI - UMR 5519 / CNRS (for 92 months)
  • Tesorion (for 92 months)
  • Bearstech (for 83 months)
  • LiHAS (for 83 months)
  • Catalyst IT Ltd (for 78 months)
  • Supagro (for 73 months)
  • Demarcq SAS (for 72 months)
  • Université Grenoble Alpes (for 58 months)
  • TouchWeb SAS (for 50 months)
  • SPiN AG (for 47 months)
  • CoreFiling (for 42 months)
  • Institut des sciences cognitives Marc Jeannerod (for 37 months)
  • Observatoire des Sciences de l’Univers de Grenoble (for 34 months)
  • Tem Innovations GmbH (for 29 months)
  • WordFinder.pro (for 28 months)
  • CNRS DT INSU Résif (for 27 months)
  • Alter Way (for 20 months)
  • Institut Camille Jordan (for 9 months)

Contents

• Nuitka this week #14

  • Communication vs. Coding

  • Nuitka has evolved a lot

  • Community

  • Optimization Work

  • Current Evolutions

  • Teasers

  • Twitter and Mastodon

  • Help Wanted

Communication vs. Coding

After GSoC 2019, it seems I dropped off with communication about Nuitka quite a lot, e.g. I stopped “Nuitka This Week”. The reasons are multi-facetted. I think part of the reason is that I was getting busy, part of it clearly also was Corona. But also a more dreadful change in my private life, where the real life Nuitka, my wife, became ill for a long time. Effectively it’s only become really better mid last year.

I think, this caused me to go full into code for Nuitka, and to launch Nuitka commercial, but generally to become more quiet. I have already relaxed this for a bit, e.g. about Python 3.11, I made a bunch of postings.

So this one is a bit general to start off, but I also provide fairly recent details about what I worked on for 2.0 as well.

Nuitka has evolved a lot

From a usability standpoint, ever since I went all in with Nuitka, but also before, the out of the box experience of Nuitka has become ever better. And even 2.0 will take it noticeable further. It’s the premier choice for Python deployment if you want efficiency. Its onefile mode is pretty great already and is continuously getting better.

It’s fair to say that Nuitka was great in 2019. I think in 2023 it became almost amazing for deployment. This is in large part due to working on the Yaml configuration and these things. In 2024 I hope to get it really smooth.

I actually made posts about the Yaml stuff, and I will resume it shortly, basically it allows people to help improve the deployment side of Nuitka, e.g. missing DLLs and data files, hacks needed, etc. for packages, and it’s quickly becoming better and complete.

Community

On the Discord server, I have been in touch with users of Nuitka a lot more. You are welcome to join us on the Discord server for Nuitka community where you can hang out with the developers and ask questions. It’s not intended as an interactive manual. You are supposed to read the docs for yourself first.

I am also now occasionally on the Python Discord server. Mostly when I get summoned to answer questions that my community thinks make sense, and have been awarded the community role there, which is pretty nice. I seem to make new connections there.

Optimization Work

I think, it’s in vain to explain what I did for performance in all that time. Mostly, some technical debts for Python3 were collected, extending to advantage in in speed of Nuitka over pure Python again. The advantage compared on Python2 was not as present, and still is not, on Python3, but for 3.10 it’s pretty good.

The major breakthroughs have not happened. But I will be taking about the plans, these sure are exciting. Lots of things are in place, some are not, but I hope to get there.

Current Evolutions

So things on my mind right now, for one, I guess, 4 plugin changes that I have yet to document in new postings. Two are visible here in this code.

- module-name: 'toga.platform' # checksum: 4db91cac variables: setup_code: 'import toga.platform' declarations: 'toga_backend_module_name': 'toga.platform.get_platform_factory().__name__' anti-bloat: - change_function: 'get_platform_factory': "'importlib.import_module(%r)' % get_variable('toga_backend_module_name')"

First, the checksum. Nuitka is going to warn you about checking your user yaml files for correctness in the future. Since it often finds structural problems, very much needed, since yaml is whitespace sensitive, and you never know what it is a list, a dict, etc. but the schema we created, can tell.

Second, variables are a new section, and in fact so new, they are not even documented. They can be used to query at compile time values from code. In this case we are using it to get at the backend to use, so we can tell it at runtime. Otherwise, it’s hidden to Nuitka, and could e.g. still be subject to a changed decision from environment variables, something we typically do not want.

For the third and forth thing, we need another example. Torch can use a JIT to speed up some things, with a compilation very similar to what Nuitka does. That however needs a compiler and the source code on the target platform. Not an easy ask for all kinds of deployments. A new feature makes this easier than before.

- module-name: 'torch' # checksum: ada8ede8 parameters: - 'name': 'enable-jit' 'values': 'value in ("yes", "no")' options: checks: - description: "Torch JIT is disabled by default, make a choice explicit with '--module-parameter=torch-disable-jit=yes|no'" support_info: 'parameter' when: 'standalone and get_parameter("disable-jit", None) is None' import-hacks: - force-environment-variables: 'PYTORCH_JIT': '0' when: 'get_parameter("disable-jit", "no" if standalone else "yes") == "yes"'

So, what this does, is to make Nuitka accept parameters. The options part is designed to complain when the default value is used in standalone mode, kind of making the user acknowledge that it’s the intended value. For accelerated mode, we do not disable the JIT, since we can expect to be in the same environment with source code intact.

With get_parameter you get the option value, and can be conditional on it in the when block. That is the 3rd new thing.

The forth new thing, is the forcing of environment variables. We have so far done this, including in plugins like tk-inter manually with post-load-code. The above is the same, effectively doing os.environ["PYTORCH_JIT"] = "0" if the JIT is to be disabled.

These changes are designed to avoid having to do plugins again. Historically for toga support, we should have been a new plugin, but now it’s not, since the Yaml mechanism can cover retrieval of compile time values from modules. And for torch and the JIT, a plugin would have been needed to provide the command line control for that decision.

This increased power of the Yaml will make it even less often the case that a plugin must be written. But of course docs will have to be added and maybe more places will need to work with variables to make that true even more often. More on that in the future.

Teasers

Future TWN will speak about Nuitka-Python (our own Python fork with incredible capabilities), about Nuitka-Watch (our way of making sure Nuitka works with PyPI packages and hot-fixes to not regress), about compilation reports as a new feature, Windows AV stuff, onefile improvements, and so on and so on. I got interesting stuff for many weeks. Limiting myself for now or I will never publish this.

Twitter and Mastodon

I should be more active there, although often I fall prey to of not wanting to talk about unfinished things, so actually I do not post there as much.

• Follow @kayhayen on Twitter

• Follow @kayhayen on Mastodon

And lets not forget, having followers make me happy. So do re-tweets. Esp. those, please do them.

Help Wanted

System Message: INFO/1 (/home/nuitka-buildslave/slave/site-main-update/build/doc/posts/nuitka-this-week-14.rst, line 7); backlink

Duplicate implicit target name: “help wanted”.

If you are interested, I am tagging issues help wanted and there is a bunch, and very likely at least one you can help with.

Nuitka definitely needs more people to work on it.

Make sure you commit anything you want to end up in the KDE Gear 24.02 releases to them

Next Dates:

•    January 31: 24.02 RC 2 (24.01.95) Tagging and Release
•   February 21: 24.02 Tagging
•   February 28: 24.02 Release

https://community.kde.org/Schedules/February_2024_MegaRelease

We're thrilled to share that the Sovereign Tech Fund (STF), based in Germany, has generously entrusted the Drupal Association with a $300,000 USD service contract for work done to benefit the public. This funding is set to fuel two crucial projects that promise to strengthen security for Drupal and enhance the Drupal ecosystem.

The Sovereign Tech Fund (STF) supports the development, improvement, and maintenance of open digital infrastructure in the public interest. Its goal to strengthen the open source ecosystem sustainably, focusing on security, resilience, technological diversity, and the people behind the code. STF is funded by the German Federal Ministry for Economic Affairs and Climate Action (BMWK) and hosted at and supported by the German Federal Ag-ency for Disruptive Innovation GmbH (SPRIND).

The Drupal Association, along with the Drupal community, support Drupal with core support, community support, flagship programs, and new innovation. The Drupal Association is a unicorn in the software sector in terms of structure and true community - and is a leader for open source collaboration and an open web.

Project 1: Developer Tools Acceleration

This project will optimize GitLab CI, streamline user authentication with Keycloak, migrate Drupal contribution credits from the old issue queue to a new GitLab integration, create a seamless opt-in process for Drupal.org hosted projects to transition to GitLab issues, and develop an accessible learning guide. The guide will be a valuable resource for project maintainers looking to shift from Drupal.org's custom tooling to GitLab.

Project 2: Community Supply Chain Security

This initiative aims to enhance the security of the Drupal ecosystem by securing the signing prototype, conducting a third-party security audit of the PHP-TUF client and Rugged server, and performing a third-party security audit of the Drupal integration code. Additionally, the project will deploy secure signing in a production environment, further bolstering the security measures in place.

This funding aligns perfectly with the Drupal Association's strategic priorities. It enables us to make significant strides towards our goals, particularly in terms of optimizing our workflows through GitLab and enhancing our security measures with secure signing. Both projects will conclude before 31 March 2024.

The partnership with STF allows us to make a positive difference in the Drupal community and advance the open source platform for all users. We are grateful to the Sovereign Tech Fund for their generous support. Their funding shows dedication to open source and their belief in the Drupal Association and the community's ability to innovate and ensure the future of web development.

Hey nonprofit Drupal users! The DA is interested in supporting community-driven content that is specifically relevant to nonprofit organization staff and related agencies at DrupalCon North America in Portland, Oregon, at the Nonprofit Summit on May 9, 2024.

We are looking for volunteers who would be interested in giving back to the community by contributing some subject matter expertise via a day of informal breakout sessions or other group activities. We are open to ideas!

Who are we looking for?

Do you have some Drupal expertise or a recent experience with a Drupal project that you would like to share with others? Is there something about Drupal that you think is really cool that you would love to share with the nonprofit Drupal community?

What’s required?

You will not be required to make slides! You don’t need to have lots of (or any) speaking experience! All you need is a willingness to facilitate a discussion group or engaging activity around a particular topic, and some expertise or enthusiasm for that topic that you wish to share. 

How to Submit an Idea or Topic

Please fill out this form by February 13th and we will get back to you as soon as we are able. Thank you! https://forms.gle/MJthh68rsFeZsuVc8

Discussion leaders will be selected by the Nonprofit Summit Planning Committee and will be notified by the end of February. 

Questions? 

Email nonprofitsummit@association.drupal.org.

Welcome to the December 2023 report from the Reproducible Builds project! In these reports we outline the most important things that we have been up to over the past month. As a rather rapid recap, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries (more).

Reproducible Builds: Increasing the Integrity of Software Supply Chains awarded IEEE Software “Best Paper” award

In February 2022, we announced in these reports that a paper written by paper Chris Lamb and Stefano Zacchiroli was now available in the March/April 2022 issue of IEEE Software. Titled Reproducible Builds: Increasing the Integrity of Software Supply Chains (PDF).

This month, however, IEEE Software announced that this paper has won their Best Paper award for 2022.

Reproducibility to affect package migration policy in Debian

In a post summarising the activities of the Debian Release Team at a recent in-person Debian event in Cambridge, UK, Paul Gevers announced a change to the way packages are “migrated” into the staging area for the next stable Debian release based on its reproducibility status:

The folks from the Reproducibility Project have come a long way since they started working on it 10 years ago, and we believe it’s time for the next step in Debian. Several weeks ago, we enabled a migration policy in our migration software that checks for regression in reproducibility. At this moment, that is presented as just for info, but we intend to change that to delays in the not so distant future. We eventually want all packages to be reproducible. To stimulate maintainers to make their packages reproducible now, we’ll soon start to apply a bounty [speedup] for reproducible builds, like we’ve done with passing autopkgtests for years. We’ll reduce the bounty for successful autopkgtests at that moment in time.

Speranza: “Usable, privacy-friendly software signing”

Kelsey Merrill, Karen Sollins, Santiago Torres-Arias and Zachary Newman have developed a new system called Speranza, which is aimed at reassuring software consumers that the product they are getting has not been tampered with and is coming directly from a source they trust. A write-up on TechXplore.com goes into some more details:

“What we have done,” explains Sollins, “is to develop, prove correct, and demonstrate the viability of an approach that allows the [software] maintainers to remain anonymous.” Preserving anonymity is obviously important, given that almost everyone—software developers included—value their confidentiality. This new approach, Sollins adds, “simultaneously allows [software] users to have confidence that the maintainers are, in fact, legitimate maintainers and, furthermore, that the code being downloaded is, in fact, the correct code of that maintainer.” […]

The corresponding paper is published on the arXiv preprint server in various formats, and the announcement has also been covered in MIT News.

Nondeterministic Git bundles

Paul Baecher published an interesting blog post on Reproducible git bundles. For those who are not familiar with them, Git bundles are used for the “offline” transfer of Git objects without an active server sitting on the other side of a network connection. Anyway, Paul wrote about writing a backup system for his entire system, but:

I noticed that a small but fixed subset of [Git] repositories are getting backed up despite having no changes made. That is odd because I would think that repeated bundling of the same repository state should create the exact same bundle. However [it] turns out that for some, repositories bundling is nondeterministic.

Paul goes on to to describe his solution, which involves “forcing git to be single threaded makes the output deterministic”. The article was also discussed on Hacker News.

Output from libxlst now deterministic

libxslt is the XSLT C library developed for the GNOME project, where XSLT itself is an XML language to define transformations for XML files. This month, it was revealed that the result of the generate-id() XSLT function is now deterministic across multiple transformations, fixing many issues with reproducible builds. As the Git commit by Nick Wellnhofer describes:

Rework the generate-id() function to return deterministic values. We use a simple incrementing counter and store ids in the 'psvi' member of nodes which was freed up by previous commits. The presence of an id is indicated by a new "source node" flag. This fixes long-standing problems with reproducible builds, see https://bugzilla.gnome.org/show_bug.cgi?id=751621 This also hardens security, as the old implementation leaked the difference between a heap and a global pointer, see https://bugs.chromium.org/p/chromium/issues/detail?id=1356211 The old implementation could also generate the same id for dynamically created nodes which happened to reuse the same memory. Ids for namespace nodes were completely broken. They now use the id of the parent element together with the hex-encoded namespace prefix.

Community updates

There were made a number of improvements to our website, including Chris Lamb fixing the generate-draft script to not blow up if the input files have been corrupted today or even in the past […], Holger Levsen updated the Hamburg 2023 summit to add a link to farewell post […] & to add a picture of a Post-It note. […], and Pol Dellaiera updated paragraph about tar and the --clamp-mtime flag […].

On our mailing list this month, Bernhard M. Wiedemann posted an interesting summary on some of the reasons why packages are still not reproducible in 2023.

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including processing objdump symbol comment filter inputs as Python byte (and not str) instances […] and Vagrant Cascadian extended diffoscope support for GNU Guix […] and updated the version in that distribution to version 253 […].

“Challenges of Producing Software Bill Of Materials for Java”

Musard Balliu, Benoit Baudry, Sofia Bobadilla, Mathias Ekstedt, Martin Monperrus, Javier Ron, Aman Sharma, Gabriel Skoglund, César Soto-Valero and Martin Wittlinger (!) of the KTH Royal Institute of Technology in Sweden, have published an article in which they:

… deep-dive into 6 tools and the accuracy of the SBOMs they produce for complex open-source Java projects. Our novel insights reveal some hard challenges regarding the accurate production and usage of software bills of materials.

The paper is available on arXiv.

Debian Non-Maintainer campaign

As mentioned in previous reports, the Reproducible Builds team within Debian has been organising a series of online and offline sprints in order to clear the huge backlog of reproducible builds patches submitted by performing so-called NMUs (Non-Maintainer Uploads).

During December, Vagrant Cascadian performed a number of such uploads, including:

• crack […] (#1021521 & #1021522)
• dustmite […] (#1020878 & #1020879)
• edid-decode […] (#1020877)
• gentoo […] (#1024284)
• haskell98-report […] (#1024007)
• infinipath-psm […] (#990862)
• lcm […] (#1024286)
• libapache-mod-evasive […] (#1020800)
• libccrtp […] (#860470)
• libinput […] (#995809)
• lirc […] (#979019, #979023 & #979024)
• mm-common […] (#977177)
• mpl-sphinx-theme […] (#1005826)
• psi […] (#1017473)
• python-parse-type […] (#1002671)
• ruby-tioga […] (#1005727)
• ucspi-proxy […] (#1024125)
• ypserv […] (#983138)

In addition, Holger Levsen performed three “no-source-change” NMUs in order to address the last packages without .buildinfo files in Debian trixie, specifically lorene (0.0.0~cvs20161116+dfsg-1.1), maria (1.3.5-4.2) and ruby-rinku (1.7.3-2.1).

Reproducibility testing framework

The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In December, a number of changes were made by Holger Levsen:

• Debian-related changes:

  • Fix matching packages for the R programming language. […][…][…]
  • Add a [Certbot](https://certbot.eff.org/ configuration for the Nginx web server. […]
  • Enable debugging for the create-meta-pkgs tool. […][…]

• Arch Linux-related changes

  • The asp has been deprecated by pkgctl; thanks to dvzrv for the pointer. […]
  • Disable the Arch Linux builders for now. […]
  • Stop referring to the /trunk branch / subdirectory. […]
  • Use --protocol https when cloning repositories using the pkgctl tool. […]

• Misc changes:

  • Install the python3-setuptools and swig packages, which are now needed to build OpenWrt. […]
  • Install pkg-config needed to build Coreboot artifacts. […]
  • Detect failures due to an issue where the fakeroot tool is implicitly required but not automatically installed. […]
  • Detect failures due to rename of the vmlinuz file. […]
  • Improve the grammar of an error message. […]
  • Document that freebsd-jenkins.debian.net has been updated to FreeBSD 14.0. […]

In addition, node maintenance was performed by Holger Levsen […] and Vagrant Cascadian […].

Upstream patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:

  • apr (hostname issue)
  • dune (parallelism)
  • epy (time-based .pyc issue)
  • fpc (Year 2038)
  • gap (date)
  • gh (FTBFS in 2024)
  • kubernetes (fixed random build path)
  • libgda (date)
  • libguestfs (tar)
  • metamail (date)
  • mpi-selector (date)
  • neovim (randomness in Lua)
  • nml (time-based .pyc)
  • pommed (parallelism)
  • procmail (benchmarking)
  • pysnmp (FTBFS in 2038)
  • python-efl (drop Sphinx doctrees)
  • python-pyface (time)
  • python-pytest-salt-factories (time-based .pyc issue)
  • python-quimb (fails to build on single-CPU systems)
  • python-rdflib (random)
  • python-yarl (random path)
  • qt6-webengine (parallelism issue in documentation)
  • texlive (Gzip modification time issue)
  • waf (time-based .pyc)
  • warewulf (CPIO modification time and inode issue)
  • xemacs (toolchain hostname)

• Chris Lamb:

  • #1057710 filed against python-aiostream.
  • #1057721 filed against openpyxl.
  • #1058681 filed against python-multipletau.
  • #1059013 filed against wxmplot.
  • #1059014 filed against stunnel4.

• James Addison:

  • #1059592 & #1059631 filed against qttools-opensource-src.

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.

• Mailing list: rb-general@lists.reproducible-builds.org

• Mastodon: @reproducible_builds

• Twitter: @ReproBuilds