FLOSS Project Planets

I posted a Python tidbit about checking if a string consists entirely of zeros and ones:

I got a bunch of replies suggesting other ways. I wanted to post those, but I also wanted to check if they were right. A classic testing structure would have required putting them all in functions, etc, which I didn’t want to bother with.

So I cobbled together a test harness for them (also in a gist if you want):

GOOD = [
    "",
    "0",
    "1",
    "000000000000000000",
    "111111111111111111",
    "101000100011110101010000101010101001001010101",
]

BAD = [
    "x",
    "nedbat",
    "x000000000000000000000000000000000000",
    "111111111111111111111111111111111111x",
    "".join(chr(i) for i in range(10000)),
]

TESTS = """
    # The original checks
    all(c in "01" for c in s)
    set(s).issubset({"0", "1"})
    set(s) <= {"0", "1"}
    re.fullmatch(r"[01]*", s)
    s.strip("01") == ""
    not s.strip("01")

    # Using min/max
    "0" <= min(s or "0") <= max(s or "1") <= "1"
    not s or (min(s) in "01" and max(s) in "01")
    ((ss := sorted(s or "0")) and ss[0] in "01" and ss[-1] in "01")

    # Using counting
    s.count("0") + s.count("1") == len(s)
    (not (ctr := Counter(s)) or (ctr["0"] + ctr["1"] == len(s)))

    # Using numeric tests
    all(97*c - c*c > 2351 for c in s.encode())
    max((abs(ord(c) - 48.5) for c in "0"+s)) < 1
    all(map(lambda x: (ord(x) ^ 48) < 2, s))

    # Removing all the 0 and 1
    re.sub(r"[01]", "", s) == ""
    len((s).translate(str.maketrans("", "", "01"))) == 0
    len((s).replace("0", "").replace("1", "")) == 0
    "".join(("1".join((s).split("0"))).split("1")) == ""

    # A few more for good measure
    set(s + "01") == set("01")
    not (set(s) - set("01"))
    not any(filter(lambda x: x not in {"0", "1"}, s))
    all(map(lambda x: x in "01", s))
"""

import re
from collections import Counter
from inspect import cleandoc

g = {
    "re": re,
    "Counter": Counter,
}

for test in cleandoc(TESTS).splitlines():
    test = test.partition("#")[0]
    if not test:
        continue
    for ss, expected in [(GOOD, True), (BAD, False)]:
        for s in ss:
            result = eval(test, {"s": s} | g)
            if bool(result) != expected:
                print("OOPS:")
                print(f"   {s = }")
                print(f"   {test}")
                print(f"   {expected = }")

It’s a good thing I did this because a few of the suggestions needed adjusting, especially for dealing with the empty string. But now they all work, and are checked!

BTW, if you prefer Mastodon to BlueSky, the posts are there too: first and second.

Drupal Advent Calendar day 4 - Drupal.org james Wed, 12/04/2024 - 09:00

Today Tim Lehnen from the Drupal Association joins us to talk about some of the changes taking place on the Drupal.org website as part of Starshot.

For day 4 of the Drupal Advent calendar, it’s a familiar face: Drupal.org! When we say “Come for the code, stay for the community!” Drupal.org is where we welcome everyone to join us.  Sure, you can find all the code, extensions, and documentation you need here, but Drupal.org is so much more. It’s the place where one of the greatest communities in open source gathers to communicate, collaborate, and celebrate.

Drupal.org is also a part of Drupal…

Tags

• Drupal.org
• Drupal Starshot

And just like that, 2024 is almost over! If your finances allow, donate to the Django Software Foundation to support the long-term future of Django.

84%

Of our US $200,000.00 goal for 2024, as of December 4th, 2024, we are at:

• 83.6% funded
• $167,272.85 donated

Donate to support Django

Other ways to give

• Official merchandise store - Buy official t-shirts, accessories, and more to support Django.
• Sponsor Django via GitHub Sponsors.
• Benevity Workplace Giving Program - If your employer participates, you can make donations to the DSF via payroll deduction.

Why give to the Django Software Foundation?

Our main focus is direct support of Django's developers. This means:

• Organizing and funding development sprints so that Django's developers can meet in person.
• Helping key developers attend these sprints and other community events by covering travel expenses to official Django events.
• Providing financial assistance to community development and outreach projects such as Django Girls.
• Providing financial assistance to individuals so they can attend major conferences and events.
• Funding the Django Fellowship program, which provides full-time staff to perform community management tasks in the Django community.

Still curious? See our Frequently Asked Questions about donations.

The Licensing and Compliance Lab has been diligently serving the free software community.

The Licensing and Compliance Lab has been diligently serving the free software community.

Basedpyright is a fork of pyright with various type checking improvements, improved vscode support and pylance features built into the language server. It has a list of benefits over Pyright.

In case you want to use that inside of neovim using Mason, you will have to remember to have the configuration inside of a settings key. The following is from my setup.

basedpyright = { settings = { basedpyright = { analysis = { diagnosticMode = 'openFilesOnly', typeCheckingMode = 'basic', capabilities = capabilities, useLibraryCodeForTypes = true, diagnosticSeverityOverrides = { autoSearchPaths = true, enableTypeIgnoreComments = false, reportGeneralTypeIssues = 'none', reportArgumentType = 'none', reportUnknownMemberType = 'none', reportAssignmentType = 'none', }, }, }, }, },

Struggled for a few hours to fix this couple of days ago.

#658 – DECEMBER 3, 2024
View in Browser »

Django Performance: Scaling and Optimization

Performance tuning in the context of Django applications is the practice of enhancing both the efficiency and effectiveness of your web project to optimize its runtime behavior. This article tells you a lot of what you need to know.
LOADFORGE.COM

Python’s pathlib Module

Python’s pathlib module is the tool to use for working with file paths. This post contains pathlib quick reference tables and examples.
TREY HUNNER

Python Developers: Scrape Any Website Without Getting Blocked

ZenRows handles all anti-bot bypass for you, from rotating proxies and headless browsers to CAPTCHAs and AI. Get a complete web scraping toolkit to extract all the data you need with a single API call. Try ZenRows now for free →
ZENROWS sponsor

Managing Dependencies With Python Poetry

Learn how Python Poetry can help you start new projects, maintain existing ones, and master dependency management.
REAL PYTHON course

Nuitka Release 2.5

NUITKA.NET

Quiz: NumPy Practical Examples: Useful Techniques

REAL PYTHON

Quiz: Interacting With Python

REAL PYTHON

Discussions Add Optional if break: Suite to for/while

PYTHON.ORG

Articles & Tutorials Advent of Code 2024

This annual tradition is a series of small programming puzzles that can be completed in any programming language.
ADVENTOFCODE.COM

CI/CD for Python With GitHub Actions

With most software following agile methodologies, it’s essential to have robust DevOps systems in place to manage, maintain, and automate common tasks with a continually changing codebase. By using GitHub Actions, you can automate your workflows efficiently, especially for Python projects.
REAL PYTHON

How to Debug Your Textual Application

Textual is a great Python package for creating a lightweight, powerful, text-based user interface. Debugging TUIs can be a challenge though as you no longer can use print() and the application may not even run in your IDE’s terminal interface. This post talks about how to debug a TUI.
MIKE DRISCOLL

Reactive Notebooks and Deployable Web Apps in Python

What are common issues with using notebooks for Python development? How do you know the current state, share reproducible results, or create interactive applications? This week on the show, we speak with Akshay Agrawal about the open-source reactive marimo notebook for Python.
REAL PYTHON podcast

Constraints Are Good: Python’s Metadata Dilemma

Python’s initial flexibility in packaging with the executable setup.py has meant that people have come to expect this power. In this post Armin argues that if constraints had been there in the first place we’d be in a better place now.
ARMIN RONACHER

Demystifying ODBC With Python

Open Database Connectivity (ODBC) is used to connect to various databases. This article aims to help you understand ODBC better by implementing database communications from scratch only using Python.
PRESTON BLACKBURN • Shared by Preston Blackburn

What the PSF Conduct WG Does

In the past week Brett has had two different people tell him what the PSF Conduct Working Group did, and both were wrong. This post tries to correct what might be common misconceptions.
BRETT CANNON

Introduction to Retrogame Programming With Pyxel

Pyxel is a Rust based framework for building retro games that comes with a Python API wrapper. This step-by-step tutorial shows you how to do some basic sprite animation to get started.
MATHIEU LECARME

Speeding Up Data Retrieval From PostgreSQL With Psycopg

Formatting and concatenating query result columns on the PostgreSQL side and then parsing them in Python might sometimes be faster than fetching the columns as separate values.
ALIAKSEI YALETSKI • Shared by Tiendil

Django Application Performance Optimization Checklist

“Improve the performance of your Django application by understanding, testing, and implementing some common optimization techniques.”
SANKET RAI

Top 10 Rules of Continuous Integration

Continuous Integration (CI) is key to rapid deployment of new features. This post gives you ten rules to consider when doing CI.
KRISTINA NIKOLOVA

Projects & Code Sensei: Simplifying API Client Generation

CROCOFACTORY.DEV • Shared by Alexey

QodoAI Cover-Agent: AI Tool for Automated Test Generation

GITHUB.COM/CODIUM-AI

Peek: Like print, but Easy

SALABIM.ORG • Shared by Ruud van der Ham

pyvista: 3D Plotting and Mesh Analysis

GITHUB.COM/PYVISTA

python-fire: Automatically Generate Command Line Interfaces

GITHUB.COM/GOOGLE

Events Weekly Real Python Office Hours Q&A (Virtual)

December 4, 2024
REALPYTHON.COM

PyCon Tanzania 2024

December 4 to December 6, 2024
PYCON.OR.TZ

DELSU Tech Invasion 2.0

December 4 to December 6, 2024
HAMPLUSTECH.COM

Canberra Python Meetup

December 5, 2024
MEETUP.COM

Sydney Python User Group (SyPy)

December 5, 2024
SYPY.ORG

PyLadies Amsterdam: Introduction to Data Storytelling

December 7, 2024
MEETUP.COM

Happy Pythoning!
This was PyCoder’s Weekly Issue #658.
View in Browser »

[ Subscribe to 🐍 PyCoder’s Weekly 💌 – Get the best Python news, articles, and tutorials delivered to your inbox once a week >> Click here to learn more ]

Another big release day! Python 3.13.1 and 3.12.8 were regularly scheduled releases, but they do contain a few security fixes. That makes it a nice time to release the security-fix-only versions too, so everything is as secure as we can make it.

Python 3.13.1

Python 3.13’s first maintenance release. My child is all growed up now, I guess! Almost 400 bugfixes, build improvements and documentation changes went in since 3.13.0, making this the very best Python release to date.

https://www.python.org/downloads/release/python-3131/

Python 3.12.8

Python 3.12 might be slowly reaching middle age, but still received over 250 bugfixes, build improvements and documentation changes since 3.12.7.

https://www.python.org/downloads/release/python-3128/
Python 3.11.11

I know it’s probably hard to hear, but this is the second security-only release of Python 3.11. Yes, really! Oh yes, I know, I know, but it’s true! Only 11 commits went in since 3.11.10.

https://www.python.org/downloads/release/python-31111/
Python 3.10.16

Python 3.10 received a total of 14 commits since 3.10.15. Why more than 3.11? Because it needed a little bit of extra attention to keep working with current GitHub practices, I guess.

https://www.python.org/downloads/release/python-31016/
Python 3.9.21

Python 3.9 isn’t quite ready for pasture yet, as it’s set to receive security fixes for at least another 10 months. Very similarly to 3.10, it received 14 commits since 3.9.20.

https://www.python.org/downloads/release/python-3921/
Stay safe and upgrade!

As always, upgrading is highly recommended to all users of affected versions.

Enjoy the new releases

Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.

Regards from your tireless, tireless release team,
Thomas Wouters
Ned Deily
Steve Dower
Pablo Galindo Salgado
Łukasz Langa 

Welcome to the Free Software Supporter, the Free Software Foundation's (FSF) monthly news digest and action update -- being read by you and 231,349 other activists.

Welcome to the Free Software Supporter, the Free Software Foundation's (FSF) monthly news digest and action update -- being read by you and 231,349 other activists.

Eleven new GNU releases in the last month (as of November 29, 2024):

Eleven new GNU releases in the last month (as of November 29, 2024):

Automatically show this month and next month in a perpetual calendar Anonymous (not verified) Tue, 12/03/2024 - 07:00 Tags Drupal CMS Website management ECA Drupal Planet

• Read more about Automatically show this month and next month in a perpetual calendar
• Add new comment

One of our clients is Programming Librarian, a site for librarians to plan educational programs. Programs, like many events, are often seasonal, oriented around holidays and seasonal activities.

The site has a block for each month of the year, containing content for that month. It has a custom field for the month number.

This blog expands on my DrupalCon Barcelona talk, which I managed to squeeze into a twenty-minute session slot. You can download a copy of my slides. Unfortunately, I could not dedicate enough time to the project and stepped down as the trial track lead. The Drupal CMS trial is no longer based on my WebAssembly work, and an ongoing process is being conducted to provide an official demo.

Dealing with errors and exceptional situations is a common requirement in programming. You can either prevent errors before they happen or handle errors after they’ve happened. In general, you’ll have two coding styles matching these strategies: look before you leap (LBYL), and easier to ask forgiveness than permission (EAFP), respectively. In this video course, you’ll dive into the questions and considerations surrounding LBYL vs EAFP in Python.

By learning about Python’s LBYL and EAFP coding styles, you’ll be able to decide which strategy and coding style to use when you’re dealing with errors in your code.

In this video course, you’ll learn how to:

• Use the LBYL and EAFP styles in your Python code
• Understand the pros and cons of LBYL vs EAFP
• Decide when to use either LBYL or EAFP

[ 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 ]

Revolutionizing Content Editing with AI in Drupal

Nowadays, artificial intelligence (AI) has become a powerful tool to enhance the process of creating and managing digital content. Drupal, known for its flexibility and robustness as a content management system (CMS), has already started to integrate this new technology, adding exceptional capabilities for generating and improving content.

In this detailed guide, as a showcase, we will demonstrate how to install and configure the modules AI (Artificial Intelligence) and Image Genie AI in Drupal, the first to integrate AI with CKEditor, thereby improving its editing capabilities, such as text generation, tone alterations, or translations, and the second to generate images, enabling the creation of complete content , quickly and efficiently.

It is worth mentioning that these modules are currently in development phase, so their use in production is currently discouraged.

Prerequisites…

Drupal Advent Calendar day 3 - Contact Form james Tue, 12/03/2024 - 09:00

Today we’re looking at a fairly simple addition to Starshot, but one that can add a lot of power to a site.

While the default Drupal install provides a contact form, it does it through the rather basic “contact” module, that is built into Drupal Core. This has a lot of limitations, and many people prefer to use the more powerful “Webform” module.

Providing this in Drupal CMS saves the somewhat tedious process of adding a contact form to each Drupal installation. It also adds a Webform contact form in a more standard way, so sites are more likely to follow a consistent pattern when adding…

Tags

• Contact Form

Review: Astrid Parker Doesn't Fail, by Ashley Herring Blake

Series: Bright Falls #2 Publisher: Berkley Romance Copyright: November 2022 ISBN: 0-593-33644-5 Format: Kindle Pages: 365

Astrid Parker Doesn't Fail is a sapphic romance novel and a sequel to Delilah Green Doesn't Care. This is a romance style of sequel, which means that it spoils the previous book but involves a different set of protagonists, one of whom was a supporting character in the previous novel.

I suppose the title is a minor spoiler for Delilah Green Doesn't Care, but not one that really matters.

Astrid Parker's interior design business is in trouble. The small town of Bright Falls doesn't generate a lot of business, and there are limits to how many dentist office renovations that she's willing to do. The Everwood Inn is her big break: Pru Everwood has finally agreed to remodel and, even better, Innside America wants to feature the project. The show always works with local designers, and that means Astrid. National TV exposure is just what she needs to turn her business around and avoid an unpleasant confrontation with her domineering, perfectionist mother.

Jordan Everwood is an out-of-work carpenter and professional fuck-up. Ever since she lost her wife, nothing has gone right either inside or outside of her head. Now her grandmother is renovating the favorite place of her childhood, and her novelist brother had the bright idea of bringing her to Bright Falls to help with the carpentry work. The remodel and the HGTV show are the last chance for the inn to stay in business and stay in the family, and Jordan is terrified that she's going to fuck that up too. And then she dumps coffee all over the expensive dress of a furious woman in a designer dress because she wasn't watching where she was going, and that woman turns out to be the designer of the Everwood Inn renovation. A design that Jordan absolutely loathes.

The reader met Astrid in Delilah Green Doesn't Care (which you definitely want to read first). She's a bit better than she was there, but she's still uptight and unhappy and determined not to think too hard about why. When Jordan spills coffee down her favorite dress in their first encounter, shattering her fragile professional calm, it's not a meet-cute. Astrid is awful to her. Her subsequent regret, combined with immediately having to work with her and the degree to which she finds Jordan surprisingly attractive (surprising in part because Astrid thinks she's straight), slowly crack open Astrid's too-controlled life.

This book was, once again, just compulsively readable. I read most of it the same day that I started it, staying up much too late, and then finished it the next day. It also once again made me laugh in delight at multiple points. I am a sucker for stories about someone learning how to become a better person, particularly when it involves a release of anxiety, and oh my does Blake ever deliver on that. Jordan's arc is more straightforward than Astrid's — she just needs to get her confidence back — but her backstory is a lot more complex than it first appears, including a morally ambiguous character who I would hate in person but who I admired as a deft and tricky bit of characterization.

The characters from Delilah Green Doesn't Care of course play a significant role. Delilah in particular is just as much of a delight here as she was in the first book, and I enjoyed seeing the development of her relationship with her step-sister. But the new characters, both the HGTV film crew and the Everwoods, are also great. I think Blake has a real knack for memorable, distinct supporting characters that add a lot of depth to the main romance plot.

I thought this book was substantially more sex-forward than Delilah Green Doesn't Care, with some lust at first or second sight, a bit more physical description of bodies, and an extended section in the middle of the book that's mostly about sex. If this is or is not your thing in romance novels, you may have a different reaction to this book than the previous one.

There is, unfortunately, another third-act break-up, and this one annoyed me more than the one in Delilah Green Doesn't Care because it felt more unnecessary and openly self-destructive. The characters felt like they were headed towards a more sensible and less dramatic resolution, and then that plot twist caught me by surprise in an unpleasant way. After two books, I'm getting the sense that Blake has a preferred plot arc, at least in this series, and I wish she'd varied the story structure a bit more. Still, the third-act conflict was somewhat believable and the resolution was satisfying enough to salvage it.

If it weren't for some sour feelings about the shape of that plot climax, I would have said that I liked this book even better than Delilah Green Doesn't Care, and that's a high bar. This series is great, and I will definitely be reading the third one. I'm going to be curious how that goes since it's about Iris, who so far has worked better for me as a supporting character than a protagonist. But Blake has delivered compulsively readable and thoroughly enjoyable books twice now, so I'm definitely here for the duration.

If you like this sort of thing, I highly recommend this whole series.

Followed by Iris Kelly Doesn't Date in the romance series sense, but as before this book is a complete story with a satisfying ending.

Rating: 9 out of 10

New era of slop security reports for open source About • Blog • Cool URLs New era of slop security reports for open source

Published 2024-12-03 by Seth Larson
Reading time: minutes

I'm on the security report triage team for CPython, pip, urllib3, Requests, and a handful of other open source projects. I'm also in a trusted position such that I get "tagged in" to other open source projects to help others when they need help with security.

Recently I've noticed an uptick in extremely low-quality, spammy, and LLM-hallucinated security reports to open source projects. The issue is in the age of LLMs, these reports appear at first-glance to be potentially legitimate and thus require time to refute. Other projects such as curl have reported similar findings.

Some reporters will run a variety of security scanning tools and open vulnerability reports based on the results seemingly without a moment of critical thinking. For example, urllib3 recently received a report because a tool was detecting our usage of SSLv2 as insecure even though our usage is to explicitly disable SSLv2.

This issue is tough to tackle because it's distributed across thousands of open source projects and due to the security-sensitive nature of reports open source maintainers are discouraged from sharing their experiences or asking for help. Sharing experiences takes time and effort, something that is in short supply amongst maintainers.

Responding to security reports is expensive

If this is happening to a handful of projects that I have visibility for, then I suspect that this is happening on a large scale to open source projects. This is a very concerning trend.

Security is already a topic that is not aligned with why many maintainers contribute their time to open source software, instead seeing security as important to help protect their users. It's critical as reporters to respect this often volunteered time.

Security reports that waste maintainers' time result in confusion, stress, frustration, and to top it off a sense of isolation due to the secretive nature of security reports. All of these feelings can add to burn-out of likely highly-trusted contributors to open source projects.

In many ways, these low-quality reports should be treated as if they are malicious. Even if this is not their intent, the outcome is maintainers that are burnt out and more averse to legitimate security work.

What platforms can do

If you're a platform accepting vulnerability reports on behalf of open source projects, here are things you can do:

• Add systems to prevent automated or abusive creation of security reports. Require reporters to solve CAPTCHAs or heavily rate-limit security report creation using automation.
• Allow a security report to be made public without publishing a vulnerability record. This would allow maintainers to "name-and-shame" offenders and better collaborate as a community how to fight back against low-quality reports. Today many of these reports aren't seen due to being private by default or when closed.
• Remove the public attribution of reporters that abuse the system, even removing previously credited reports in the case of abuse.
• Take away any positive incentive to reporting security issues, for example GitHub showing the number of GitHub Security Advisory "credits" a user appears on.
• Prevent or hamper newly registered users from reporting security issues.

What reporters can do

If you're starting a new campaign of scanning open source projects and reporting potential vulnerabilities upstream:

• DO NOT use AI / LLM systems for "detecting" vulnerabilities. These systems today cannot understand code, finding security vulnerabilities requires understanding code AND understanding human-level concepts like intent, common usage, and context.
• DO NOT run experiments on open source volunteers. My alma-mater the University of Minnesota rightfully had its reputation thrown in the trash in 2021 over their experiment to knowingly socially deceive Linux maintainers.
• DO NOT submit reports that haven't been reviewed BY A HUMAN. This reviewing time should be paid first by you, not open source volunteers.
• DO NOT spam projects, open a handful of reports and then WAIT. You could run the script and open tons of reports all-at-once, but likely you have faults in your process that will cause mass-frustration at scale. Learn from early mistakes and feedback.
• Have someone with experience in open source maintenance for the size of projects you are scanning review your plan before you begin. If that person is not on your team, then pay them for their time and expertise.
• Show up with patches, not just reports. By providing patches this makes the work of maintainers much easier.

Doing all of the above will likely lead to better outcomes for everyone.

What maintainers can do

Put the same amount of effort into responding as the reporter put into submitting a sloppy report: ie, near zero. If you receive a report that you suspect is AI or LLM generated, reply with a short response and close the report:

"I suspect this report is (AI-generated|incorrect|spam). Please respond with more justification for this report. See: https://sethmlarson.dev/slop-security-reports"

If you hear back at all then admit your mistake and you move on with the security report. Maybe the reporter will fix their process and you'll have helped other open source maintainers along the way to helping yourself.

If you don't hear back: great, you saved time and can get back to actually useful work.

Here are some questions to ask of a security report and reporter:

• If you aren't sure: ask for help! Is there someone I trust in my community that I can ask for another look. You are not alone, there are many people around that are willing to help. For Python open source projects you can ask for help from me if needed.

• Does the reporter have a new account, no public identity, or multiple "credited" security reports of low quality? There are sometimes legitimate reasons to want anonymity, but I've seen this commonly on very low-stakes vulnerability reports.

• Is the vulnerability in the proof-of-concept code or the project itself? Oftentimes the proof-of-concept code will be using the project insecurely and thus the vulnerability is in the proof-of-concept code, not your code.

Most vulnerability reporters are acting in good faith

I wanted to end this article with a note that many vulnerability reporters are acting in good faith and are submitting high quality reports. Please keep in mind that vulnerability reporters are humans: not perfect and trying their best to make the world a better place.

Unfortunately, an increasing majority of reports are of low quality and are ruining the experience for others. I hope we're able to fix this issue before it gets out of hand.

Have thoughts or questions? Let's chat over email or social:

sethmichaellarson@gmail.com
@sethmlarson@fosstodon.org

Want more articles like this one? Get notified of new posts by subscribing to the RSS feed or the email newsletter. I won't share your email or send spam, only whatever this is!

Want more content now? This blog's archive has ready-to-read articles. I also curate a list of cool URLs I find on the internet.

Find a typo? This blog is open source, pull requests are appreciated.

Thanks for reading! ♡ This work is licensed under CC BY-SA 4.0

︎

This is bits from DPL for November.

MiniDebConf Toulouse

I had the pleasure of attending the MiniDebConf in Toulouse, which featured a range of engaging talks, complementing those from the recent MiniDebConf in Cambridge. Both events were preceded by a DebCamp, which provided a valuable opportunity for focused work and collaboration.

DebCamp

During these events, I participated in numerous technical discussions on topics such as maintaining long-neglected packages, team-based maintenance, FTP master policies, Debusine, and strategies for separating maintainer script dependencies from runtime dependencies, among others. I was also fortunate that members of the Publicity Team attended the MiniDebCamp, giving us the opportunity to meet in person and collaborate face-to-face.

Independent of the ongoing lengthy discussion on the Debian Devel mailing list, I encountered the perspective that unifying Git workflows might be more critical than ensuring all packages are managed in Git. While I'm uncertain whether these two questions--adopting Git as a universal development tool and agreeing on a common workflow for its use--can be fully separated, I believe it's worth raising this topic for further consideration.

Attracting newcomers

In my own talk, I regret not leaving enough time for questions--my apologies for this. However, I want to revisit the sole question raised, which essentially asked: Is the documentation for newcomers sufficient to attract new contributors? My immediate response was that this question is best directed to new contributors themselves, as they are in the best position to identify gaps and suggest improvements that could make the documentation more helpful.

That said, I'm personally convinced that our challenges extend beyond just documentation. I don't get the impression that newcomers are lining up to join Debian only to be deterred by inadequate documentation. The issue might be more about fostering interest and engagement in the first place.

My personal impression is that we sometimes fail to convey that Debian is not just a product to download for free but also a technical challenge that warmly invites participation. Everyone who respects our Code of Conduct will find that Debian is a highly diverse community, where joining the project offers not only opportunities for technical contributions but also meaningful social interactions that can make the effort and time truly rewarding.

In several of my previous talks (you can find them on my talks page –just search for "team," and don't be deterred if you see "Debian Med" in the title; it's simply an example), I emphasized that the interaction between a mentor and a mentee often plays a far more significant role than the documentation the mentee has to read. The key to success has always been finding a way to spark the mentee's interest in a specific topic that resonates with their own passions.

Bug of the Day

In my presentation, I provided a brief overview of the Bug of the Day initiative, which was launched with the aim of demonstrating how to fix bugs as an entry point for learning about packaging. While the current level of interest from newcomers seems limited, the initiative has brought several additional benefits.

I must admit that I'm learning quite a bit about Debian myself. I often compare it to exploring a house's cellar with a flashlight –you uncover everything from hidden marvels to things you might prefer to discard. I've also come across traces of incredibly diligent people who have invested their spare time polishing these hidden treasures (what we call NMUs). The janitor, a service in Salsa that automatically updates packages, fits perfectly into this cellar metaphor, symbolizing the ongoing care and maintenance that keep everything in order. I hadn't realized the immense amount of silent work being done behind the scenes--thank you all so much for your invaluable QA efforts.

Reproducible builds

It might be unfair to single out a specific talk from Toulouse, but I'd like to highlight the one on reproducible builds. Beyond its technical focus, the talk also addressed the recent loss of Lunar, whom we mourn deeply. It served as a tribute to Lunar's contributions and legacy. Personally, I've encountered packages maintained by Lunar and bugs he had filed. I believe that taking over his packages and addressing the bugs he reported is a meaningful way to honor his memory and acknowledge the value of his work.

Advent calendar bug squashing

I’d like to promote an idea originally introduced by Thorsten Alteholz, who in 2011 proposed a Bug Squashing Advent Calendar for the Debian Med team. (For those unfamiliar with the concept of an Advent Calendar, you can find an explanation on Wikipedia.) While the original version included a fun graphical element —which we’ve had to set aside due to time constraints (volunteers, anyone?)— we’ve kept the tradition alive by tackling one bug per day from December 1st to 24th each year. This initiative helps clean up issues that have accumulated over the year.

Regardless of whether you celebrate the concept of Advent, I warmly recommend this approach as a form of continuous bug-squashing party for every team. Not only does it contribute to the release readiness of your team’s packages, but it’s also an enjoyable and bonding activity for team members.

Best wishes for a cheerful and productive December

Andreas.