Posted on July 10, 2019 by — Leave a comment

Fedora job opening: Fedora Community Action and Impact Coordinator (FCAIC)

I’ve decided to move on from my role as the Fedora Community Action and Impact Coordinator (FCAIC). This was not an easy decision to make. I am proud of the work I have done in Fedora over the last three years and I think I have helped the community move past many challenges. I could NEVER have done all of this without the support and assistance of the community!

As some of you know, I have been covering for some other roles in Red Hat for almost the last year. Some of these tasks have led to some opportunities to take my career in a different direction. I am going to remain at Red Hat and on the same team with the same manager, but with a slightly expanded scope of duties. I will no longer be day-to-day on Fedora and will instead be in a consultative role as a Community Architect at Large. This is a fancy way of saying that I will be tackling helping lots of projects with various issues while also working on some specific strategic objectives.

I think this is a great opportunity for the Fedora community. The Fedora I became FCAIC in three years ago is a very different place from the Fedora of today. While I could easily continue to help shape and grow this community, I think that I can do more by letting some new ideas come in. The new person will hopefully be able to approach challenges differently. I’ll also be here to offer my advice and feedback as others who have moved on in the past have done. Additionally, I will work with Matthew Miller and Red Hat to help hire and onboard the new Fedora Community and Impact Coordinator. During this time I will continue as FCAIC.

This means that we are looking for a new FCAIC. Love Fedora? Want to work with Fedora full-time to help support and grow the Fedora community? This is the core of what the FCAIC does. The job description (also below), has a list of some of the primary job responsibilities and required skills – but that’s just a sample of the duties required, and the day to day life working full-time with the Fedora community.

Day to day work includes working with Mindshare, managing the Fedora Budget, and being part of many other teams, including the Fedora Council. You should be ready to write frequently about Fedora’s achievements, policies and decisions, and to draft and generate ideas and strategies. And, of course, planning Flock and Fedora’s presence at other events. It’s hard work, but also a great deal of fun.

Are you good at setting long-term priorities and hacking away at problems with the big picture in mind? Do you enjoy working with people all around the world, with a variety of skills and interests, to build not just a successful Linux distribution, but a healthy project? Can you set priorities, follow through, and know when to say “no” in order to focus on the most important tasks for success? Is Fedora’s mission deeply important to you?

If you said “yes” to those questions, you might be a great candidate for the FCAIC role. If you think you’re a great fit apply online, or contact Matthew Miller, Brian Exelbierd, or Stormy Peters.

Fedora Community Manager

Location: CZ-Remote – prefer Europe but can be North America

Company Description

At Red Hat, we connect an innovative community of customers, partners, and contributors to deliver an open source stack of trusted, high-performing solutions. We offer cloud, Linux, middleware, storage, and virtualization technologies, together with award-winning global customer support, consulting, and implementation services. Red Hat is a rapidly growing company supporting more than 90% of Fortune 500 companies.

Job summary

Red Hat’s Open Source Programs Office (OSPO) team is looking for the next Fedora Community Action and Impact Lead. In this role, you will join the Fedora Council and guide initiatives to grow the Fedora user and developer communities, as well as make Red Hat and Fedora interactions even more transparent and positive. The Council is responsible for stewardship of the Fedora Project as a whole, and supports the health and growth of the Fedora community.

As a the Fedora Community Action and Impact Lead, you’ll facilitate decision making on how to best focus the Fedora community budget to meet our collective objectives, work with other council members to identify the short, medium, and long-term goals of the Fedora community, and organize and enable the project.

You will also help make decisions about trademark use, project structure, community disputes or complaints, and other issues. You’ll hold a full council membership, not an auxiliary or advisory role.

Primary job responsibilities

Identify opportunities to engage new contributors and community members; align project around supporting those opportunities.
Improve on-boarding materials and processes for new contributors.
Participate in user and developer discussions and identify barriers to success for contributors and users.
Use metrics to evaluate the success of open source initiatives.
Regularly report on community metrics and developments, both internally and externally.
Represent Red Hat’s stake in the Fedora community’s success.
Work with internal stakeholders to understand their goals and develop strategies for working effectively with the community.
Improve onboarding materials and presentation of Fedora to new hires; develop standardized materials on Fedora that can be used globally at Red Hat.
Work with the Fedora Council to determine the annual Fedora budget.
Assist in planning and organizing Fedora’s flagship events each year.
Create and carry out community promotion strategies; create media content like blog posts, podcasts, and videos and facilitate the creation of media by other members of the community

Required skills

Extensive experience with the Fedora Project or a comparable open source community.
Exceptional writing and speaking skills
Experience with software development and open source developer communities; understanding of development processes.
Outstanding organizational skills; ability to prioritize tasks matching short and long-term goals and focus on the tasks of high priority
Ability to manage a project budget.
Ability to lead teams and participate in multiple cross-organizational teams that span the globe.
Experience motivating volunteers and staff across departments and companies

Red Hat is proud to be an equal opportunity workplace and an affirmative action employer. We review applications for employment without regard to their race, color, religion, sex, sexual orientation, gender identity, national origin, ancestry, citizenship, age, veteran status, genetic information, physical or mental disability, medical condition, marital status, or any other basis prohibited by law.

Red Hat does not seek or accept unsolicited resumes or CVs from recruitment agencies. We are not responsible for, and will not pay, any fees, commissions, or any other payment related to unsolicited resumes or CVs except as required in a written contract between Red Hat and the recruitment agency or party requesting payment of a fee.

Photo by Deva Williamson on Unsplash.

Posted on July 9, 2019 by — Leave a comment

Red Hat, IBM, and Fedora

Today marks a new day in the 26-year history of Red Hat. IBM has finalized its acquisition of Red Hat, which will operate as a distinct unit within IBM.

What does this mean for Red Hat’s participation in the Fedora Project?

In short, nothing.

Red Hat will continue to be a champion for open source, just as it always has, and valued projects like Fedora that will continue to play a role in driving innovation in open source technology. IBM is committed to Red Hat’s independence and role in open source software communities. We will continue this work and, as always, we will continue to help upstream projects be successful and contribute to welcoming new members and maintaining the project.

In Fedora, our mission, governance, and objectives remain the same. Red Hat associates will continue to contribute to the upstream in the same ways they have been.

We will do this together, with the community, as we always have.

If you have questions or would like to learn more about today’s news, I encourage you to review the materials below. For any questions not answered here, please feel free to contact us. Red Hat CTO Chris Wright will host an online Q&A session in the coming days where you can ask questions you may have about what the acquisition means for Red Hat and our involvement in open source communities. Details will be announced on the Red Hat blog.

Regards,

Matthew Miller, Fedora Project Leader
Brian Exelbierd, Fedora Community Action and Impact Coordinator

Posted on July 8, 2019 by — Leave a comment

Command line quick tips: Permissions

Fedora, like all Linux based systems, comes with a powerful set of security features. One of the basic features is permissions on files and folders. These permissions allow files and folders to be secured from unauthorized access. This article explains a bit about these permissions, and shows you how to share access to a folder using them.

Permission basics

Fedora is by nature a multi-user operating system. It also has groups, which users can be members of. But imagine for a moment a multi-user system with no concept of permissions. Different logged in users could read each other’s content at will. This isn’t very good for privacy or security, as you can imagine.

Any file or folder on Fedora has three sets of permissions assigned. The first set is for the user who owns the file or folder. The second is for the group that owns it. The third set is for everyone else who’s not the user who owns the file, or in the group that owns the file. Sometimes this is called the world.

What permissions mean

Each set of permissions comes in three flavors — read, write, and execute. Each of these has an initial that stands for the permission, thus r, w, and x.

File permissions

For files, here’s what these permissions mean:

Read (r): the file content can be read
Write (w): the file content can be changed
Execute (x): the file can be executed — this is used primarily for programs or scripts that are meant to be run directly

You can see the three sets of these permissions when you do a long listing of any file. Try this with the /etc/services file on your system:

$ ls -l /etc/services
-rw-r--r--. 1 root root 692241 Apr 9 03:47 /etc/services

Notice the groups of permissions at the left side of the listing. These are provided in three sets, as mentioned above — for the user who owns the file, for the group that owns the file, and for everyone else. The user owner is root and the group owner is the root group. The user owner has read and write access to the file. Anyone in the group root can only read the file. And finally, anyone else can also only read the file. (The dash at the far left shows this is a regular file.)

By the way, you’ll commonly find this set of permissions on many (but not all) system configuration files. They are only meant to be changed by the system administrator, not regular users. Often regular users need to read the content as well.

Folder (directory) permissions

For folders, the permissions have slightly different meaning:

Read (r): the folder contents can be read (such as the ls command)
Write (w): the folder contents can be changed (files can be created or erased in this folder)
Execute (x): the folder can be searched, although its contents cannot be read. (This may sound strange, but the explanation requires more complex details of file systems outside the scope of this article. So just roll with it for now.)

Take a look at the /etc/grub.d folder for example:

$ ls -ld /etc/grub.d
drwx------. 2 root root 4096 May 23 16:28 /etc/grub.d

Note the d at the far left. It shows this is a directory, or folder. The permissions show the user owner (root) can read, change, and cd into this folder. However, no one else can do so — whether they’re a member of the root group or not. Notice you can’t cd into the folder, either:

$ cd /etc/grub.d
bash: cd: /etc/grub.d: Permission denied

Notice how your own home directory is setup:

$ ls -ld $HOME
drwx------. 221 paul paul 28672 Jul 3 14:03 /home/paul

Now, notice how no one, other than you as the owner, can access anything in this folder. This is intentional! You wouldn’t want others to be able to read your private content on a shared system.

Making a shared folder

You can exploit this permissions capability to easily make a folder to share within a group. Imagine you have a group called finance with several members who need to share documents. Because these are user documents, it’s a good idea to store them within the /home folder hierarchy.

To get started, use sudo to make a folder for sharing, and set it to be owned by the finance group:

$ sudo mkdir -p /home/shared/finance
$ sudo chgrp finance /home/shared/finance

By default the new folder has these permissions. Notice how it can be read or searched by anyone, even if they can’t create or erase files in it:

drwxr-xr-x. 2 root root 4096 Jul 6 15:35 finance

That doesn’t seem like a good idea for financial data. Next, use the chmod command to change the mode (permissions) of the shared folder. Note the use of g to change the owning group’s permissions, and o to change other users’ permissions. Similarly, u would change the user owner’s permissions:

$ sudo chmod g+w,o-rx /home/shared/finance

The resulting permissions look better. Now, anyone in the finance group (or the user owner root) have total access to the folder and its contents:

drwxrwx---. 2 root root 4096 Jul 6 15:35 finance

If any other user tries to access the shared folder, they won’t be able to do so. Great! Now our finance group can put documents in a shared place.

Other notes

There are additional ways to manipulate these permissions. For example, you may want any files in this folder to be set as owned by the group finance. This requires additional settings not covered in this article, but stay tuned to the Magazine for more on that topic soon.

Posted on July 5, 2019 by — Leave a comment

Manage your shell environment

Some time ago, the Fedora Magazine has published an article introducing ZSH — an alternative shell to Fedora’s default, bash. This time, we’re going to look into customizing it to use it in a more effective way. All of the concepts shown in this article also work in other shells such as bash.

Alias

Aliases are shortcuts for commands. This is useful for creating short commands for actions that are performed often, but require a long command that would take too much time to type. The syntax is:

$ alias yourAlias='complex command with arguments'

They don’t always need to be used for shortening long commands. Important is that you use them for tasks that you do often. An example could be:

$ alias dnfUpgrade='dnf -y upgrade'

That way, to do a system upgrade, I just type dnfUpgrade instead of the whole dnf command.

The problem of setting aliases right in the console is that once the terminal session is closed, the alias would be lost. To set them permanently, resource files are used.

Resource Files

Resource files (or rc files) are configuration files that are loaded per user in the beginning of a session or a process (when a new terminal window is opened, or a new program like vim is started). In the case of ZSH, the resource file is .zshrc, and for bash it’s .bashrc.

To make the aliases permanent, you can either put them in your resource. You can edit your resource file with a text editor of your choice. This example uses vim:

$ vim $HOME/.zshrc

Or for bash:

$ vim $HOME/.bashrc

Note that the location of the resource file is specified relatively to a home directory — and that’s where ZSH (or bash) are going to look for the file by default for each user.

Other option is to put your configuration in any other file, and then source it:

$ source /path/to/your/rc/file

Again, sourcing it right in your session will only apply it to the session, so to make it permanent, add the source command to your resource file. The advantage of having your source file in a different location is that you can source it any time. Or anywhere which is especially useful in shared environments.

Environment Variables

Environment variables are values assigned to a specific name which can be then called in scripts and commands. They start with the $ dollar sign. One of the most common is $HOME that references the home directory.

As the name suggests, environment variables are a part of your environment. Set a variable using the following syntax:

$ http_proxy="http://your.proxy"

And to make it an environment variable, export it with the following command:

$ export $http_proxy

To see all the environment variables that are currently set, use the env command:

$ env

The command outputs all the variables available in your session. To demonstrate how to use them in a command, try running the following echo commands:

$ echo $PWD
/home/fedora
$ echo $USER
fedora

What happens here is variable expansion — the value stored in the variable is used in your command.

Another useful variable is $PATH, that defines directories that your shell uses to look for binaries.

The $PATH variable

There are many directories, or folders (the way they are called in graphical environments) that are important to the OS. Some directories are set to hold binaries you can use directly in your shell. And these directories are defined in the $PATH variable.

$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/usr/libexec/sdcc:/usr/libexec/sdcc:/usr/bin:/bin:/sbin:/usr/sbin:/opt/FortiClient

This will help you when you want to have your own binaries (or scripts) accessible in the shell.

Posted on July 2, 2019 by — Leave a comment

Jupyter and data science in Fedora

In the past, kings and leaders used oracles and magicians to help them predict the future — or at least get some good advice due to their supposed power to perceive hidden information. Nowadays, we live in a society obsessed with quantifying everything. So we have data scientists to do this job.

Data scientists use statistical models, numerical techniques and advanced algorithms that didn’t come from statistical disciplines, along with the data that exist on databases, to find, to infer, to predict data that doesn’t exist yet. Sometimes this data is about the future. That is why we do a lot of predictive analytics and prescriptive analytics.

Here are some questions to which data scientists help find answers:

Who are the students with high propensity to abandon the class? For each one, what are the reasons for leaving?
Which house has a price above or below the fair price? What is the fair price for a certain house?
What are the hidden groups that my clients classify themselves?
Which future problems this premature child will develop?
How many calls will I get in my call center tomorrow 11:43 AM?
My bank should or should not lend money to this customer?

Note how the answer to all these question is not sitting in any database waiting to be queried. These are all data that still doesn’t exist and has to be calculated. That is part of the job we data scientists do.

Throughout this article you’ll learn how to prepare a Fedora system as a Data Scientist’s development environment and also a production system. Most of the basic software is RPM-packaged, but the most advanced parts can only be installed, nowadays, with Python’s pip tool.

Jupyter — the IDE

Most modern data scientists use Python. And an important part of their work is EDA (exploratory data analysis). EDA is a manual and interactive process that retrieves data, explores its features, searches for correlations, and uses plotted graphics to visualize and understand how data is shaped and prototypes predictive models.

Jupyter is a web application perfect for this task. Jupyter works with Notebooks, documents that mix rich text including beautifully rendered math formulas (thanks to mathjax), blocks of code and code output, including graphics.

Notebook files have extension .ipynb, which means Interactive Python Notebook.

Setting up and running Jupyter

First, install essential packages for Jupyter (using sudo):

$ sudo dnf install python3-notebook mathjax sscg

You might want to install additional and optional Python modules commonly used by data scientists:

$ sudo dnf install python3-seaborn python3-lxml python3-basemap python3-scikit-image python3-scikit-learn python3-sympy python3-dask+dataframe python3-nltk

Set a password to log into Notebook web interface and avoid those long tokens. Run the following command anywhere on your terminal:

$ mkdir -p $HOME/.jupyter
$ jupyter notebook password

Now, type a password for yourself. This will create the file $HOME/.jupyter/jupyter_notebook_config.json with your encrypted password.

Next, prepare for SSLby generating a self-signed HTTPS certificate for Jupyter’s web server:

$ cd $HOME/.jupyter; sscg

Finish configuring Jupyter by editing your $HOME/.jupyter/jupyter_notebook_config.json file. Make it look like this:

{
 "NotebookApp": {
 "password": "sha1:abf58...87b",
 "ip": "*",
 "allow_origin": "*",
 "allow_remote_access": true,
 "open_browser": false,
 "websocket_compression_options": {},
 "certfile": "/home/aviram/.jupyter/service.pem",
 "keyfile": "/home/aviram/.jupyter/service-key.pem",
 "notebook_dir": "/home/aviram/Notebooks"
 }
}

The parts in red must be changed to match your folders. Parts in blue were already there after you created your password. Parts in green are the crypto-related files generated by sscg.

Create a folder for your notebook files, as configured in the notebook_dir setting above:

$ mkdir $HOME/Notebooks

Now you are all set. Just run Jupyter Notebook from anywhere on your system by typing:

$ jupyter notebook

Or add this line to your $HOME/.bashrc file to create a shortcut command called jn:

alias jn='jupyter notebook'

After running the command jn, access https://your-fedora-host.com:8888 from any browser on the network to see the Jupyter user interface. You’ll need to use the password you set up earlier. Start typing some Python code and markup text. This is how it looks:

In addition to the IPython environment, you’ll also get a web-based Unix terminal provided by terminado. Some people might find this useful, while others find this insecure. You can disable this feature in the config file.

JupyterLab — the next generation of Jupyter

JupyterLab is the next generation of Jupyter, with a better interface and more control over your workspace. It’s currently not RPM-packaged for Fedora at the time of writing, but you can use pip to get it installed easily:

$ pip3 install jupyterlab --user
$ jupyter serverextension enable --py jupyterlab

Then run your regular jupiter notebook command or jn alias. JupyterLab will be accessible from http://your-linux-host.com:8888/lab.

Tools used by data scientists

In this section you can get to know some of these tools, and how to install them. Unless noted otherwise, the module is already packaged for Fedora and was installed as prerequisites for previous components.

Numpy

Numpy is an advanced and C-optimized math library designed to work with large in-memory datasets. It provides advanced multidimensional matrix support and operations, including math functions as log(), exp(), trigonometry etc.

Pandas

In this author’s opinion, Python is THE platform for data science mostly because of Pandas. Built on top of numpy, Pandas makes easy the work of preparing and displaying data. You can think of it as a no-UI spreadsheet, but ready to work with much larger datasets. Pandas helps with data retrieval from a SQL database, CSV or other types of files, columns and rows manipulation, data filtering and, to some extent, data visualization with matplotlib.

Matplotlib

Matplotlib is a library to plot 2D and 3D data. It has great support for notations in graphics, labels and overlays

Seaborn

Built on top of matplotlib, Seaborn’s graphics are optimized for a more statistical comprehension of data. It automatically displays regression lines or Gauss curve approximations of plotted data.

StatsModels

StatsModels provides algorithms for statistical and econometrics data analysis such as linear and logistic regressions. Statsmodel is also home for the classical family of time series algorithms known as ARIMA.

Normalized number of passengers across time (blue) and ARIMA-predicted number of passengers (red)

Scikit-learn

The central piece of the machine-learning ecosystem, scikit provides predictor algorithms for regression (Elasticnet, Gradient Boosting, Random Forest etc) and classification and clustering (K-means, DBSCAN etc). It features a very well designed API. Scikit also has classes for advanced data manipulation, dataset split into train and test parts, dimensionality reduction and data pipeline preparation.

XGBoost

XGBoost is the most advanced regressor and classifier used nowadays. It’s not part of scikit-learn, but it adheres to scikit’s API. XGBoost is not packaged for Fedora and should be installed with pip. XGBoost can be accelerated with your nVidia GPU, but not through its pip package. You can get this if you compile it yourself against CUDA. Get it with:

$ pip3 install xgboost --user

Imbalanced Learn

imbalanced-learn provides ways for under-sampling and over-sampling data. It is useful in fraud detection scenarios where known fraud data is very small when compared to non-fraud data. In these cases data augmentation is needed for the known fraud data, to make it more relevant to train predictors. Install it with pip:

$ pip3 install imblearn --user

NLTK

The Natural Language toolkit, or NLTK, helps you work with human language data for the purpose of building chatbots (just to cite an example).

SHAP

Machine learning algorithms are very good on predicting, but aren’t good at explaining why they made a prediction. SHAP solves that, by analyzing trained models.

Install it with pip:

$ pip3 install shap --user

Keras

Keras is a library for deep learning and neural networks. Install it with pip:

$ sudo dnf instal python3-h5py
$ pip3 install keras --user

TensorFlow

TensorFlow is a popular neural networks builder. Install it with pip:

$ pip3 install tensorflow --user

Photo courtesy of FolsomNatural on Flickr (CC BY-SA 2.0).

Posted on June 28, 2019 by — Leave a comment

Upcoming features in Fedora 31 Workstation

The Fedora Workstation edition is a fabulous operating system that includes everything a developer needs. But it’s also a perfect solution for anyone who wants to be productive online with their desktop or laptop computer. It features a sleek interface and an enormous catalog of ready-to-install software. Recently, Christian Schaller shared information about what’s coming in the Workstation for Fedora 31.

Fedora 31 is currently scheduled for release in late October 2019. With it, as usual, will come an assortment of new and refreshed free and open source software. This includes the GNOME desktop which is planned to be updated to the latest 3.34.

Under the hood of the desktop, many intrepid open source developers have been toiling away. They’ve been working on things like:

The Wayland desktop compositor
Working with NVidia to provide better driver support
PipeWire, for better audio and video handling
Expanded Flatpak support and features
A container toolbox
…and much more!

Long-time and keen readers of the Magazine probably know that Christian is deeply involved in the Workstation effort. He heads up the desktop engineering groups at Red Hat. But he’s also involved heavily in the community Workstation Working Group, which guides these efforts as well. As an experienced developer himself, he brings his expertise to the open source community every day to build a better desktop.

For all the details, check out Christian’s detailed and informative blog post on Fedora 31 Workstation. And stay tuned to the Magazine for more about the upcoming release in the next few months!

Posted on June 27, 2019 by — Leave a comment

RPM packages explained

Perhaps the best known way the Fedora community pursues its mission of promoting free and open source software and content is by developing the Fedora software distribution. So it’s not a surprise at all that a very large proportion of our community resources are spent on this task. This post summarizes how this software is “packaged” and the underlying tools such as rpm that make it all possible.

RPM: the smallest unit of software

The editions and flavors (spins/labs/silverblue) that users get to choose from are all very similar. They’re all composed of various software that is mixed and matched to work well together. What differs between them is the exact list of tools that goes into each. That choice depends on the use case that they target. The basic unit of all of these is an RPM package file.

RPM files are archives that are similar to ZIP files or tarballs. In fact, they uses compression to reduce the size of the archive. However, along with files, RPM archives also contain metadata about the package. This can be queried using the rpm tool:

 $ rpm -q fpaste

fpaste-0.3.9.2-2.fc30.noarch



$ rpm -qi fpaste

Name        : fpaste

Version     : 0.3.9.2

Release     : 2.fc30

Architecture: noarch

Install Date: Tue 26 Mar 2019 08:49:10 GMT

Group       : Unspecified

Size        : 64144

License     : GPLv3+

Signature   : RSA/SHA256, Thu 07 Feb 2019 15:46:11 GMT, Key ID ef3c111fcfc659b9

Source RPM  : fpaste-0.3.9.2-2.fc30.src.rpm

Build Date  : Thu 31 Jan 2019 20:06:01 GMT

Build Host  : buildhw-07.phx2.fedoraproject.org

Relocations : (not relocatable)

Packager    : Fedora Project

Vendor      : Fedora Project

URL         : https://pagure.io/fpaste

Bug URL     : https://bugz.fedoraproject.org/fpaste

Summary     : A simple tool for pasting info onto sticky notes instances

Description :

It is often useful to be able to easily paste text to the Fedora

Pastebin at http://paste.fedoraproject.org and this simple script

will do that and return the resulting URL so that people may

examine the output. This can hopefully help folks who are for

some reason stuck without X, working remotely, or any other

reason they may be unable to paste something into the pastebin



$ rpm -ql fpaste

/usr/bin/fpaste

/usr/share/doc/fpaste

/usr/share/doc/fpaste/README.rst

/usr/share/doc/fpaste/TODO

/usr/share/licenses/fpaste

/usr/share/licenses/fpaste/COPYING

/usr/share/man/man1/fpaste.1.gz

When an RPM package is installed, the rpm tools know exactly what files were added to the system. So, removing a package also removes these files, and leaves the system in a consistent state. This is why installing software using rpm is preferred over installing software from source whenever possible.

Dependencies

Nowadays, it is quite rare for software to be completely self-contained. Even fpaste, a simple one file Python script, requires that the Python interpreter be installed. So, if the system does not have Python installed (highly unlikely, but possible), fpaste cannot be used. In packager jargon, we say that “Python is a run-time dependency of fpaste“.

When RPM packages are built (the process of building RPMs is not discussed in this post), the generated archive includes all of this metadata. That way, the tools interacting with the RPM package archive know what else must must be installed so that fpaste works correctly:

 $ rpm -q --requires fpaste

/usr/bin/python3

python3

rpmlib(CompressedFileNames) &lt;= 3.0.4-1

rpmlib(FileDigests) &lt;= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) &lt;= 4.0-1

rpmlib(PayloadIsXz) &lt;= 5.2-1



$ rpm -q --provides fpaste

fpaste = 0.3.9.2-2.fc30



$ rpm -qi python3

Name        : python3

Version     : 3.7.3

Release     : 3.fc30

Architecture: x86_64

Install Date: Thu 16 May 2019 18:51:41 BST

Group       : Unspecified

Size        : 46139

License     : Python

Signature   : RSA/SHA256, Sat 11 May 2019 17:02:44 BST, Key ID ef3c111fcfc659b9

Source RPM  : python3-3.7.3-3.fc30.src.rpm

Build Date  : Sat 11 May 2019 01:47:35 BST

Build Host  : buildhw-05.phx2.fedoraproject.org

Relocations : (not relocatable)

Packager    : Fedora Project

Vendor      : Fedora Project

URL         : https://www.python.org/

Bug URL     : https://bugz.fedoraproject.org/python3

Summary     : Interpreter of the Python programming language

Description :

Python is an accessible, high-level, dynamically typed, interpreted programming

language, designed with an emphasis on code readability.

It includes an extensive standard library, and has a vast ecosystem of

third-party libraries.



The python3 package provides the "python3" executable: the reference

interpreter for the Python language, version 3.

The majority of its standard library is provided in the python3-libs package,

which should be installed automatically along with python3.

The remaining parts of the Python standard library are broken out into the

python3-tkinter and python3-test packages, which may need to be installed

separately.



Documentation for Python is provided in the python3-docs package.



Packages containing additional libraries for Python are generally named with

the "python3-" prefix.



$ rpm -q --provides python3

python(abi) = 3.7

python3 = 3.7.3-3.fc30

python3(x86-64) = 3.7.3-3.fc30

python3.7 = 3.7.3-3.fc30

python37 = 3.7.3-3.fc30

Resolving RPM dependencies

While rpm knows the required dependencies for each archive, it does not know where to find them. This is by design: rpm only works on local files and must be told exactly where they are. So, if you try to install a single RPM package, you get an error if rpm cannot find the package’s run-time dependencies. This example tries to install a package downloaded from the Fedora package set:

 $ ls

python3-elephant-0.6.2-3.fc30.noarch.rpm



$ rpm -qpi python3-elephant-0.6.2-3.fc30.noarch.rpm

Name        : python3-elephant

Version     : 0.6.2

Release     : 3.fc30

Architecture: noarch

Install Date: (not installed)

Group       : Unspecified

Size        : 2574456

License     : BSD

Signature   : (none)

Source RPM  : python-elephant-0.6.2-3.fc30.src.rpm

Build Date  : Fri 14 Jun 2019 17:23:48 BST

Build Host  : buildhw-02.phx2.fedoraproject.org

Relocations : (not relocatable)

Packager    : Fedora Project

Vendor      : Fedora Project

URL         : http://neuralensemble.org/elephant

Bug URL     : https://bugz.fedoraproject.org/python-elephant

Summary     : Elephant is a package for analysis of electrophysiology data in Python

Description :

Elephant - Electrophysiology Analysis Toolkit Elephant is a package for the

analysis of neurophysiology data, based on Neo.



$ rpm -qp --requires python3-elephant-0.6.2-3.fc30.noarch.rpm

python(abi) = 3.7

python3.7dist(neo) >= 0.7.1

python3.7dist(numpy) >= 1.8.2

python3.7dist(quantities) >= 0.10.1

python3.7dist(scipy) >= 0.14.0

python3.7dist(six) >= 1.10.0

rpmlib(CompressedFileNames) &lt;= 3.0.4-1

rpmlib(FileDigests) &lt;= 4.6.0-1

rpmlib(PartialHardlinkSets) &lt;= 4.0.4-1

rpmlib(PayloadFilesHavePrefix) &lt;= 4.0-1

rpmlib(PayloadIsXz) &lt;= 5.2-1



$ sudo rpm -i ./python3-elephant-0.6.2-3.fc30.noarch.rpm

error: Failed dependencies:

        python3.7dist(neo) >= 0.7.1 is needed by python3-elephant-0.6.2-3.fc30.noarch

        python3.7dist(quantities) >= 0.10.1 is needed by python3-elephant-0.6.2-3.fc30.noarch

In theory, one could download all the packages that are required for python3-elephant, and tell rpm where they all are, but that isn’t convenient. What if python3-neo and python3-quantities have other run-time requirements and so on? Very quickly, the dependency chain can get quite complicated.

Repositories

Luckily, dnf and friends exist to help with this issue. Unlike rpm, dnf is aware of repositories. Repositories are collections of packages, with metadata that tells dnf what these repositories contain. All Fedora systems come with the default Fedora repositories enabled by default:

 $ sudo dnf repolist

repo id              repo name                             status

fedora               Fedora 30 - x86_64                    56,582

fedora-modular       Fedora Modular 30 - x86_64               135

updates              Fedora 30 - x86_64 - Updates           8,573

updates-modular      Fedora Modular 30 - x86_64 - Updates     138

updates-testing      Fedora 30 - x86_64 - Test Updates      8,458

There’s more information on these repositories, and how they can be managed on the Fedora quick docs.

dnf can be used to query repositories for information on the packages they contain. It can also search them for software, or install/uninstall/upgrade packages from them:

 $ sudo dnf search elephant

Last metadata expiration check: 0:05:21 ago on Sun 23 Jun 2019 14:33:38 BST.

============================================================================== Name &amp; Summary Matched: elephant ==============================================================================

python3-elephant.noarch : Elephant is a package for analysis of electrophysiology data in Python

python3-elephant.noarch : Elephant is a package for analysis of electrophysiology data in Python



$ sudo dnf list \*elephant\*

Last metadata expiration check: 0:05:26 ago on Sun 23 Jun 2019 14:33:38 BST.

Available Packages

python3-elephant.noarch      0.6.2-3.fc30      updates-testing

python3-elephant.noarch      0.6.2-3.fc30              updates

Installing dependencies

When installing the package using dnf now, it resolves all the required dependencies, then calls rpm to carry out the transaction:

 $ sudo dnf install python3-elephant

Last metadata expiration check: 0:06:17 ago on Sun 23 Jun 2019 14:33:38 BST.

Dependencies resolved.

==============================================================================================================================================================================================

 Package                                      Architecture                     Version                                                        Repository                                 Size

==============================================================================================================================================================================================

Installing:

 python3-elephant                             noarch                           0.6.2-3.fc30                                                   updates-testing                           456 k

Installing dependencies:

 python3-neo                                  noarch                           0.8.0-0.1.20190215git49b6041.fc30                              fedora                                    753 k

 python3-quantities                           noarch                           0.12.2-4.fc30                                                  fedora                                    163 k

Installing weak dependencies:

 python3-igor                                 noarch                           0.3-5.20150408git2c2a79d.fc30                                  fedora                                     63 k



Transaction Summary

==============================================================================================================================================================================================

Install  4 Packages



Total download size: 1.4 M

Installed size: 7.0 M

Is this ok [y/N]: y

Downloading Packages:

(1/4): python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch.rpm                                                                                                  222 kB/s |  63 kB     00:00

(2/4): python3-elephant-0.6.2-3.fc30.noarch.rpm                                                                                                               681 kB/s | 456 kB     00:00

(3/4): python3-quantities-0.12.2-4.fc30.noarch.rpm                                                                                                            421 kB/s | 163 kB     00:00

(4/4): python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch.rpm                                                                                               840 kB/s | 753 kB     00:00

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Total                                                                                                                                                         884 kB/s | 1.4 MB     00:01

Running transaction check

Transaction check succeeded.

Running transaction test

Transaction test succeeded.

Running transaction

  Preparing        :                                                                                                                                                                      1/1

  Installing       : python3-quantities-0.12.2-4.fc30.noarch                                                                                                                              1/4

  Installing       : python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch                                                                                                                    2/4

  Installing       : python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch                                                                                                                 3/4

  Installing       : python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 4/4

  Running scriptlet: python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 4/4

  Verifying        : python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 1/4

  Verifying        : python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch                                                                                                                    2/4

  Verifying        : python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch                                                                                                                 3/4

  Verifying        : python3-quantities-0.12.2-4.fc30.noarch                                                                                                                              4/4



Installed:

  python3-elephant-0.6.2-3.fc30.noarch   python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch   python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch   python3-quantities-0.12.2-4.fc30.noarch



Complete!

Notice how dnf even installed python3-igor, which isn’t a direct dependency of python3-elephant.

DnfDragora: a graphical interface to DNF

While technical users may find dnf straightforward to use, it isn’t for everyone. Dnfdragora addresses this issue by providing a graphical front end to dnf.

dnfdragora (version 1.1.1-2 on Fedora 30) listing all the packages installed on a system.

From a quick look, dnfdragora appears to provide all of dnf‘s main functions.

There are other tools in Fedora that also manage packages. GNOME Software, and Discover are two examples. GNOME Software is focused on graphical applications only. You can’t use the graphical front end to install command line or terminal tools such as htop or weechat. However, GNOME Software does support the installation of Flatpaks and Snap applications which dnf does not. So, they are different tools with different target audiences, and so provide different functions.

This post only touches the tip of the iceberg that is the life cycle of software in Fedora. This article explained what RPM packages are, and the main differences between using rpm and using dnf.

In future posts, we’ll speak more about:

The processes that are needed to create these packages
How the community tests them to ensure that they are built correctly
The infrastructure that the community uses to get them to community users in future posts.

Posted on June 24, 2019 by — Leave a comment

Using i3 with multiple monitors

Are you using multiple monitors with your Linux workstation? Seeing many things at once might be beneficial. But there are often much more windows in our workflows than physical monitors — and that’s a good thing, because seeing too many things at once might be distracting. So being able to switch what we see on individual monitors seems crucial.

Let’s talk about i3 — a popular tiling window manager that works great with multiple monitors. And there is one handy feature that many other window managers don’t have — the ability to switch workspaces on individual monitors independently.

Quick introduction to i3

The Fedora Magazine has already covered i3 about three years ago. And it was one of the most popular articles ever published! Even though that’s not always the case, i3 is pretty stable and that article is still very accurate today. So — not to repeat ourselves too much — this article only covers the very minimum to get i3 up and running, and you’re welcome to go ahead and read it if you’re new to i3 and want to learn more about the basics.

To install i3 on your system, run the following command:

$ sudo dnf install i3

When that’s done, log out, and on the log in screen choose i3 as your window manager and log back in again.

When you run i3 for the first time, you’ll be asked if you wish to proceed with automatic configuration — answer yes here. After that, you’ll be asked to choose a “mod key”. If you’re not sure here, just accept the default which sets you Windows/Super key as the mod key. You’ll use this key for mostly all the shortcuts within the window manager.

At this point, you should see a little bar at the bottom and an empty screen. Let’s have a look at some of the basic shortcuts.

Open a terminal using:

$mod + enter

Switch to a second workspace using:

$mod + 2

Open firefox in two steps, first by:

$mod + d

… and then by typing “firefox” and pressing enter.

Move it to the first workspace by:

$mod + shift + 1

… and switch to the first workspace by:

$mod + 1

At this point, you’ll see a terminal and a firefox window side by side. To close a window, press:

$mod + shift + q

There are more shortcuts, but these should give you the minimum to get started with i3.

Ah! And to exit i3 (to log out) press:

$mod + shift + e

… and then confirm using your mouse at the top-right corner.

Getting multiple screens to work

Now that we have i3 up and running, let’s put all those screens to work!

To do that, we’ll need to use the command line as i3 is very lightweight and doesn’t have gui to manage additional screens. But don’t worry if that sounds difficult — it’s actually quite starighforward!

The command we’ll use is called xrandr. If you don’t have xrandr on your system, install it by running:

$ sudo dnf install xrandr

When that’s installed, let’s just go ahead and run it:

$ xrandr

The output lists all the available outputs, and also indicated which have a screen attached to them (a monitor connedted with a cable) by showing supported resolutions. Good news is that we don’t need to really care about the specific resolutions to make the them work.

This specific example shows a primary screen of a laptop (named eDP1), and a second monitor connected to the HDMI-2 output, physically positionned right of the laptop. To turn it on, run the following command:

$ xrandr --output HDMI-2 --auto --right-of eDP1

And that’s it! Your screen is now active.

Second screen active. The commands shown on this screenshot are slightly different than in the article, as they set a smaller resolution to make the screenshots more readable.

Managing workspaces on multiple screens

Switching workspaces and creating new ones on multiple screens is very similar to having just one screen. New workspaces get created on the screen that’s currently active — the one that has your mouse cursor on it.

So, to switch to a specific workspace (or to create a new one in case it doesn’t exist), press:

$mod + NUMBER

And you can switch workspaces on individual monitors independently!

Workspace 2 on the left screen, workspace 4 on the right screen.

Left screen switched to workspace 3, right screen still showing workspace 4.

Right screen switched to workspace 4, left screen still showing workspace 3.

Moving workspaces between monitors

The same way we can move windows to differnet workspaces by the following command:

$mod + shift + NUMBER

… we can move workspaces to different screens as well. However, there is no default shortcut for this action — so we have to create it first.

To create a custom shortcut, you’ll need to open the configuration file in a text editor of your choice (this article uses vim):

$ vim ~/.config/i3/config

And add the following lines to the very bottom of the configuration file:

# Moving workspaces between screens 
bindsym $mod+p move workspace to output right

Save, close, and to reload and apply the configuration, press:

$mod + shift + r

Now you’ll be able to move your active workspace to the second monitor by:

$mod + p

Workspace 2 with Firefox on the left screen

Workspace 2 with Firefox moved to the second screen

And that’s it! Enjoy your new multi-monitor experience, and to learn more about i3, you’re welcome to read the previous article about i3 on the Fedora Magazine, or consult the official i3 documentation.

Posted on June 21, 2019 by — Leave a comment

Making Fedora 30

What does it take to make a Linux distribution like Fedora 30? As you might expect, it’s not a simple process.

Changes in Fedora 30

Although Fedora 29 released on October 30, 2018, work on Fedora 30 began long before that. The first change proposal was submitted in late August. By my count, contributors made nine separate change proposals for Fedora 30 before Fedora 29 shipped.

Some of these proposals come early because they have a big impact, like mass removal of Python 2 packages. By the time the proposal deadline arrived in early January, the community had submitted 50 change proposals.

Of course, not all change proposals make it into the shipped release. Some of them are more focused on how we build the release instead of what we release. Others don’t get done in time. System-wide changes must have a contingency plan. These changes are generally evaluated at one of three points in the schedule: when packages branch from Rawhide, at the beginning of the Beta freeze, and at the beginning of the Final freeze. For Fedora 30, 45 Change proposals were still active for the release.

Fedora has a calendar-based release schedule, but that doesn’t mean we ship whatever exists on a given date. We have a set of release criteria that we test against, and we don’t put out a release until all the blockers are resolved. This sometimes means a release is delayed, but it’s important that we ship reliable software.

For the Fedora 30 development cycle, we accepted 22 proposed blocker bugs and rejected 6. We also granted 33 freeze exceptions — bugs that can be fixed during the freeze because they impact the released artifacts or are otherwise important enough to include in the release.

Other contributions

Of course, there’s more to making a release than writing or packaging the code, testing it, and building the images. As with every release, the Fedora Design team created a new desktop background along with several supplemental wallpapers. The Fedora Marketing team wrote release announcements and put together talking points for the Ambassadors and Advocates to use when talking to the broader community.

If you’ve looked at our new website, that was the work of the Websites team in preparation for the Fedora 30 release:

The Documentation Team wrote Release Notes and updated other documentation. Translators provided translations to dozens of languages.

Many other people made contributions to the release of Fedora 30 in some way. It’s not easy to count everyone who has a hand in producing a Linux distribution, but we appreciate every one of our contributors. If you would like to join the Fedora Community but aren’t sure where to start, check out What Can I Do For Fedora?

Photo by Robin Sommer on Unsplash.

Posted on June 20, 2019 by — Leave a comment

Critical Firefox vulnerability fixed in 67.0.3

On Friday, Mozilla issued a security advisory for Firefox, the default web browser in Fedora. This advisory concerns a CVE for a vulnerability based on type confusion that can happen when JavaScript objects are being manipulated. It can be used to crash your browser. There are apparently already attacks in the wild that exploit the issue. Read on for more information, and how to protect your system against this flaw.

At the same time the security vulnerability was issued, Mozilla also released Firefox 67.0.3 (and ESR 60.7.1) to fix the issue.

Updating Firefox in Fedora

Firefox 67.0.3 (with the security fixes) has already been pushed to the stable Fedora repositories. The security fix will be applied to your system with your next update. You can also update the firefox package only by running the following command:

$ sudo dnf update firefox

This command requires you to have sudo setup. Note that not every Fedora mirrors syncs at the same rate. Community sites graciously donate space and bandwidth these mirrors to carry Fedora content. You may need to try again later if your selected mirror is still awaiting the latest update.