FLOSS Project Planets
The Drop Times: Brad Jones on Modernizing Drupal's Data Management with JSON Integration
Real Python: The Real Python Podcast – Episode #214: Build Captivating Display Tables in Python With Great Tables
Do you need help making data tables in Python look interesting and attractive? How can you create beautiful display-ready tables as easily as charts and graphs in Python? This week on the show, we speak with Richard Iannone and Michael Chow from Posit about the Great Tables Python library.
[ 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 ]
Python Software Foundation: Notice of Python Software Foundation Bylaws change, effective 10 August 2024
Specifically, Bylaws Article XIII as originally written compels the Python Software Foundation to extend indemnity coverage to individual Members (including our thousands of “Basic Members”) in certain cases, and to advance legal defense expenses to individual Members with surprisingly few restrictions.
Further, the Bylaws compel the Foundation to take out insurance to cover these requirements, however, insurance of this nature is not actually available to 501(c)(3) nonprofit corporations such as the Python Software Foundation to purchase, and thus it is impossible in practice to comply with this requirement.
In the unlikely but not impossible event of the Foundation being called upon to advance such expenses, the potential financial burden would be virtually unlimited, and there would be no recourse to insurance.
As this is an existential threat to the Foundation, the Board has agreed that it must immediately reduce the Foundation’s exposure, and has opted to exercise its ability to amend the Bylaws by a majority vote of the Board directors, rather than by putting it to a vote of the membership, as allowed by Bylaws Article XI.
Acting on legal advice, the full Board has voted unanimously to amend its Bylaws to no longer extend an offer to indemnify, advance legal expenses, or insure Members when they are not serving at the request of the Foundation. The amended Bylaws still allow for indemnification of a much smaller set of individuals acting on behalf of the PSF such as Board Members and officers, which is in line with standard nonprofit governance practices and for which we already hold appropriate insurance.
The full text of the changes can be viewed at https://github.com/python/psf-bylaws/compare/a35a607...298843b
These changes shall become effective on Saturday 10 August 2024, 15 days from the date of this notice.
Any questions about these changes may be sent to psf@python.org. We gladly welcome further suggestions or recommendations for future Bylaws amendments.
Thank you,
The PSF Board of Directors
1xINTERNET blog: How to optimise team efficiency by reducing "Work in Progress"
Work in Progress (WIP) is a well-known concept for optimising efficiency in various business processes. It is straightforward to understand and apply. In this article, we will show you how, and give examples how we apply it with a team of around 100 colleagues.
mark.ie: My Drupal Core Contributions for week-ending July 26th, 2024
Here's what I've been working on for my Drupal contributions this week. Thanks to Code Enigma for sponsoring the time to work on these.
Python Software Foundation: Python’s Supportive and Welcoming Environment is Tightly Coupled to Its Progress
We believe to be “welcoming” means to do our best to provide all participants with a safe, civil, and respectful environment when they are engaging with our community - on our forums, at PyCon events, and other spaces that have committed to following our Code of Conduct. That kind of environment doesn’t happen by accident - a lot of people have worked hard over a long time to figure out the best ways to nurture this welcoming quality for the Python community. That work has included drafting and improving the Code of Conduct, crafting and implementing processes for enforcing it, and moderating the various online spaces where it applies. And most importantly the huge, collective effort of individuals across the community, each putting in consistent effort to show up in all the positive ways that make the Python community the warm and welcoming place that we know.
The recent slew of conversations, initially kicked off in response to a bylaws change proposal, has been pretty alienating for many members of our community. They haven’t all posted publicly to explain their feelings, but they have found other ways to let the PSF know how they are feeling.
- After the conversation on PSF-Vote had gotten pretty ugly, forty-five people out of ~1000 unsubscribed. (That list has since been put on announce-only)
- We received a lot of Code of Conduct reports or moderation requests about the PSF-vote mailing list and the discuss.python.org message board conversations. (Several reports have already been acted on or closed and the rest will be soon).
- PSF staff received private feedback that the blanket statements about “neurodiverse people”, the bizarre motives ascribed to the people in charge of the PSF and various volunteers and the sideways comments about the kinds of people making reports were also very off-putting.
Some examples:
- Most Code of Conduct reports – Oftentimes, these reports have the potential to affect both the reporter and the reported person’s reputations and livelihoods so our practice is to keep them confidential when possible to protect everyone involved. Some of you have been here long enough to remember the incident at PyCon US in 2013, an example of the entire internet discussing a Code of Conduct violation that led to negative repercussions for everyone involved, but especially for the person who reported the behavior.
- Legal advice and proceedings – It is an unfortunate fact of the world that the legal system(s) we operate under sometimes require us to keep secret information we might otherwise prefer to disclose, often because doing so could open us up to liability in a way that would create significant risk to the PSF or it could potentially put us in violation of laws or regulation. It’s our responsibility to follow legal guidance about how to protect the Foundation, our resources, and our mission in these situations.
- Mental health, personal history, or disability status – Community members should not, for example, have to disclose their status as neurodivergent or share their history with abuse so that others can decide if they are allowed to be offended. Community members should also not be speculating about other individuals’ characteristics or experience in this regard.
Part of the care-taking of a diverse community “where everyone feels welcome” sadly often means asking some people to leave – or at least take a break. This is known as the paradox of tolerance. We can not tolerate intolerance and we will not allow combative and aggressive behavior to ruin the experience in our spaces for everyone else. People do make honest mistakes and don’t always understand the impact that their words have had. All we ask is that as community members we all do our best to adhere to the Code of Conduct we’ve committed to as a community, and that we gracefully accept feedback when our efforts fall short. Sometimes that means learning that the words, assumptions or tone you’re using aren’t coming across the way you’ve intended. When a person’s words and actions repeatedly come in conflict with our community norms and cause harm, and that pattern hasn’t changed in response to feedback – then we have to ask people to take a break or as a last resort to leave the conversation.
Our forum, mailing lists and events will continue to be moderated. We want to thank everyone who contributed positively to the recent conversations and everyone who made the hard choice to write to us to point out off-putting, harmful, unwelcoming or offensive comments. We especially want to thank all the volunteers who serve on the Python Discourse moderation team and our Code of Conduct Working Group. We know it’s been a long couple of weeks, and although your work may occasionally be draining and unpleasant, it is also absolutely essential and endlessly appreciated by the vast majority of the community. Thank you for everything you do!
Sincerely,
Deb Nicholson
Dawn Wages
Tania Allard
KwonHan Bae
Kushal Das
Georgi Ker
Jannis Leidel
Cristián Maureira-Fredes
Christopher Neugebauer
Denny Perez
Cheuk Ting Ho
Simon Willison
Web Review, Week 2024-30
Let’s go for my web review for the week 2024-30.
On Open Source and the Sustainability of the CommonsTags: tech, foss, licensing, sustainability, commons, politics
It’s a piece which really resonates with me. I’ve been thinking and saying for a while that focusing mostly on the technical (licensing and dev) aspects of Open Source was a mistake. This completely overlooked the political side of the Free Software equation. This is why the industry is as it is now. We need stronger commons and indeed the AGPL is best for that.
https://ploum.net/2024-07-01-opensource_sustainability.html
Tags: tech, programming
A few surprises in there but otherwise it feels a bit like a repeat from last year. I keep being dismayed at how low the ethical concern of the energy impact of generative AI scores in this survey.
https://survey.stackoverflow.co/2024/
Tags: tech, windows, safety
The cleanup of that mess is still on-going. A bit more automation would help.
Tags: tech, ai, machine-learning, gpt, criticism
Content creators are clearly annoyed at the lack of consent. The more technical ones are trying to take the matter in their own hands.
https://www.404media.co/the-backlash-against-ai-scraping-is-real-and-measurable/
Tags: tech, ai, machine-learning, gpt, graphics, astronomy, physics
Still not perfect, but that’s an interesting development.
Tags: tech, data, ai, machine-learning, gpt, research
More discussion about models collapse. The provenance of data will become a crucial factor to our ability to train further models.
https://www.nature.com/articles/s41586-024-07566-y
Tags: tech, security, hiring, remote-working
Interesting story. This is getting harder to hire for remote positions I guess.
https://blog.knowbe4.com/how-a-north-korean-fake-it-worker-tried-to-infiltrate-us
Tags: tech, bios, security, hardware
A reminder that Secure Boot is worth nothing if the device makers don’t manage cryptographic keys properly…
Tags: tech, transportation, security
Make sure to read also part 2. You’d expect critical infrastructure like this to not be exposed over the Internet, and to be properly protected…
https://www.redthreatsec.com/blog/greenlightspart1
Tags: tech, crdt, rust, javascript
Need to make a realtime collaboration application? This might come in handy.
Tags: tech, networking, storage, benchmarking
Interesting comparisons, some of it was a bit unexpected to me. I didn’t expect SSHFS to be that OK.
https://blog.ja-ke.tech/2019/08/27/nas-performance-sshfs-nfs-smb.html
Tags: tech, time, tests, tools
This can definitely come in handy. I can see myself using it for testing behaviors in the past or the future on a real application. This should also help writing automated tests in some cases.
https://github.com/wolfcw/libfaketime
Tags: tech, c++
This is indeed a shame. It’d be nice to not add all the concepts you plan on supporting in the class declaration…
https://lemire.me/blog/2024/07/22/does-c-allow-template-specialization-by-concepts/
Tags: tech, c++, type-systems
There’s a good reason to have it in the standard. As mentioned in this post it can help with std::variant.
https://devblogs.microsoft.com/oldnewthing/20240708-00/?p=109959
Tags: tech, psychology, developer-experience
Interesting preprint review. Not sure I got it all in depth, will definitely need to revisit it at some point.
https://osf.io/preprints/psyarxiv/qz43x
Bye for now!
Promet Source: Provus®Gov vs CivicPlus for Local Government
Talk Python to Me: #472: State of Flask and Pallets in 2024
KDE Human Interface Guidelines update
It’s been about a month and a half since I wrote about KDE’s new Human Interface Guidelines (HIG). It turns out there’s a surprising amount to report since then!
First of all, the news got picked up by Linux Magazine which did a story about it, including an interview with me! That felt nice.
Next, there have been a number of contributions and enhancements:
Joshua Goins- Fixed a lot of typos, awkward wordings, and small errors.
- Added information about using Qt to set Task Manager badges directly.
- Expanded the instructions on contributing to the HIG.
- Corrected several typos and spelling errors.
- Improved the grammatical correctness of one of the text recommendations.
- Polished up the text some more.
- Added additional suggested inclusiveness-related text replacements.
- Clarified when a hamburger menu is and isn’t appropriate.
- Updated the icon size recommendations.
- Added examples and suggested replacements for common acronyms.
- Wrote a recommendation for how to implement “go home” navigation.
- Mentioned when first-run wizards are and aren’t appropriate, migrating some content from our old “Frequently discussed topics” wiki page.
- Refined the recommendation for button length and combox text capitalization.
- Described when it’s appropriate to shorten button labels because nearby context indicates what they affect.
- Expanded the Icons page to offer more concrete guidelines about how to choose an icon and what style to use, and also added more pictures.
Overall I think it’s looking pretty good now, especially the Icons page which received a lot of attention recently.
In addition, there are more pending merge requests by Christoph Wolk, Emir Sari, and me. So it feels like an actual team project now! I think the goal of encouraging more contribution can be called a success.
Finally, Christoph Wolk and I have been going through System Settings pages and tweaking them to comply with the HIG. System Settings is good low-hanging fruit since it’s almost all QML at this point, so changes are easy. And there are a lot of pages, so it’s not hard to find small inconsistencies.
But were not finished yet! More eyeballs are needed. A few TODOs need resolving. More images could be helpful. So check out these two links to learn how to contribute changes:
- https://develop.kde.org/hig/#contributing
- https://invent.kde.org/documentation/develop-kde-org/-/blob/master/README.md
Even a beginner developer can help out by tweaking the user interface to conform to the HIG. And if you’re a hardcore developer, we still need some more components for writing powerful QML apps.
Still too scary? Then donate to KDE. Our budget is tiny, so your money genuinely does have an impact!
eiriksm.dev: Getting rid of cronner.module
Background: This blog post is part 2 of musings around legacy code on violinist.io. Violinist.io is an automated dependency updater for PHP/Composer. It's a SaaS built on Drupal 8, now running on Drupal 10, in its eigth year. In this second post I am looking at one way to approach legacy code, and how to use static analysis and test driven development to safely refactor and remove legacy code.
Some months ago I wrote about the combined feeling of shame and respect that surrounds legacy code. In an attempt to get rid of the legacy code in what is called cronner.module, I will start from the top of the .module file, and work my way towards removing it completely. From time to time, that can also result in a good blog post, I thought. Here's a blog post about that.
The first lines of the module file is this:
<?php /** * @file * Cronner module. * * Bad name, but what are you going to do, right? */The code here sounds a bit resigned when it asks about what are you going to do. But in this blog post, what are we going to do? We will start the process of getting rid of all of it, that's what we will do!
The first few lines of actual code are constant definitions. Here's the first one:
define('CRONNER_STATE_KEY_PREFIX', 'cronner_state.node.');So far we can speculate, but it seems to be a prefix. And it's used for storing some state about nodes. Defining constants like this might seem strange if you are a bit new to Drupal, but this way of defining constants was canonical in Drupal 7 and below, but also followed a lot of codebases into the Drupal 8 era. Drupal core as well actually. One such example is the constant FILE_EXISTS_RENAME which lived on until Drupal 9 (deprecated in 8.7.0). Anyway I digress.
What we want then, is to remove this one constant. Let's just try that and see what breaks? Here's the output from phpunit:
There were 19 errors: … Error: Undefined constant "CRONNER_STATE_KEY_PREFIX”The unit tests are failing. 19 of them. Good start, we have decent unit test coverage. Let's see if our integration tests fail?
xxx scenarios (xx passed, 112 failed) xxxx steps (xxxx passed, 49 failed, xxx skipped) xxmxx.xxs (90.59Mb)112 scenarios failed in our behat test suite. Great indication that we can remove things safely! Lastly let's do some static analysis with PHPStan:
Line web/modules/custom/cronner/cronner.module ------ --------------------------------------------------------------------- xxx Constant CRONNER_STATE_KEY_PREFIX not found.As expected, PHPStan also informs me about this change being a problem. Thanks PHPStan! It also indicates that among the scanned files, the constant is only used once. It's used like this:
/** * Gets the state key of a node. */ function _cronner_get_state_key(NodeInterface $node) { return CRONNER_STATE_KEY_PREFIX . $node->id(); }In addition to the comment being very little helpful, this tells me I have just encountered another part of the cronner module to remove. Let's remove this entire function as well since we already know the function must be covered by both unit tests and integration tests. Then let’s go ahead and use a combination of TDD and static analysis (with PHPStan) to make sure our refactoring is successful. I remove the function and re-run PHPStan:
Function _cronner_get_state_key not found. … [ERROR] Found 7 errorsPHPStan is helpfully pointing out all of the 7 places I should start with the refactoring. I look through some of them and see the usages are quite connected to some of the other constants in the beginning of the file:
define('CRONNER_PROJECT_NEW', 'new'); define('CRONNER_PROJECT_QUEUED', 'queued'); define('CRONNER_PROJECT_RUNNING', 'running'); define('CRONNER_PROJECT_PROCESSED', 'processed'); define('CRONNER_PROJECT_ERRORED', 'errored'); define('CRONNER_PROJECT_UNKNOWN', 'unknown');My mother always used to say. When you are tidying up your room it’s best to keep going while you are somewhat effective in deciding what to get rid of. If you find some of your old toys and start to play with them, it’s an indication that the tidying session is heading towards an unproductive state. And right now I feel effective and decide right away I am removing those constants as well. I guess that also makes the analogy to me tidying my room as a kid kind of weird, since the opposite would mean these constants were my toys, and I end up playing with them? I mean, I do end up playing with old code from time to time, but constants? No fun playing with.
But looking at these old toys, it also becomes obvious what we use these constants for. Node state could mean all kinds of things, right? This is used to store and update the job status of the projects. Like if they are currently queued, if they are currently running and so on.
So it turns out that while removing this, this actually seems like a good opportunity to clean up some of that code and make it a bit more modern. What I usually do when cleaning up custom code like this is to put as much as possible on drupal.org as open source code. This is the case now as well. So I open an issue to create a project run status service, and start to refactor the custom code and logic surrounding the removals of constants and functions in cronner.module. It can be found here: https://www.drupal.org/project/violinist_projects/issues/3453459.
Now I go ahead and start using this service. It quickly becomes obvious that some of the constants are also used in a map to display a human readable status to the user:
/** * Gets a human readable version of a status constant. * * @param string $status * A status constant. * * @return string * Something more sensible. */ function cronner_get_human_status($status) { $map = [ CRONNER_PROJECT_UNKNOWN => t('Unknown'), CRONNER_PROJECT_ERRORED => t('Errored'), CRONNER_PROJECT_PROCESSED => t('Processed'), CRONNER_PROJECT_RUNNING => t('Running'), CRONNER_PROJECT_NEW => t('New'), CRONNER_PROJECT_QUEUED => t('Queued'), ]; return !empty($map[$status]) ? $map[$status] : $status; }There’s also methods for getting a state from a node, and setting it. Which I am also removing, and finding usages of in static analysis:
xxx Function cronner_set_state not found. 💡 Learn more at https://phpstan.org/user-guide/discovering-symbols xxx Function _cronner_get_state_key not found. 💡 Learn more at https://phpstan.org/user-guide/discovering-symbols xxx Function cronner_get_human_status not found. 💡 Learn more at https://phpstan.org/user-guide/discovering-symbolsOr in unit tests like so:
ReplaceTokensTest::testClaimJobAndTokenReplaced Error: Call to undefined function cronner_set_state()Instead of these calls to getting the state, setting the state, and getting the human readable state, I am now using the newly created service. When I started writing this blog post I was very much looking forward to summarizing the numbers of deleted lines and how great that was, but in practice some of the changes are actually adding lines to the module:
- cronner_set_state($node, CRONNER_PROJECT_PROCESSED); + /** @var \Drupal\violinist_projects\ProjectRunStatus $run_status_service */ + $run_status_service = \Drupal::service('violinist_projects.run_status'); + $run_status_service->setRunStatusForProject($node, ProjectRunStatusValue::STATUS_PROCESSED);Jokes aside. After some successful deletions and refactorings into using a service I am looking at 99 deletions and 55 additions. A net positive result I would say. Unfortunately there is still quite a way to go before I can go ahead and delete the entire folder called “cronner”. But at least I managed to refactor the codebase and delete the first 7 lines of constants in the file.
To celebrate this tiny step towards getting rid of cronner.module I tried to search for cronner on giphy. No hits, at this point. Oh well, here is an animated gif that supposedly illustrates “cronn”
FSF Blogs: A world where software freedom has a fighting chance and hope exists
A world where software freedom has a fighting chance and hope exists
GSoC'24 Okular | Week 4-8 Recap
The past weeks involved a lot of work surrounding the implementation of Acrobat specific methods for processing form fields, added support for different types of form widgets and some UI improvements were made or are being worked upon. A detailed list of MRs merged and raised is described below.
MRs merged:- AFTime_Keystroke implementation : This method implementation specifies what input keystrokes are allowed in a form field accepting time information. !MR987
- AFSpecial_Keystroke implementation : This method implementation specifies what input keystrokes are allowed in form fields of special type i.e. those that accept as input phone numbers, ssn and zip codes. !MR1013
- AFPercent_Keystroke and AFNumber_Keystroke methods implemented : These methods specify input keystrokes for percents and numerical data. !MR988
- Implement AFDate_KeystrokeEx and AFDate_FormatEx methods. : For correctly accepting input dates and formatting them according to some pre-specified format. !MR1017
- Global object implementation : A very basic implementation of global object that allows users to read and write to the global object. Persistence and subscription not supported as of now. !MR1016
- Commit values and restore: Implemented the feature to restore values to the previous committed value upon entering a value that is rejected by a keystroke action.!MR985
- Fix numerical interpretation in form fields: Calculations were suffering from a major bug 474661 that caused incorrect results when using different locales. This was fixed in the !MR992. The MR focused on how numerical values should be interpreted in form fields.
- Implemented DocClose, DocWillPrint, DocDidPrint, DocWillSave and DocDidSave events: Now actions are triggered during these events with the changes introduced in the !MR1019.
- Radio Buttons and Check Boxes size fix: Now radio buttons and check boxes are painted with correct size and resized when zooming to provide a better user experience. !MR1015
- Implement value (getter), numItems, currentValueIndices properties and getItemAt for FormFieldChoices: These methods were introduced to improve the functionality of FormFieldChoices. !MR1031
- ResetForm functionality in Poppler: The Reset form functionality was added to the Qt frontend in Poppler. Introduced in this commit
Along with these, more MRs are under works for things like implementing UI experience when using form fields and extending functionality of different types of form fields and actions.
See you next time. Cheers!
libtool @ Savannah: libtool-2.5.1 released [beta]
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.5.1, a beta release.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.
There have been 33 commits by 8 people in the 10 weeks since 2.5.0.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
The following people contributed changes to this release:
Bruno Haible (3)
Ileana Dumitrescu (24)
Julien ÉLIE (1)
Khem Raj (1)
Peter Kokot (1)
Richard Purdie (1)
Vincent Lefevre (1)
trcrsired (1)
Ileana
[on behalf of the libtool maintainers]
==================================================================
Here is the GNU libtool home page:
https://gnu.org/s/libtool/
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=v2.5.1
or run this command from a git-cloned libtool directory:
git shortlog v2.5.0..v2.5.1
Here are the compressed sources:
https://alpha.gnu.org/gnu/libtool/libtool-2.5.1.tar.gz (1.9MB)
https://alpha.gnu.org/gnu/libtool/libtool-2.5.1.tar.xz (1020KB)
Here are the GPG detached signatures:
https://alpha.gnu.org/gnu/libtool/libtool-2.5.1.tar.gz.sig
https://alpha.gnu.org/gnu/libtool/libtool-2.5.1.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
5e2f00be5b616b0a6120b2947e562b8448e139b2 libtool-2.5.1.tar.gz
aoPtr9QtTi69wJV5+ZzoKNX5MvFzjeAklcyMKITkMM4= libtool-2.5.1.tar.gz
9f72b896f593c4f81cdd6c20c9d99463663e48a9 libtool-2.5.1.tar.xz
0oDmTIzb8UXXb7kbOyGe2rAb20PLmUAuSsuX0BAGNv0= libtool-2.5.1.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify libtool-2.5.1.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa4096 2021-09-23 [SC]
FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid Ileana Dumitrescu <ileanadumi95@protonmail.com>
uid Ileana Dumitrescu <ileanadumitrescu95@gmail.com>
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key ileanadumi95@protonmail.com
gpg --recv-keys 6570EA01146F7354
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=libtool&download=1' | gpg --import -
As a last resort to find the key, you can try the official GNU
keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.5.1.tar.gz.sig
This release was bootstrapped with the following tools:
Autoconf 2.72e
Automake 1.17
Gnulib v1.0-563-gd3efdd55f3
NEWS
- Noteworthy changes in release 2.5.1 (2024-07-25) [beta]
** New features:
- Support C++17 compilers in the C++ tests.
- Add sysroot to library path for cross builds.
** Important incompatible changes:
- Autoconf 2.64 is required for libtool.m4 to use AS_VAR_APPEND.
** Bug fixes:
- Fix for uninitialized variable in libtoolize.
- Skip Fortran/C demo tests when using Clang with fsanitize to
avoid an incompatible ASan runtime.
- Updated documentation for testing.
- Fix failing test to account for program-prefix usage.
- Replaced a deprecated macro to remove warning messages in the
testsuite logs.
- Fix number of arguments for AC_CHECK_PROG call.
- Fix test failures with no-canonical-prefixes flag by checking
if the flag is supported first.
- Fix test failures with no-undefined flag by checking host OS
before appending the flag.
- Skip test when passing CXX flags through libtool to avoid test
failure on NetBSD.
- Remove texinfo warning for period in node name of pxref.
- Alter syntax in sed command to fix numerous test failures
on 64-bit windows/cygwin/mingw.
- Fix 'Wstrict-prototypes' warnings.
- Correct DLL Installation Path for mingw multilib builds.
- Fix '--preserve-dup-deps' stripping duplicates.
- Disable chained fixups for macOS, since it is not compatible with
'-undefined dynamic_lookup'.
** Changes in supported systems or compilers:
- Support additional flang-based compilers, 'flang-new' and 'ftn'.
Enjoy!
The Drop Times: A Look Back: Highlights from DrupalCamp Asheville 2024
mark.ie: My LocalGov Drupal contributions for week-ending July 26th, 2024
Here's what I've been working on for my LocalGov Drupal contributions this week. Thanks to Big Blue Door for sponsoring the time to work on these.
Tag1 Consulting: Migrating Your Data from D7 to D10: Migrating content types
This step-by-step series has covered a lot of ground on planning and preparing for a Drupal 7 to Drupal 10 migration. Today, we start putting that knowledge into practice by automatically migrating content types. First, we will execute a migration to pull all content types in Drupal 7. Then, we will customize the migration to remove unnecessary content types. Finally, we will learn how a separate node title label migration also affects content type configuration in Drupal 10.
Read more mauricio Thu, 07/25/2024 - 06:32Drupal Association blog: FAQs About Drupal 7's End of Life
As Drupal 7's end-of-life (EOL) approaches on 5 January 2025, many users have questions about what this means for their Drupal websites and what steps they need to take. Here, we address the most frequently asked questions to help you navigate this transition.
What does end-of-life mean for Drupal 7?End-of-life (EOL) means that Drupal 7 will no longer receive security updates, fixes, or official support from the Drupal community after 5 January 2025. This will impact the security, compliance, and functionality of any site that continues to run on Drupal 7.
Why is Drupal 7 being retired?Drupal 7 will be 14 years old when it reaches the end of life. That's a long time in the software world. Drupal 7 is being retired to allow the Drupal community to focus on newer versions built with a more modern architecture and more advanced capabilitie. This shift ensures that resources are directed towards maintaining and innovating the more modern versions of Drupal, including the Drupal Starshot intiative.
What are the key dates I need to know?- 23 February 2022: Announcement of Drupal 7 EOL extension.
- 1 August 2023: Commencement of reduced support for moderately critical issues, alongside other support changes.
- 5 January 2025: Official end-of-life date for Drupal 7.
Once Drupal 7 reaches its EOL, no further security advisories or updates will be provided. If you must remain on Drupal 7, we recommend opting for a commercial vendor who offers extended support. HeroDevs Drupal 7 Never-Ending Support (NES), is the first such offering available. This service is a seamless drop-in replacement for Drupal 7, providing your site with ongoing security updates, compliance support, and compatibility fixes past end-of-life.
What happens to unsupported modules and themes?Starting 1 August 2023, any unsupported Drupal 7 module or theme will no longer be eligible for new maintenance once it goes unsupported. If a module or theme you rely on becomes unsupported, it’s crucial to proactively adopt or migrate it to a newer version. HeroDevs Drupal 7 NES also provides module support if you choose that route.
What are the PHP version requirements?From 1 August 2023, Drupal 7 no longer supports PHP versions lower than 5.6. Further increases in the minimum PHP requirement may occur before Drupal 7's EOL.
Are there any specific operating system considerations?Drupal 7 security fixes for Windows-only issues ceased on 1 August 2023. If your site runs on Windows, migrating to another operating system is recommended.
Will drupal.org continue to package Drupal 7 distributions?No, as of 1 August 2023, Drupal.org stopped packaging Drupal 7 distributions. Users needing a distribution built must use Drush make locally.
What are my options moving forward?- Migrate to Modern Drupal: Upgrading to Drupal 10 or the upcoming Drupal 11 is strongly recommended to ensure continued security, support, and access to new features. Modern Drupal versions adopt the latest PHP standards and offer enhanced performance and security. In addition, Drupal Starshot is coming at the end of 2024, which bundles Drupal core with cutting-edge features and easier maintenance.
- Extended Security Support: The Drupal Association has partnered with HeroDevs to offer Drupal 7 Never-Ending Support (NES). This service provides ongoing security updates, compliance support, and compatibility fixes for Drupal 7 sites, allowing businesses more time to transition.
- Stay on Unsupported Drupal 7: Continuing to use Drupal 7 after its EOL is an option but comes with significant risks, including increased vulnerability to security exploits and compliance issues. Over time, support for PHP versions and other dependencies will also wane, making it harder to maintain your site. Other vendors may join the program before end of life.
The Drupal Association is certifying migration partners to help Drupal 7 site owners transition. Certified Migration Partners will be promoted on Drupal.org and can provide resources to assist in the migration process.
What should I do if I need help?For assistance, consider engaging with the Drupal community or Certified Migration Partners. Donating to the Drupal Security Team or sponsoring core maintainers and contributors can also help ensure the continuity and security of Drupal projects.
ConclusionOrganizations must make informed decisions as Drupal 7's EOL approaches to maintain security, compliance, and functionality. Upgrading to Drupal 10, Drupal 11, or leveraging extended support options will position your site for long-term success.
Real Python: Quiz: Getting Started With Testing in Python
In this quiz, you’ll test your understanding of testing your Python code.
Testing in Python is a huge topic and can come with a lot of complexity, but it doesn’t need to be hard. You can get started creating simple tests for your application in a few easy steps and then build on it from there.
With this quiz, you can check your understanding of the fundamentals of Python testing. Good luck!
[ 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 ]
Pages
Recent Publications
- Managing Hidden Dependencies in OO Software: a Study Based on Open Source Projects
- Open Source Communities as Liminal Ecosystems
- Investigating developers' email discussions during decision-making in Python language evolution
- Developers, Quality Control and Download Volume in Open Source Software (OSS) Projects
More...FLOSS Project Planets
- ImageX: Bold, Sleek, and Endlessly Customizable: the Gin Theme for Next-Level Drupal Admin Experiences
- Joerg Jaspert: Electric Car, Vacation trip
- Drupal blog: Drupal CMS: the official name for Drupal Starshot
- Drupal Starshot blog: Drupal CMS: the official name for Drupal Starshot
- Tag1 Consulting: Migrating Your Data from Drupal 7 to Drupal 10: Preparing for field migrations