Log in

What is going on in the Fedora Modularity project

We are currently in a 4 week Modularity Sprint #10, the usual 2 week sprint got extended due to FLOCK and pre-FLOCK developer meetings.
As you can see in the 'In Progress' and 'Complete' columns on our Taiga board, lots of tiny and larger pieces are coming together.
The following text describes how various parts of the Modularity infrastructure work together. Ralph Bean shows these connections in his Modularity infrastructure diagram.
Module build tasks can be submitted to orchestrator (rida) either by posting a short yaml text into the REST API or with 'fedpkg module-build'. The orchestrator will then download and parse the module description file, check the dependencies and schedule koji builds for missing components. The build process can be monitored with the Build Pipeline Overview (BPO) component and the final result will be fed into the Product definition center (PDC) which is a webapp and API designed for storing and querying product metadata.
All of the above is already done and in a usable state after this sprint, although not all patches have been added to the upstream repositories yet. Same features are still missing, but we'll continue adding them in the upcoming weeks.

Langdon demoed how all this works from a user perspective during his talk [1] at FLOCK in Krakow. Unfortunately a recording of his talk isn’t available on YouTube yet. Nils and Adam therefore put together a similar demo, you’ll find it in the Fedora Modularity channel on Youtube

[1] https://flock2016.sched.org/event/6yoy/modularity-why-where-we-are-and-how-to-get-involved
[Link to Part 1

One of our main communication channels is IRC. We've recently decided to standardize the name of our efforts as 'Modularity' where we prior to that sometimes used the term 'Modularization' and sometimes 'Modularity'.
That's why you can now find us in the #fedora-modularity channel on Freenode IRC. (The old channel #fedora-modularization will redirect you to our new channel).If you have any questions about what we do or, even better, would like to join our group and help with programming (mostly python) or if you have some ideas for improvements, this is where you need to go and post your questions: irc://chat.freenode.net:6667/#fedora-modularity
To get opinions of other Fedora developers, a post to the Fedora development list devel@lists.fedoraproject.org is probably a good idea. Please use the [Modularity] prefix in your subject for Modularity related posts.

For those of you going to FLOCK in Krakow (August 2-5, 2016), Langdon White will be there and has a session about Modularity on Wednesday, August 3, 11:00-11:50 with the topic 'Modularity: Why, where we are, and how to get involved'.
The Fedora Modularity Project is an effort to fix several problems that all distributions face. One of them is the disconnect between Fedora's release cycle and the release cycle of larger Fedora components like for example GNOME, KDE or even the kernel. Those components obviously don't have the same lifecycle that Fedora follows and Fedora can't always wait for major components to be released upstream and on the other hand doesn't want to ship outdated software.
An earlier attempt to work around this disconnect were the Fedora Rings with a central core 'base design', a concentric ring #2 around it for 'environments and stacks' and a ring #3 for applications. It wasn't possible to have different release cycles for packages in ring #2 as dependencies wouldn't allow that most of the time.

Another problem that the Modularity project is attempting to fix is the need for parallel installations of different versions of components without having to use compatibilty packages. The reason for this is that users want the latest set of components and they also want to keep their older applications running even though they require older components.

Fedora Modularity takes the 'Fedora Rings' approach to the next level. Instead of having complete rings we're now using something like 'ring segments' around a core module where the segments on the same ring # are independent on each other whereas segments on outer rings depend on certain inner segments.

There's a Wiki page describing how to get involved with Modularity. I'd strongly suggest reading those onboarding docs including the links on that page. As we're using agile software development methods for Modularity with 2 week sprints it is very easy to get involved even if you're unsure if this really is something you'd like to spend more of your time on. Just pick a task that you'll be able to finish during one of the sprints  from the 'New' column of our Taiga board, move it to 'In progress' and assign it to yourself. Also make sure to get involved in our ongoing discussions in the #fedora-modularization channel on Freenode IRC.
At the end of each sprint each of us creates a short demo about the work that was done during that sprint. These videos are available on YouTube and show for example how to install the modularity environment by checking out our git repositories, how to set up and configure product definition-center, how to use fm-tools for modules and so on.

As it difficult to follow the URL's in the videos, here's a short writeup about the git repositories and which git branches you need to get started:
export MODULARITY_DIR="modularity"
sudo rm -rf ~/modularity_workdir 2>/dev/null
# Set up the pungi / pdc modularity environment
#Create a new working directory first and chdir into it
#check out the pungi-modularity git repository
git clone https://pagure.io/pungi-modularity.git
#check out the modularity-prototype branch of Lubos's pungi git repository
git clone --branch modularity-prototype http://pagure.io/forks/lkocman/pungi.git pungi
#check out the modularity branch of Lubos's productmd git repository
git clone --branch modularity http://github.com/lkocman/productmd.git productmd
#fm-metadata got renamed to modulemd, check out the git repository
git clone http://pagure.io/modulemd.git modulemd

#set up some environment variables so that python finds the files
export MODULARITY_DIR="$HOME/modularity-work"
export PATH="$MODULARITY_DIR/pungi/bin:$PATH"

#now do some work
#create a directory to store the compose, I've used ~/modularity_workdir
sudo mkdir ~/modularity_workdir
sudo chown $USER.$USER ~/modularity_workdir
cd $MODULARITY_DIR/pungi/bin
# get all the packages required by the packages referenced 
# in ../../pungi-modularity/pungi-inputs/core.yaml
./pungi-gather-prototype \
  --arch x86_64 \
  --config ../../pungi-modularity/pungi-inputs/core.yaml \
  --target-dir ~/modularity_workdir \
  --source-repo-from-path /home/24/Everything/x86_64/os/ \
  --source-repo-from-path /home/24/Everything/source/tree/ \
# get all the packages required by the packages referenced 
# in ../../pungi-modularity/pungi-inputs/shells.yaml
./pungi-gather-prototype \
  --arch x86_64 \
  --config ../../pungi-modularity/pungi-inputs/shells.yaml \
  --target-dir ~/modularity_workdir \
  --source-repo-from-path /home/24/Everything/x86_64/os/ \
  --source-repo-from-path /home/24/Everything/source/tree/ \
#create repositories with those RPMs
./pungi-createrepo-prototype \
  --arch x86_64  \
  --static-content-manifest ~/modularity_workdir/manifest_core-x86_64-*/  \
  --target-dir ~/modularity_workdir \
  --source-repo-from-path /home/24/Everything/x86_64/os/ \
  --source-repo-from-path /home/24/Everything/source/tree/ \
./pungi-createrepo-prototype \
  --arch x86_64  \
  --static-content-manifest ~/modularity_workdir/manifest_shells-x86_64-*/ \
  --target-dir ~/modularity_workdir \
  --source-repo-from-path /home/24/Everything/x86_64/os/ \
  --source-repo-from-path /home/24/Everything/source/tree/ \
#and finally do a compose
pungi-compose-prototype \
  --release fedora-24 \
  --variants-file /home/karsten/tmp/modularity/pungi-modularity/pungi-inputs/variants-fm.xml \
  --arch x86_64 \
  --target-dir ~/modularity_workdir \

After the last step you have several json files in ~/modularity_workdir/compose*/compose/metadata that describe the exact package versions used for this module and that will be later will be used by the Orchestrator to create koji buildroots with these packages and then build the module components and the module itself.

VIM Tip of the day

Ok, here's a short one:

Why don't you use vimx instead of vim ? It is part of the vim-x11 package and starts gvim in terminal mode without the GUI.

It has one major advantage over vim: It has access to the X clipboard.

So if you have marked some text in your browser, you can access it in vimx with the special register '*'.
To test it, mark something in the browser or in another terminal and then switch to vimx and type :reg to list the contents of vim's registers. There should be one called "* with the marked text.

To use it, just yank it into your text as usual. Move the cursor to where the marked text needs to appear and then press
which means 'paste the contents of register * at the current cursor location'

Tested with KDE, if it doesn't work in Gnome, please let me know.

VIM Tip of the day

VIM Tip of the day

Even as the long term Fedora VIM maintainer I'm using only a minimal subset of VIM's features and commands.
But there are lots of small tips and tricks that I think every VIM user should know about and I'll try to post them occasionally in a small series of blog posts.

So today it is about Ctrl-p. Have you ever tried to remember and pronounce a function name or maybe just a name correctly several times in a document ? That's not necessary, you just have to get it correct the first time and then use Ctrl-p to make VIM do this job for you.

Lets take this text from Volcanology of Iceland which I chose because of those hard to get correct names:

The eruption under Eyjafjallajökull ("glacier of Eyjafjöll") in 2010 was notable because the volcanic ash plume disrupted air travel in northern Europe for several weeks; however this volcano is minor in Icelandic terms. In the past, eruptions of Eyjafjallajökull have been followed by eruption of the larger volcano Katla, but after the 2010 eruption no signs of an imminent eruption of Katla were seen

If you have to type that volcano name again, just (in insert mode)type Ey and then press Ctrl-p.
Vim shows you a text menu where you can choose between


with the cursor keys and selct one with ENTER. VIM inserts the selected word into your document.

That's it, fast and easy ;-)

Another great FUDCon

Thanks a lot to the organizers of the FUDCon Lawrence !

The location was great, near the hotel were lots of pubs and restaurants to meet at in the evening. We had coffee (!!!), more than enough rooms afaik, lunch each day and even sponsored beverages at the FUDpub on Saturday. Even the weather played nice, who would have thought that we would be able to sit outside for Lunch in January ?
We've got a lot of topics covered and will keep you informed on the PPC mailing list about improvements to our wiki pages and the future direction of the PPC secondary arch.
Brent has also mentioned some other topics on the PPC mailinglist, so klick the link and read his post...

Fedora 16 for PowerPC: Alpha got released !

Phil has already posted the announcement, but I think this is also worth a blog entry.
We've finally fixed all our blockers for the alpha release of F-16 for PowerPC, got all packages properly signed and synced to the mirrors !
So, if anyone has a PowerMac or an IBM PowerPC that is catching dust because you don't know what to do with it, now is your chance to get the latest Fedora version on it and help out with testing.

You can grab the DVD or netboot images from one of the mirrors for F-16 Alpha for PPC (32bit) or for PPC64 (64bit). PPC64 is our main platform that we develop and test our packages and installer on, 32bit installs are unfortunately completely untested as we don't have the necessary hardware for that.

Report any issues that you find during testing in bugzilla, but please make sure that you set the architecture to 'powerpc' so that we can find your report.

PPC secondary arch progress

Automatic rebuilds with koji-shadow have started, so I'd expect that the number of older packages continues to drop even more in the next few days:

Martin Gracik has almost completed his work on PPC support for lorax, that's our tool to populate the new unified ramdisk.
This means that we can start looking into boot and install issues now.

PPC secondary arch progress

Steady progress, 2126 packages older than the latest package with the same name on primary arch dist-f15, 7543 have the same N-V-R, 250 are newer than its counterpart (sometimes we have to use packages from dist-f15-updates-candidate).

'Older' means the latest RPM of a package is older on PPC then on the primary archs.
'Same' and 'newer' are for the reader to figure out.
'total_missing' is calculated like this: primary arch has the RPMs foo-1.0-1.fc15, foo-1.0-2.fc15 and foo-1.0-3.fc15, PPC has only foo-1.0-1.fc15, so that's 2 missing builds. And when foo-1.0-3.fc15 is built on PPC, the missing_builds counter goes to zero, it's the worst case number

PPC secondary arch progress

6860 packages done, 2800 more required to catch up with the primary archs:

'Older' means the latest RPM of a package is older on PPC then on the primary archs.
'Same' and 'newer' are for the reader to figure out.
'total_missing' seems to be calculated like this: primary arch has the RPMs foo-1.0-1.fc15, foo-1.0-2.fc15 and foo-1.0-3.fc15, PPC has only foo-1.0-3.fc15, so that's 2 missing builds.