Tails

#2 Updated by intrigeri 2017-03-17 12:52:56

• Priority changed from Normal to Elevated

#3 Updated by sajolida 2017-04-25 19:40:45

• Assignee changed from sajolida to intrigeri
• QA Check set to Info Needed

Well, with this kind of tickets it seems like two different people could start working on it in parallel. You would be better placed to study DAVE and maybe Tails Upgrader and I would be better placed to study the website, the inlines, etc. So I’m not sure how to handle this in Redmine. Maybe assign it to you if you think you could do this quite fast because you’ll be having a look at more deeper code and my fixes on the website could be done maybe later on… But I’ll still keep in on my radar somehow.

Does it make sense?

#4 Updated by sajolida 2017-04-26 18:04:57

• QA Check changed from Info Needed to Ready for QA

Here is a proposal for handling the renaming of the IDF file:

- For 3.0, have a copy of the same IDF on both:
- http://dl.amnesia.boum.org/tails/stable/tails-i386-3.0/tails-i386-2.12.iso
- http://dl.amnesia.boum.org/tails/stable/tails-amd64-3.0/tails-amd64-3.0.iso

- (Shortly) after 3.0, release a new version of DAVE pointing to the amd64 IDF.
- (Shortly) after releasing this new version of DAVE:
- Force the use of this version through <div id="extension-version"> on the download page.
- Remove the i386 IDF.

Would this work?

I also updated a whole bunch of website pages that were mentioning i386 in the branch feature/11962-update-install-and-upgrade-to-amd64.

#5 Updated by sajolida 2017-04-26 18:28:46

• Feature Branch set to https://labs.riseup.net/code/issues/11573

#7 Updated by intrigeri 2017-04-29 10:04:54

• Assignee changed from intrigeri to sajolida
• QA Check changed from Ready for QA to Info Needed
• Feature Branch changed from https://labs.riseup.net/code/issues/11573 to feature/11962-update-install-and-upgrade-to-amd64

> - For 3.0, have a copy of the same IDF on both:
> - http://dl.amnesia.boum.org/tails/stable/tails-i386-3.0/tails-i386-2.12.iso
> - http://dl.amnesia.boum.org/tails/stable/tails-amd64-3.0/tails-amd64-3.0.iso

I don’t get this part: these links point to ISOs and not to IDFs, and I don’t get what 2.12 has to do with this ticket. Did you instead mean that we publish 2 IDFs:

• https://tails.boum.org/install/v1/Tails/amd64/stable/latest.yml
• https://tails.boum.org/install/v1/Tails/i386/stable/latest.yml

… that both point to the 3.0 (amd64) ISO image? This should be a nice way to handle the transition smoothly. If we do that, I’ll need a subtask to avoid forgetting this during the 3.0 release process.

> - (Shortly) after 3.0, release a new version of DAVE pointing to the amd64 IDF.

ACK, but this depends on the previous point. I think this will need a subtask for anonym. Apparently the needed change is a mere s/i386/amd64/ in conf.json.

> - (Shortly) after releasing this new version of DAVE:
> - Force the use of this version through <div id="extension-version"> on the download page.
> - Remove the i386 IDF.

ACK, but this depends on the previous points. I think this will need a subtask for you.

> I also updated a whole bunch of website pages that were mentioning i386 in the branch feature/11962-update-install-and-upgrade-to-amd64.

Adjusting Redmine metadata accordingly. Is this branch ready to be reviewed and merged into feature/stretch?

Regarding Tails Upgrader: no code change needed as far as I can tell. Regarding UDFs: we’ll need to point i386 2.x users to the full upgrade (and 3.0~ amd64 users to incremeental/full upgrades, but that’s already covered by our current release process). This will require a subtask for me so I don’t forget during the 3.0 release process.

Regarding Tails Installer: I think we’re already all set — it works fine when run on both i386 and amd64 systems, to install both i386 and amd64 Tails, since we ship an i386 syslinux binary in utils/linux.

I can’t think of anything else I should look into, let me know if you can :)

#8 Updated by sajolida 2017-04-29 18:29:22

• Assignee changed from sajolida to intrigeri
• QA Check changed from Info Needed to Ready for QA

>> - For 3.0, have a copy of the same IDF on both:
>> - http://dl.amnesia.boum.org/tails/stable/tails-i386-3.0/tails-i386-2.12.iso
>> - http://dl.amnesia.boum.org/tails/stable/tails-amd64-3.0/tails-amd64-3.0.iso
>
> I don’t get this part: these links point to ISOs and not to IDFs, and I don’t get what 2.12 has to do with this ticket. Did you instead mean that we publish 2 IDFs:
>
> * https://tails.boum.org/install/v1/Tails/amd64/stable/latest.yml
> * https://tails.boum.org/install/v1/Tails/i386/stable/latest.yml
>
> … that both point to the 3.0 (amd64) ISO image? This should be a nice way to handle the transition smoothly.

D’oh, yes! That’s what I meant :)

> If we do that, I’ll need a subtask to avoid forgetting this during the 3.0 release process.

Created Bug #12495.

>> - (Shortly) after 3.0, release a new version of DAVE pointing to the amd64 IDF.
>
> ACK, but this depends on the previous point. I think this will need a subtask for anonym. Apparently the needed change is a mere s/i386/amd64/ in conf.json.

Created Bug #12494.

>> - (Shortly) after releasing this new version of DAVE:
>> - Force the use of this version through <div id="extension-version"> on the download page.
>> - Remove the i386 IDF.
>
> ACK, but this depends on the previous points. I think this will need a subtask for you.

Created Bug #12496.

> Is this branch ready to be reviewed and merged into feature/stretch?

Yes!

> Regarding Tails Upgrader: no code change needed as far as I can tell. Regarding UDFs: we’ll need to point i386 2.x users to the full upgrade (and 3.0~ amd64 users to incremeental/full upgrades, but that’s already covered by our current release process). This will require a subtask for me so I don’t forget during the 3.0 release process.

I’ll let you create that one.

> I can’t think of anything else I should look into, let me know if you can :)

Me neither…

I still see a bunch of occurrences of ‘i386’ in the release process but I won’t touch that:

• contribute/release_process/icedove.mdwn
• contribute/release_process/test.mdwn

The rest are not significant, for example stuff in inc/ will be updated during the release process, lib/download_stable_i386_iso_sig.de.html and lib/download_stable_i386_iso_sig.html are meant to be deleted.

#9 Updated by intrigeri 2017-04-30 10:34:18

• related to Bug #12495: Create a copy of the 3.0 IDF on both 'amd64' and 'i386' paths added

#10 Updated by intrigeri 2017-04-30 10:48:28

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

> D’oh, yes! That’s what I meant :)

:)

>> Is this branch ready to be reviewed and merged into feature/stretch?

> Yes!

Cool! Will do once you’ve fixed the (probably trivial) merge conflicts… unless you prefer to have this reviewed by one of your fellow tech doc writers instead? OTOH the changes seem to be mostly tricky ikiwiki stuff that I probably understand better than they do.

>> Regarding Tails Upgrader: no code change needed as far as I can tell. Regarding UDFs: we’ll need to point i386 2.x users to the full upgrade (and 3.0~ amd64 users to incremeental/full upgrades, but that’s already covered by our current release process). This will require a subtask for me so I don’t forget during the 3.0 release process.

> I’ll let you create that one.

Sure, that’s Feature #12497.

> I still see a bunch of occurrences of ‘i386’ in the release process but I won’t touch that:

> * contribute/release_process/icedove.mdwn

Fixed in commit:cdcebaa4c2, thanks.

> * contribute/release_process/test.mdwn

Fixed in commit:f33d1ac. Thanks!

> The rest are not significant, for example stuff in inc/ will be updated during the release process, lib/download_stable_i386_iso_sig.de.html and lib/download_stable_i386_iso_sig.html are meant to be deleted.

Right, and no harm done if they are not I think.

#11 Updated by intrigeri 2017-05-20 07:12:53

• Status changed from Confirmed to In Progress
• Priority changed from Normal to Elevated
• % Done changed from 0 to 10
• Parent task set to Feature #11916
• Type of work changed from Research to End-user documentation

I’ve heard that you thought you were done with doc updates for 3.0, so mangling metadata to ensure this one is on your radar :)

#12 Updated by sajolida 2017-05-22 17:39:47

• blocks Feature #12432: Technical writing core work 2017Q2 added

#14 Updated by sajolida 2017-05-22 19:50:01

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

I merge feature/stretch into this branch and fix the conflicts. And yes, I think that you can review the ikiwiki tricks without going through my team mates.

Anything else?

#15 Updated by intrigeri 2017-05-23 08:23:23

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

> I merge feature/stretch into this branch and fix the conflicts. And yes, I think that you can review the ikiwiki tricks without going through my team mates.

Merged into feature/stretch!

> Anything else?

For the same reason as on Bug #11573, let’s avoid having to deal with ikiwiki.setup on our production website during the 3.0 release process, so please:

1. create a new topic branch based on master, check it out
2. cherry-pick commit:cf40d8a0c73e2bf2bdc2ecf9515b436f00e49c6e in there
3. re-add support for inc/stable_i386_release_notes (so both i386 and amd64 are supported and the transition is smoother) and commit
4. merge this new topic branch into feature/stretch and push
5. revert the “re-add support” commit on feature/stretch
6. submit the topic branch based on master to me for QA and I’ll coordinate with root@b.o
7. then ikiwiki.setup in production will have a harmless leftover that will be cleaned up, post-3.0, next time we request an update to po_translatable_pages

#16 Updated by sajolida 2017-05-23 13:46:57

• Assignee changed from sajolida to intrigeri
• QA Check changed from Dev Needed to Ready for QA
• Feature Branch changed from feature/11962-update-install-and-upgrade-to-amd64 to feature/11962-update-install-and-upgrade-to-amd64-ikiwiki-setup

Woh, that’s heavy Git gym! But I think I understood the idea.

So my branch based on master is feature/11962-update-install-and-upgrade-to-amd64-ikiwiki-setup.

And I also pushed some stuff to feature/stretch. Note that I also pushed after step 5 of your instructions (otherwise you wouldn’t fetch the revert).

I hope I got it right. These po_translatable_pages lines are super long and we’ve been modifying them for three different tickets in parallel this release cycle :P

#17 Updated by bertagaz 2017-05-23 16:37:46

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

sajolida wrote:
> And I also pushed some stuff to feature/stretch. Note that I also pushed after step 5 of your instructions (otherwise you wouldn’t fetch the revert).

I think you broke the build of feature/stretch with this push (as shown here https://jenkins.tails.boum.org/job/reproducibly_build_Tails_ISO_feature-stretch/6/console). Seems that wiki/src/support/known_issues.de.po and wiki/src/support/known_issues.fa.po at least contain remainings of an unresolved merge. Seems to have been introduced in commit:191fc948e24658f460254ddd101a93d566f7de3b

#18 Updated by intrigeri 2017-05-23 17:22:31

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

> sajolida wrote:
>> And I also pushed some stuff to feature/stretch. Note that I also pushed after step 5 of your instructions (otherwise you wouldn’t fetch the revert).

> I think you broke the build of feature/stretch with this push

I’ve fixed that a hour ago.

#21 Updated by intrigeri 2017-05-24 15:42:12

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

sajolida wrote:
> So my branch based on master is feature/11962-update-install-and-upgrade-to-amd64-ikiwiki-setup.

Please push it :)

#22 Updated by sajolida 2017-05-25 16:38:18

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

Done now: https://git-tails.immerda.ch/tails/log/?h=feature/11962-update-install-and-upgrade-to-amd64-ikiwiki-setup :)

#23 Updated by intrigeri 2017-05-25 17:06:22

• Assignee changed from intrigeri to sajolida
• % Done changed from 10 to 50
• QA Check changed from Ready for QA to Dev Needed

Some bits of commit:466f954524201b7d4e22da071e60d27853bc6ea2 shouldn’t be merged on master I think — only the ikiwiki setup things are relevant there. Sorry, looks like my instructions were so detailed that you applied them almost blindly :)

#24 Updated by sajolida 2017-05-25 18:02:33

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

Oops, indeed! This should be fixed with 85f180eae8. git diff origin/master...origin/feature/11962-update-install-and-upgrade-to-amd64-ikiwiki-setup makes more sense now!

#25 Updated by intrigeri 2017-05-25 19:20:27

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

Merged into master, asked root@b.o to apply the same change on our production website, then merged into feature/strech and reverted your last revert (i.e. steps 4 and 5 above) otherwise feature/stretch would be back to i386. We should now be good.

Lesson learnt: next time, add to the list of translatable pages on master first. This will make transitions smoother, and will avoid the kind of revert hell we’ve gone through this time.

#26 Updated by intrigeri 2017-12-16 07:37:06

• Affected tool deleted (Download and Verification Extension)