Feeds

Download from https://ftp.gnu.org/pub/gnu/gettext/gettext-0.22.5.tar.gz

This is a bug-fix release.

New in this release:

• The replacements for the printf()/fprintf()/... functions that are provided through <libintl.h> on native Windows and NetBSD now enable GCC's format string analysis (-Wformat).

• Bug fixes:
  • xgettext's processing of Vala files with printf method invocations has been corrected (regression in 0.22).
  • Build fixes on macOS.

Co-written by Pal Patel, Solutions Architect, WWPS - Amazon Web Services

In the intricate landscape of government technology, where innovation and security coalesce, the potent combination of Acquia and Amazon Web Services (AWS) delivers enterprise digital experience capabilities for public sector agencies. This empowers such agencies with the technical intricacies of Acquia's Drupal prowess fused with AWS's cloud infrastructure resulting in a new era of digital excellence for federal, state, and local government agencies.

Evolving with Drupal: A Technical Revolution

Shifting from conventional platforms to Drupal is a strategic leap that empowers organizations to harness the power of open-source technology, fostering rapid development, scalability, and customization.

Learn to develop an effective content strategy for your Drupal site with expert advice. Drive traffic, engage users, and boost conversions with strategic content planning.

Introduction

A content strategy is essential for any modern Drupal site as it aligns content with business goals, optimizes user experience, ensures quality and consistency, and leverages Drupal's advanced content management features for efficient governance and workflow management. Your organization’s content strategy will incorporate SEO best practices to amplify online visibility and prepare the organization for future digital trends and multi-channel distribution. 

Ultimately, a well-crafted content strategy is a linchpin in transforming a Drupal CMS into a dynamic asset that supports engagement, lead conversion, and customer loyalty, thus driving an organization's digital success.

In this episode, we completed the Stripe integration. I added all the necessary test code, incorporated the webhook for handling account activation, and wrote the view that Stripe needed to redirect to on successful signup.

Climate change is impacting the whole planet, and getting worse every year. So you want to do something—but you’re not sure what. If you do some research you might encounter an essay by Bret Victor—What can a technologist do about climate change? There’s a whole pile of good ideas in there, and it’s worth reading, but the short version is that you can use technology to “create options for policy-makers.” And working on clean energy or efficiency is definitely a great way to spend your time.

Thing is, policy-makers are doing far less than they should. As a result, this essay isn’t about technology, even though that’s what I mostly write about on this site, because I’m not so certain that technology is the bottleneck right now.

Instead, I’m writing about policy and politics, and what you can do about it. Keep in mind that my perspective is heavily influenced by living in the US, but the big picture issues are likely universal.

Read more...

Windows SBOM work and Alpha-Omega 2023 annual report About • Blog • Newsletter • Links Windows SBOM work and Alpha-Omega 2023 annual report

Published 2024-02-22 by Seth Larson
Reading time: minutes

This critical role would not be possible without funding from the Alpha-Omega project. Massive thank-you to Alpha-Omega for investing in the security of the Python ecosystem! Starting on SBOMs for Python Windows artifacts

Windows artifacts for CPython get built using Azure Pipelines so the generation of the final SBOM for Windows artifacts should also be added to these workflows.

Part of the workflows is to download source code for dependencies like OpenSSL, libffi, and more. These dependencies and their versions are tracked in a file named get_externals.bat in a unintentionally parseable format that the CPython SBOM tooling can extract and generate an SBOM file for. This works in a similar way to the "checked-in" source dependencies where any changes require the partial SBOM to be regenerated and acknowledged by core developers during PR review.

The plan is to find this SBOM during the Windows release build and then depending on which libraries have been pulled locally by get_externals.bat an SBOM will be generated for the Windows artifact.

After chatting with Steve Dower it seems that the Windows build happens once and then is repackaged into all the different distribution methods (python.org, Windows store, Nuget, etc) so we'll only need to generate the Windows-specific SBOM once and then reuse it for each distribution method.

I also removed regen-sbom makefile target from regen-all to avoid breaking downstream distributors.

Alpha-Omega published 2023 Annual Report

Alpha-Omega published its 2023 annual report this week and there's a ton of goodness inside, including lots of mentions of the Python Software Foundation and my own work. I contributed content to this report last year, so I'm excited to see it published.

One quote regarding my current role:

Alpha-Omega has helped fund security champion roles at the Python Software Foundation, the Eclipse Foundation, and the Rust Foundation. In all cases, we are seeing significant impact as these individuals are incubating a security culture in their respective communities.

Both Deb Nicholson, the executive director of the PSF and I were quoted in the report, take a look if you're interested in what Alpha-Omega has next in 2024.

Other items

• Working on grant renewal with Alpha-Omega for the Python Software Foundation.
• CPython 3.13.0a4 was released which also included SBOM documents.
• Draft and submit talk for Alpha-Omega at PyCon US 2024.
• Reviewed the OpenSSF announcement blog post for Linux becoming a CNA
• Reviewed the lock file with sdists proposal from Brett Cannon

That's all for this week! 👋 If you're interested in more you can read last week's report.

Thanks for reading! ♡ Did you find this article helpful and want more content like it? Get notified of new posts by subscribing to the RSS feed or the email newsletter.

This work is licensed under CC BY-SA 4.0

NGI Webinar: The GNU Name System and the road to publishing an RFC

We have been invited by NLnet to present the GNU Name System and our efforts to create and publish RFC 9498 .

You can find the recording and slides on the NLnet webinar page . It includes a live demo of our GNS registrar with integrated GNU Taler payments.

The work on GNS was generously funded by NLnet as part of their NGI Search and Discovery and NGI Zero Entrust Programme .

Our new EAP build for PyCharm 2024.1 is now available for you to download!

This new build is packed with a bunch of updates to the integration with version control systems.

You can download the new version from our website, update directly from the IDE or via the free Toolbox App, or use snaps for Ubuntu.

Download PyCharm 2024.1 EAP

Version control systems In-editor code review

PyCharm 2024.1 EAP 6 introduces a more streamlined and agile code review workflow for both GitHub and GitLab users. Authors and reviewers can now seamlessly interact directly within the editor, thanks to the implementation of the Review Mode.

Once the pull/merge request branch is checked out, the review mode is automatically enabled. When you open a source file related to the pull/merge request, either from a diff or from the Project tool window, you’ll notice purple controls on the gutter, indicating changes made to the lines of code and available for the code review workflow. For both authors and reviewers, clicking on these markers reveals a popup showing the original code, making it easier to understand the change. Use the icons in the gutter to discuss changes: click the + icon appearing on hover to start a new discussion or the Message icon to open or hide existing comments where you can reply, react, and resolve threads.

You can use the widget in the editor’s upper right corner to see only unresolved discussions or turn off the review mode completely. You can also toggle review mode from VCS widget.

Preventing large file commits to repositories

To prevent instances where the version control system rejects pushes due to files exceeding size limits, we’ve introduced a mechanism that prohibits the committing of such files. The IDE will now perform a pre-commit check and notify you about the restriction hence saving time on reverting your rejected commits and enhancing the repository management. 

Allow unrelated histories merge option 

We’ve enhanced the Merge into dialog with the addition of the Allow unrelated histories option. When selected from the dropdown menu, this option enables the merge operation to proceed even if the two branches being merged have no common history.

Support for reactions on code review comments 

PyCharm 2024.1 EAP 6 brings support for reactions on review comments for GitHub Pull Requests and GitLab Merge Requests. You can now select from a set of emojis to use as a reaction to your code review comments, enhancing your collaboration process. 

CI checks suite statuses in the Git tool window 

We’ve introduced a new column in the Log tab of the Git tool window, allowing you to easily review the results of GitHub commit checks performed by your CI system. Simply click on it to view the full details of the CI checks. 

Create pull/merge requests from push notifications

After successfully pushing your changes to the version control system, the IDE will now prompt a single notification to inform you about the successful push and suggest an action to create a pull/merge request.

Branch filter for the History tab of the Git tool window

We’ve revamped the user experience for file history in the Git tool window. First, the Show all branches button has been replaced with a branch filter, enabling you to review changes made to a file within a designated branch. Additionally, we’ve adjusted the toolbar orientation, positioning it horizontally for improved usability. 

Stash tab in the Commit tool window

For users who rely on stashes to store temporary uncommitted changes, we’ve introduced a dedicated tab within the Commit tool window for convenient access. If you utilize both stashes and shelves, you have the option to enable a combined Stashes and Shelves tab via a corresponding checkbox in Settings/Preferences | Version Control | Git.  

Visual indicators for pending updates

We’ve introduced visual indicators to hint about pending updates within your code review workflow. When there are changes requiring your attention, a dot badge will appear on the tool window icon. Additionally, unseen pull requests will be marked with a blue dot, ensuring you don’t miss updates in your code review process.

These are the most notable updates for this week. For the full list of implemented changes, refer to the release notes. 

Take the new features for a test drive, share your feedback with us via X (formerly Twitter) or in the comments below, and stay tuned for more updates! If you spot a bug, report it to our issue tracker.

I have spent some more time on improving my language server for debian/control. Today, I managed to provide the following features:

• The X- style prefixes for field names are now understood and handled. This means the language server now considers XC-Package-Type the same as Package-Type.

• More diagnostics:

  • Fields without values now trigger an error marker
  • Duplicated fields now trigger an error marker
  • Fields used in the wrong paragraph now trigger an error marker
  • Typos in field names or values now trigger a warning marker. For field names, X- style prefixes are stripped before typo detection is done.
  • The value of the Section field is now validated against a dataset of known sections and trigger a warning marker if not known.

• The "on-save trim end of line whitespace" now works. I had a logic bug in the server side code that made it submit "no change" edits to the editor.

• The language server now provides "hover" documentation for field names. There is a small screenshot of this below. Sadly, emacs does not support markdown or, if it does, it does not announce the support for markdown. For now, all the documentation is always in markdown format and the language server will tag it as either markdown or plaintext depending on the announced support.

• The language server now provides quick fixes for some of the more trivial problems such as deprecated fields or typos of fields and values.

• Added more known fields including the XS-Autobuild field for non-free packages along with a link to the relevant devref section in its hover doc.

This covers basically all my known omissions from last update except spellchecking of the Description field.

Spellchecking

Personally, I feel spellchecking would be a very welcome addition to the current feature set. However, reviewing my options, it seems that most of the spellchecking python libraries out there are not packaged for Debian, or at least not other the name I assumed they would be.

The alternative is to pipe the spellchecking to another program like aspell list. I did not test this fully, but aspell list does seem to do some input buffering that I cannot easily default (at least not in the shell). Though, either way, the logic for this will not be trivial and aspell list does not seem to include the corrections either. So best case, you would get typo markers but no suggestions for what you should have typed. Not ideal.

Additionally, I am also concerned with the performance for this feature. For d/control, it will be a trivial matter in practice. However, I would be reusing this for d/changelog which is 99% free text with plenty of room for typos. For a regular linter, some slowness is acceptable as it is basically a batch tool. However, for a language server, this potentially translates into latency for your edits and that gets annoying.

While it is definitely on my long term todo list, I am a bit afraid that it can easily become a time sink. Admittedly, this does annoy me, because I wanted to cross off at least one of Otto's requested features soon.

On wrap-and-sort support

The other obvious request from Otto would be to automate wrap-and-sort formatting. Here, the problem is that "we" in Debian do not agree on the one true formatting of debian/control. In fact, I am fairly certain we do not even agree on whether we should all use wrap-and-sort. This implies we need a style configuration.

However, if we have a style configuration per person, then you get style "ping-pong" for packages where the co-maintainers do not all have the same style configuration. Additionally, it is very likely that you are a member of multiple packaging teams or groups that all have their own unique style. Ergo, only having a personal config file is doomed to fail.

The only "sane" option here that I can think of is to have or support "per package" style configuration. Something that would be committed to git, so the tooling would automatically pick up the configuration. Obviously, that is not fun for large packaging teams where you have to maintain one file per package if you want a consistent style across all packages. But it beats "style ping-pong" any day of the week.

Note that I am perfectly open to having a personal configuration file as a fallback for when the "per package" configuration file is absent.

The second problem is the question of which format to use and what to name this file. Since file formats and naming has never been controversial at all, this will obviously be the easy part of this problem. But the file should be parsable by both wrap-and-sort and the language server, so you get the same result regardless of which tool you use. If we do not ensure this, then we still have the style ping-pong problem as people use different tools.

This also seems like time sink with no end. So, what next then...?

What next?

On the language server front, I will have a look at its support for providing semantic hints to the editors that might be used for syntax highlighting. While I think most common Debian editors have built syntax highlighting already, I would like this language server to stand on its own. I would like us to be in a situation where we do not have implement yet another editor extension for Debian packaging files. At least not for editors that support the LSP spec.

On a different front, I have an idea for how we go about relationship related substvars. It is not directly related to this language server, except I got triggered by the language server "missing" a diagnostic for reminding people to add the magic Depends: ${misc:Depends}[, ${shlibs:Depends}] boilerplate. The magic boilerplate that you have to write even though we really should just fix this at a tooling level instead. Energy permitting, I will formulate a proposal for that and send it to debian-devel.

Beyond that, I think I might start adding support for another file. I also need to wrap up my python-debian branch, so I can get the position support into the Debian soon, which would remove one papercut for using this language server.

Finally, it might be interesting to see if I can extract a "batch-linter" version of the diagnostics and related quickfix features. If nothing else, the "linter" variant would enable many of you to get a "mini-Lintian" without having to do a package build first.

Authored by: Nadiia Nykolaichuk.

Whatever specific kinds of content your website needs — articles, news, testimonials, products, user profiles, events — fields help organize them into predefined structures or templates. This ensures consistency in how all items of a certain type are displayed and managed, and gives you ultimate flexibility in content modeling.

We’re streamlining the git terms of service acceptance process, by moving it into our GitLab instance.

When you next use git.drupalcode.org, you will be asked to accept terms of service. The terms of service aren't changing, but how we ask you to accept them is. You can always review the current Drupal Git Contributor Agreement & Repository Usage Policy

You will need to accept these terms before pushing code to git.drupalcode.org or continuing while logged in.

www.drupal.org had been the place where we recorded acceptance of these terms. Now we are leaning on GitLab to take over this functionality. Instead of migrating who had previously accepted, we're taking the opportunity to remind everyone of these terms.

As we're improving developer tools on Drupal.org, working to migrate issues to GitLab, and update www.drupal.org, this change makes it easier to get a git.drupalcode.org account, and simplifies our codebase.

For more background, see #3230072: Streamline Git Access Agreement/username assignment and #3227737: [Meta] GitLab Acceleration Initiative

Mike Gifford shares his first-hand insights from FOSDEM'24, the eminent open-source conference, shedding light on the significant discussions around open-source solutions in government, digital public goods, and the evolving role of open-source in societal advancement. Gain unique perspectives on the intersection of open-source technology and public good initiatives, as well as the impact of open source on government innovation. Delve into discussions on web accessibility, sustainability, and the application of open source in governmental projects, presented with real-world examples from various government agencies. Explore the emergence of Open Website Alliance and the impact of AI on the broader community.

In the enterprise realm, automation stands as a transformative force, offering a dual-edged sword of efficiency gains and emergent challenges. Its implementation is reshaping industry norms, potentially redefining the operational paradigms of the business world.

So that’s it, DrupalCon Lille 2023 has come to a close - for me at least. I’m currently sitting in the train heading home. Now’s the perfect time to reflect on what’s been an amazing three days. And it really has been amazing! Lille has been the perfect host city, providing great brasseries with great beer and lots of food with lots of melted cheese all over it - who could ask for more? And this DrupalCon has provided me with so many opportunities to learn, to talk, to listen and to have fun. 2023 has been a vintage year.

DrupalCon Lille Day 2 has already proven to be a unique day at DrupalCon! I’ve been lucky enough to attend “a few” DrupalCons in my day (I’ve been to every North American DrupalCon since Denver in 2012) but this is only my second European DrupalCon. And today for the first time at a DrupalCon (or tech conference) I listened to a keynote from a retired helicopter pilot. 

DrupalCon Europe 2023 started off today with over 1200 attendees in Lille, France! The energy in the building was amazing to see. Attendees started off exploring booths and took a chance at the Acquia claw machine to get some swag as the event kicked off with a welcome brunch in the exhibition area. It was great to meet old friends and new folks excited for what the week holds.

Introduction In the ever-evolving landscape of modern technology, a critical conversation has been unfolding around the environmental impact of our digital advancements. The spotlight has more recently been sharply focused on the primary offending sectors like cryptocurrency and artificial intelligence, revealing a concerning narrative about their substantial energy consumption and carbon footprint. This narrative also extends to the broader tech realm, encompassing the vast and intricate web of digital solutions we have all come to rely on. Amidst this backdrop, the IT sector, including software development, is becoming increasingly recognized for its significant carbon footprint. Recent estimates suggest that its CO2 emissions are around 4% of global totals, comparable to the aviation industry. This alarming statistic underscores the urgent need for sustainable practices within the sector. Organizations like the Green Software Foundation and The Green Web Foundation are at the forefront of addressing these challenges. They are leading the way in developing standards and best practices for greener software development. Their focus on software efficiency and energy-aware design is crucial in reshaping how the industry approaches sustainability. Drupal is a leading open-source CMS that[ powers 1%... Read more michaelemeyers Wed, 02/21/2024 - 07:11

You may often want to make your Python programs more interactive by responding dynamically to input from the user. Learning how to read user input from the keyboard unlocks exciting possibilities and can make your code far more useful.

The ability to gather input from the keyboard with Python allows you to build programs that can respond uniquely based on the preferences, decisions, or data provided by different users. By fetching input and assigning it to variables, your code can react to adjustable conditions rather than just executing static logic flows. This personalizes programs to individual users.

The input() function is the simplest way to get keyboard data from the user in Python. When called, it asks the user for input with a prompt that you specify, and it waits for the user to type a response and press the Enter key before continuing. This response string is returned by input() so you can save it to a variable or use it directly.

Using only Python, you can start building interactive programs that accept customizable data from the user right within the terminal. Taking user input is an essential skill that unlocks more dynamic Python coding and allows you to elevate simple scripts into personalized applications.

Get Your Code: Click here to download the free sample code that shows you how to get user input from the keyboard with Python.

How to Read Keyboard Input in Python With input()

You can create robust and interactive programs by taking advantage of input(). It opens up possibilities for creating scripts that respond dynamically based on adjustable conditions, personalized data, and real-time decision-making from the user. It is an ideal option when you want to read keyboard input with Python.

Getting started is straightforward. Just launch the Python interpreter shell, and you can immediately utilize input() for basic interactivity.

To try it, first open your terminal and launch the Python REPL by typing python and hitting Enter. This will display the familiar >>> Python prompt indicating the REPL is ready. Use input(), passing any string in the parentheses:

Python >>> input("What is your name? ") What is your name? Vincent 'Vincent' Copied!

Once you execute the code, the string that you specified in input() will be rendered on screen, and you’ll be able to type in any response. Your response will also print to the screen once you press Enter. This is because the REPL automatically prints return values—in this case, the value returned by input().

The best practice when using input() is to assign it to a variable that you can use later in your code. For example, you can ask the user to type in their name. Assign input() to the name variable:

Python >>> name = input("What is your name? ") What is your name? Vincent Copied!

This prints the prompt What is your name? and pauses, waiting for keyboard input. After the user types a name and presses Enter, the text string is stored in the name variable. This time, your input won’t automatically print in the REPL, because a variable stores the value instead.

You can now use the variable in any part of your code in the same session, like printing a personalized greeting:

Python >>> print(f"Hello there, {name}!") Hello there, Vincent! Copied!

Your program reacted based on the custom name that you provided. It used the name that you gave in the input() request.

This is the essential pattern when working with Python keyboard input:

1. Call input() with a prompt explaining what to enter.
2. Assign the result to a descriptively named variable.
3. Use that variable later in your code.

By following this template, you can start building all types of interactive scripts tailored to custom data from different users. Your programs can gather input of all types, such as names, numbers, and lists, making it quite handy in processing data from your users.

NOTE: Using input() processes all inputs as string literals, the users’ input isn’t executed as code. However, you should be wary of users’ inputs and assess them before executing them in your program, using them in database queries, or otherwise trusting them.

This is just the initial step that you can take in using input() in your interactive program. There are other modifications that you can make to ensure that the function takes in all manner of data types.

Reading Specific Data Types With the Input Function

The general rule for input() is that it collects textual input and delivers strings. Your code often needs numbers, Booleans or other data types instead. For example, maybe you need to get integers for math operations, floats for calculations with decimals, or Booleans for logical conditions.

As input() returns strings, you need to convert all the input into the targeted desired data type before using it in your code. If you ask for numerical input, the outcome will still be returned as a string:

Read the full article at https://realpython.com/python-keyboard-input/ »

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

I use GeoPandas for a lot of my vector GIS data manipulation in Python.

I had a situation the other day where I ended up with duplicates of some geometries in my GeoDataFrame, and I wanted to remove them. The simple way to do this is to use the underlying pandas method drop_duplicates on the geometry column, like:

gdf.drop_duplicates('geometry')

However, even after running this I still had some duplicate geometries present. I couldn’t quite believe this, so checked multiple times and then started examining the geometries themselves.

What I found was that my duplicates were technically different geometries, but they looked the same when viewing them on a map. That’s because my geometries were LineStrings and I had two copies of the geometry: one with co-ordinates listed in the order left-to-right, and one in the order right-to-left.

This is illustrated in the image below: both lines look the same, but one line has the individual vertex co-ordinates in order from left-to-right and one has the same co-ordinates in order from right-to-left.

These two geometries will show as the same when using the geometry.equals() method, but won’t be picked up by drop_duplicates. That’s because drop_duplicates just serialises the geometry to Well-Known Binary and compares those to check for equality.

I started implementing various complex (and computationally-intensive) ways to deal with this, and then posted an issue on the GeoPandas Github page. Someone there gave me a simple solution which I want to share with you.

All you need to do is run gdf.normalize() first. So, the full code would be:

gdf.normalize() gdf.drop_duplicates('geometry')

The normalize() method puts the vertices into a standard order so that they can be compared easily. This works for vertex order in lines and polygons, and ring orders in complex polygons.

Starting today, the Drupal 11.x branch is used for building the next major Drupal version, Drupal 11. This means that major version specific changes can now happen on the Drupal 11.x branch. This includes dependency and requirements updates and removal of deprecated API and extensions. Details are available in the allowed changes during Drupal core release cycle document.

Drupal 11 is planned to be released either on the week of June 17, week of July 29 or week of December 9, 2024, depending on when beta requirements are completed.

A 10.3.x branch was created to work on the upcoming minor version. Drupal 10.3.0 will be released on the week of June 17, 2024.

Issues should remain targeted at the 11.x branch and will be backported when appropriate.