Bug #11361

Document how to build Onion Circuits Debian packages

Added by anonym 2016-04-22 07:30:58 . Updated 2016-06-02 11:41:15 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2016-04-22
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Onion Circuits
Deliverable for:

Description

While reviewing Bug #11192 I tried to build the package I actually want to be in Tails 2.3, and then I first noticed that there is no mention of it in the release process (Bug #11360) and no instructions how we package it (seemingly by importing the upstream Debian packaging).


Subtasks


History

#1 Updated by anonym 2016-04-22 07:32:59

  • Target version changed from Tails_2.3 to Tails_2.4

While this should target Tails 2.3, since I will have to build a package for it, I know there’s not enough time for that. For 2.3 I’ll just import the required commits as patches to the tails/jessie branch and build a 0.3-0tails2.

#2 Updated by anonym 2016-04-22 07:38:41

Also, please push the pristine-tar and upstream branches. At least I was prompted for the former when trying to build 0.3-0tails2, and had to work around it by temporarily disabling pristine-tar, and then building from the 0.3 orig tarball from the Debian source package.

#3 Updated by anonym 2016-04-22 08:10:19

  • blocks Bug #11360: Integrate Onion Circuits into our release process added

#4 Updated by intrigeri 2016-05-18 09:34:45

anonym wrote:
> Also, please push the pristine-tar and upstream branches.

They are in the Debian Vcs-Git repo.

#5 Updated by intrigeri 2016-05-18 09:50:53

I’ve proposed on Bug #11360 that we do not do that, let’s wait what’s the outcome of that discussion.

#6 Updated by anonym 2016-05-22 15:59:15

  • blocked by deleted (Bug #11360: Integrate Onion Circuits into our release process )

#7 Updated by anonym 2016-05-22 16:03:26

  • QA Check set to Info Needed

intrigeri wrote:
> I’ve proposed on Bug #11360 that we do not do that, let’s wait what’s the outcome of that discussion.

As you can see I agreed with you and hence rejected that ticket.

I still expect us to (for some more time) frequently have to ship a patched onioncircuits, so documenting the preferred way to do that would be nice. I can improvise, otherwise, like I did for Tails 2.3, if that is good enough.

#8 Updated by intrigeri 2016-05-23 11:50:05

  • Assignee changed from intrigeri to anonym

> As you can see I agreed with you and hence rejected that ticket.

Glad we’re on the same page! :)

> I still expect us to (for some more time) frequently have to ship a patched onioncircuits, so documenting the preferred way to do that would be nice.

IMO Onion Circuits doesn’t deserve any special treatment here: just like for any other Debian package we want to patch (e.g. grub2, torbirdy, mesa), the general workflow is to get the source package (apt-get source or, when feasible, debcheckout), import patches into whatever patch system is used (e.g. quilt), add a changelog entry and build (with gbp when feasible, else with pbuilder or similar). Bonus points if we push the resulting packaging branch to Git (which we can do for onioncircuits, but then it feels somewhat weird to push Tails-specific packaging branches into the upstream Git repo), but in the general case we simply don’t have any Git repo to push to, so we skip that step.

Another approach that we often use is to not re-package at all, and to simply use config/chroot_local-patches/. Perhaps it would sometimes be more suitable for interpreted code, like Onion Circuits’, that we can easily patch in-place. One advantage of this approach is that we’ll be forced to notice whenever our patches are not needed anymore (i.e. because they now are in the Debian package), since we’ll get an ISO build failure due to an already applied patch. As opposed to the “upload modified package to our custom APT repo” approach, that is prone to keeping shipping an outdated fork.

So, IMO we should either document this process in the general case, or assume that all this is kinda obvious to those of us who modify Debian packages for Tails. I really don’t mind quickly documenting this workflow if you think it’s needed, my point here is merely to get the scope right and document it in the best place :)

> I can improvise, otherwise, like I did for Tails 2.3, if that is good enough.

IMO that’s good enough.

#9 Updated by anonym 2016-06-02 11:41:15

  • Status changed from Confirmed to Rejected
  • Assignee deleted (anonym)
  • QA Check deleted (Info Needed)

intrigeri wrote:
> > I still expect us to (for some more time) frequently have to ship a patched onioncircuits, so documenting the preferred way to do that would be nice.
>
> IMO Onion Circuits doesn’t deserve any special treatment here: […]
>
> Another approach that we often use is to not re-package at all, and to simply use config/chroot_local-patches/. Perhaps it would sometimes be more suitable for interpreted code, like Onion Circuits’, that we can easily patch in-place. One advantage of this approach is that we’ll be forced to notice whenever our patches are not needed anymore (i.e. because they now are in the Debian package), since we’ll get an ISO build failure due to an already applied patch. As opposed to the “upload modified package to our custom APT repo” approach, that is prone to keeping shipping an outdated fork.
>
> So, IMO we should either document this process in the general case, or assume that all this is kinda obvious to those of us who modify Debian packages for Tails. I really don’t mind quickly documenting this workflow if you think it’s needed, my point here is merely to get the scope right and document it in the best place :)

Ok, I like this approach becoming “accepted” (it’s not like it ever was not), and I don’t think it needs to be documented explicitly. => rejecting