News and updates for about the Fedora Project community that develops supports and promotes Fedora. For more information, and to download the Fedora OS head to Get Fedora. For general news about the Fedora OS, check out the Fedora Magazine

Page 2 of 53

Moving from fedmsg to fedora-messaging

The Fedora infrastructure is working on replacing our current message bus fedmsg by a new library fedora-messaging based on AMQP. This is an update on the work currently in progress.

Continue reading

Stories from the amazing world of release-monitoring.org

How I got here

One wise man once said: “It is always best to start from the beginning”.

Our story begins in August 2018. I was summoned by the Archmage (my ex-manager Jim Perrin) to be part of the mage conclave (Fedora Infrastructure team) and take care of a world that laid abandoned for some time. The name of this realm is release-monitoring.org and Jim recommended I start on the continent of Anitya (web server).

Continue reading

FPgM report: 2019-10

Here’s your report of what has happened in Fedora Program Management this week.

I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else.

Announcements

Meetings and test days

Events

Fedora 30 Status

Fedora 30 includes a Change that will cause ambiguous python shebangs to error.  A list of failing builds is available on Taskotron.

Blocker bugs

Bug IDBlocker statusComponentBug Status
1686326
AcceptedanacondaMODIFIED
1686679AcceptedcephMODIFIED
1683197Acceptedgdm
NEW
1673710Accepted
gstreamer1-plugins-goodNEW
1684612AcceptedPackage ReviewON_QA
1686679AcceptedlibdnfASSIGNED
1685992Proposedinitial-setupASSIGNED
1686636ProposedpodmanNEW
1686919Proposedpython-blivetNEW

Changes

An updated list of incomplete changes is available in Bugzilla.

Fedora 31 Status

Changes

Announced

Submitted to FESCo

Approved by FESCo

Modularity Hackfest, March 2019

Some time ago, the Modularity team in Fedora attempted to organize a proper hackfest on Modularity.  The hackfest was intended to gather together members of the Fedora community (both internal and external to Red Hat) in Ireland and work through some of the bigger UX and packaging concerns around Fedora Modularity. Unfortunately, the planning and funding for the hackfest fell through. However, it turned out that we were able to pull together a less-ambitious hackfest in the Red Hat Boston office over Monday and Tuesday (at effectively no notice). The attendance was a bit limited, but we were able to get several people together along with several more through video-conferencing technology.

Among the attendees from Red Hat were Petr Šabata, Langdon White, Adam Šamalík, Mohan Boddu and Matthew Miller. From outside of Red Hat, we were joined by Neal Gompa and Igor Gnatenko.

Much of this two-day hackfest was spent identifying and scoping the most urgent problems that we need to solve. We opened the session by inviting Neal Gompa to report on his experiences with attempting to consume and build modules for the projects he works on in his day-job. In particular, his internal toolchain uses the Open Build Service (OBS) to build his tools on multiple operating systems. At present, OBS does not handle repositories with modular content appropriately. OBS relies directly on libsolvext for working with repodata which does not currently handle the module metadata. As a result,  the Fedora Modular and Red Hat Enterprise Linux 8 Beta AppStream repositories look like a collection of conflicting data.

We spent quite a lot of time in discussion on this topic and eventually broke it down into two specific problems to solve. First, we need to work with libsolvext upstream to add support for reading the modulemd YAML format. Second, we need to then convert the data read by this format into “solvables” that can be processed by libsolv. This will enable OBS to process modules in an appropriate manner (and may eventually be able to replace the implementation done by libdnf). The first issue is currently blocked on libsolv upstream’s unwillingness to include the libyaml parser, preferring to insist that modulemd be provided instead as XML. However, Igor (a member of libsolv upstream himself) has become sufficiently convinced that such a switch won’t happen and is going to approach the rest of upstream to reconsider their stance.

The third primary issue we identified was that there exists some content that is used when building Fedora and RHEL 8 Beta modules that are not published outside of the build-system, resulting in those modules being impossible to reproduce externally. In Fedora we have modules (called “buildroot-only” modules) that are not shipped in any public repository. As it relates to reproducibility of the distro, we will probably need to publish this content somewhere. We discussed with Mohan (the Fedora release engineering lead) that we may want to provide a new repository for this content that we will not mirror widely (and probably produce without deltarpms, etc so as not to unnecessarily slow the compose process).

The last big issue we discussed was the difficulty currently faced by users who want to build their own modules locally. To define the term “locally”, we mean that once the necessary dependencies are cached onto the local system, it should be possible to complete builds and rebuilds without any internet access. Today, the MBS has limited local build functionality out of the box for building Fedora modules. However, it is not truly local, as the build process will reach out to Fedora’s infrastructure including both Koji and PDC at some points. We agreed that the MBS needs to be updated to be able to either cache all content locally or be directed at a specific site-mirror of the repositories to be able to perform builds without access to the Fedora Infrastructure. In the case of RHEL 8 modules, this becomes even more urgent as anyone outside the Red Hat firewall will not have access to the Red Hat MBS and Koji instances.

Beyond the problems with network access, we also looked into what people will need to be able to do in order to compose and release their third-party modules in their own repositories, either internal to their organization or publicly as a non-official Fedora or RHEL repository. Today, there are painfully-difficult ways to accomplish this with the createrepo_c family of tools, but those present at the hackfest agreed that we need to enhance this experience by making module metadata a first class citizen in those tools. To that end, I opened several issues against the createrepo_c project:

  • Issue 131: Make module metadata a first-class citizen in mergerepo. This is necessary to ensure that tools that want to compose modular content will be able to update their final repos with the content produced by a local MBS build. In other words, it must be possible to take the module-specific repo created by an MBS local build and add it to a combined repository without a log of manual steps to set the module metadata correctly.
  • Issue 132: Add package checksums to the module metadata when creating a repository. This is needed for libsolvext, as it uses the checksums as the lookup key for each package.
  • Issue 133: Similar to how it handles packages, when running createrepo_c or mergerepo_c, it needs to be possible to exclude a subset of modules from the resulting repository.

As we were discussing these createrepo issues, we also identified several gaps in the libmodulemd API that will need addressing to support them.

  • Issue 208: In order to simplify things for libsolvext and createrepo_c, libmodulemd needs to be able to decompress modules.yaml.gz or modules.yaml.bz2 streams.
  • Issue 209: In support of the createrepo issue 133 above, we need to add a routine to make it simple to exclude an entire module (defaults object and all) from a ModuleIndex object.
  • Issue 212: We discovered in our discussions a shortcoming in the libmodulemd 2.x API. It made an incorrect assumption that separate CPU architectures would always be contained in separate repositories. Neal noted that there are some prominent repositories in the wild that converge multiple arches into a single repository. We will need to evaluate whether we can fix this without breaking API.

The hackfest also discussed a number of issues around upgrades from one release to the next, including the current issues plaguing efforts around the Fedora 30 Beta. We brought in Adam Williamson of the Fedora QA team for this part of the discussion. In this case, we reached a clear agreement that the currently-proposed workaround on the Fedora Devel mailing list (of requiring users to pass a special --setopt argument to the upgrade command) is not an acceptable solution for Fedora 30 Beta. We will ask that the DNF team find a way such that the existing expected commands dnf --releasever=$NEXTVERSION system-upgrade download must work without additional arguments.

Open Questions:

We had some discussions throughout the course of the hackfest that didn’t reach a clear consensus. The most contentious was around what to do about empty profile data. There are several uncommon cases that need to have clear UX decisions made around them.

A module does not have one or more of its profiles specified to be the default.

The module creator has not provided a defaults object into the YAML (in Fedora, this is done by requesting it be added by release engineering or submitting a pull request to the fedora-module-defaults repository). This may be intentional or unintentional. Fedora QA has asked us if they should be treating the lack of a defaults reference for the profile as a failure, since this is something that could be detected during post-compose testing and reported. My personal opinion on this case is that for modules in Fedora itself, we should indeed treat this as a bug and require that all modules have a defaults object that properly references a set of default profiles for any stream included in that compose.

The open question here is what the DNF experience should be if dnf module install modulename:modulestream​ is called. The current behavior is that DNF treats this as equivalent to calling dnf module enable modulename:modulestream (it makes the contents of this module explicitly available, but installs nothing at that time. Feedback from users of the RHEL 8 Beta have indicated that this is an unexpected behavior of the install verb. They’d prefer to see DNF report an error if install is called and results in no packages being installed. In part, this is because it would be silently hiding the possibility that the defaults are missing.

A module has explicitly set one or more of its streams to have no default profiles

This is a similar case to the above, except that a conscious choice was made by the module maintainer to say that this module has no reasonable default packages that could be selected. (For example, it could be a collection of popular libraries that extend a particular programming language, but there’s no obvious subset of them that makes sense to install. It may exist and have streams solely because it needs to be kept in sync with the interpreter version.)

The open question is the same as the previous one: how should dnf module install handle this case? In this particular example, it might be more acceptable that it follows the enable fallback, since the maintainer selected the lack of a profile explicitly. However, having context-sensitive differences can be difficult for people to process.

A module has a profile that contains zero RPMs

In this case, a profile definition has been made in the module metadata and it explicitly contains zero RPMs within it. Such an example might be for compatibility: the module previously provided a profile with that name that contained content, but it is no longer doing so. Retaining the name may have been done to allow existing scripts to avoid breaking. If we have a profile that contains zero packages, should it be an error if we attempt to install it? If not, what should the UX look like?

Kernel 5.0 Test Day 2019-03-12

Tuesday, 2019-03-12 is the Kernel 5.0 Test Day!

Why Test Kernel?

The kernel team is working on Kernel 5.0.  This version was just recently released, and will arrive soon in Fedora.
This version will also be the shipping Kernel for Fedora 30. So it’s to see whether it’s working well enough and catch any remaining issues.
It’s also pretty easy to join in: all you’ll need is an iso (which you can grab from the wiki page).

We need your help!

All the instructions are on the wiki page, so please read through and come help us test! As always, the event will be in #fedora-test-day on Freenode IRC.

Share this!

Help promote the Test Day and share the article in your own circles! Use any of the buttons below to help spread the word.

FPgM report: 2019-09

Here’s your report of what has happened in Fedora Program Management this week.

I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else.

Announcements

Meetings and test days

Events

Fedora 30 Status

  • Mass rebuild is complete. A list of outstanding build failures is available
  • Fedora 30 is branched from Rawhide
  • Code complete (100%) deadline is 2019-03-05.

Fedora 30 includes a Change that will cause ambiguous python shebangs to error.  A list of failing builds is available on Taskotron.

Blocker bugs

Bug IDBlocker statusComponentBug Status
1672761Accepteddevice-mapper-multipathMODIFIED
1656509Acceptedfedora-reposNEW
1683197Proposedgdm
NEW
1673710Proposedgstreamer1NEW
1684612ProposedPackage ReviewNEW

Changes

Deferred to Fedora 31

Fedora 31 Status

Changes

Announced

Submitted to FESCo

Approved by FESCo

Fedora IoT Docs are Live

Fedora Internet of Things is a variant of Fedora focused on IoT ecosystems. This month I had the opportunity to focus on the Fedora IoT Documentation with the working group as a part advancing their objectives.

What was done

I began by expanding the “Getting Started” section to help people do as the title indicates: get started. This section is focused on getting the images downloaded and a device up and running with an initial user. The steps are detailed enough to help those that are also new to Fedora distributions.

Next I reorganized some of the remaining initial content into a “User Guide” section. This section covers topics thought of as the “next steps” in using the Fedora IoT images. I detailed the steps for managing updates with rpm-ostree and switching between development and stable builds. I also added examples for layered packages, adding repositories, and even running containers. Finally I provided some pointers for other administration tasks with links to existing Fedora Documentation

What is next

Design ideas: My focus was on technical content. The basic layout is dictated by the Fedora Docs project but a bit of design work on the welcome page and the addition of any IoT specific logos would be nice. Also, there are a few screenshots that could use a pointer or box to highlight the area described in the text.

Verify links for downloads and upgrades: The working group now has regular updated images available in a CDN and the next downloadable image is in progress along with the final version of the landing page for downloads. Once the update and release schedule process is smoothed out, the documentation needs to be verified.

Get ready for F30: When Fedora 30 is ready, the site will need some Release Notes and the User Guide will need some updates to cover new features. You can submit suggestions as iot-docs issues in pagure.

A lot of progress was made this month and I learned more about asciidoc, ostree, and my Pi device. Also that my fingers are too big for microSD cards!

Check out the content at https://docs.fedoraproject.org/en-US/iot/
Feedback is welcome — just let us know with an iot-docs issue or through any of the methods mentioned on the welcome page!

Fedora 30 Gnome Test Day 2019-02-27

Wednesday, 2019-02-27 is the Fedora 30 Gnome Test Day! As part of changes Gnome 3.32  in  Fedora 30, we need your help to test if everything runs smoothly!

Why Gnome Test Day?

We try to make sure that all the gnome features are performing as they should. So it’s to see whether it’s working well enough and catch any remaining issues.
It’s also pretty easy to join in: all you’ll need is Fedora 30(which you can grab from the wiki page).

We need your help!

All the instructions are on the wiki page, so please read through and come help us test! As always, the event will be in #fedora-test-day on Freenode IRC.

Share this!

Help promote the Test Day and share the article in your own circles! Use any of the buttons below to help spread the word.

FPgM report: 2019-08

Here’s your report of what has happened in Fedora Program Management this week.

I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else.

Continue reading

Fedora Strategy FAQ Part 3: What does this mean for Fedora releases?

This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.

What does it mean to “release Fedora”?

Fedora operating system releases are (largely) time-based activity where a new base operating system (kernel, libraries, compilers) is built and tested against our Editions for functionality.  This provides a new source for solutions to be built on. The base operating systems may continue to be maintained on the current 13 month life cycle — or services that extend that period may be provided in the future.  A solution is never obligated to build against all currently maintained bases.

What does this mean for today’s Editions, Labs and Spins?

We are not moving your cheese. At least, not very far. Today’s outputs are essentially unaffected, except in being granted more freedom.  It becomes easier for these solutions to release on their own cadence and to provide alternative software (which could be consumed by other solutions) to meet their users’ needs. We may want to release (for example) Fedora CoreOS completely separately from the base OS refresh, and have a marketing splash entirely around that solution and what the new release does for its target audience.

Labs and Spins are no longer required to be named as such — within the project, they are “Solutions”. (If you like the term “Lab” or “Spin” for something you’re making, feel free to keep calling it that!) These Solutions are “vertical” in that they consume various services to solve their target use case.  Solution builders are free to build their solutions on anything the Project has to offer that meets their needs.

Solutions may have access to different services based on criteria set by those vertical service providers, possibly following strategic guidance set by the Council or following recommendations from Mindshare.  For example, the Website Team support in the form of presentation on the main downloads page may be restricted to solutions with a large user base. Solutions with smaller user bases can grow their usage and gain access to this.

We are retaining the idea of Editions to denote those solutions we use as a test-gate for our releases.  These are our showcases that we will advertise heavily to users and use as a way of framing conversations about the project.

What about solutions that need long or short release cycles?

This is an area where we want the Fedora platform to shine. Modularity enables us to provide multiple versions of applications simultaneously, solutions can release frequently with what have traditionally been thought of as blocking upgrades. This means that these high-speed solutions can keep growing.

When a solution requires frequent changes to the base operating system to meet its need, the entire Fedora platform benefits.  These solutions can also be building block or service providers. Therefore if, for example, an IoT solution requires more frequent base library upgrades, another solution can also choose to use those rapidly updating base libraries as part of their build too.

« Older posts Newer posts »

Copyright © 2019 Fedora Community Blog

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Theme by Anders NorenUp ↑