make and maintain a registry of what debs are on deb.tp.o and why

We've accumulated a variety of debs on deb.tp.o, with a variety of maintainers. I think the knowledge of who these people are is not recorded well.

Step one, we should figure out who is in charge of each of the debs that's there. For example, is the pyptlib deb there because of one of the obfs debs? Or is it leftover from something and nobody needs it anymore? Similarly, is tor-arm there because it got brought in as a dependency to...something else that's there?

Then step two, we should write all of that in one place (a page on this wiki? a text file in the deb.tp.o root? someway else?), and make sure that those people know that they have the responsibility to keep their debs up to date, or to decide to take them down when they're no longer needed.

added component::internal services/service - deb.tpo owner::irl priority::medium resolution::fixed reviewer::arma severity::normal status::closed type::task labels

I'm giving this one to hiro since I bet weasel is unexcited to do it.

Trac:
Owner: weasel to hiro
Status: new to assigned

Oh, and for extra credit, we could figure out what our current policy is for adding new ones (I suspect it is "badger weasel until he says it's ok, and then later when you don't maintain your debs he regrets it"), and figure out an improved policy (like, something about having a sponsor who is a core tor contributor), and write it down for people.

And for extra extra credit, we could set up some nagios or other monitoring to let us know when the versions on deb.tp.o have fallen behind the versions of the mainline debian repos.

To be clear, there's no need to edit or write to deb.tp.o in order to do the items in this ticket.

I started having a go at this before I knew there was a ticket. Some ideas that I've had regarding this:

• I like the view provided by DDPO (e.g. https://qa.debian.org/developer.php?login=irl)
• I'd like to be able to compare to the versions in the corresponding Debian/Ubuntu suites
• I'd like to see the results of uscan to see when the package needs updating to a new upstream (can be the results of the Debian package's uscan provided by Debian)
• The packages on deb.tpo are listed nicely in the Sources.gz file for each suite, you can read these files with deb822 (in python-debian on Debian systems)
• A single HTML table is really all that's required here
• We could have a policy of having an extra Maintainer line in the control files that ends up in the Sources.gz to keep track of who is the maintainer for each package, depending on what the archive software supports (I think Ubuntu does this to differentiate the Ubuntu maintainer from the Debian maintainer)

I'm still excited for somebody to work on this!

The topic came up again in #25704 (closed), where somebody was suggesting putting nyx into our deb.tpo repo.

Hoping to look at this this week.

Trac:
Owner: hiro to irl
Status: assigned to accepted

I have compiled information [[org/operations/Infrastructure/deb.torproject.org|here]].

Trac:
Status: accepted to needs_review
Reviewer: N/A to arma

Any reason we can't drop tor-arm?

atagar: Primarily the reason is not being sure that there is no reason. If you think we can drop it, then please file a ticket on the deb.tpo component.

Thanks irl, done: #27084 (moved)

Great! I looked at the wiki page.

The wiki page lists these packages as being available on deb.tp.o: deb.torproject.org-keyring, tor, obfsproxy, pyptlib, obfs4proxy.

But I see other debs, like python-klein: http://deb.torproject.org/torproject.org/pool/main/k/klein/ and ooniprobe: http://deb.torproject.org/torproject.org/pool/main/o/ooniprobe/ python-certifi: http://deb.torproject.org/torproject.org/pool/main/p/python-certifi/ and txtorcon: http://deb.torproject.org/torproject.org/pool/main/t/txtorcon/

So it seems like this list on the wiki is incomplete?

Also, I didn't find the obfsproxy package in the pool/ directory. (Maybe it was removed in the past 7 months, when wheezy went away?)

Are these extra debs somehow not "really" on deb.tpo, since they're not in the Releases files that you mentioned? If that is so, should we delete them?

But I have a memory of Arturo thinking that the ooniprobe deb was still in use? (It appears to still be referenced directly from https://ooni.torproject.org/docs/ so I would guess yes it is.)

In the example command line on the wiki there is this typo, "$PACKCAGETOREMOVE"

To satisfy the "and maintain" part of this ticket, we should figure out some way to make sure that a pointer to the wiki page is in the critical path to adding or removing a package from deb.tpo, so people know to go update the wiki page. An alternative option would be that we run some sort of nagios cron that automatically enumerates the available packages, and notifies somebody when they differ from the entries on the wiki?

And lastly, for the "and why" part of the ticket, it would be nice to have a short explanation of why we have each package on deb.tpo. Such an explanation would primarily help it stay easy to notice when that reason no longer applies and it's time to reconsider having a separate copy here.

Thanks!

Trac:
Status: needs_review to needs_revision

Only ooniprobe packages remain to be removed, then we're just down to tor and the archive keyring.

ooniprobe packages are tracked in #27008 (moved). I think that this ticket is done.

Trac:
Status: needs_revision to closed
Resolution: N/A to fixed

closed

mentioned in issue #25704 (closed)