Tails

#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.

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

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

#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