How to completely remove a package from a build farm's status page?

Buildfarm
1

I’ve set up a private build farm that we’re using to build our packages, and so far everything’s working well. It’s configured to point at and load packages from an internal, private GitLab server that we use, and I’ve been able to bloom >130 of our packages that it has successfully built and pushed to our apt repository.

We’ve got an internal clone of rosdistro, where we’ve modified the index.yaml file to add a seconds distribution.yaml file to the indigo and kinetic distributions (the only ones we support), and those distribution files have a “swri” tag in them; then, in all of the build.yaml files in our ros_buildfarm_config repository, we have a tag_whitelist that contains “swri”. So far, so good; our build farm only builds packages that we add to our custom distribution.yaml file and not ones that get merged in to the main distribution.yaml file when we update from the main rosdistro repo.

There’s one problem: When I first set up the build farm, there was a brief period where I had not added the tag_whitelist yet, and there was an update to the “tornado” package and our build farm decided to build it. It’s not building any more now that the whitelist is in place, and I’ve manually gone through the filesystem on the master, slave, and repo computers and removed every file I can find referencing “tornado”, but somehow when the indigo_default.html page gets generated on the repo server, and it says that ros-indigo-tornado 4.2.1-1 exists in the “building” repository for Tsource.

Why is that entry still being added, and how can I remove it?

Thanks in advance!

–
P. J. Reed, Senior Research Analyst
(210) 522-6948
Intelligent Vehicle Systems (http://ivs.swri.org)
Applied Sensing Department (http://appliedsensing.swri.org)
Southwest Research Institute (http://www.swri.org)

2

The status page shows the content of your apt repository. While obsolete binary packages are being removed in a sync that is not the case for source debs. You will have to remove the source deb from the apt repo manually.

3

That’s what I had thought, but as far as I can tell I do not have any reference to it in my repo at all:

$ ssh uss-repo
preed@uss-repo:~$ sudo -i -u jenkins-slave
$ cd /var/repos/ubuntu
$ find . -iname "*tornado*"
$

Is there some location where it’s still referenced outside of the repository?

4

Can you attach a screenshot of the status page (e.g. with a search string “tornado” to hide your package names). That should show where the package is being found.

5

Sure:

In addition, running sudo updatedb && sudo locate 4.2.1 on the repo, slave, and master machines all return no relevant results. (aside from a Jenkins jar file on the master with 4.2.1 in it)

6

You should find a tornado entry in the index of source packages then (in your apt repo under ubuntu/building/dists/trusty/main/source/Sources.gz). The entry will then reference the directory of the .orig.tar.gz, debian.tar.gz, and .dsc files.

If that is not the case I can only speculate that the job is using an outdated apt cache. Maybe the log of the status page job contains something useful.

7

I’m surprised that you’re not finding the package with locate.

To find the packages in the repo

You can use a query the repo directly like this:

reprepro -v -b /var/repos/ubuntu/building -A source listfilter trusty "Package (% *tornado* )"
trusty|main|source: ros-indigo-tornado 4.2.1-1trusty
trusty|main|source: ros-jade-tornado 4.2.1-0trusty

When doing things on the repo make sure to su to jenkins-slave to not override file permissions.

As jenkins-slave user on your repository the following command should clear the packages after listing all matches on the default repo locations.

jenkins-slave@ip-172-31-9-243:~/reprepro-updater$ ./remove_packages.py "Package (% *tornado* )"
8

I tried manually editing the contents of the Sources.gz file, but it must be automatically generated by something else, because it just reappeared after the next build.

Using the remove_packages.py script did the trick, though. Thanks!