Dear Tumbleweed users and hackers,

While everybody started thinking about HackWeek, Tumbleweed kept rolling on without any major bumps on the road. This week, we released five snapshots (1108, 1109, 1111, 1112, and 1113).

The most relevant changes were:

• KDE Gear 24.08.3
• KDE Frameworks 6.8.0
• Mesa 24.2.6
• LLVM 19.1.3
• cURL 8.11.0
• Mozilla Firefox 132.0.1: No longer use custom patches to interact with KDE’s file dialogs, but rather use the xdg-desktop-portals
• Linux kernel 6.11.7
• Swig 4.3.0

Looking back at last week’s review, that is pretty much what had been advertised then. The preview for the upcoming snapshots includes:

• Linux kernel 6.11.8
• Enabling Python 3.13 modules; Python 3.11 will remain the default for now, subject to change
• Icu 76.1
• cmake 3.31.0
• Debugedit 5.1
• dbus-1-x11 will be removed: after the move to dbus-broker, we only need a simple dbus-launch, without X11-integration

The openSUSE Board is calling for the formation of a working group to explore topics focused on project governance, operational models and rebranding for the project.

This follows a call on the openSUSE Project mailing list to formalize efforts, ideas and suggestions by community members in a centralized location.

The openSUSE Board emphasizes its role as a facilitator rather than the sole driver as community participation should shape the project.

“The strength of open-source projects like openSUSE comes from the community,” was posted in an email to the openSUSE Project mailing list.

Objectives of the Work Group:

• Exploring Models for Project Governance
• Examining Operational Improvements
• Determining Resources for Effective Project Rebranding

The work group will concentrate community discussions and propose actionable options within 90 days; this will provide opportunities for the wider community to weigh in on the items proposed. Key governance documents, such as the current Board guidelines and election rules, should be reviewed to assess potential updates.

Discussions will be organized centrally in a separate section of the openSUSE forums to foster constructive debate and minimize off-topic discussions. This forum will be heavily moderated. openSUSE community members interested in participating can request access to the forum; the discussions will be publicly viewable.

The November syslog-ng newsletter is now on-line:

• A call for syslog-ng testing
• Working with Quickwit
• Huge improvements for syslog-ng in MacPorts

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2024-11-testing-quickwit-macports

Introduction This is part 4 of a series on running AI locally on an openSUSE system. Previous parts can be found here: Running AI locally Generating images with LocalAI using a GPU Introduction to AI training with openSUSE Since we have LocalAI running, generated images, text and even trained own LoRAs, another big topic is […]

The post Adding own Documents to your Local AI Using RAG appeared first on SUSE Communities.

How to create a MCP server

This guide is for developers who want or need to build an MCP server. It describes how to implement an MCP for listing and adding users.

What is a MCP server

A MCP server is a wrapper which sits between a LLM (Large Language Model) and an application and wraps calls from the LLM to the application in JSON. You might be tempted to wrap existing APIs of your application via fastapi and fastmcp but as described by mostly harmless, this is a bad idea.

The main reason for this is that an LLM performs text completion based on the ‘downloaded’ internet and can focus on the topic for not more than approximately 100 pages of text. It’s hard to fill these pages with chat; you may have never encountered this limit. This also means that you have to have a user story or tasks, which has to fill this book, with all the possible failures and dead ends. In the our example it will add a user "tux" to the system.

The first pages of this imaginary book, are already filled by the system prompt and with the description of the MCP tool and its parameters. This description is provided by tool author, so you can be very descriptive when writing the tool descriptions. A few more lines of text won’t harm.

Now every tool call has a JSON overlay, so you also want to avoid too many tool calls. Try to minimize the number of tools and combine similar operations into one tool. If you had a tool interacting with systemd, you would have just one tool that combines enabling, disabling, starting, restarting… the service, and not one tool for each operation.

For the tool output, do not hesitate to combine as much information as possible. A good tool output shouldn’t just return the group ID (GID) but also the group name.

The caveat here is that you can easily oversaturate the LLM with too much information, like returning the information of find /. This would completely fill up the imaginary book of the LLM conversation. In such a case, trim the information and provide parameters for tools, like filtering the output.

This boils down to the following points:

• Have a user story for the tools.
• Provide extensive tool descriptions and their parameters
• Condense the tools into sensible operations and don’t hesitate to add many parameters
• A tool call can have several API calls
• Avoid overload: LLMs can’t ignore output, so you are responsible for trimming information And also the following bonus point, which I learned along the way:
• Avoid a verbose parameter; an LLM will always use it

[!NOTE]Always remember: “Context is King”

Members of the openSUSE’s election committee have provided notice to the project about the start of this year’s board election. This election there are three board seats up for grabs.

The election begins its nomination process on Nov. 15 and invites all eligible openSUSE members to participate in shaping the community’s future.

The open seats are currently held by Douglas DeMaio, Neal Gompa, and Patrick Fitzgerald. Board members serve as guides for the community, oversee some key project functions, facilitate community initiatives and handle responsibilities from organizing board meetings to managing openSUSE domains and trademarks. They also play a role in upholding community standards, including overseeing complaint processes and ensuring compliance with openSUSE’s Code of Conduct.

Election Timeline The election process will unfold over the next month. The plan is to follow this official schedule:

• Nov. 15: Official announcement, nominations open, membership drive begins
• Nov. 30: Final candidate list announced; campaign begins
• Dec. 1: Voting opens
• Dec. 15: Voting closes
• Dec. 16: Election results announced

How to Participate Any openSUSE member can stand for election by sending an email to project@lists.opensuse.org and election-officials@lists.opensuse.org. Members may also nominate others by contacting the Election Committee, who will follow up with the nominee to confirm their interest.

Eligibility Requirements According to the organization’s Election Rules, only current members are eligible to run for board positions. While new members are welcome to join during the membership drive and participate in the voting process, they will not be eligible to stand as candidates. The election committee overseeing this year’s event includes members Ish Sookun, Edwin Zakaria, and Ariez Vachha. The committee is responsible for ensuring a smooth election process and for finalizing the list of candidates by Nov. 30.

The openSUSE Project is excited to announce rsync.net as the latest Gold Sponsor!

The company’s support will empower the openSUSE community to continue building open-source solutions that serve users worldwide.

Rsync.net’s secure cloud storage and data backup solutions can assist openSUSE members with projects and package development. This is an excellent solution for securing offsite backups of critical data for a system. The cloud storage company rsync.net dedicates resources not only to the openSUSE Project, but to other open-source projects like Debian developers.

Through this partnership, openSUSE community members with an openSUSE email address can access 500 GB of free-forever storage. Members can also gain the additional benefits from rsync.net with affordable options for those who need even more space:

• Standard Single Region: $0.008 per GB per month, ensuring 99.9999% resiliency.
• Geo-Redundant Storage: $0.014 per GB per month, with automatic replication across regions for enhanced security.

Storage locations in Silicon Valley, Denver, Zurich, and Hong Kong can help to best suit developer needs.

The openSUSE Project values this partnership with rsync.net and its members appreciate the company’s commitment to support our community and open-source efforts.

For openSUSE members interested in rsync.net’s support, click here.

Members were informed about the sponsorship through the Factory mailing list. Members of openSUSE can view the perks of being a member of the project on the wiki.

Companies interested in supporting the openSUSE Community can find sponsorship details on our sponsors page. The project also accepts donations to support the community through the Geeko Foundation.

The openSUSE Project is excited to announce rsync.net as the latest Gold Sponsor!

The company’s support will empower the openSUSE community to continue building open-source solutions that serve users worldwide.

Rsync.net’s secure cloud storage and data backup solutions can assist openSUSE members with projects and package development. This is an excellent solution for securing offsite backups of critical data for a system. The cloud storage company rsync.net dedicates resources not only to the openSUSE Project, but to other open-source projects like Debian developers.

Through this partnership, openSUSE community members with an openSUSE email address can access 500 GB of free-forever storage. Members can also gain the additional benefits from rsync.net with affordable options for those who need even more space:

• Standard Single Region: $0.008 per GB per month, ensuring 99.9999% resiliency.
• Geo-Redundant Storage: $0.014 per GB per month, with automatic replication across regions for enhanced security.

Storage locations in Silicon Valley, Denver, Zurich, and Hong Kong can help to best suit developer needs.

The openSUSE Project values this partnership with rsync.net and its members appreciate the company’s commitment to support our community and open-source efforts.

For openSUSE members interested in rsync.net’s support, click here.

Members were informed about the sponsorship through the Factory mailing list. Members of openSUSE can view the perks of being a member of the project on the wiki.

Companies interested in supporting the openSUSE Community can find sponsorship details on our sponsors page. The project also accepts donations to support the community through the Geeko Foundation.

Managing localization of desktop menus and applications takes a specific tool and approach that fills a gap but leaves inconsistent upstream translations.

Open-source translation standards have advanced over the years and the downstream-only model being used has proven to become inefficient, which is why Update-Desktop-Files Deprecation efforts are developing.

Over the past two decades, SUSE’s translation system has grown to cover more than 5,747 packages, with a total of about 380,000 translated strings. These efforts are labor-intensive and often redundant since many translations upstream already exist. The update-desktop-files tool contradicts an upstream-first policy. The SUSE-specific translations override upstream versions, causing inconsistencies and duplicating translation work. It also limits package maintainers’ control as translations are often integrated during runtime, which then appear different from what package maintainers expect. The tool adds complexity and requires SUSE-specific infrastructure (e.g., SUSE intranet and OpenQA VPN) that complicates maintenance and makes it challenging to align with certain open-source practices.

Given these challenges, transitioning to an upstream-first approach aligns with openSUSE’s goals of reducing redundancy, improving translation quality and supporting community collaboration.

Starting with the new update-desktop-files release to Factory in November 2024, package maintainers are encouraged to check build logs for instructions on upstreaming SUSE-specific translations.

Below is the roadmap for these effort:

• November 2024: New version in Factory enables upstreaming of translations done over the past 20 years.
• Early 2025: Packages using the opaque translation process will start upstreaming changes.
• March 2025: Package maintainers review and propose changes to upstream projects.
• End of 2025: Upstream responses are integrated; package maintainers import changes to Factory.
• 2026: Any remaining SUSE-specific desktop files are patched. By year-end, the use of update-desktop-files will trigger errors, phasing it out completely.

To help in this transition, package maintainers should verify translations for Name, GenericName, Comment, and Keywords against upstream standards. Where applicable, patches can be generated using the update-desktop-files.tar.gz files, which provide various patch formats (e.g., -downstream-translated.diff for direct translations). Package maintainers should also update spec files, remove %suse_update_desktop_file and use the appropriate upstream translation mechanisms. Following the guidelines outlined in the openSUSE wiki page will help those who have questions.

The change is expected to use the upstream translations wherever possible, so the community can focus on openSUSE translations.

For more information, visit openSUSE wiki or subscribe to the translations mailing list.

Due to recent changes in the worker configuration of the SUSE internal openQA instance, we needed to reconfigure some of the PowerPC jobs in openQA. This triggered a couple of questions regarding the availability of openQA worker, worker backends, their differences and their caveats. This blog post should act as a quickstart/overview guide for people getting into OpenQA testing on the PowerPC architecture.