Opened 4 years ago

Closed 14 months ago

#20643 closed task (fixed)

make and maintain a registry of what debs are on and why

Reported by: arma Owned by: irl
Priority: Medium Milestone:
Component: Internal Services/Service - deb.tpo Version:
Severity: Normal Keywords:
Cc: hiro Actual Points:
Parent ID: Points:
Reviewer: arma Sponsor:


We've accumulated a variety of debs on, 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 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.

Child Tickets

Change History (14)

comment:1 Changed 4 years ago by arma

Owner: changed from weasel to hiro
Status: newassigned

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

comment:2 Changed 4 years ago by arma

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.

comment:3 Changed 4 years ago by arma

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

comment:4 Changed 3 years ago by arma

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

comment:5 Changed 3 years ago by irl

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.
  • 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)

comment:6 Changed 2 years ago by arma

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

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

comment:7 Changed 2 years ago by irl

Owner: changed from hiro to irl
Status: assignedaccepted

Hoping to look at this this week.

comment:8 Changed 2 years ago by irl

Reviewer: arma
Status: acceptedneeds_review

I have compiled information here.

comment:9 Changed 2 years ago by atagar

Any reason we can't drop tor-arm?

comment:10 Changed 2 years ago by irl

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.

comment:11 Changed 2 years ago by atagar

Thanks irl, done: #27084

Last edited 2 years ago by irl (previous) (diff)

comment:12 Changed 17 months ago by arma

Status: needs_reviewneeds_revision

Great! I looked at the wiki page.

The wiki page lists these packages as being available on, tor, obfsproxy, pyptlib, obfs4proxy.

But I see other debs, like python-klein:
and ooniprobe:
and 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 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.


comment:13 Changed 14 months ago by irl

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

comment:14 Changed 14 months ago by irl

Resolution: fixed
Status: needs_revisionclosed

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

Note: See TracTickets for help on using tickets.