Feature #10414

Update release documentation for Tails Installer with info about Ubuntu PPA

Added by Anonymous 2015-10-23 10:06:00 . Updated 2016-02-10 15:16:52 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Tails_2.2
Start date:
2015-10-23
Due date:
% Done:

100%

Feature Branch:
doc/10407+ubuntuppa
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Installer
Deliverable for:

Description

If we want to distribute Tails Installer through a PPA, we need to update the PPA, each time we upload a new Debian package. This needs to be documented.

Subtasks

History

#1 Updated by intrigeri 2015-10-31 10:09:48

  • blocks #8538 added

#2 Updated by intrigeri 2015-10-31 10:10:23

  • Category set to Installation
  • Status changed from New to Confirmed
  • Target version set to Tails_1.8

#3 Updated by Anonymous 2015-11-10 14:24:07

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to 451f:tails/doc/10407+ubuntuppa

#4 Updated by Anonymous 2015-11-10 14:24:40

  • Assignee set to intrigeri
  • QA Check set to Ready for QA

We need to test this once we’ve actually released tails-installer.

#5 Updated by intrigeri 2015-11-11 08:29:39

  • Feature Branch changed from 451f:tails/doc/10407+ubuntuppa to doc/10407+ubuntuppa

#6 Updated by intrigeri 2015-11-11 08:34:48

  • Assignee deleted (intrigeri)
  • % Done changed from 10 to 20
  • QA Check changed from Ready for QA to Dev Needed

I’ve pushed some changes to the official Git repo, in a branch called the same as yours. Please base your future work on it. Here’s a first review:

  • It’s not clear what .changes we’re supposed to use (“Once the package has been built” isn’t very clear since the above sections instruct to build multiple packages). Presumably the same one as was uploaded to Debian? Please make it clear.
  • Must we upload a source package or binaries too to the PPA?
    • If binaries, for which (distribution,architecture) tuples?
    • If source only: then the .changes needs to be crafted to avoid uploading the binaries.
  • I think it should be made explicit that the .changes file is supposed to have been signed already (and with what key(s) exactly).
  • It’s not explicit what branch/version we’ll upload to Ubuntu, when exactly (upload to sid? to Debian stable backports?), and what Ubuntu version we’re targetting. I know too little about PPAs to guess, as you can see above :) Perhaps we need to discuss/research this together at some point, but if you gather relevant data first we’ll save some time (at least some of my time).

> We need to test this once we’ve actually released tails-installer.

I think we could already do a first upload to test things such as this piece of doc, no? Or can’t we remove stuff later?

#7 Updated by intrigeri 2015-11-25 08:48:03

  • blocked by deleted (#8538)

#8 Updated by intrigeri 2015-11-25 08:48:38

#9 Updated by intrigeri 2015-11-25 08:52:17

  • Target version changed from Tails_1.8 to Tails_2.2

#10 Updated by Anonymous 2015-11-30 16:18:19

intrigeri wrote:
> I’ve pushed some changes to the official Git repo, in a branch called the same as yours. Please base your future work on it. Here’s a first review:
>
> * It’s not clear what .changes we’re supposed to use (“Once the package has been built” isn’t very clear since the above sections instruct to build multiple packages). Presumably the same one as was uploaded to Debian? Please make it clear.

ack. Now, we are using debian/experimental as base but i think it should be the debian/sid one in the future.

> * Must we upload a source package or binaries too to the PPA?

It’s a source only upload.
One receives an email for each upload, informing if the upload was successful or not and why not.

> If binaries, for which (distribution,architecture) tuples?
> If source only: then the .changes needs to be crafted to avoid uploading the binaries.

I’ve done this with debbuild -sa -S.

> * I think it should be made explicit that the .changes file is supposed to have been signed already (and with what key(s) exactly).

ack.

> * It’s not explicit what branch/version we’ll upload to Ubuntu, when exactly (upload to sid? to Debian stable backports?), and what Ubuntu version we’re targetting. I know too little about PPAs to guess, as you can see above :) Perhaps we need to discuss/research this together at some point, but if you gather relevant data first we’ll save some time (at least some of my time).

Yes I think we need to talk about it.
From what you said at least we do not target the old LTS as it misses many dependencies which are needed by the installer.

> > We need to test this once we’ve actually released tails-installer.
>
> I think we could already do a first upload to test things such as this piece of doc, no? Or can’t we remove stuff later?

yes. I’ve tested it on my personal PPA for now.

#11 Updated by Anonymous 2015-11-30 16:18:51

  • Assignee set to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

#12 Updated by intrigeri 2015-12-01 15:15:44

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Dev Needed

> intrigeri wrote:
>> I’ve pushed some changes to the official Git repo, in a branch called the same as yours. Please base your future work on it.

It seems that you’ve merged my changes, but silently reverted at least some of them in commit 1368d0c812119e8049b4ec4c7164c02743727fc3, reintroducing problems I had fixed. May you please correct that?

tails-team is not a very good name for “the Tails team’s PPA of Tails Installer”. E.g. we’ll have namespace issues if we ever want to put another PPA under that team’s umbrella. I suggest “ppa-tails-installer”.

>> * Must we upload a source package or binaries too to the PPA?

> It’s a source only upload.

OK, cool.

The instructions for “build a signed source only package” feel weird, since all other similar doc we have instructs to first build, and later sign (e.g. I have the habit of only signing stuff I have validated somehow — e.g. piuparts, manual testing, autopkgtests). Can you please make it consistent?

Also note that some of us (e.g. myself) have custom --git-builder settings, so this line won’t work for all of us. But well, those who tweak these things know how to build a source-only package and sign it, I guess.

The debian/changelog updating doc (“bump version to”) should document what target distro one should write in there.

>> If binaries, for which (distribution,architecture) tuples?

Apparently the target distribution set in the changes file determines the distribution the PPA is about. So if we want to support Vivid too, we’ll have to upload a source package for Vivid, right? Can it have the same version number as the one for Xenial? If not, then the doc will need updates.

>> If source only: then the .changes needs to be crafted to avoid uploading the binaries.

> I’ve done this with debbuild -sa -S.

I see. This works! But then please don’t document a totally different command :) I think the gbp buildpackage command should either be removed, or adjusted to work both for you and I: apparently none of us will use it in its current shape.

>> * It’s not explicit what branch/version we’ll upload to Ubuntu, when exactly
>> (upload to sid? to Debian stable backports?), and what Ubuntu version we’re
>> targetting. I know too little about PPAs to guess, as you can see above :) Perhaps
>> we need to discuss/research this together at some point, but if you gather relevant
>> data first we’ll save some time (at least some of my time).

> Yes I think we need to talk about it.
> From what you said at least we do not target the old LTS as it misses many dependencies which are needed by the installer.

Right.

The syslinux we need is in Vivid and newer. I think we should support:

  • the last LTS release when possible (starting with 16.04)
  • the last release even if it’s not a LTS, that is currently Wily
  • next release, that is currently Xenial

What do you think?

I believe all those should support our 4.x codebase just fine, but this remains to be tested.

IMO we should upload:

  • to our PPA targetting their next release: whatever we push to sid or experimental
  • to our PPA:s targetting older Ubuntu releases: whatever we push to Debian stable backports

… so we keep the delta as small as possible between our stuff for Debian and Ubuntu, and we have “only” two times when we prepare and upload stuff.

If you agree with all this, then please go ahead and update (and test!) the doc accordingly. Note that sajolida would like the PPA to be ready on December 15 (for what Ubuntu release?), which conflicts with the fact this ticket is scheduled for mid-March. If we can’t have this in place in time for his deadline, we should let him know.

#13 Updated by intrigeri 2015-12-01 15:35:03

Also, the versioning scheme for Ubuntu needs to be thought through and documented on top of the page along with the branch setup.

#14 Updated by Anonymous 2015-12-02 04:40:44

intrigeri wrote:
> > intrigeri wrote:
> >> I’ve pushed some changes to the official Git repo, in a branch called the same as yours. Please base your future work on it.
>
> It seems that you’ve merged my changes, but silently reverted at least some of them in commit 1368d0c812119e8049b4ec4c7164c02743727fc3, reintroducing problems I had fixed. May you please correct that?

argh. sure.

> tails-team is not a very good name for “the Tails team’s PPA of Tails Installer”. E.g. we’ll have namespace issues if we ever want to put another PPA under that team’s umbrella. I suggest “ppa-tails-installer”.

ack. modified.

> The instructions for “build a signed source only package” feel weird, since all other similar doc we have instructs to first build, and later sign (e.g. I have the habit of only signing stuff I have validated somehow — e.g. piuparts, manual testing, autopkgtests). Can you please make it consistent?

Ok, in that case I’ll split the command.

> Also note that some of us (e.g. myself) have custom --git-builder settings, so this line won’t work for all of us. But well, those who tweak these things know how to build a source-only package and sign it, I guess.

That is what I thought. First I’ve built with “debuild -sa -S” but I wanted to continue using gbp and pristine-tar as for the rest of the documentation. Hence the modification to the now present command.

> The debian/changelog updating doc (“bump version to”) should document what target distro one should write in there.

ok.

> >> If binaries, for which (distribution,architecture) tuples?
>
> Apparently the target distribution set in the changes file determines the distribution the PPA is about. So if we want to support Vivid too, we’ll have to upload a source package for Vivid, right? Can it have the same version number as the one for Xenial? If not, then the doc will need updates.

I need to test that.

> >> If source only: then the .changes needs to be crafted to avoid uploading the binaries.
>
> > I’ve done this with debbuild -sa -S.
>
> I see. This works! But then please don’t document a totally different command :) I think the gbp buildpackage command should either be removed, or adjusted to work both for you and I: apparently none of us will use it in its current shape.

see on top. both commands work. and i do indeed use the one i’ve documented. Do you want to tell me how you would do it?

> >> * It’s not explicit what branch/version we’ll upload to Ubuntu, when exactly
> >> (upload to sid? to Debian stable backports?), and what Ubuntu version we’re
> >> targetting. I know too little about PPAs to guess, as you can see above :) Perhaps
> >> we need to discuss/research this together at some point, but if you gather relevant
> >> data first we’ll save some time (at least some of my time).
>
> > Yes I think we need to talk about it.
> > From what you said at least we do not target the old LTS as it misses many dependencies which are needed by the installer.
>
> Right.
>
> The syslinux we need is in Vivid and newer. I think we should support:
>
> * the last LTS release when possible (starting with 16.04)

So that is Xenial, right?

> * the last release even if it’s not a LTS, that is currently Wily
> * next release, that is currently Xenial
>
> What do you think?

sounds reasonable.

> I believe all those should support our 4.x codebase just fine, but this remains to be tested.
>
> IMO we should upload:
>
> * to our PPA targetting their next release: whatever we push to sid or experimental
> * to our PPA:s targetting older Ubuntu releases: whatever we push to Debian stable backports

yep. And then we need to merge the Debian branches accordingly.

> … so we keep the delta as small as possible between our stuff for Debian and Ubuntu, and we have “only” two times when we prepare and upload stuff.

:)

> If you agree with all this, then please go ahead and update (and test!) the doc accordingly. Note that sajolida would like the PPA to be ready on December 15 (for what Ubuntu release?), which conflicts with the fact this ticket is scheduled for mid-March. If we can’t have this in place in time for his deadline, we should let him know.

This should work out just fine.

I’ll build packages for the named distributions, upload them to my testing PPA and try to install them on the corresponding Ubuntu versions then.

#15 Updated by intrigeri 2015-12-02 04:50:00

> see on top. both commands work. and i do indeed use the one i’ve documented. Do you want to tell me how you would do it?

I don’t think my current gbp config would allow me to do that; that’s my fault for using tons of wrappers that don’t all allow passing the right info through. So I would have to use pdebuild..

>> * the last LTS release when possible (starting with 16.04)

> So that is Xenial, right?

Yes, 16.04 is Xenial: https://en.wikipedia.org/wiki/Ubuntu_(operating_system)#Releases

#16 Updated by Anonymous 2015-12-02 05:46:32

After some more discussion we decided that it is for now not necessary to have dedicated Git branches for the packages we upload to our Ubuntu PPA as they are the same as the Debian packages, simply there version number and release distribution changes.

To build a package for Ubuntu, we would simply need to checkout a Debian branch (sid or experimental for the upcoming Ubuntu release, or whatever we release to stable/backports for the current Ubuntu release and LTS), bump changelog and version, build a source package, test it, sign it, upload to the PPA.

Later on we might want to investigate if we can script this, similarly to what weasel does here https://gitweb.torproject.org/project/jenkins/tools.git/tree/slaves/linux/tor-debian-master-nightly-source/misc/build-tor-sources and there https://gitweb.torproject.org/project/jenkins/tools.git/tree/slaves/linux/tor-debian-master-nightly-source/misc/backport so that we would not have to build 5 packages manually everytime.

#17 Updated by Anonymous 2015-12-02 07:22:51

  • Assignee set to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

Updated according to our discussion.
I hope I did re-implement the correct changes you made beforehand.

  • Added how to use dput with SFTP.
  • Uploaded the packages to the PPA, now for Wily and Xenial :)

I still need to test installing from Ubuntu. Will create a ticket for this.

#18 Updated by intrigeri 2015-12-07 14:38:56

  • blocks #8538 added

#19 Updated by Anonymous 2015-12-11 06:15:02

Pushed a minor fix to the doc today.

#20 Updated by Anonymous 2016-02-04 18:34:20

  • Feature Branch changed from doc/10407+ubuntuppa to 451f:doc/10407+ubuntuppa

#21 Updated by intrigeri 2016-02-09 20:45:49

  • % Done changed from 20 to 30

Merged your branch and current master, resolved conflicts.

#22 Updated by intrigeri 2016-02-09 20:46:01

  • Feature Branch changed from 451f:doc/10407+ubuntuppa to doc/10407+ubuntuppa

#23 Updated by intrigeri 2016-02-09 20:56:44

  • Assignee deleted (intrigeri)
  • % Done changed from 30 to 60

I’ve pushed a few fixes on top of it. I think it’s ready to be merged, please review.

My main remaining concern is that these instructions need to be heavily interpreted by a human, and are not much executable. But we can iterate from here, we’ll want to automate stuff when we go through it anyway :)

#24 Updated by Anonymous 2016-02-10 14:00:21

  • Assignee set to intrigeri
  • QA Check changed from Ready for QA to Pass

Hi,

thanks. Yes indeed that’s not so much automatic.. but it stays fairly easy to do.

I let you do the merge and close this ticket.

I am closing the parent ticket already.

#25 Updated by intrigeri 2016-02-10 15:14:49

  • Status changed from In Progress to Resolved
  • % Done changed from 60 to 100

Applied in changeset commit:0806f40f1380e74457026255aa7b6ca20b5e8505.

#26 Updated by intrigeri 2016-02-10 15:15:29

> I let you do the merge and close this ticket.

Thanks! Merged.

#27 Updated by intrigeri 2016-02-10 15:16:52

  • Assignee deleted (intrigeri)