Tails

#1 Updated by intrigeri 2015-01-06 13:55:27

• blocked by Feature #8552: Rename liveusb-creator to Tails Installer added

#2 Updated by intrigeri 2015-01-06 13:56:47

• blocks Feature #8554: Repack a DFSG-free Tails Installer tarball added

#3 Updated by intrigeri 2015-01-06 14:47:35

• blocks #8538 added

#4 Updated by Anonymous 2015-02-26 15:08:06

• Target version changed from Hardening_M1 to Tails_1.4

#5 Updated by Anonymous 2015-05-13 09:27:57

• Target version changed from Tails_1.4 to Tails_1.4.1

oops, mistake in target version

#6 Updated by Anonymous 2015-06-28 10:02:48

• Target version changed from Tails_1.4.1 to Tails_1.5

#7 Updated by Anonymous 2015-07-14 04:31:49

• Assignee set to intrigeri
• QA Check set to Info Needed

@intrigeri: could you please confirm some details of this task for me?
My plan is to rename liveusb-creator to tails-installer, the executable as well as the packaging (debian/control and debian/changelog). I would base this on the new feature/jessie branch which uses gtk3. Does that seem correct to you?

#8 Updated by intrigeri 2015-07-17 08:04:13

• Assignee deleted (intrigeri)
• QA Check deleted (Info Needed)

u wrote:
> My plan is to rename liveusb-creator to tails-installer, the executable as well as the packaging (debian/control and debian/changelog). I would base this on the new feature/jessie branch which uses gtk3. Does that seem correct to you?

Yes. We also need to rename the Python modules (in Feature #8552), because we don’t want to steal the “liveusb” namespace from the original liveusb-creator.

#9 Updated by intrigeri 2015-07-18 04:52:46

• blocked by deleted (Feature #8554: Repack a DFSG-free Tails Installer tarball)

#10 Updated by Anonymous 2015-08-04 07:41:47

• Target version changed from Tails_1.5 to Tails_1.6

#11 Updated by Anonymous 2015-09-22 15:22:49

• Target version changed from Tails_1.6 to Tails_1.7

#12 Updated by intrigeri 2015-10-02 17:36:04

• blocks Feature #8557: Have Tails Installer uploaded and accepted into Debian added

#13 Updated by Anonymous 2015-10-02 17:40:01

• Priority changed from Normal to Elevated

#15 Updated by intrigeri 2015-10-31 08:13:35

• Description updated

#16 Updated by intrigeri 2015-11-06 02:58:08

• Priority changed from Elevated to High
• Target version changed from Tails_1.7 to Tails_1.8

Blocks a high prio ticket => adjusting priority accordingly. We’re almost there! :)

#17 Updated by Anonymous 2015-11-10 03:26:40

• Status changed from Confirmed to In Progress
• % Done changed from 0 to 10

#18 Updated by Anonymous 2015-11-10 04:29:49

• Assignee set to ioerror
• % Done changed from 10 to 50
• QA Check set to Ready for QA

Built and tested 4.4.1, could you review it again please?
Thanks for your help :)

#19 Updated by Anonymous 2015-11-10 04:34:31

• Assignee changed from ioerror to intrigeri

oops sorry, wrong assignee

#20 Updated by intrigeri 2015-11-10 06:08:10

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

I’ve read the diff and pushed some fixes (please merge my tails/jessie). Looks good! I’ll upload once you do a new package that fixes Bug #10374 and includes my last fixes.

#21 Updated by Anonymous 2015-11-10 12:41:16

• Assignee set to intrigeri
• QA Check changed from Dev Needed to Ready for QA
• Feature Branch set to 451f:tails/jessie

merged your fixes. please review again.

#22 Updated by intrigeri 2015-11-11 06:29:25

• Status changed from In Progress to Resolved
• Assignee deleted (intrigeri)
• % Done changed from 70 to 100
• QA Check changed from Ready for QA to Pass

Merged all branches, uploaded to Tails’ feature-jessie APT suite, yay!

I have a few comments though:

• I’ve seen @ + b1953a0…1de0e2b pristine-tar -> 451f/pristine-tar (forced update)@ while I had already merged the previous state. Please never, ever, rewrite history you’ve already pushed without first coordinating with everyone who may have already based their work on what you’ve pushed.
• In your upstream/4.x+dfsg branch I see three “Imported Upstream version 4.4.2+dfsg” commits. It used to be fine to publish such buggy history earlier in our dev process, but now we’re trying to finalize something for Debian, that should be more polished IMO. In the future, please avoid pushing history that exposes the fact that you’ve given the same version number to 3 different tarballs / imports in a row.
• The two above points make me wonder if the release process doc we have are good enough: ideally we should be able to follow them without seeing such problems in the end. But I guess there may be other reasons for the above problems, and you know better, so it’s your call :)