GeekSocket Plug in and be Geekified

Creating pull request on

I use torbrowser-launcher to install and run Tor Browser on my machine. Since last few months, I noticed that the logo of ‘Tor Browser’ entry in my applications list is still the old one. So I decided to dig into it and figure out the root cause.

Old logo of Tor Browser

After tinkering for few minutes, I found that the desktop entry for ‘Tor Browser’ is actually torbrowser-launcher. It launches the browser for us. The icon comes from the launcher and not from Tor Browser installation.

$ cat /usr/share/applications/torbrowser.desktop 
[Desktop Entry]
Name=Tor Browser
GenericName=Tor browser
Comment=Launch Tor Browser
Exec=torbrowser-launcher %u
StartupWMClass=Tor Browser

While going through the source code over GitHub, it showed that the icon file is already updated according to new logo of Tor Browser. And a new version was also released after that commit. According to package installed, the version I had was torbrowser-launcher-0.3.2-7.fc30.noarch. But starting torbrowser-launcher from terminal it was reporting 0.3.1

$ torbrowser-launcher
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.1
Launching Tor Browser.

Now, the next place to check was the spec file of the rpm on, from which the package is build.

What is (src.fp.o) is the place where most of the packages from official repository have their build scripts stored, also called as package sources. It’s an instance of Pagure.

In a .spec file, macros are called, from which the packages are build and rpm files are generated. It includes steps like downloading source tarball, installing build time dependencies (packages which are required to build our target software), building the actual binary/package etc.

The commit hash mentioned in torbrowser-launcher.spec was still pointing to an old release of torbrowser-launcher.

As this was an easy fix, I decided to make the change and create a Pull Request (PR). After forking the repository to my account, I realized that I forgot the correct procedure to clone the repository and push the changes. Last year, I contributed to few container images and those Dockerfiles are also stored on src.fp.o. I should have written a blog post at that time ;)

Forking the repository

Once you login with your FAS account, any repository can be forked to your account. Earlier not everyone used to have access to make changes to the package sources (pkgs.fp.o). Now with src.fp.o being hosted as a Pagure instance, anyone can fork existing repositories and contribute by creating a PR. For me it created the fork at

More details about this - Infrastructure/HTTPS-commits: Background

Cloning the repository

In order to clone your fork, you need to install the package ‘fedpkg’. sudo dnf install fedpkg should install it for you. The clone needs to be happen as anonymous clone i.e. without any login. Any fork can be cloned with,

$ fedpkg clone -a forks/bhavin192/rpms/torbrowser-launcher

This will clone the git repository correctly and set required authentication methods for you. Make sure the format is correct forks/<username>/rpms/<package_name>.

Cloning the forked repository

Once you are done with the changes, make sure you also add changelog entry in the spec file. Normal git commit and git push origin <branch_name> should work. This will open a browser window and ask you to login with your FAS account. More details about this can be found at Infrastructure/HTTPS-commits: How it works

A Note about SSH access

The ssh access is available only to the people who are a part of packager group. They are planning to remove ssh cloning ability and completely switch to HTTPS cloning for everyone. Detailed discussion about this can be found in Issue #6361.

After doing the changes and pushing them, I created a PR for torbrowser-launcher.

What’s next?

Once the package maintainer pushes the new build to buildsystem (Koji) using fedpkg build command, it will build the rpms for various Fedora versions and CPU architectures.

After successful build, they will submit an update on Fedora Updates System (Bodhi). It’s possible to do that with fedpkg update as well. Bodhi has karma system, using which testers give feedback if the update works or not. Based on criteria of minimum +3 karma, the update will become available to everyone.

You can read more about this process in Using the Koji build system and Bodhi.


Thanks to Vishal, who helped me to understand the workflow of updates.

If you find any mistake in this blog post please comment or directly reach out to me on bhavin192 [at]


Comments are not enabled on this site. The old comments might still be displayed. You can reply on one of the platforms listed in β€˜Posted on’ list, or email me.