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.
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
Terminal=false
Type=Application
Icon=torbrowser
Categories=Network;WebBrowser;
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
https://github.com/micahflee/torbrowser-launcher
Launching Tor Browser.
Now, the next place to check was the spec file of the rpm on src.fedoraproject.org, from which the package is build.
What is src.fedoraproject.org?
src.fedoraproject.org (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 ;)
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 https://src.fedoraproject.org/fork/bhavin192/rpms/torbrowser-launcher
More details about this - Infrastructure/HTTPS-commits: Background
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>
.
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
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.
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] geeksocket.in.
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.