September 2026 brought another wave of organizations whose Kiwi TCMS instances crossed the 1000-events mark for the first time. Below is a short, by no means exhaustive, look at who they are and what they do.

Disclaimer: the information below was obtained via anonymous analytics and represents only instances of Kiwi TCMS which crossed 1000 events during September 2026. We've used publicly available data in order to identify these organizations. Note that we don't keep track of individuals or IP addresses!

Austria

• Scientific Games - lottery systems, digital gaming and sports betting technology

Brazil

• S2 Game Test - game QA studio
• Wooba - technology for those who sell trips

Canada

• Incognito Software Systems - OSS Solutions for Broadband Management
• Sofstica - Software, Design & Digital Solutions

China

• Qitianhe Technology - software and AI agents
• X2Robot - general-purpose embodied intelligence robots

Colombia

• Prosof SAS - Soluciones que evolucionan

Ethiopia

• Commercial Bank of Ethiopia - the largest commercial bank in Ethiopia

Finland

• Gurulogic Microsystems Oy - video and image compression technology

Germany

• esatus AG - Digitale Identitäten & EUDI Wallet Integration

Indonesia

• Central Mega Kencana - luxury retail jewelry

Japan

• Fujitsu - technology and business solutions

Poland

• Maio Software House - IT solutions for growing your business

Romania

• SGDEV - Sky Game & Robotics Development

Spain

• IZERTIS - technology consultancy

Switzerland

• evismo AG - modern medical diagnostic services

Taiwan

• Dudoo - restaurant technology platform
• Pegatron - design and manufacturing services

UK

• Luno - crypto wallet and exchange
• MaxBill - Modern Billing and Revenue Management Solutions

USA

• Cisco Jabber - unified communications
• Krivexa - AI operating system for modern law firms

Academia & Education

• TH Köln - Germany

Government

• Gobierno de Colombia - Tayana institutional platform, Government of Colombia
• Belajar.id - learning platform, Ministry of Education - Indonesia

If you like what we're doing and how Kiwi TCMS supports various communities please help us!

• Give ⭐ on GitHub;
• Join our newsletter and follow all project news;
• Become a contributor and an awesome open source hacker;
• Become a subscriber and help us sustain development;
• Become a reseller and help us serve your community

Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.

The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.

There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don’t find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.

Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.

Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)

AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don’t have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.

That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.

Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.

I propose the following:

• GNOME maintainers should rewrite their AI contribution policies to permit AI-generated vulnerability reports, as I previously requested four months ago.
• Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.

We don’t have to tolerate bad issue reports, but AI use alone should not be disqualifying.

Shouldn’t humans rewrite AI-generated bug reports?

When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI’s report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.

Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it’s much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.

Rewriting issue reports also does not scale. Let’s say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI’s claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That’s more work than everything else combined, and is unrealistic.

Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won’t be as useful as a full report.

The CVE Wave Hits GNOME

The current wave of vulnerability reports is reflected in GNOME’s CVE issuance trends:

The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.

(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)

Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.

The CVE Wave Hits WebKitGTK

A similar pattern holds for WebKitGTK:

CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit’s own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.

There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.

I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.

Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program

My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It’s already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)

The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency. I’m not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had — naively — seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.

I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:

Those numbers for 2026 reflect less than two months’ worth of issue reports, so you can see why it was no longer sustainable.

After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack’s professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.

At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.

Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.

Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it’s not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.

Lessons from the Bug Bounty Program

Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.

I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.

I had hypothesized that GLib would be much better than libsoup. I’m not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.

A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It’s likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.

Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.

Red Hat Scans GLib

Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I’m not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.

Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.

I don’t have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.

It’s rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.

Humans Still Useful

In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in critical findings.

Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.

Humanity Still Desired

Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It’s pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.

We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.

Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:

• Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
• Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I’d like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
• Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
• Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You’re not fooling anybody.

Maintain Perspective

Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they’re not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.

I don’t want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.

Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It’s certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline — because issue reports should not stay confidential indefinitely — not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that’s how you want to spend your volunteer time.

Rust

Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.

Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably — I would even say probably — outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.

To Be Continued…

I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.

As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).

Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat’s suggestions to encrypt your mail using GPG, and use the following email template:

Hi, I request a CVE for:

Summary:
Requirements to exploit:
Component affected:
Version affected: All versions <-- change this if needed
Patch available: Yes/No
Version fixed (if any already):
Upstream coordination: See issue report (below)
CVSS (optional):
Impact (optional):
Embargo: No
Acknowledgment:
Steps to reproduce if available: see issue report
Mitigation if available: <-- it's OK to write "None"
Original report:

Request a CVE after making your issue report public. It’s possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.

GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.

In my other blog today, I explored how the other Reform UK Party Limited party/company was previously subject to a judgment and insolvency proceedings to try and extract payment.

Very few companies are ever listed in the official Gazette.

After that painful lesson, as they progress towards being in a position to run the UK Government, wouldn't you expect them to improve their procedures and run their party headquarters competently?

When Sarah Cooper-Lesadd recently resigned and defected from Reform UK, she told the BBC that Reform UK is chaotic.

In the Scotsman's report about the VMS Enterprises vs Brexit Party dispute, the party was described as "beyond chaotic". They can't seem to learn how to tie their shoelaces but they want to run the United Kingdom. If Nigel Farage does ever become Prime Minister, I hope his party remembers to pass on the messages when Argentina makes their next attempt to take the Falkland Islands.

It looks like Sarah Cooper-Lesadd is right. They admit despite having one of the most serious legal documents, a [redacted], served on their party headquarters, they have no idea where it went:

Fortunately, the process server provide video evidence so I can prove it was served correctly and the incompetence is not on my side.

In fact, the case only reached this point because of a litany of errors on the part of Reform UK themselves. Errors they should never have made if they learnt the lesson from the somebody who brought their party into insolvency proceedings in 2022.

Look at the cost. Their lawyers, Aston Bond, have invoiced over £25,000 before the first hearing. Most of that is for investigating what went wrong inside their own organisation and how the dispute was leaked by the MouseInTheCourt before the [redacted] ever arrived on the doorstep of party HQ.

Why is Nigel Farage so so afraid of a candidate who only got sixteen votes?

Read more about the various judgments in the history of Reform UK Party Limited.

As Reform UK tries to [redacted], they have complained to the court that [redacted] other failed candidates, Reform UK defectors, independent contractors and small business owners how to [redacted].

If they block more people [redacted]

It is not my intention to publish the forms unless the conduct and behaviour of these people forces me to do so.

Judgment: VMS Enterprises Ltd vs The Brexit Party Ltd ([2021] SC GLA 49)

The Brexit Party Ltd became Reform UK Party Ltd, company number 11694875. This subsequently got merged into Reform 2025 Ltd to become a different Reform UK Party Limited company no. 16260766. An inconvenient consequence of this name change and merger is that people searching for judgments against the new company number 16260766 don't see the history of the old company name and company number.

The full judgment is available here for download as an Acrobat document:

VMS Enterprises Ltd won the case but it took them over a year to get paid after the judgment. The records about VMS Enterprises Ltd (SC476412) at Companies House show us they are no longer active. It looks like beating Brexit Party / Reform UK in court was only a phyrric victory.

Not only was there a judgment ([2021] SC GLA 49), there were also some scholarly research articles published about the dispute:

On 10 September 2021, Scottish Legal News published a detailed summary "Glasgow sheriff orders Brexit Party to pay £22k in unpaid invoices to advertising firm".

On 15 November 2021, the case appeared again in a Law Society of Scotland article about case management review.

Despite the Sheriff making a judgment against the Reform people in July 2021, they still didn't pay the bill. On 19 July 2022, The Scotsman reported "Reform UK face winding up petition over £22,000 debt owed to Scottish firm".

Quoting the article:

The political party, formerly led by Nigel Farage as the Brexit Party during the 2019 general election, faces a hearing in the High Court in London as early as September. Victor Shields, director of VMS Enterprises, was forced to take the party – since rebranded and led by Richard Tice – to court over the bill from the 2019 general election. Despite Glasgow Sheriff Court agreeing the party should pay up, it has consistently refused to answer letters or pay the sum owed to the businessman, forcing him to take further legal action in England. It is understood a winding up petition was served on the political party last week, with a hearing set for September 7 or soon thereafter. Reform UK has consistently rejected the claim, now worth more than £26,000 after interest and before court expenses are taken into account. A winding up order, if granted by the court, would see the party face liquidation proceedings to pay the outstanding amount and could include an investigation into director conduct. The initial Scottish court case arose after a dispute between the party and VMS Enterprises around payment for election billboards in London during the general election campaign. The court stated the party was liable for the bill for advertising services after some invoices were paid by Brexit Party staff and others were not questioned. Several invoices had gone unpaid amid claims a volunteer did not have the authority to charge the party for the billboards. However, the court stated the failure to question the payment of invoices incurred by candidates meant the party was liable for the full costs. Speaking to The Scotsman last year, Mr Shields attacked Reform UK’s “hypocrisy” in failing to pay. He said: “I was quite happy to keep quiet after the judgment because I assumed they would respect the Scottish courts and duly pay us. "They don't care. They feel they are above the law. "Richard Tice is positioning himself to the right of Boris [Johnson] and trying to capture the Conservative voters, Scottish voters too and here we are being forced to go to English courts, for me being forced to spend further money, to try and recover a debt that is legally due to us." The court case heard witnesses describe the organisation of the Brexit Party, then led by former UKIP leader Nigel Farage, as "shambolic" by a party official as it struggled to cope with its popularity and decision to pull hundreds of candidates from the ballot paper ahead of polling day. Witnesses told the court the party’s organisational structure "visibly started to fall apart", was "very unprofessional" and "beyond chaotic" ahead of the 2019 election. Reform UK’s latest accounts state that in 2020 it received nearly £3 million in donations, with a further £17m in 2019. Reform UK has been contacted for comment by The Scotsman.

Eighteen months after the judgment, almost two years after the judicial procedure began, in December 2022, VMS Enterprises Ltd used the High Court insolvency procedure to publish an insolvency notice for Reform UK Party Limited.

As a consequence, a listing was placed in the official Gazette with their old company number 11694875 and the High Court case number CR-2022-003973.

Diagram demonstrating evolution of the Reform UK companies

Searching for information about the names and company numbers is tedious and time consuming. I created a colour-coded diagram so people can see and understand the relationship between the companies in the history of Reform UK at a glance.

Here is what you see if you search for Reform UK at Companies House. Which Reform UK is which?

Looking through the filing history of each company, you can see many minor changes, including some name changes. I put the filing history for both companies side-by-side:

Drilling down on the name changes, it is fascinating to put the two forms side-by-side like this:

Here is the full diagram I created to help people understanding the judgment and insolvency court history of Reform UK and its leaders at a glance:

Direct links to search the Gazette for old company number 11694875 and for the new company number 16260766.

People who have a legitimate claim against any company are encouraged to contact their solicitor for advice and share their contact details with other creditors to resolve the dispute more expediently. See my previous blog about how to join a creditors petition in the UK.

Read more about the various judgments in the history of Reform UK Party Limited.

On 25 June 2026, Reform UK, the political party, filed accounts for the 2025 calendar year with the Electoral Commission.

Reform UK is the only major political party in the UK that is also registered as a company at Companies House.

Consequently, each year, they must file a set of accounts, with an auditor's report, at Companies House. The deadline was today, 30 September 2026. Why did they file the accounts at the very last minute and not at the same time they filed with the Electoral Commission?

Click here to see the filing history and access the other accounts.

As explained in my previous blog on the subject, the reports given to Companies House are slightly different from the reports given to the Electoral Commission. The Electoral Commission is trying to show the impact of money on democracy. The Companies House report aims to give members, investors, trading partners and employees an image of the organisation's strength or weakness.

The document uploaded to the Electoral Commission in June is a text-searchable PDF. The PDF uploaded to Companies House is not text-searchable. However, Companies House also has another copy in iXBRL, which is an XHTML file that is text-searchable in a web browser.

At a glance, we can see the numbers are not exactly the same. For example, the membership revenue in the report to the Electoral Commission appears to be a bit higher because they used to collect the money through a different company and then they subsequently merged the two companies during the 2025 reporting year.

Like the report submitted to the Electoral Commission, the report submitted to Companies House does not mention the potential impact of the new, backdated restrictions on donations from overseas electors. If those restrictions are implemented soon, they will have a very severe impact on Reform UK. It seems odd to me they can completely omit that from the statement about the company being a going concern for the next 12 months.

One of the very significant differences in the Companies House report submitted today is on the very last page. It is the declaration about how they merged the two former companies and who really has control over the company, which is acting as a political party but is really a business:

19. Related party transactions

On 19 February 2025, the company acquired the entire issued share capital of Reform 2025 Ltd for consideration of £15.

...

20. Controlling party

The company is limited by guarantee and has no share capital. The company has two members, who have equal voting rights. Neither member has individual control of the company and, accordingly, there is no ultimate controlling party.

...

Legal form of entity and country of incorporation

...

The company is limited by guarantee and has no share capital. The liability of each member is limited to £1, being the amount that each member undertakes to contribute to the assets of the company in the event of its winding up. There were two members at the year end.

Looking at the full list of documents on the Companies House web site, we can find the first document filed when the company was created. They tell us the two real members of the company are Nigel Farage and Zia Yusuf.

Companies limited by guarantee in the UK are a special type of company that is normally used for non-profits and charities. In some non-profits, like sporting clubs, every member is really a member of the company and invited to the annual general meeting.

The accounts that Reform UK has just filed show us they have a two-tier membership structure, similar to the scandal of the FSFE misfits.

People who "join" Reform UK and pay £25 per year are not really members like Nigel Farage and Zia Yusuf are members in the accounts.

In UK law, the real members, Nigel Farage and Zia Yusuf, can choose to change it into a normal shareholder company at any time they want and then they can sell the shares or pass them to their children, as long as the articles of association permit that.

In June 2025, Zia Yusuf resigned from Reform UK and came back two days later. The accounts show us that he resigned from his position on the board but they do not tell us if he transferred his position as one of the two controlling members to somebody else.

Reform UK claims to have more members than any other political party in the UK. These accounts tell us their company only has two members, making it one of the smallest political parties at the same time as being one of the biggest.

If the members accept this two-tier structure, does that mean it really is a cult, as we were told by Rupert Lowe?

When they changed the structure, they told people they were making it more democratic. What they really did is they reduced their risk. If it fails, they only lose their guarantee, which is £1 each. If it succeeds, these two people can choose to pivot back to a shareholder company form, issue shares and sell them on the stock market.

The other thing they did through this reoganisation is obfuscating the history of disputes and judgments against the former company. It looks like at least one law suit is still progressing against the old company and it is not clear if the new company structure will be obliged to pay for it if they lose.

The UK permits directors, company secretaries and shareholders to be nominees, in other words, proxies contracted to obey the person who really pays them to perform that role. While Nigel Farage and Zia Yusuf are listed publicly as the members who founded the new entity in February 2025, there is no obligation for them to publicly identify any transfers of these memberships to other people. The only thing we can deduce from the report is that there are currently two members, the same number of members they had when they created the entity but not necessarily the same two people.

Read more about the various judgments in the history of Reform UK Party Limited.

Read more about the various judgments in the history of Reform UK Party Limited.

In the sentencing of the late Cardinal George Pell, it was his defence lawyer Robert Richter KC who argued the Cardinal should receive a lighter punishment because it was a "plain vanilla" case of abuse. In fact, when somebody in such a senior position of trust commits an offence of that nature, it is a lifelong case of psychological torture for the victims. That is what makes institutional abuse, such as the abuse by jurists and the abuse by the Catholic Church so much worse than other types of abuse.

The Cardinal was later acquitted on appeal. The day I dared to walk into a Carabinieri post, in Italy and explained the similarities between the way the snobby set collaborated to protect paedophiles in both the Church & Debian, the Cardinal died four hours later.

In my case against Reform UK Party Limited, I meekly asked them to pay £5,000, barely 0.1 percent of the controversial £5 million donation, based on Farage's promise to pay for the election. Instead, I received this priceless gem from Farage's own lawyers. Adam Richardson from 4-5 Gray's Inn Square has admitted Nigel Farage is "the Company's own candidate". This is one of those gaffs that may well stand the test of time, like the "plain vanilla" defense. I've never seen a confession like that in democracy before. So much for the promise the Clacton-on-Sea by-election was an opportunity to vote against the Establishment.

Read more about the various judgments in the history of Reform UK Party Limited.

Read more about the various judgments in the history of Reform UK Party Limited.

The Fedora QA team invites you to participate in the Anaconda F45 features Test Week, which is running now through October 2, 2026. There is still time to jump in this week and help us shape the Fedora 45 installer before it ships.

What’s New in the Anaconda F45 Installer

Fedora 45 brings three significant changes to how you install the system. Each one is ready for real-world testing – and better testing means a better installer.

On September 19, 2026, the Fedora Project supported the conduct of Software Freedom Day Bukidnon 2026. The event took place at the Northern Bukidnon State College, Manolo Fortich, Philippines.

Now in its second run, Software Freedom Day Bukidnon gathered students, professionals, educators, and community members to explore how Free and Open Source Software can empower innovation, digital inclusion, and impact their daily lives, primarily in the province of Bukidnon, Philippines. Despite the challenges like power outage, the event was a massive success, demonstrating the local community’s resilience and passion for open technology.

Event Highlights

The event features an impressive speaker lineup, with presentations spanning foundational Open Source principles and cutting-edge technology trends.

• 

• 

• 

• 

• 

• 

• 

• 

Linux and Open Systems

Hello Fedora by Paul Harriet Asiñero – This session introduced attendees to Fedora Linux, highlighting its pivotal role in driving Open Source innovation. Participants explored the power, robust security, and exceptional flexibility that make it one of the world’s premier Open Source operating systems.

Introduction to Automotive Grade Linux by Walt Miner – Attendees received an exciting look at how Open Source technology has moved beyond PCs and servers, driving the software systems that power modern smart vehicles.

Art and the Developer Workflow

Harnessing Krita For Fun and Profit by Romar Mayer Micabalo – Proving that Open Source is just as crucial for creatives as it is for developers, this talk walked attendees through building a career or hobby using Krita, a premier Open Source digital painting tool.

5 Cool Open Source Tools to Pimp Out Your Windows CLI by Jay Ginete – A practical guide for developers stuck on proprietary systems, showing how to upgrade a boring terminal into an Open Source-powered developer powerhouse.

The AI and Data Pipeline

Local LLMs: My 8GB VRAM vs the World by Arjay Sitoy – In a highly relevant, budget-conscious session, this talk demonstrated how developers can break free from corporate API reliance by running powerful Large Language Models locally on standard consumer hardware.

Practical Agentic Coding with OpenCode by Roger Madjos – Shifting from consumption to creation, this session showed developers how to leverage Open Source AI agents to actively write and debug code. Attendees walked away with a practical blueprint for turning agentic coding into a reliable, secure, and repeatable development workflow that delivers value faster without compromising quality.

Building a Second Brain: Turning Information into Leverage by Rafael Tibudan – Explored how to use knowledge management, AI, and automation to build a digital “second brain.” The session shared simple, scalable strategies to transform past code bugs, research notes, and AI conversations into a personal knowledge base.

Orchestration Still Matters: Apache Airflow in the Age of AI by Wei Lee – Attendees got a deep dive into the backend infrastructure powering modern technology. The talk drove home a crucial point: even as artificial intelligence dominates the headlines, leveraging Apache Airflow to control and orchestrate the data pipelines and workflows powering AI applications remains absolutely vital to AI success.

Page Follow Bingo Game and Raffle Draw

In addition to the engaging sessions, the event featured a Page Follow Bingo Game and an exciting raffle for all attendees. The Bingo game was designed to boost engagement for our event sponsors and partners by encouraging participants to follow their official pages, with the first five to complete the task being crowned winners. The event wrapped up with a raffle draw featuring an array of prizes generously contributed by our sponsors. The raffle was conducted using pyraffle, an Open Source raffle draw software executed within a notebook environment.

Final Thoughts

Despite the challenges, Software Freedom Day Bukidnon 2026 was a resounding success! An impactful movement like this cannot happen in isolation. As we look back on the success of this year’s event, our deepest gratitude goes out to the incredible individuals and organizations who helped bring this vision to life.

Event Sponsors and Partners

This event was made possible through the generous support of our partners and sponsors. In addition to the Fedora Project, we would like to extend our sincere gratitude to the following organizations:

Event Sponsors:

• NorthQA
• AlmaLinux OS Foundation
• ScaleForge
• Innovuze Solutions, Inc.
• openSUSE Project
• Northern Bukidnon State College

Event Partners:

• Google Developers Group Cagayan de Oro
• PyTsada (Cagayan de Oro Python Community)
• CDO Tech News

Aside from the participating organizations, we would like to express our gratitude to an anonymous donor for providing financial support for the event.

Speakers

Thank you for sharing your time, passion, and unparalleled expertise. You gave our community tangible frameworks to work with, sparking ideas that will undoubtedly fuel local tech innovation for months to come.

Event Volunteers

Volunteers are the backbone of Software Freedom Day Bukidnon 2026, driving everything from pre-event preparations to post-event operations. We are proud to recognize the dedicated individuals who made this success possible:

• Ma. Estella Bravo
• Alyssa Luchana Vallejos
• Jhon Lloyd Cabahug
• Cherry Mae Ann Besin
• Silverio M. Laspoña, Jr.
• Demie More Terig

• Marlon Camongay
• Diether Labis
• Cliff Amadeus Evangelio
• Giovanny Barsobia
• Paul Harriet Asiñero

Participants

Thank you for taking the time out of your weekend to show up, engage, and learn. Your energy, thoughtful questions, and collaborative spirit are what give life to the FOSS movement in Bukidnon. You are the future of our digital landscape, a thriving ecosystem where the veterans lift up the rookies, passing the torch to ensure the next generation keeps pushing boundaries.

The event has wrapped up, but our mission continues. The Free and Open Source Software movement in Bukidnon thrives because of community advocates and supporters like you. As we look ahead to the return of Software Freedom Day next September, we invite you to join us as a participant, volunteer, sponsor, or partner. Together, we can empower local tech ecosystems and drive collaborative innovation.

The post Fedora Shines Blue at Software Freedom Day Bukidnon 2026 appeared first on Fedora Community Blog.

2026-09-29T12:00:00Z 2026-09-29T12:00:00Z Paul Harriet Asiñero https://communityblog.fedoraproject.org/ https://communityblog.fedoraproject.org/wp-content/uploads/2022/07/favicon-fedora-commblog.png The Community Blog provides a single source for members of the community to share important news, updates, and information about Fedora with others in the Project community. 2026-10-07T21:07:54Z https://fedorafans.com/?p=8576

ای مهرِ دارنده‌ی چراگاه‌های فراخ! به اسبانِ ما تندی و به تن‌های ما نیرو ببخش، تا دشمنانمان را زیر نظر گیریم، آنان را فروکوبیم و هماوردان و دشمنان و بدخواهانمان را به یک زخم از پای درآوریم.

The post مهرگان بر شما خجسته باد first appeared on طرفداران فدورا.

2026-09-29T11:36:16Z 2026-09-29T11:36:16Z hos7ein https://fedorafans.com همه برای فدورا , فدورا برای همه 2026-09-29T11:36:16Z https://www.scrye.com/blogs/nirik/posts/2026/09/26/misc-fedora-bits-fourth-week-of-sep-2026/

Time for another saturday recap of the week in longer form.

A interesting interrelated issue

A while back we moved our ansible control host to rhel10. After this move, I noticed that the nightly job we run to run a --check --diff over all our playbooks was taking a really long time to finish. I added it to my todo list to look at sometime but didn't think it was super high priority.

Last week we got some zabbix alerts about disk space on our central logging host (log01). Usually when this happens, it's caused by some openshift application crash looping or sending large tracebacks over and over. However, that was not the case this time, as we had added some checks to notify if that ever started happening so we could fix things more quickly.

Looking at the (large) logs, it seemed like it was mostly builders and mostly ssh-session messages.

Thinking these two issues could somehow be related, we started digging into the check-diff run first. It seemed that ansible was connecting to the target hosts, then just disconnecting again and again in a loop. But why?

Dumping the trace output into a clanker gave a quick answer: it's an ansible-core bug. Specifically: https://github.com/ansible/ansible/issues/82685

TLDR: If you specify multiple facts gathering modules (which we do because we have one that gathers some python information), it tries to do them in parallel, but there is a bug and it fails.

So, That was the base cause of both issues. check-diff was slow because it would get stuck trying to gather facts (and get killed after 24h by the script), and it was also causing tons of log messages for each ssh connection which was filling up log01.

A simple:

ansible_facts_parallel: false

Fixed both things.

RHEL10 Database servers

Staging is all done, all servers there are postgresql 18 and rhel10 now. The last one was db-datanommer01.stg, which I did monday. Its still a complex process, but it seems working and doesn't need a intermediate rhel9 instance (as long as I am willing to upgrade the existing one's timescaledb).

So, next thursday we have a outage and I am going to try and migrate all the production database servers. I'll be glad when they are all done.

I might try and do db-datnommer production a different day. Its a lot more complex than the rest and might be good to get out of the way seperately. Also, it's not super end user facing, so it can probibly be down for a little while without too much ill effect. Thats likely to be tuesday or wed.

Mass updates/reboots/outage next week

This is going to be a big one:

• We are going to apply firmware updates on servers. This always makes reboots take a while as they have to apply the firmware upgrades.

• We have some machines that aren't booting with secureboot enabled and we want to fix those. Sadly that means a boot to setup, enable, and another boot, which takes a while.

• I am going to migrate all the prod database servers over to rhel10. This is likely to take a while, but not too bad. There's no dump restore needed, just 'fast' upgrades and shuffling things around so the old rhel9 instances are retired and the new rhel10 ones take their place.

Of course eariler in the week we will do staging and any hosts we can take out of dns, etc... so thursday will mostly just be the bare metal / vmhosts and their guests that we can't take down without an outage.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117338602297421813

Time for another saturday recap of the week in longer form.

A interesting interrelated issue

A while back we moved our ansible control host to rhel10. After this move, I noticed that the nightly job we run to run a --check --diff over all our playbooks was taking a really long time to finish. I added it to my todo list to look at sometime but didn't think it was super high priority.

Last week we got some zabbix alerts about disk space on our central logging host (log01). Usually when this happens, it's caused by some openshift application crash looping or sending large tracebacks over and over. However, that was not the case this time, as we had added some checks to notify if that ever started happening so we could fix things more quickly.

Looking at the (large) logs, it seemed like it was mostly builders and mostly ssh-session messages.

Thinking these two issues could somehow be related, we started digging into the check-diff run first. It seemed that ansible was connecting to the target hosts, then just disconnecting again and again in a loop. But why?

Dumping the trace output into a clanker gave a quick answer: it's an ansible-core bug. Specifically: https://github.com/ansible/ansible/issues/82685

TLDR: If you specify multiple facts gathering modules (which we do because we have one that gathers some python information), it tries to do them in parallel, but there is a bug and it fails.

So, That was the base cause of both issues. check-diff was slow because it would get stuck trying to gather facts (and get killed after 24h by the script), and it was also causing tons of log messages for each ssh connection which was filling up log01.

A simple:

ansible_facts_parallel: false

Fixed both things.

RHEL10 Database servers

Staging is all done, all servers there are postgresql 18 and rhel10 now. The last one was db-datanommer01.stg, which I did monday. Its still a complex process, but it seems working and doesn't need a intermediate rhel9 instance (as long as I am willing to upgrade the existing one's timescaledb).

So, next thursday we have a outage and I am going to try and migrate all the production database servers. I'll be glad when they are all done.

I might try and do db-datnommer production a different day. Its a lot more complex than the rest and might be good to get out of the way seperately. Also, it's not super end user facing, so it can probibly be down for a little while without too much ill effect. Thats likely to be tuesday or wed.

Mass updates/reboots/outage next week

This is going to be a big one:

• We are going to apply firmware updates on servers. This always makes reboots take a while as they have to apply the firmware upgrades.

• We have some machines that aren't booting with secureboot enabled and we want to fix those. Sadly that means a boot to setup, enable, and another boot, which takes a while.

• I am going to migrate all the prod database servers over to rhel10. This is likely to take a while, but not too bad. There's no dump restore needed, just 'fast' upgrades and shuffling things around so the old rhel9 instances are retired and the new rhel10 ones take their place.

Of course eariler in the week we will do staging and any hosts we can take out of dns, etc... so thursday will mostly just be the bare metal / vmhosts and their guests that we can't take down without an outage.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117338602297421813

2026-09-26T17:15:38Z 2026-09-26T17:15:38Z nirik https://www.scrye.com/blogs/nirik/categories/fedora.atom nirik 2026-10-04T23:36:01Z https://blog.kulakowski.fr/?p=38419

Retour sur la migration UI de SeedboxSync de Bulma vers Bootstrap : pourquoi quitter un écosystème au ralenti, les limites de Bootstrap (Dart Sass, dark mode JS, balise progress) et les gains d'un framework riche en composants.

2026-09-26T13:12:20Z 2026-09-26T13:12:20Z Guillaume Kulakowski https://blog.kulakowski.fr https://blog.kulakowski.fr/wp-content/uploads/2026/04/cropped-logo-32x32.png Le journal d’un Directeur Conseil Expert en solutions digitales – API Management, DevOps & Open Source. 2026-10-11T16:27:43Z urn:md5:e1e7b409d277280ed0d9741546aeb4ba

RPMs of PHP version 8.5.11 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.26 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.35 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.34 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ� These versions are also available as Software Collections in the remi-safe repository.

ℹ� The packages are available for x86_64 and aarch64.

⚠� PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.

🛡ï¸� These Versions fix 10 security bugs (CVE-2026-91768, CVE-2025-1218, CVE-2026-91769, CVE-2026-91767, CVE-2026-6103, CVE-2026-91765, CVE-2025-14181, CVE-2026-93682, CVE-2026-92842, CVE-2026-91766), so the update is strongly recommended.

Version announcements:

• PHP 8.5.11 Release Annoucement
• PHP 8.4.26 Release Annoucement
• PHP 8.3.35 Release Annoucement
• PHP 8.2.34 Release Annoucement

ℹ� Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

• Fedora Rawhide now has PHP version 8.5.11
• Fedora 45 - PHP 8.5.11
• Fedora 44 - PHP 8.5.11
• Fedora 43 - PHP 8.4.26

⚠� To be noticed :

• EL-10 RPMs are built using RHEL-10.2
• EL-9 RPMs are built using RHEL-9.8
• EL-8 RPMs are built using RHEL-8.10
• intl extension now uses libicu74 (version 74.2)
• mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
• oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
• A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ� Information:

• Migrating from PHP 8.2.x to PHP 8.3.x
• Migrating from PHP 8.3.x to PHP 8.4.x
• Migrating from PHP 8.4.x to PHP 8.5.x

Base packages (php)

Software Collections (php83 / php84 / php85)

2026-09-25T06:00:00Z 2026-09-25T06:00:00Z Remi https://blog.remirepo.net/en Licence: Creative Commons Attribution-ShareAlike 4.0 International License. Remi's RPM repository blog Information about RPM PHP Fedora RHEL and CentOS 2026-10-12T06:10:35Z https://blog.kulakowski.fr/?p=38439

L'annonce de Portainer 3.0 confirme le virage stratégique de l'éditeur vers Kubernetes et les besoins des entreprises, laissant la version CE sur la branche 2.x. Un changement de cap qui confirme la pertinence de ma récente migration vers Arcane pour la gestion des conteneurs de mon NAS.

2026-09-23T10:52:00Z 2026-09-23T10:52:00Z Guillaume Kulakowski https://blog.kulakowski.fr https://blog.kulakowski.fr/wp-content/uploads/2026/04/cropped-logo-32x32.png Le journal d’un Directeur Conseil Expert en solutions digitales – API Management, DevOps & Open Source. 2026-10-11T16:27:43Z urn:md5:81c908d2267c3146fb1539de645b4d62

RPMs of Valkey version 9.2 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

⚠️ Warning: this is a pre-release version not ready for production use.

1. Installation

Packages are available in the valkey:remi-9.1 module stream.

1.1. Using dnf4 on Enterprise Linux

# dnf install https://rpms.remirepo.net/enterprise/remi-release-<ver>.rpm
# dnf module switch-to valkey:remi-9.2/common

1.2. Using dnf5 on Fedora

# dnf install https://rpms.remirepo.net/fedora/remi-release-<ver>.rpm
# dnf module reset  valkey
# dnf module enable valkey:remi-9.2
# dnf install valkey

The valkey-compat-redis compatibility package is not available in this stream. If you need the Redis commands, you can install the redis package.

2. Modules

Some optional modules are also available:

• valkey-bloom (Fedora and EL ≥ 9)
• valkey-json
• valkey-ldap (Fedora and EL ≥ 9)
• valkey-lua (always available)
• valkey-rdma
• valkey-tls (always available)

These packages are weak dependencies of Valkey, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).

The Modules are automatically loaded after installation and service (re)start.

3. Future

Valkey also provides a set of modules, which may be submitted for the Fedora official repository.

ℹ️ Notices:

• Enterprise Linux 9.8 and 10.2 have Valkey 8.0 in their repository
• Enterprise Linux 9.9 and 10.3 will have Valkey 8.1, already in CentOS Stream
• Fedora 43 has Valkey 8.1
• Fedora 44 has Valkey 9.0
• Fedora 45 will have Valkey 9.1
• Fedora 46 will have Valkey 9.2

4. Statistics

valkey

2026-09-22T06:50:00Z 2026-09-22T06:50:00Z Remi https://blog.remirepo.net/en Licence: Creative Commons Attribution-ShareAlike 4.0 International License. Remi's RPM repository blog Information about RPM PHP Fedora RHEL and CentOS 2026-10-12T06:10:35Z https://dvratil.cz/2026/09/akademy-2026/

This year’s Akademy is over - at least for me. I’m already on a train on my way back home, but there’s still plenty of people staying in Graz for more days of hacking and fun. Even though I haven’t contributed to KDE much in the past few years, I am really glad I decided to go.

First, I want to thank everyone from the organization and local team for hosting us in Graz and orginzing a great Akademy. I know how much work it is, so kudos to all of you <3.

This year’s Akademy is over - at least for me. I’m already on a train on my way back home, but there’s still plenty of people staying in Graz for more days of hacking and fun. Even though I haven’t contributed to KDE much in the past few years, I am really glad I decided to go.

First, I want to thank everyone from the organization and local team for hosting us in Graz and orginzing a great Akademy. I know how much work it is, so kudos to all of you <3.

I’m really happy that the community is in such a great shape. There’s a lot of new people participating and contributing, which is a great sign! After all as Cornelius showed in his talk - this year we have the most people ever contributing to KDE - and the year is not even over yet!

This year we also voted the new KDE Goals. I am really happy that KDE for Enterprise goal have been voted in. As someone pointed out (with a little tongue-in-cheek): we’ve solved gamers, now it’s time to solve enterprise. Kevin and the team in enioka Haute Couture are already doing great work on KDE PIM thanks to the Sovereign Tech Fund. They started with improving my akonadi-e2e-tests experiment and pushing it forward to a point where it has helped them discover (and fix) many bugs in CalDAV in IMAP - this is foundational work that everyone will benefit from. It’s inspiring to see so much activity and many new contributors in KDE PIM again.

I attended another talk about making KDE “lovable” by Eva and Jan. They discussed many things, but one that stood out to me, especially with relation to the Enterprise goal, is that we should make sure that the end-users, those who actually use our software in organizations, feel like they gained something by migrating away from whatever they were running on before and were used to. They should feel our software makes their jobs easier, makes them more efficient and feel like it adapts to their needs - make it not just usable, but /lovable/. I really liked that thought. How do we make KMail loveble, though? That’s a tough one…

As for myself, I had a lot of schnitzels over the couple days, took a slide down from Schlossberg, fixed some bugs and generally had a great time. I managed to get KMail, KOrganizer and KAddressBook to compile and run on macOS to the point that I can actually read and write emails. But there’s a lot of fixes and polish needed still, more on that some other day.

All in all, it was a very fun, very productive and very inspiring Akademy for me, and I can’t wait to see everyone again.

2026-09-21T16:00:00Z 2026-09-21T16:00:00Z https://dvratil.cz/category/kde/ Daniel Vrátil me@dvratil.cz https://dvratil.cz/ Because opensource matters. 2026-09-21T16:00:00Z tag:None,2026-09-20:/blog/kiwi-tcms-team/2026/09/20/kiwi-tcms-enterprise-1651/

Dear testers, we're happy to announce Kiwi TCMS Enterprise version 16.5.1-mt!

IMPORTANT:

This is a minor version release which introduces improved checks for requests to /uploads/.

Changes since Kiwi TCMS Enterprise v16.5-mt

• Based on Kiwi TCMS v16.5
• Improve checks for requests to /uploads/
• Multiple fixes for …

Dear testers, we're happy to announce Kiwi TCMS Enterprise version 16.5.1-mt!

IMPORTANT:

This is a minor version release which introduces improved checks for requests to /uploads/.

Changes since Kiwi TCMS Enterprise v16.5-mt

• Based on Kiwi TCMS v16.5
• Improve checks for requests to /uploads/
• Multiple fixes for issues reported by ShellCheck
• Update sentry-sdk from 2.68.1 to 2.69.2

Private container images

hub.kiwitcms.eu/kiwitcms/enterprise       16.5.1-mt (aarch64)     a01dc7aa0920    20 Sep 2026     1.06GB
hub.kiwitcms.eu/kiwitcms/enterprise       16.5.1-mt (x86_64)      151049acaac5    20 Sep 2026     1.04GB

IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!

How to upgrade

Follow the Upgrading instructions from our documentation.

Happy testing!

---

If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!

• Give â­� on GitHub;
• Join our newsletter and follow all news;
• Become a subscriber and help us sustain development
• Become a reseller and help us serve your community

2026-09-20T09:50:00Z 2026-09-20T09:50:00Z Kiwi TCMS Team https://kiwitcms.org/ 2026-10-12T11:07:00Z https://www.scrye.com/blogs/nirik/posts/2026/09/19/misc-fedora-bits-third-week-of-sep-2026/

A somewhat busy week for me, so lets get into it..

RHEL10 Database migrations

So, I had finished off all the staging databases except for one the week before, so I spent a fair bit of time this last week looking at the last one. It's a pretty fun case, our db-datanommer.

This is the database that stores all the messages that go accross our message bus and allows you to search them via datagrepper. Because of the nature of the data in it, it uses the timescaledb extention on top of postgres. It's currently (in both staging and production) a rhel9 vm with postgresql 13 and timescaledb 2.10.1.

Before getting into the fun set of constraints, I'll mention that I am a paranoid sysadmin. This means I always think about 'what would happen if this migration fails there, or there' So I strongly prefer to leave something in a state where I can backout to it if something goes wrong. So, in this case I strongly prefered to just leave the existing vm alone an dmigrate to a new one, and if something blows up, can just move back to the old one.

So, the constraints were pretty fun here:

• timescaledb has a handy chart about which versions support which postgres versions. 2.10.1 doesn't support 16 or 18. No versions support both 13 and 18. 1 version does support both 13 and 16 however.

• rhel9 actually has postgresql-16 available, but as a module. Because it's a module it makes it hard to build normal rpms against it.

• dump and restore of the db would take way way way too long as a pg_dumpall (sql) dump. The pg_dump formats would be faster, but not all that much because timescaledb doesn't work with -j (N jobs) on restore.

• rhel10 has postgresql16 (default) and 18 available as seperate packages.

• When you upgrade from 16 to 18, you need to either enable data page checksums (running a tool over the db's) or make 18 start without them. They sound like a really good idea though, so I wanted to enable them

So, in order to do this under all my constraints it would require 3 vm's: The current one (untouched), another rhel9 one to sync the data to, upgrade timescaledb on, then sync that to a rhel10 one to upgrade to 16 and then another timescaledb upgrade and upgrade from 16 to 18.

In the end though, it seems like timescaledb upgrades are pretty smooth and easy, so I decided (at least in staging) to just upgrade timescaledb to 2.13.1 (which supports both 13 and 16). That allows no intermediate rhel9 vm.

So, thats the plan, but there's more gotchas I hit along the way:

• When upgrading from 13 to 16, you have to also have timescaledb from the 13 install installed in the right place for the upgrader to use it.

• You also need to modify the template postgresql.conf file the upgrader users to enable timescaledb, or else when it upgrades it blows up at the end because there's a missing extension.

• Both those last 2 things apply for 16 to 18 too.

• The upgrader also helpfully tells you to look at some log when things fail, but it's the log from the data dir it JUST DELETED BECAUSE IT FAILED! I ended up reading those logs by running the upgrader under strace. :(

After all that, I think I have a process now. I was going to do the staging one friday, but I made a stupid mistake (putting the 13 timescaledb.so in the wrong dir) so I ran out of time. Will move it monday.

Mass firmware update/mass reboot/database migrations

So, with the last database server sorted in staging, time to get production done. We are tenatively planning an outage for 2026-10-01, the thursday before final freeze. Hopefully we can get all the databases done then.

https://forge.fedoraproject.org/infra/tickets/issues/13563

Scrapers?

Of course this will jinx things, but things have been reasonably quiet on the scraper front of late. There was some activity where they were hitting our wiki really hard, but luckily it was reasonably easy to block them in that case. It did cause problems for other services however as it caused our proxy network to hit max connections.

Otherwise it's been quite nice not to have to battle them day to day so much.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117299904300111203

A somewhat busy week for me, so lets get into it..

RHEL10 Database migrations

So, I had finished off all the staging databases except for one the week before, so I spent a fair bit of time this last week looking at the last one. It's a pretty fun case, our db-datanommer.

This is the database that stores all the messages that go accross our message bus and allows you to search them via datagrepper. Because of the nature of the data in it, it uses the timescaledb extention on top of postgres. It's currently (in both staging and production) a rhel9 vm with postgresql 13 and timescaledb 2.10.1.

Before getting into the fun set of constraints, I'll mention that I am a paranoid sysadmin. This means I always think about 'what would happen if this migration fails there, or there' So I strongly prefer to leave something in a state where I can backout to it if something goes wrong. So, in this case I strongly prefered to just leave the existing vm alone an dmigrate to a new one, and if something blows up, can just move back to the old one.

So, the constraints were pretty fun here:

• timescaledb has a handy chart about which versions support which postgres versions. 2.10.1 doesn't support 16 or 18. No versions support both 13 and 18. 1 version does support both 13 and 16 however.

• rhel9 actually has postgresql-16 available, but as a module. Because it's a module it makes it hard to build normal rpms against it.

• dump and restore of the db would take way way way too long as a pg_dumpall (sql) dump. The pg_dump formats would be faster, but not all that much because timescaledb doesn't work with -j (N jobs) on restore.

• rhel10 has postgresql16 (default) and 18 available as seperate packages.

• When you upgrade from 16 to 18, you need to either enable data page checksums (running a tool over the db's) or make 18 start without them. They sound like a really good idea though, so I wanted to enable them

So, in order to do this under all my constraints it would require 3 vm's: The current one (untouched), another rhel9 one to sync the data to, upgrade timescaledb on, then sync that to a rhel10 one to upgrade to 16 and then another timescaledb upgrade and upgrade from 16 to 18.

In the end though, it seems like timescaledb upgrades are pretty smooth and easy, so I decided (at least in staging) to just upgrade timescaledb to 2.13.1 (which supports both 13 and 16). That allows no intermediate rhel9 vm.

So, thats the plan, but there's more gotchas I hit along the way:

• When upgrading from 13 to 16, you have to also have timescaledb from the 13 install installed in the right place for the upgrader to use it.

• You also need to modify the template postgresql.conf file the upgrader users to enable timescaledb, or else when it upgrades it blows up at the end because there's a missing extension.

• Both those last 2 things apply for 16 to 18 too.

• The upgrader also helpfully tells you to look at some log when things fail, but it's the log from the data dir it JUST DELETED BECAUSE IT FAILED! I ended up reading those logs by running the upgrader under strace. :(

After all that, I think I have a process now. I was going to do the staging one friday, but I made a stupid mistake (putting the 13 timescaledb.so in the wrong dir) so I ran out of time. Will move it monday.

Mass firmware update/mass reboot/database migrations

So, with the last database server sorted in staging, time to get production done. We are tenatively planning an outage for 2026-10-01, the thursday before final freeze. Hopefully we can get all the databases done then.

https://forge.fedoraproject.org/infra/tickets/issues/13563

Scrapers?

Of course this will jinx things, but things have been reasonably quiet on the scraper front of late. There was some activity where they were hitting our wiki really hard, but luckily it was reasonably easy to block them in that case. It did cause problems for other services however as it caused our proxy network to hit max connections.

Otherwise it's been quite nice not to have to battle them day to day so much.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117299904300111203

2026-09-19T21:21:54Z 2026-09-19T21:21:54Z nirik https://www.scrye.com/blogs/nirik/categories/fedora.atom nirik 2026-10-04T23:36:01Z http://fossjon.wordpress.com/?p=7928

100.64.0.0/10 = 100.64.0.0 - 100.127.255.255 Thanks to Lawrence Systems who covered his own network setup!

100.64.0.0/10 = 100.64.0.0 - 100.127.255.255

Thanks to Lawrence Systems who covered his own network setup!

2026-09-19T03:44:39Z 2026-09-19T03:44:39Z fossjon https://fossjon.wordpress.com https://s0.wp.com/i/webclip.png Anything networking, coding, crypto, or security 2026-10-13T03:07:36Z https://adam.younglogic.com/?p=11782

I am booting VMs via qemu (no libvirt) and sometimes they don't tell me what IP address they got when booted.  To figure it out, considering I know the IP address, I can query the network via the Address Resolution Protocol (ARP)

I know they get address in sequence, so:


ayoung@sut11sys-r112:~/devel/ampvirt$ arp -n | grep -i "52:54:00:70:0c:"
10.76.112.154            ether   52:54:00:70:0c:02   C                     virbr0
10.76.112.153            ether   52:54:00:70:0c:04   C                     virbr0
10.76.112.155            ether   52:54:00:70:0c:03   C                     virbr0

2026-09-17T20:17:23Z 2026-09-17T20:17:23Z Adam Young https://adam.younglogic.com The Notebook of a Programmer Climber Musician Ex-Soldier Woodworker and a few other things 2026-09-17T20:17:23Z https://blogs.gnome.org/aday/?p=10935

It’s been about 4 months since my last GNOME Foundation update. Time flies. I’m sorry that it’s been so long. I will try to do more regular posts again in the future, but perhaps not at the same tempo as before. While I would love to post every other week, it’s hard to sustain. With … Continue reading GNOME Foundation Update, September 2026

It’s been about 4 months since my last GNOME Foundation update. Time flies. I’m sorry that it’s been so long. I will try to do more regular posts again in the future, but perhaps not at the same tempo as before. While I would love to post every other week, it’s hard to sustain.

With that said, let’s jump in. Given the time since my last post, I’m going to focus on the bigger and more recent news items that have happened at the GNOME Foundation.

New board, new officers

The Foundation’s board elections happen every year, and this year’s election completed in July. The election resulted in a number of changes to the board:

• Sri Ramkrishna, Jonathan Blandford and Adrian Vovk joined the board as new/returning directors
• Deepa Venkatraman, our treasurer, secured a new two year term
• Robert McQueen, Federico Mena Quintero and myself all ceased to be directors (Rob failed to be re-elected, Federico didn’t run, I withdrew part-way through the process)

The election was a difficult one for me personally, and left me reconsidering my involvement in the Foundation. This was not because I lacked motivation or commitment, but because the situation around the election had become untenable for me personally. However, I’ve spent a good deal of time since I withdrew my candidacy thinking about my role at the Foundation, and I’ve concluded that I care about this organisation and the progress we’ve made, and I want to see that work through. Conversations I’ve recently had with members of the community have also given me confidence that we can move forward together. In short: I’m happy to be sticking around.

The new board held its annual meeting in August, which is when officers and committees are appointed for the next 12 months. The Board decided to put me into position as Interim Executive Director, with Sri Ramkrishna taking my place as President. This is a good move from my perspective: it recognises that I’ve been doing a lot of the day to day management work (which I will continue to do), and gives the Board more ability to hold me accountable. Sri stepping into the role of President means that he will be my backup.

Other officer changes include Jonathan coming in as Second Vice-President, Cassidy moving from Vice-Secretary to Secretary, and Adrian stepping up as Vice-Secretary. Our other officers remain in post, with Maria as chair, Deepa as Treasurer, and Arun as Vice-President.

Huge thanks to everyone who volunteered for these positions!

In terms of committees, the Executive Committee had a minor reshuffle, with Jonathan, Adrian, and Sri joining, and Julian and Rob departing. The new members of the exec are already taking on work, which is great, and I’m hopeful for the newly reconstructed committee. The Finance Committee had some slight membership changes, with Rob leaving and Sri joining.

Finance and Operations Director

Last April we opened the search for a new paid team member, to join us as our Finance and Operations Director. There are a number of goals for this new position: to enhance the finance and accounting expertise that we have internally, to lead the development of our internal systems and budgets, to ensure the sustainability of finance and compliance tasks, to manage our fiscally sponsored projects, and more generally take ownership of the business side of the organisation.

We had a huge number of applicants apply for the position, and had some extremely high quality candidates to choose from. After going through several rounds of interviews we selected Dawn Matlak for the role, who we are extremely excited about joining us. Those of you who have read my previous posts might remember Dawn’s name: she initially started working with us as a consultant last year, in order to help us prepare for our first formal audit, which happened in March this year. As part of this work she helped us to transform many of our internal systems and processes. We’re thrilled that she is joining the Foundation on an ongoing basis, and are confident that our internal operations will continue to improve under her stewardship.

Dawn is already doing a small number of hours for us each week, which she will continue to do until she properly starts in the role in November.

Many thanks to Arun and Deepa who helped enormously with the hiring process.

FY27 Budget

The Foundation’s financial year runs from 1 October to 30 September, and each financial year requires a new budget, both for planning and as the basis of reporting and spending authorisation. We have all therefore been working hard on the new budget that will come into effect on 1 October. The new budget has been in the works for a while, and has been a major focus for the board over the past few months. Thankfully we got the initial budget approval done last week at the board’s regular September meeting. We’ll follow-up with a more detailed post about the budget as soon as we’re able, so the community can have some insight into how we’re managing our finances.

Events

With GUADEC 2026 wrapped up, Kristi has turned her attention to the next event in our schedule: GNOME.Asia 2026. This is being held in Terengganu, Malaysia, from 31 October to 2 November. There’s a great venue lined up, and Kristi is busy working on the details with a fantastic local team.

Aside from GNOME.Asia, the other recent focus has been GUADEC 2027. We have a couple of options for locations right now, and are in the process of confirming details before we commit to one of them for next year. We’ll share updates as soon as we have more details confirmed.

Fundraising

The end of the calendar year is an important time for non-profit fundraising, and we are currently busy planning our campaign for the end of 2026. I’ll be posting more about this soon, in particular in relation to the budget, but for now I will say that this campaign is going to be critical for our ability to grow and support the GNOME project.

Other

As ever, many other things have been happening at the Foundation, and there’s too much to go into detail about here. Work on GNOME’s infrastructure and Flathub continues, our back office operation continues with finances and other routine paperwork, and the board continues to discuss our long-term plans.

That’s it for now. Many thanks for reading, and feel free to leave questions in the comments.

2026-09-17T15:26:04Z 2026-09-17T15:26:04Z Allan Day https://blogs.gnome.org/aday Allan Day's GNOME Blog 2026-09-17T15:26:04Z https://communityblog.fedoraproject.org/?p=15938

On Saturday, August 22, 2026, the Fedora Project joined forces with openSUSE at Data Con LA 2026, hosted on the campus of California State University, Long Beach (CSULB). Now in its 14th year, Data Con LA is Southern California’s largest gathering of data professionals, students, and practitioners covering data science, AI/ML, and data engineering. While […]

The post Fedora at Data Con LA 2026: Open Source & Local AI appeared first on Fedora Community Blog.

On Saturday, August 22, 2026, the Fedora Project joined forces with openSUSE at Data Con LA 2026, hosted on the campus of California State University, Long Beach (CSULB).

Now in its 14th year, Data Con LA is Southern California’s largest gathering of data professionals, students, and practitioners covering data science, AI/ML, and data engineering. While Data Con LA is not a traditional Linux-centric conference, our presence offered a unique, hands-on opportunity to engage a fresh audience of prospective contributors, test our event planning workflows, and showcase Fedora Workstation in action.

As part of our ongoing work to standardize the Fedora Ambassador event pipeline, this report reflects on our operational outcomes, what worked well, and key lessons learned for future event organizers.

1. A Standout Win: “A House with Many Rooms” (Co-Hosting with openSUSE)

Our standout operational victory at Data Con LA was co-locating and sharing table space side-by-side with openSUSE advocates (coordinated with Patrick Finie / mir and Drew Adams).

Rather than maintaining isolated tables, we embraced the philosophy of “A House with Many Rooms.” This cross-community collaboration was an immediate force multiplier:

• Shared Energy & Presence: Combining our presence effectively doubled our footprint and visual appeal, turning our shared booth area into a high-energy focal point in the expo area.
• Seamless Staffing & Rotations: Having four volunteers across both distributions allowed for seamless shift rotations during peak traffic and lunch breaks, completely preventing booth fatigue.
• Cross-Promotion: When attendees visited our table, we engaged them collaboratively by directing people to open source solutions across distros based on their specific technical needs and interests.

For future community organizers planning small-to-medium booths, establishing a shared booth with allied open source projects is an operational model we strongly recommend.

2. Demographics & Lead Engagement

Over the course of the day, our booth engaged approximately 100 visitors (110% of our initial goal), with peak traffic occurring during the post-keynote morning rush (9:30 AM – 11:00 AM) and lunch transitions (12:30 PM – 2:00 PM).

The attendee demographic offered valuable insights into the broader tech ecosystem:

• Student & Alumni Presence: The majority of visitors were CSU Long Beach undergraduate and graduate students, alumni, and local data practitioners.
• First Encounters with Linux: Roughly 10% of attendees were active Linux users; for the remaining 90%, Data Con LA was their first direct introduction to Linux and Fedora.
• Lead Qualification Breakdown:
  • Hot Leads (30): Inquired specifically about Fedora, visited the website, and expressed interest in installing Fedora Workstation or exploring the Join SIG.
  • Warm Leads (20): Asked for links to documentation, Fedora Discussion forums, Matrix channels, or local user groups (such as SGV LUG in Pasadena and SFV LUG in Northridge).
  • General Engagements (10+): Discussed general data industry trends, tech careers, or university studies.

3. The Technical Showcase: Local AI on Fedora Asahi Remix

To connect directly with the conference’s AI/ML focus, we showcased a fully offline, containerized local AI demonstration running on an Apple Silicon laptop.

The Setup

• Hardware: 2020 Apple M1 MacBook Air (8 GB RAM) dual-booting macOS.
• Operating System: Fedora Asahi Remix (Fedora 44 release) running GNOME on Wayland.
• Software Stack: Fedora-native Podman containers running Ollama alongside Open WebUI, exposing a private, ChatGPT-style web interface at localhost.
• Model: llama3.2:1b (sized appropriately for the laptop’s 8 GB memory ceiling).

Why It Resonated

This demonstration served as a major crowd-pleaser across two distinct attendee groups:

1. Data Professionals & Privacy: Attendees expressed fatigue with commercial operating systems that enforce invasive telemetry and proprietary cloud AI features. Highlighting how Fedora enables private, offline LLM inference with zero data leakage resonated powerfully.
2. Students on a Budget: CSULB students loved seeing how Linux can revive older, restricted hardware to deliver a capable, subscription-free AI workspace without requiring expensive cloud API tokens.

4. Advice & Lessons for Future Event Owners

If you are planning to organize a small event (under $150) or booth presence in the next six months, here are four practical takeaways from our experience:

1. Design 100% Offline Demos: Campus and conference Wi-Fi networks are notoriously unreliable, firewalled, or slow. Designing our demo to run entirely inside local Podman containers without requiring an internet connection kept our booth fully functional all day without friction.
2. Account for Outdoor Environmental Factors: Our booth was located in an outdoor expo space. During the afternoon peak heat, direct sunlight caused our demo laptop to heat up, requiring us to tuck it under banners in the shade. Recommendation: Always confirm booth coverage in advance, and pack brimmed hats, pop-up shade, or cooling accessories if outdoor placement is unavoidable.
3. The Power of the Daily User Perspective: You do not need to be a kernel developer or upstream maintainer to staff a Fedora booth. Sharing how you use Fedora day-to-day for work, study, or home projects alleviates “imposter syndrome” and provides relatable, authentic guidance that newcomers appreciate.
4. Keep Swag Requests Lean on Short Timelines: Because our event planning window was short, we kept our Forgejo Mindshare swag request focused strictly on high-impact essentials: stickers, case badges, and pens. Podman and Fedora logo stickers drew in decision-makers and students alike.

5. Next Steps & Wrap-Up

We would like to thank Patrick Finie, Drew Adams, and the openSUSE community for partnering with us, as well as the CSULB organizers for putting together a fantastic event.

Following Data Con LA, our team of Ambassadors Perry Rivera and Rob McBryde are incorporating these lessons directly into the new Small Events Standard Operating Procedure (SOP) and preparing for upcoming community participation at SCaLE. Our intention is to share and publish this information in the Fedora Docs website so that other event owners in the Fedora community may benefit from common wisdom from others who have done this work before.

• Want to get involved? Connect with us on Fedora Discussion or drop by the #ambassadors:fedoraproject.org Matrix channel!

The post Fedora at Data Con LA 2026: Open Source & Local AI appeared first on Fedora Community Blog.

2026-09-17T12:00:00Z 2026-09-17T12:00:00Z Rob McBryde https://communityblog.fedoraproject.org/ https://communityblog.fedoraproject.org/wp-content/uploads/2022/07/favicon-fedora-commblog.png The Community Blog provides a single source for members of the community to share important news, updates, and information about Fedora with others in the Project community. 2026-10-07T21:07:54Z https://fedorafans.com/?p=8564

نسخه بتای Fedora Linux 45 از امروز، ۱۵ سپتامبر ۲۰۲۶، در دسترس علاقه‌مندان و آزمایش‌کنندگان قرار گرفته است. کاربران می‌توانند نسخه بتای فدورا ۴۵ را دریافت کرده و پیش از انتشار نسخه نهایی، قابلیت‌ها و تغییرات جدید این نگارش را آزمایش کنند. فدورا همچنین امکان ارتقای سیستم‌های موجود به نسخه بتا را از طریق ابزار DNF […]

The post نسخه بتای Fedora Linux 45 منتشر شد first appeared on طرفداران فدورا.

2026-09-17T07:56:27Z 2026-09-17T07:56:27Z hos7ein https://fedorafans.com همه برای فدورا , فدورا برای همه 2026-09-29T11:36:16Z https://fedorafans.com/?p=8394

در بخش ۱ به صورت کلی Podman معرفی شد و نحوه کارکرد آن توضیح داده شد. در این مطلب قصد داریم تا آن را نصب و استفاده کنیم. نصب Podman در فدورا لینوکس در فدورا لینوکس معمولا پادمن به صورت پیش فرض نصب می باشد، ولی به هر حال روش نصب به صورت زیر می […]

The post معرفی و استفاده از Podman – بخش ۲ first appeared on طرفداران فدورا.

2026-09-16T13:31:24Z 2026-09-16T13:31:24Z hos7ein https://fedorafans.com همه برای فدورا , فدورا برای همه 2026-09-29T11:36:16Z https://dvratil.cz/2026/09/im-going-to-akademy/

It’s been 7 years since I last posted such a banner, and just today I remembered how I was always excited about this kind of posts, so here we go. I’ve also been to Akademy in Würzburg 2 years ago, but didn’t post the banner for some reason (silly me!).

I haven’t really contributed to KDE for quite a while, but Akademy is always worth attending, even just to meet old friends again and make some new ones. Plus this year is KDE’s 30th birthday. KDE has been such a huge part of my life, so I am not going to miss such an anniversary.

It’s been 7 years since I last posted such a banner, and just today I remembered how I was always excited about this kind of posts, so here we go. I’ve also been to Akademy in Würzburg 2 years ago, but didn’t post the banner for some reason (silly me!).

I haven’t really contributed to KDE for quite a while, but Akademy is always worth attending, even just to meet old friends again and make some new ones. Plus this year is KDE’s 30th birthday. KDE has been such a huge part of my life, so I am not going to miss such an anniversary.

Can’t wait to see you all in Graz soon!

2026-09-15T21:00:00Z 2026-09-15T21:00:00Z https://dvratil.cz/category/kde/ Daniel Vrátil me@dvratil.cz https://dvratil.cz/ Because opensource matters. 2026-09-21T16:00:00Z https://blogs.gnome.org/mcatanzaro/?p=11326

Andreas Gabriel Berbescu has reported several root privilege escalation vulnerabilities in various NetworkManager VPN plugins. If the VPN plugin is installed, then an unprivileged user can escalate to root by loading a malicious VPN configuration file: While most obviously bad for multi-user systems, root privilege escalation is also a serious defense in depth problem for […]

Andreas Gabriel Berbescu has reported several root privilege escalation vulnerabilities in various NetworkManager VPN plugins. If the VPN plugin is installed, then an unprivileged user can escalate to root by loading a malicious VPN configuration file:

• (CVE-2026-91837) network-manager-iodine: Option confusion reaches iodine’s pre-drop root shell
• (CVE-2026-91838) network-manager-sstp profile data reaches root pppd pty shell
• (CVE-2026-91839) NetworkManager-fortisslvpn credential newline injection permits local root code execution
• (CVE-2026-91840) NetworkManager-vpnc: Top-level VPN username newline injection reaches a root password helper
• (CVE-2026-91841) NetworkManager-vpnc: Incomplete fix of CVE-2018-10900
• September 25, 2026 Update: There is also CVE-2026-75131 and CVE-2026-75883 for NetworkManager-l2tp. I didn’t know about this because it is not a GNOME project.

While most obviously bad for multi-user systems, root privilege escalation is also a serious defense in depth problem for single user systems. You are vulnerable if you have the VPN plugin installed; it does not matter whether you actually use it or not.

These are not vulnerabilities in NetworkManager itself. The VPN plugins are each separate projects, with their own separate maintainers, hosted by GNOME rather than by freedesktop.org. The status of each project is a little different:

• The NetworkManager-vpnc and Network-Manager-fortisslvpn git repos have both been archived. Contributions are no longer accepted, and you should uninstall them immediately. NetworkManager-vpnc users should migrate to NetworkManager-libreswan, and NetworkManager-fortisslvpn users should migrate to NetworkManager-openconnect.
• network-manager-sstp is currently unmaintained, but it is not obsolete. If you are interested in SSTP, this project needs a new maintainer.
• network-manager-iodine is maintained, and the maintainer has created a merge request to resolve this issue.

For more information on NetworkManager VPN plugins, see Josephine’s VPN plugin overview and announcement.

2026-09-15T16:26:48Z 2026-09-15T16:26:48Z Michael Catanzaro https://blogs.gnome.org/mcatanzaro On Fedora Workstation, GNOME, Epiphany, and WebKitGTK 2026-10-02T19:08:04Z http://fossjon.wordpress.com/?p=7868

[SimpleShell] ~ $ curl -sL 'https://github.com/stoops/SimpleShell/commits/main/' | tr '=:,<>[]{}"\' '\n' | grep -Ei '/commit/' | head -n 1 | awk -F'/' '{ print $NF }'$ spctl -a -v bin/SimpleShell.appbin/SimpleShell.app: acceptedsource=Notarized Developer ID I was searching for a good quality but simple free open terminal for MacOS and I couldn’t really find what I was looking […]

[SimpleShell]

~

$ curl -sL 'https://github.com/stoops/SimpleShell/commits/main/' | tr '=:,<>[]{}"\' '\n' | grep -Ei '/commit/' | head -n 1 | awk -F'/' '{ print $NF }'

$ spctl -a -v bin/SimpleShell.app
bin/SimpleShell.app: accepted
source=Notarized Developer ID

I was searching for a good quality but simple free open terminal for MacOS and I couldn’t really find what I was looking for interface wise (I used to use iTerm for a long time but it started getting more and more bloated and laggy on me – using up a lot of system power on battery and I don’t want all that AI stuff baked in).

I started a project earlier this year but got stuck on it because I was trying to implement a basic ANSI parser which was a mistake on my part. I didn’t realize how incredibly complicated that finite state machine would be, esp with bash and ansi apps sending complicated instructions into the machine! I then asked Google AI for help and it pointed me to a GitHub page that hosted a libvterm (from vim) that was compatible with Objective-C.

I’ve been working on this app non-stop for the last 9 days now and I only have the basics covered, I didn’t realize how much code it took just to make a basic text processing input/output app but I think this is one of my more complicated code bases (possibly TurnTable is the other app of mine that might be more complicated but that one is in Swift).

I still have a lot more work on my todo list for and I will continue development on it now that I got ANSI parsing to work, the rest is just mainly ViewController and functionality features. I targeted it for the bash shell so I don’t know if it works with other shells but this is just my first release post about it.

Layout List

• Date (Month / Day)
• Terminal (Rows / Cols)
• Network (LAN / WAN)
• System (CPU / RAM / NET)
• WiFi (Freq / Rate)
• Highest Process (PID / MEM)
• Shell PS1 Prompt Info (User / Directory)
• Dynamic Prompt Prefix Information Insertion (Any scriptable line items)

Feature List

• Simple Clean Minimal Functional Design
• Window / View / Layout — Colors / Opacity / Blur
• Selector / Highlighter Separator Character List (Automation)
• Auto Copy On Selection (Automation)
• Single-Line Paste Manual Enter (Safety)
• Multi-Line Paste Prevention Protection (Safety)
• Huge-Line Paste Limitation Protection (Safety)
• Multi-Window / Multi-Tab
• Left Aligned Tab Titles With Monospace Font (Readability)
• Scriptable Standard Window And Tab Title Text
• Scriptable Dynamic Shell Prompt Prefix (Found No Where Else!)
• Always Visible Command Line Prompt (Found No Where Else!)
• Live System Information Stats Bar
• Separated Open / Close Tab Buttons To Reduce Accidental Closures
• Multi-Tab Window Detection To Reduce Accidental Closures
• Dual Output Modes (line/ansi) With Separated Input Prompt (comd)
• Smooth Scroll Locking
• Clear Console Command
• Easy Use Shortcut Keys (cmd/opt + left/right)
• Regular Expression Search
• Basic Output Text Colors
• Basic Process Job Detection
• Transparent Rounded Cursor Block!
• Dock Icon!!

Todo List

• Add settings for font text type / size
• Add settings for ansi color codes

Limitation List

• Tabs Can’t Be Transferred To Other Windows
• Only Reopens One Window / Tab On Launch
• No Previous History Or Information Is Restored

Warning List

• User Beware: This is still a brand new framework and there may be bugs (or at the very least incompatibilities)!

~

Source Code: https://github.com/stoops/SimpleShell

~

2026-09-15T04:54:58Z 2026-09-15T04:54:58Z fossjon https://fossjon.wordpress.com https://s0.wp.com/i/webclip.png Anything networking, coding, crypto, or security 2026-10-13T03:07:36Z https://www.scrye.com/blogs/nirik/posts/2026/09/12/misc-fedora-bits-second-week-of-sep-2026/

Another saturday, time for another recap of interesting things in longer form.

RHEL10 database migrations

I managed to migrate all but one database server in staging. No particular problems with those and they are all on postgresql 18 now with data page checksums enabled (well, except the single mariadb instance, and it's on 10.11.18). Hopefully I can get the production ones done in the next outage we have (probibly the week before final freeze).

The last staging database server is more interesting: db-datanommer01.stg This is using timescaledb on top of postgres and is currently the rhel9 default version: 13.

After looking around, I think this one is doable, but needs another step:

• sync a data backup off the existing server

• upgrade it to postgresql 16

• enable data page checksums

• install a new rhel10 vm

• sync the data to it

• upgrade to 18

• install the correct timescaledb extension

• take down the old instance and swap in the new

I think this will all work, just an extra 13->16 jump. I will try it out in staging next week. I'm also a bit worried about how long it will take to generate all those checksums. The datanommer db's are really large. However, if we can do it I would love to as it's a very nice feature. Doing staging should at least give us an idea.

Fedora 45 Beta is go for release next tuesday ( 2026-09-15 )

Looks like we are go for fedora 45 beta next week. I hope everyone will test it out and help us iron out any problems before the final release.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117260119278106794

Another saturday, time for another recap of interesting things in longer form.

RHEL10 database migrations

I managed to migrate all but one database server in staging. No particular problems with those and they are all on postgresql 18 now with data page checksums enabled (well, except the single mariadb instance, and it's on 10.11.18). Hopefully I can get the production ones done in the next outage we have (probibly the week before final freeze).

The last staging database server is more interesting: db-datanommer01.stg This is using timescaledb on top of postgres and is currently the rhel9 default version: 13.

After looking around, I think this one is doable, but needs another step:

• sync a data backup off the existing server

• upgrade it to postgresql 16

• enable data page checksums

• install a new rhel10 vm

• sync the data to it

• upgrade to 18

• install the correct timescaledb extension

• take down the old instance and swap in the new

I think this will all work, just an extra 13->16 jump. I will try it out in staging next week. I'm also a bit worried about how long it will take to generate all those checksums. The datanommer db's are really large. However, if we can do it I would love to as it's a very nice feature. Doing staging should at least give us an idea.

Fedora 45 Beta is go for release next tuesday ( 2026-09-15 )

Looks like we are go for fedora 45 beta next week. I hope everyone will test it out and help us iron out any problems before the final release.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117260119278106794

2026-09-12T20:50:47Z 2026-09-12T20:50:47Z nirik https://www.scrye.com/blogs/nirik/categories/fedora.atom nirik 2026-10-04T23:36:01Z https://blogs.gnome.org/feborges/?p=11347

It’s been another fantastic year for Google Summer of Code with GNOME! This year, six contributors worked on a range of interesting projects across our ecosystem. Our contributors have been blogging about their progress on Planet GNOME throughout the summer. In case you missed their updates, here is a breakdown of what they have worked […]

It’s been another fantastic year for Google Summer of Code with GNOME! This year, six contributors worked on a range of interesting projects across our ecosystem.

Our contributors have been blogging about their progress on Planet GNOME throughout the summer. In case you missed their updates, here is a breakdown of what they have worked on:

• Adding a recovery mechanism for GPU resets in Mutter by Toluwaleke Ogundipe
• Adding debug adapter protocol (DAP) support to GJS by Angelo Verlain Shema
• Playing vocab-style puzzles in GNOME Crosswords by Laureen Caliman
• Rewriting the Pitivi timeline ruler in GTK4/Rust by Michael Calabrese
• Implementing app uninstallation in the GNOME Shell app grid by Ramayanapu Jagath
• Porting Gitg to GTK4 by Shivam

Our interns also presented their work during GUADEC. You can watch their lightning talks on YouTube.

This would not have been possible without the support of our community mentors. A huge thank you to Jonathan Blandford, Federico Mena Quintero, Alex Băluț, Yatin, Adrian Vovk, Jonas Ådahl, Robert Mader, Carlos Garnacho, and Philip Chimento. Mentoring takes a lot of time and energy, and it plays a vital role in onboarding new contributors to our community.

If you are a GNOME developer and interested in mentoring a project next year, you can already start working on your project ideas and submit them at gitlab.gnome.org/Teams/internship/project-ideas.

If you are a newcomer interested in starting your journey toward becoming a GNOME contributor, check out gsoc.gnome.org and stay tuned to Planet GNOME and our social media channels for updates on the 2027 program!

 

2026-09-12T12:16:43Z 2026-09-12T12:16:43Z Felipe Borges https://blogs.gnome.org/feborges https://blogs.gnome.org/feborges/files/2023/12/cropped-avatar-32x32.jpg Felipe's blog about GNOME 2026-09-15T11:08:01Z urn:md5:2de0619a9afd8af1aa5b5fe9203b27ba

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.

RPMs of PHP version 8.5.11RC1 are available

• as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

RPMs of PHP version 8.4.26RC1 are available

• as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

• PHP 8.5.11RC1 available for testing
• PHP 8.4.26RC1 available for testing

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

dnf module switch-to php:remi-8.5
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

• version 8.5.11RC1 is in Fedora rawhide for QA
• version 8.6.0beta3 is also available in the repository
• EL-10 packages are built using RHEL-10.2 and EPEL-10.2
• EL-9 packages are built using RHEL-9.8 and EPEL-9
• EL-8 packages are built using RHEL-8.10 and EPEL-8
• oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
• intl extension uses libicu 74.2
• RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
• versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

2026-09-11T04:32:00Z 2026-09-11T04:32:00Z Remi https://blog.remirepo.net/en Licence: Creative Commons Attribution-ShareAlike 4.0 International License. Remi's RPM repository blog Information about RPM PHP Fedora RHEL and CentOS 2026-10-12T06:10:35Z tag:blogger.com,1999:blog-4530460124602916146.post-887042169247638700

 After much back and forth and hoops jumping, I can finally reveal nouveau/nvk running on a NVIDIA Spark box. 

This is running on a version of nouveau[1] that has

a) ported to the 610 NVIDIA firmware 

b) a bunch of display rework from Moham

c) a bunch of 0 VRAM and L2 cache handling fixes

d) spark boot support 

e) spark display support 

and NVK[2] with patches to handle gb10 depth/stencil differences and 0 VRAM support. 

I'm not sure how best to upstream it all, it's 100 patches and a new firmware which might mean it's a wait for nova type situation, but I just wanted to see it work. 

[1] https://gitlab.freedesktop.org/nouvelles/kernel/-/commits/nouveau-610-wip-spark

[2] https://gitlab.freedesktop.org/airlied/mesa/-/commits/nvk-spark-wip 

 

 

2026-09-09T19:56:34Z 2026-09-09T04:17:59Z Dave Airlie noreply@blogger.com http://www.blogger.com/profile/03386351362681039664 tag:blogger.com,1999:blog-4530460124602916146 Dave Airlie noreply@blogger.com http://www.blogger.com/profile/03386351362681039664 2026-10-11T22:48:00Z http://fossjon.wordpress.com/?p=7812

Layer 2 – Ethernet Frames – Leet ARP Spoofing ~ Layer 3 – Second Favorites – Lazy DHCP Snooping ~ [kmod-nft-bridge] ~ OpenWRT Config ~ Untested Commands ~ Note: Most of these commands won’t work on UAP-U7-PRO APs I believe due to hardware based frame/packet routing/forwarding – I have since enabled arp-proxy and dhcp-snooping in […]

Layer 2 – Ethernet Frames – Leet ARP Spoofing

ebtables -t nat -I PREROUTING -i wifi+ -p ARP --arp-opcode Reply --arp-ip-src 192.168.1.1 -s ! 00:12:34:56:78:00 -j DROP
ebtables -t nat -A PREROUTING -i wifi+ -p ARP --arp-opcode Reply --arp-ip-dst 192.168.1.1 -s ! 00:12:34:56:78:00 -j DROP

~

Layer 3 – Second Favorites – Lazy DHCP Snooping

ebtables -t nat -I PREROUTING -i eth0.1 -p IPv4 --ip-proto udp --ip-sport 67 -j ACCEPT
ebtables -t nat -A PREROUTING -i wifi+  -p IPv4 --ip-proto udp --ip-sport 67 -j DROP

~

[kmod-nft-bridge]

table bridge ethernet {
	chain PREROUTING {
		type filter hook prerouting priority filter; policy accept;
		iifname "wifi*" arp operation reply arp saddr ether != 00:11:22:33:44:00 arp saddr ip 192.168.1.1 counter drop
		iifname "wifi*" ip protocol udp udp sport 67 counter drop
	}
}

~

OpenWRT Config

wireless.default_radio0.isolate='1'
wireless.default_radio0.bridge_isolate='1'

~

Untested Commands

bridge link set dev wlan0 hairpin off isolated on
ebtables -A FORWARD -i wlan0 -o wlan0 -j DROP

~

Note: Most of these commands won’t work on UAP-U7-PRO APs I believe due to hardware based frame/packet routing/forwarding – I have since enabled arp-proxy and dhcp-snooping in the UI network controller application, however, I don’t see them working either, possibly because I am running a third-party gateway device. I have finally enabled client-isolation, which as tested, solves the ARP and DHCP attacks completely and forces client-to-client communication through the router instead for even further filtering!

~

2026-09-08T02:29:00Z 2026-09-08T02:29:00Z fossjon https://fossjon.wordpress.com https://s0.wp.com/i/webclip.png Anything networking, coding, crypto, or security 2026-10-13T03:07:36Z http://fossjon.wordpress.com/?p=7791

I have first since used a couple web based AI systems for different specific tech things and they are pretty useful if you do the extra work to verify and modify what they are telling you. I’ve found that Google Gemini AI is really good a general tech questions and configuration items (with looking it […]

I have first since used a couple web based AI systems for different specific tech things and they are pretty useful if you do the extra work to verify and modify what they are telling you. I’ve found that Google Gemini AI is really good a general tech questions and configuration items (with looking it over and understanding it and modifying it of course for your specific needs) and Claude Sonnet AI is really amazing at verifying that your code is correct and other more in-depth programming related tasks (for example, memory allocation and pointer handling and file descriptor tracking). I was also trying to test and see if the AI system would learn from me or others over time and add that previous historical context for each conversation into future interactions.

I’ve been using these systems lightly whenever I get stuck and they are able to find the exact code snippets I was looking for to complete the rest of my projects – prompt engineering!

Tips:

• You need to try and give as much extra debugging info that you can for it to properly figure things out or update its answer
• It’s better to ask it small specific questions and break the problem apart into pieces and then tailor a customized solution
• There are interesting differences between asking it high-level design questions versus low-level coding questions
• It’s also interesting to ask it open-minded / open-ended questions versus asking for a specific solution implementation only
• Sometimes it will loop through repeated answers if it gets stuck on one specific solution
• Sometimes the quality of a given answer decreases the longer that you interact with it
• Sometimes it gets stuck on one specific solution that won’t work in the end but if you try to ask it how to approach the problem from a different angle it can provide steps for you to get extra info for it to either re-fine or re-suggest its solution

Note: It’s a shame that AI resources are being used on social or political issues rather than solving technology and scientific issues to help progress humanity. I’m still amazed that I was able to feed a 1000 lines of C code to Claude as a test and it was able to determine the components purposes and the network proxy applications of it all…

Google AI seems a little more friendly and personable whereas Claude is more on task and professional ha

~

2026-09-06T22:04:51Z 2026-09-06T22:04:51Z fossjon https://fossjon.wordpress.com https://s0.wp.com/i/webclip.png Anything networking, coding, crypto, or security 2026-10-13T03:07:36Z https://www.scrye.com/blogs/nirik/posts/2026/09/05/misc-fedora-bits-first-week-of-sep-2026/

This week seemed to have a lot of small irq's all around. That said, I did make some progress on a few things:

RHEL10 migrations: databases

Next up on the migration train: databases. It turns out we already had one database server in staging moved to rhel10, but it was using the default postgresql 16 and since I am going to the trouble to migrate things to a new os, might as well move them to newer postgresql too.

postgresql 18 makes data page checksums default. You can disable them at startup if you really want to, but they seem like a really good idea to enable. So, I took db-koji01.stg down and added checksums and it took around 45minutes. Not super great, but not nearly as bad as it could be.

Then, the upgrade to 18 was super fast and painless.

I did some work in our ansible repo to set up rhel10 hosts with postgresql18 to start with and created a db-fas02.stg to migrate that to.

The rest of these servers will follow basically this pattern:

• Setup a rhel10/postgresql18 02 vm for each server

• Sync data from rhel9 one.

• Stop rhel9 one (OUTAGE)

• Sync data again from rhel9 one.

• Enable data page checksums

• Migrate from 16 to 18

• Profit

I hope to get the staging ones all done next week and find any issues, then we can look at scheduling an outage after Beta freeze to do all the production ones.

Laptop Battery replacement

My lenovo slim7x battery was getting pretty pathetic. It was 2 years old and it's max full capacity was something like 35% of design full and sometimes it was now refusing to charge without a reboot.

So, I ordered a new battery and installed it this last week.

This laptop is anoying to work on because, while there are screws on the bottom panel, it's also held on by clips. So you have to pry it off and it sounds like you are breaking it while doing so. Anoying.

Also on this laptop they routed all the cables around the battery. The battery has cable guides all around it. So, to replace the battery you have to move all those cables carefully and slide the old battery out and new one in, along with unplugging the bluetooth and wifi antennas, and disconnecting/connecting the battery connector.

I did manage to do it, but it took more time that I thought it would.

While I had the machine open I swapped the windows drive I had back in and updated the firmware (which there's no way to do from linux). It was quite a pain. windows took quite a while to notice that it was not 2024 and that it should check what _current_ updates were available. Did manage it in the end. I don't know what effect the newer firmware has, everything still works the same as far as I can tell.

Fedora 45 beta rc's

We have started making rc's for beta. That sure reads weird, but if you are able, please do test and file bugs.

Authentication issues

There's one weird auth issue I am aware of. Thats where services with keytabs are sometimes getting permission denied. It seems to be somehow some differing config on two of our ipa servers. Thats being tracked in https://forge.fedoraproject.org/infra/tickets/issues/13539

I am not aware of any other issues remaining. So, if you hit something, please do file a ticket and include enough information for us to try and fix it. ie, time/date, exactly what you were trying to login to, exactly what error message you got, etc.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117219935269136120

This week seemed to have a lot of small irq's all around. That said, I did make some progress on a few things:

RHEL10 migrations: databases

Next up on the migration train: databases. It turns out we already had one database server in staging moved to rhel10, but it was using the default postgresql 16 and since I am going to the trouble to migrate things to a new os, might as well move them to newer postgresql too.

postgresql 18 makes data page checksums default. You can disable them at startup if you really want to, but they seem like a really good idea to enable. So, I took db-koji01.stg down and added checksums and it took around 45minutes. Not super great, but not nearly as bad as it could be.

Then, the upgrade to 18 was super fast and painless.

I did some work in our ansible repo to set up rhel10 hosts with postgresql18 to start with and created a db-fas02.stg to migrate that to.

The rest of these servers will follow basically this pattern:

• Setup a rhel10/postgresql18 02 vm for each server

• Sync data from rhel9 one.

• Stop rhel9 one (OUTAGE)

• Sync data again from rhel9 one.

• Enable data page checksums

• Migrate from 16 to 18

• Profit

I hope to get the staging ones all done next week and find any issues, then we can look at scheduling an outage after Beta freeze to do all the production ones.

Laptop Battery replacement

My lenovo slim7x battery was getting pretty pathetic. It was 2 years old and it's max full capacity was something like 35% of design full and sometimes it was now refusing to charge without a reboot.

So, I ordered a new battery and installed it this last week.

This laptop is anoying to work on because, while there are screws on the bottom panel, it's also held on by clips. So you have to pry it off and it sounds like you are breaking it while doing so. Anoying.

Also on this laptop they routed all the cables around the battery. The battery has cable guides all around it. So, to replace the battery you have to move all those cables carefully and slide the old battery out and new one in, along with unplugging the bluetooth and wifi antennas, and disconnecting/connecting the battery connector.

I did manage to do it, but it took more time that I thought it would.

While I had the machine open I swapped the windows drive I had back in and updated the firmware (which there's no way to do from linux). It was quite a pain. windows took quite a while to notice that it was not 2024 and that it should check what _current_ updates were available. Did manage it in the end. I don't know what effect the newer firmware has, everything still works the same as far as I can tell.

Fedora 45 beta rc's

We have started making rc's for beta. That sure reads weird, but if you are able, please do test and file bugs.

Authentication issues

There's one weird auth issue I am aware of. Thats where services with keytabs are sometimes getting permission denied. It seems to be somehow some differing config on two of our ipa servers. Thats being tracked in https://forge.fedoraproject.org/infra/tickets/issues/13539

I am not aware of any other issues remaining. So, if you hit something, please do file a ticket and include enough information for us to try and fix it. ie, time/date, exactly what you were trying to login to, exactly what error message you got, etc.

As always, comment on the fediverse: https://fosstodon.org/@nirik/117219935269136120

2026-09-05T18:10:05Z 2026-09-05T18:10:05Z nirik https://www.scrye.com/blogs/nirik/categories/fedora.atom nirik 2026-10-04T23:36:01Z tag:marcin.juszkiewicz.com.pl,2026-09-04:/2026/09/04/how-i-use-llm-for-my-work/

Not every use of “AI/LLM” ends with “AI slop”.

One of the hot topics in the last months has been the use of “AI” — which usually means using LLMs (Large Language Models).

After a big push at work to adopt “AI”, it took me some time to find a good use of it in my daily workflow.

Rewriting software

One of most popular ways of using “AI” is rewriting software. I know people having old games ported from one retro platform to another this way.

However, the low barrier to entry gave many people a way to jump in which did not end well…

As a result, countless projects have stopped accepting merge requests because so many of them were nothing more than “AI slop” (aka “worthless junk not even worth looking at”).

My example

I have used Claude to rewrite my EDK2 ArmCpuInfo project to make it easier for me to update it. The statistics of the commit that did most of the work:

lines changed: 5630 additions & 3552 deletions

I would not send anything like that to anyone for review. Far too messy. Going through it was painful but I got what I asked for. And this was a result of several prompts and manual changes.

Fixing packages

As you know, my work is mostly around building packages. I have worked on Arm, AArch64, ppc64le, s390x and now RISC-V. I fixed countless packages by hand, going through their source and finding out why they failed and how to get them building on target platforms.

After my last vacation I decided to check how an LLM would help with it.

I fetched the package, unpacked the sources (fedpkg prep), fetched the build.log file from the latest failed build, and ran Claude with one, simple prompt:

Look at build.log and source and find out why it does not build on risc-v.

The amount of time I had to wait and output to read varied from package to package. Sometimes build logs from other Fedora architectures were needed, sometimes a few build attempts. At the end I had a patch which made the package buildable on the RISC-V architecture.

Types of fixes

Some fixes were simple, like fastnetmon where a change in the link order was the only thing needed.

Some were funny, like GNU Data Language where fixing RISC-V fixed it for AArch64 as well. This made the build fail, as some tests, which were expected to fail, passed.

Others were related to differences between RISC-V (RV64GC) floating-point unit compared to other architectures. Such “simple” things like “are we dividing by zero” can be a problem.

Things I do not send

There were also packages for which I got some patches and never sent them neither upstream nor to the package maintainer.

Those were ones I did not understand. For instance, a patch changed how the “R” language handles “NA and NaN” numbers. It was yet another issue related to how RISC-V FPU works. Also it was so cryptic that I looked at code and had no idea what I was looking at.

The final question

I understand FOSS developers who refuse to accept any “AI generated” changes. There is too much “AI slop” being submitted. At the same time I wonder where their limit is.

Would they merge patch below or not? And would presence of the “Assisted-by: LLM” line make them refuse this patch or not? Will they accept it without such line?

Subject: [PATCH] Fix abseil link order for ld.bfd

Move absl:: libraries after gRPC in fastnetmon_api_client link list.
ld.bfd (used on riscv64) is a single-pass linker and needs dependees
before dependencies.

Assisted-by: LLM
---
 src/CMakeLists.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 10caf4c6..5bde9fcc 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -800,10 +800,6 @@ if (ENABLE_GOBGP_SUPPORT)

     add_executable(fastnetmon_api_client fastnetmon_api_client.cpp)

-    if (LINK_WITH_ABSL)
-        target_link_libraries(fastnetmon_api_client  absl::base absl::synchronization)
-    endif()
-
     # We use another way to specify dependencies for Windows as our standard approach clearly does not work
     # https://www.f-ax.de/dev/2020/11/08/grpc-plugin-cmake-support.html
     if (${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
@@ -819,6 +815,10 @@ if (ENABLE_GOBGP_SUPPORT)

     target_link_libraries(fastnetmon_api_client protobuf::libprotobuf)

+    if (LINK_WITH_ABSL)
+        target_link_libraries(fastnetmon_api_client  absl::base absl::synchronization)
+    endif()
+
     if (KAFKA_SUPPORT)
         target_link_libraries(fastnetmon ${LIBKAFKA_CPP_LIBRARY_PATH})
     endif()

I would accept it. Because for me, despite the origin of that patch, it is a very simple change to review.

2026-09-04T14:40:00Z 2026-09-04T14:40:00Z Marcin Juszkiewicz https://marcin.juszkiewicz.com.pl/ 2026-09-04T14:40:00Z https://blogs.gnome.org/feborges/?p=11327

Once again, GNOME is considering participating in the Outreachy internship program. Outreachy provides internships to people subject to systemic bias and impacted by under-representation in the tech industry where they live. Outreachy internships are funded by the participating communities. While the GNOME Foundation has not yet finalized the budget for this cohort, having a strong […]

Once again, GNOME is considering participating in the Outreachy internship program. Outreachy provides internships to people subject to systemic bias and impacted by under-representation in the tech industry where they live.

Outreachy internships are funded by the participating communities. While the GNOME Foundation has not yet finalized the budget for this cohort, having a strong list of proposed projects and available mentors helps the Board decide how many slots to fund.

Project ideas will be selected based on available funding and their relevance to the overall goals of the GNOME project. Project selection will be handled by Matthias Clasen, Allan Day, and Sri Ramkrishna.

If you are a GNOME developer/maintainer available for mentoring between December 2026 and March 2027, please submit a project proposal at gitlab.gnome.org/Teams/internship/project-ideas as soon as possible (by September 11).

If you have any questions, you can contact the Internship Committee on Matrix or ask on Discourse.

2026-09-01T12:59:08Z 2026-09-01T12:59:08Z Felipe Borges https://blogs.gnome.org/feborges https://blogs.gnome.org/feborges/files/2023/12/cropped-avatar-32x32.jpg Felipe's blog about GNOME 2026-09-15T11:08:01Z https://blogs.gnome.org/mcatanzaro/?p=11331

It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning […]

It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning to disclose the issue report within the next few months, it should probably already already be public.

For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don’t forget about it and leave the issue report confidential forever. That’s not fair to your project’s users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.

2026-08-31T19:21:23Z 2026-08-31T19:21:23Z Michael Catanzaro https://blogs.gnome.org/mcatanzaro On Fedora Workstation, GNOME, Epiphany, and WebKitGTK 2026-10-02T19:08:04Z https://blogs.gnome.org/feborges/?p=11312

For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn’t kept up with the rest of GNOME’s modern interface updates. I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself […]

For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn’t kept up with the rest of GNOME’s modern interface updates.

I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself worked on modernizing the interface. There’s still more work to do in the UI and in fprintd, but what we will ship in 51 is already a great step forward.

Historically, the fingerprint dialog in User Settings was stuck on a GTK3-style design. Even after being ported to GTK4, conceptually it remained unchanged. Beyond looking out of place alongside Libadwaita-based settings panels, it suffered from responsiveness and accessibility issues that made it difficult for some users to enroll their prints.

The new fingerprint management dialog uses a standard boxed list displaying your enrolled fingers. From here, each enrolled finger can be removed individually.

Clicking the “Add Fingerprint” button starts the finger enrollment process. First, you choose one of the unused finger options to enroll. From there, an assistant guides you through the scanning process. As you place your finger on the reader, the UI detects the touch and provides feedback on whether it was read correctly. You continue touching the reader until enough samples have been collected (the exact number depends on your reader’s driver). Once the progress bar fills, your finger is ready for authentication.

This is only one of the improvements that GNOME 51 is bringing. As with everything in GNOME, we will continue gathering user feedback and making iterations over time. There are already more fingerprint features in the pipeline, such as renaming enrolled fingers and verifying individual prints. Stay tuned!

2026-08-31T09:57:31Z 2026-08-31T09:57:31Z Felipe Borges https://blogs.gnome.org/feborges https://blogs.gnome.org/feborges/files/2023/12/cropped-avatar-32x32.jpg Felipe's blog about GNOME 2026-09-15T11:08:01Z https://blogs.gnome.org/mcatanzaro/?p=11317

In Some Changes to GNOME Security Tracking, I reported: I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done. This […]

In Some Changes to GNOME Security Tracking, I reported:

I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

2026-08-27T14:56:33Z 2026-08-27T14:56:33Z Michael Catanzaro https://blogs.gnome.org/mcatanzaro On Fedora Workstation, GNOME, Epiphany, and WebKitGTK 2026-10-02T19:08:04Z http://blog.verbum.org/?p=1936

If your agentic workload involves the agent being able to run arbitrary code (like bash or equivalent), then you should not use a “LLM as part of your app” framework like LangChain, BeeAI, OGX etc. Instead, run OpenCode, goose, or another general coding agent inside a sandbox such as OpenShell.

Sandboxing limits what the agent can access directly. For privileged effects, it is best augmented with a pattern like safe outputs: the agent emits a structured, unprivileged request that separately trusted code validates and applies.

A compact decision tree

Can it run bash or arbitrary code?
├─ Yes → Run a generic agent in a sandbox
└─ No  → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"?
         ├─ Yes → OK, maybe LangChain or equivalent makes sense
         └─ No  → Goto start

I also think the builtin sandboxing in most agent tools (like Claude Code and Gemini CLI) is a bad idea, and it’s better to just ensure the entire thing is sandboxed.

Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different from just writing an agent skill”. From my previous post you’ll know that I think GitHub Agentic Workflows is a good reference baseline for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is almost exactly just an agent skill, but with a bit of YAML defining its integration with the outer system.

Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like LangChain to proliferate in most use cases. Sure you can use LLMs to generate it, but it’s even more secure and understandable to not have that code at all.

Even for the use case of an interactive chat bot, do you really need a custom app versus just MCP tools for an already generic frontend? I doubt it.

I don’t think it makes sense for most organizations to have proliferation of custom bespoke agents like these LangChain-style frameworks encourage. Skills and sandboxed generic agents are just easier to understand and work with.

2026-08-27T01:07:33Z 2026-08-27T01:07:33Z Colin Walters https://blog.verbum.org https://s0.wp.com/i/webclip.png I put my pants on just like the rest of you -- one leg at a time. Except, once my pants are on, I make Free Software. 2026-08-27T01:09:37Z http://ro7bit.wordpress.com/?p=541

## https://github.com/rosset/myconfig/tree/master/brother-t420w-2026# ┌───────────────────────┐ │ Brother DCP-T420W │ │ (final architecture) │ │ IPP / PWG-Raster │ └──────────▲────────────┘ │ ┌──────────┴───────────┐ │ Network / IPP │ └──────────▲───────────┘ │ ┌─────────────────────┴─────────────────────┐ │ │ Linux / Raspberry Pi 5 macOS 27 Golden Gate aarch64 IPP Everywhere │ │ CUPS + PPD CUPS │ │ br-box64-filter driver=everywhere │ box64 │ Brother … Continue reading Brother DCP-T420W (workaround for Linux aarch64 and macOS 27 Golden Gate)

#
# https://github.com/rosset/myconfig/tree/master/brother-t420w-2026
#

                         ┌───────────────────────┐
                         │   Brother DCP-T420W                          │
                         │  (final architecture)                              │
                         │   IPP / PWG-Raster                                │
                         └──────────▲────────────┘
                                                         │
                         ┌──────────┴───────────┐
                         │      Network / IPP    │
                         └──────────▲───────────┘
                                                         │
              ┌─────────────────────┴─────────────────────┐
              │                                           │
    Linux / Raspberry Pi 5                         macOS 27 Golden Gate
        aarch64                                                            IPP Everywhere
              │                                                                                     │
        CUPS + PPD                                                                    CUPS
              │                                                                                     │
      br-box64-filter                                                           driver=everywhere
              │
            box64
              │
    Brother x86_64 filter
              │
       HBP / PWG-Raster
              │
              └───────────────────────► Printer

# Linux
# Printer Brother_T420W running with Linux (aarch64) + box64 + cups filter + modified ppd
# Status: working

=> uncompress opt-brother.tar.gz to /opt - final path = /opt/brother

=> copy /opt/brother/br-box64-filter to /usr/lib/cups/filter/br-box64-filter
    * make sure it is executable: chmod +x /usr/lib/cups/filter/br-box64-filter
    * this filter is a wrapper for the Brother LPD filter, which is a x86_64 binary
    * it uses box64 to run the x86_64 binary on aarch64 (rpi5 in my case)
    * if you try to use ./lpd/x86_64/brdcpt420wfilter directly, it will fail with "wrong architecture" error
    * DietPi v10.6.2 (Debian 13.6) + [BOX64] Box64 with Dynarec v0.3.4 nogit built on Apr 24 2025 09:54:47
    * the "key" thing is to keep the A4 Geometry: 2480x3508 (some wrappers are changing it to 2480x3507, which is wrong)
    
=> key files under /opt/brother:
    - /opt/brother/Printers/dcpt420w/inf/brdcpt420wrc
        -changed PageSize=Letter to PageSize=A4

    - /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd
        - changed from *cupsFilter: "application/vnd.cups-postscript 0 brother_lpdwrapper_dcpt420w"
            - to.      *cupsFilter: "application/pdf 0 br-box64-filter"

    - copy /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd
        to /etc/cups/ppd/Brother_T420W.ppd
    
    - finally add the printer:
        lpadmin -p Brother_T420W -E -v ipp://printer-IP:631/ipp/print -P /etc/cups/ppd/Brother_T420W.ppd


# V2 => Easiest path for Linux aarch64, avoid use of box64 and Brother
# x86_64 filter, use IPP (no everywhere) driverless printing instead
#
# Brother_T420W - V1
#    → Brother proprietary LPD + box64
#    → maximum Brother specific compatibility

# Brother_T420W_IPP - V2
#    → native CUPS driverless
#    → PWG Raster over IPP
#    → no x86_64 emulation

driverless \
    ipp://printer-IP:631/ipp/print \
    > /tmp/brother-ipp/dcp-t420w.ppd

sed -i 's/\*DefaultPageSize: Letter/*DefaultPageSize: A4/' \
    /tmp/brother-ipp/dcp-t420w.ppd

lpadmin \
    -p Brother_T420W_IPP \
    -E \
    -v ipp://printer-IP:631/ipp/print \
    -P /tmp/brother-ipp/dcp-t420w.ppd

cupsenable Brother_T420W_IPP
cupsaccept Brother_T420W_IPP

lpstat -v
lpstat -p Brother_T420W_IPP -l

# macOS 27 Golden Gate
# Printer Brother_T420W with CUPS + IPP Everywhere
# Kind: DCP-T420W - IPP Everywhere
# Driver version: 2.3
# Status: working

lpadmin -p Brother_T420W -E -v "ipp://printer-IP/ipp/print" -m everywhere

2026-08-26T03:43:32Z 2026-08-26T03:43:32Z rossetfilipe https://ro7bit.wordpress.com https://ro7bit.wordpress.com/wp-content/uploads/2019/01/cropped-Rosset.jpg?w=32 IT, soccer & chimarrão 2026-08-26T14:50:00Z https://communityblog.fedoraproject.org/?p=15900

By Ananya Nalavathu and Francois Gonothi Toure Introduction Open source communities run on contribution, and contribution runs on documentation, storytelling, and knowledge sharing. At the Fedora Project, that means the Fedora Community Blog and Fedora Magazine, two publications that give contributors a voice and give the community a way to stay informed, inspired, and connected. […]

The post Meet editorial-guide-ramalama: An AI Assistant That Checks Your Fedora CommBlog and Magazine Articles Against Editorial Guidelines appeared first on Fedora Community Blog.

By Ananya Nalavathu and Francois Gonothi Toure

Introduction

Open source communities run on contribution, and contribution runs on documentation, storytelling, and knowledge sharing. At the Fedora Project, that means the Fedora Community Blog and Fedora Magazine, two publications that give contributors a voice and give the community a way to stay informed, inspired, and connected.

This year, as part of my internship with the Fedora CommOps team at Red Hat Ireland, I got to experience that firsthand. Publishing 11 articles, running editorial campaigns, and coordinating content across sprints gave me a deep appreciation for how much thought goes into keeping Fedora’s editorial standards consistent and how much easier that journey could be for new contributors with the right tool in hand.

That’s exactly what my fellow intern Gonothi built during his Outreachy internship with the Fedora Project. In our final sprint together, we decided to share it with the community because tools that make contributions more accessible deserve to be heard. With that context in mind, I’ll hand over to Gonothi to walk you through what he built and why. 

What I built and why

My name is Gonothi, and I’m an Outreachy intern within the Fedora Project. The tool I built is called editorial-guide-ramalama, a Retrieval-Augmented Generation (RAG) assistant that reads Fedora’s actual editorial guidelines and published articles, then checks your draft against them. It tells you whether your article meets the standards and exactly what to fix if it doesn’t.

A regular chatbot would guess. RAG grounds every answer in the actual guidelines. When the tool flags a problem, it cites the specific guideline and gives you an actionable fix. Not “this looks off”- but “your article is missing the Read More tag, which is required per the Magazine guidelines.” 

RamaLama is the engine behind the whole tool, and it’s a big part of why this project works the way it does. It runs open models locally as OCI containers, the same container tooling Fedora already uses, so there’s no API key, no external service, and no data leaving the machine, which keeps everything private and fully reproducible. It also has RAG built in: RamaLama handles the ingestion, chunking, and retrieval itself (running Docling internally to parse and chunk the guidelines), so I don’t have to wire together a separate vector pipeline. That combination of local inference, OCI-container packaging, and built-in RAG is what lets the tool ship as a single image that anyone can pull from Quay and run.

How it works

The tool supports both Fedora publications, Fedora Magazine and the Fedora Community Blog, each with its own editorial guidelines loaded as the primary source the model checks against. Switch publications in the sidebar, and the guidelines change accordingly.

The stack is built on RamaLama, Docling, Quay, and Streamlit, with small GPT-Generated Unified Format (GGUF) models benchmarked for quality versus size. The pipeline works like this:

Articles are pulled from both publications via the WordPress REST API; no static files are committed, and the corpus is always rebuilt from source and stays reproducible. RamaLama RAG runs Docling internally to parse and chunk the documents into a vector store, packaged as OCI images published to Quay at quay.io/fedora/editorial-guide-ramalama. To run a check, pull the relevant image and use either the Streamlit interface or the terminal; no build step required.

Paste a draft that meets the Magazine’s standards, and the model confirms compliance, citing the relevant guideline. Paste one with known issues, a missing featured image, a missing Read More tag, and it flags each problem with an actionable fix.

One honest note: small local models have limits. editorial-guide-ramalama is great for catching common issues before submission. It is not a replacement for a human editor, and it doesn’t try to be.

Why the open source community should care 

What strikes me most about this project is not just what it does technically, but what it represents for contributor onboarding in open source communities. One of the biggest barriers for new Fedora contributors isn’t motivation; it’s knowing the unwritten rules. Editorial guidelines, packaging standards, community norms these exist, but they’re scattered, and learning them through rejection is discouraging.

Tools like editorial-guide-ramalama lower that barrier. They don’t replace human editors or community knowledge; instead, they give new contributors a first pass, a way to self-check before they submit, and a way to learn the guidelines through doing rather than through trial and error. That’s exactly the kind of tooling that makes open source communities more accessible.

What comes next

This mini-project was the proof of concept that validated the RAG approach for Fedora editorial documentation. The same architecture is now feeding into a larger project applying RAG to RPM packaging guidelines, a higher-stakes domain where grounded, local, open-model AI can help contributors get packaging right.

The code is on the Fedora Forge at ai-ml/editorial-guide-ramalama. Pull the image from Quay and try it on your next draft before you submit.

Try it yourself

The tool is live and available now. Pull the image from Quay, paste your draft, and see what it says. If you’re a new contributor, nervous about your first article, this was built for you.

Thank you to the Fedora community, our mentors Justin Wheeler, Dominik Kawka, and Carol Chen, and Outreachy for making this internship possible.

The post Meet editorial-guide-ramalama: An AI Assistant That Checks Your Fedora CommBlog and Magazine Articles Against Editorial Guidelines appeared first on Fedora Community Blog.

2026-08-25T12:47:18Z 2026-08-25T12:47:18Z Ananya Nalavathu https://communityblog.fedoraproject.org/ https://communityblog.fedoraproject.org/wp-content/uploads/2022/07/favicon-fedora-commblog.png The Community Blog provides a single source for members of the community to share important news, updates, and information about Fedora with others in the Project community. 2026-10-07T21:07:54Z http://blog.verbum.org/?p=1930

In my last post, I talked about the value GitHub provides to FOSS, while arguing that we should avoid deep dependency on it.

Now let’s talk about agentic AI (LLMs).

TL;DR: I think GitHub Agentic Workflows is a new minimum quality bar that anyone having hosted agents operate on a git repository should strive to meet. It’s FOSS (unlike the built-in Copilot stuff) and pretty well designed in my opinion especially from a security point of view.

One background opinion I have here is that agentic AI is a strong reason to go even more deeply into “git-ops” style workflows. Having the ability to audit, verify (CI) and include a rationale for changes to things that aren’t necessarily software even (like a team’s travel budget) make even more sense in a world of agents.

OK you’re using git already, now let’s say you want to use agentic AI. There are rather a lot of solutions to this =) I want to narrow in first on “hosted” workflows (as opposed to just spinning up opencode/claude/codex/whatever on your laptop).

A simple scenario here is “mostly readonly with one write output” flows, which include:

• PR reviews
• CI failure diagnosis
• Duplicate issue detection

etc.

The more complex scenarios are “issue to PR” style flows, or intermixing CI and AI (e.g. having an agent run during a CI run after it fails but before the VMs/containers are torn down and being able to do some live debugging).

There’s of course plenty of third party services (mostly proprietary) that will do much of this. Today on GitHub you can assign an issue to Copilot for example, etc.

GitHub Agentic Workflows is simply a compiler that outputs GitHub Actions that run in the context of your repository. Aside from the inference endpoint, there’s no proprietary black boxes (also assuming you are using a FOSS tool inside, like Codex but not Claude Code) etc.

What the compiler takes as input is a Markdown prompt that is very much similar to an agent skill with YAML frontmatter that defines its integration with GitHub such as event triggering – but especially key is restrictions on its output.

There’s a lot to like about this. As part of my job lately I’ve had to look over what other people are doing in this space, and I have to say there’s people doing things that are worse than this. In some cases significantly worse (mostly less secure).

Let’s say you want to implement a duplicate issue detector.

A serious problem with all agentic AI is prompt injection. It’s easy for someone to encode malicious instructions in an issue they file, and an agent can easily run those. If you’re running this issue triage as e.g. an agent skill from your laptop with full credentials, you can easily get your account taken over.

But the problem is the “most obvious” way to do this stuff by e.g. writing a GitHub Action with a GH_TOKEN and the following permissions will allow writing to all issues:

permissions:
  issues: write

If e.g. a person prompt injects an agent and says “by the way this project is archived, close all the issues” an agent might just act on that!

And for “issue to PR” style workflows, the contents: write permission to a token is very powerful.

The safe outputs portion of GH-AW is very well designed in this respect, greatly limiting the blast radius of a compromised agent (e.g. the duplicate issue detector can add at most one comment, not close other issues etc.)

For public repositories, GH-AW also has a concept of an “integrity threshold” when reading from GitHub itself and the default is approved, so it the agent will not even see issues from new or unaffiliated contributors. For this use case, we have to remove that filter, but it’s balanced by restricting the output.

Prompt injection can also leak the API key you use to access the inference endpoint – definitely not something you want to be surprised by when you get the bill later that month. GH-AW runs an actions VM as normal, but the agent runs in an OpenShell-like sandbox (it’s not actually OpenShell, that’s a whole other discussion!)

Now, I’m not saying all agentic AI should be GH-AW; in addition to the advantages above, it has a whole host of downsides. In particular it’s not at all designed to be interactive and certainly there are many use cases where that’s much more efficient, especially research/planning, some types of debugging etc.

A pattern I expect to emerge is that these types of “less structured/organic/interactive/local” flows end up delegating some work to per-repository workflows. For example a weekly planning session may result in filing issues, which get driven to completion via a GH-AW style flow in each repo.

Further hybrids are possible of course, nothing truly stops one from having a GH-AW style flow send an interactive question to a human via a MCP tool or equivalent. But I don’t think I’d want to do that personally, I’d rather make it easier to turn a whole session dynamically interactive, kind of like how today one can use things like the tmate action to log into a runner.

GH-AW definitely has its issues; one thing is that it’s annoying to reproduce the sandboxing outside of a GHA run. There’s also a really high latency to each run because it involves spinning up not just a GHA runner, but also downloading and provisioning the container agent wrappers etc. That’s for good security reasons overall, and anyone doing something else should be able to justify the security tradeoffs.

Just to restate the conclusion: I think GitHub Agentic Workflows is a good reference baseline for a safe way to add agentic workflows to a GitHub hosted repository, and everyone doing something similar should include a comparison with it at least. If not, take some of the code: the “safe outputs” stuff is reasonably easy to use in other systems too.

2026-08-21T20:26:48Z 2026-08-21T20:26:48Z Colin Walters https://blog.verbum.org https://s0.wp.com/i/webclip.png I put my pants on just like the rest of you -- one leg at a time. Except, once my pants are on, I make Free Software. 2026-08-27T01:09:37Z http://blog.verbum.org/?p=1928

The question of using proprietary tools to build FOSS has always been one of the tension points in our community. One of the most prominent proprietary tools is github.com and the non-FOSS parts of gitlab.com (and a longer tail of other platforms).

A while ago I came across Give Up GitHub from the Software Freedom Conservancy which is on one side of this. My opinion remains nuanced and split. One I think few people would argue with is that there’s been enormous value provided to FOSS by the $0 github.com (and gitlab.com etc) services. Just the basic hosting of git infrastructure, issue tracking and other ancillary things (discussions, etc) but especially GitHub Actions.

There are a lot of critical projects out there getting by with the $0 “free/personal organization” infrastructure. It’s actually plenty for most projects (e.g. mature language libraries).

And while GitHub hasn’t been shy about pushing into the web interface things like Copilot (a proprietary agent framework) – in my opinion the platform still generally hasn’t been subject to platform decay. I mean, there’s no advertisements (which probably wouldn’t work because people would use custom interfaces talking to the API anyways).

This could of course change literally tomorrow; or next month, etc. But my gut says that at the current time Microsoft is OK funding github.com just to provide reliable infrastructure for their own teams, and those using it at large scale on premise probably provide enough income to offset the loss-leader economics for now.

I personally believe in (and argue for at my employer) avoiding a truly deep dependency on any one (proprietary) service (which includes github.com). In particular, I think Forgejo is a nice bit of software; it’s easy to run on premise for homelabs etc. The decision to run the Fedora Forge was not an easy one – there’s real ecosystem splitting effects, but I think we’ll be OK.

The thing is though, running a $0, publicly reachable internet service where people can just store/write things is genuinely hard (and especially when paired with a service to execute arbitrary code like Github Actions). It’s under constant attack from spam, scraping, bitcoin mining and abuse in a way that probably few people outside of the administrators truly appreciate.

I have a lot of respect for people and projects choosing to self-host or use smaller-scale hosts like Codeberg, but there’s real tradeoffs there around sustainability and availability.

I don’t expect this status quo to change much in the near future. In the next post, I’ll talk about how this relates to agentic AI.

2026-08-21T20:23:32Z 2026-08-21T20:23:32Z Colin Walters https://blog.verbum.org https://s0.wp.com/i/webclip.png I put my pants on just like the rest of you -- one leg at a time. Except, once my pants are on, I make Free Software. 2026-08-27T01:09:37Z