Project

General

Profile

Bug #16902

Tails ISO directory name has ".iso" in it, confusing some software

Added by vom 3 months ago. Updated 17 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

For example, Virtualbox errors out as it thinks that the subdirectory itself is an iso image. The Virtualbox folks could probably do a better job validating that the target is a file and not a directory, but perhaps renaming the directory to Tails-x.xx-iso (use dash instead of dot) would save folks a bit of frustration.

Workaround is to simply rename the subdirectory.

Associated revisions

Revision eebf75fe (diff)
Added by intrigeri 2 months ago

Release process: .iso→-iso and .img→-img in the directories downloaded over BitTorrent (refs: #16902)

As reported by @vom, "Virtualbox errors out as it thinks that the subdirectory
itself is an iso image".

Revision a8964667 (diff)
Added by anonym about 2 months ago

Release process: unite BitTorrent download folders.

I.e. we remove the "-iso" and "-img" suffixes, so if you download both
the ISO and USB image, they will be stored in the same folder.

Refs: #16902

Revision af34f8e7 (diff)
Added by intrigeri about 1 month ago

Release process: fix .img.torrent generation.

Fixup against commit a89646673b0c8bee973b9cea7dbd1888ddad966c: without this fix,
the .iso torrent is correct but the .img one includes both the ISO and IMG.

Closes: #16902

Revision 5e0d46d6 (diff)
Added by intrigeri about 1 month ago

Release process: fix Torrent publication.

When renaming the Torrent directories, I broke the part that was assuming that
the name of each such directory is the same as the name of the image
it contains.

And then, when uniting the Torrent folders, anonym broke the part that was
assuming we have a dedicated folder per image.

Closes: #16902

Revision e0fa8b82 (diff)
Added by intrigeri 17 days ago

Revert "Release process: unite BitTorrent download folders" (Closes: #16902)

Giving both Torrents the same name has problematic side effects.

For example, if someone downloads both Torrents at the same time (USB image +
ISO):

- The UI in a Bittorrent client does not allow to tell, at a glance, which
is which.
- If they use a BitTorrent client configured to download first to a temporary
folder and then move the downloaded files elsewhere (e.g. kibi tells me most
documentations for rtorrent recommend that), then when the 1st Torrent
download completes, it breaks the 2nd one, deleting all files that were
partially downloaded already.

So let's revert to having the Torrents download directories whose
names end respectively with -iso and -img.

This reverts most of commit a89646673b0c8bee973b9cea7dbd1888ddad966c, except the
part that got rid of permanent -iso and -img folders on the RM's filesystem,
which I assume is what made anonym unhappy with my initial implementation.

I've tried to salvage the hotfixes kibi and I had to do at release time, to fix
issues introduced by me while I did the first part of #16902 and later by anonym
in a89646.

I'll be the first one to go through the updated doc when I'll prepare 4.0~rc1
and 4.0, so I'll have the opportunity to notice and fix any breakage introduced
by this commit before it affects anyone else.

History

#1 Updated by intrigeri 2 months ago

@vom, this is about the directory downloaded via BitTorrent, right?

#2 Updated by vom 2 months ago

intrigeri wrote:

@vom, this is about the directory downloaded via BitTorrent, right?

Yes that's correct.

#3 Updated by intrigeri 2 months ago

  • Status changed from New to In Progress

#4 Updated by intrigeri 2 months ago

  • Status changed from In Progress to Needs Validation
  • Assignee set to sajolida
  • Target version set to Tails_3.16
  • Feature Branch set to doc/16902-no-image-type-extension-in-torrent-directories

Hi @sajolida! I've done my best to check and it seems to me that nothing else in our doc/code relies on the name of the directory downloaded over BitTorrent to have the ".iso" or ".img" suffix. Can you please confirm?

My branch renames these directories so their names ends with "-iso" or "-img" instead. Good enough?

If you're fine with this, please reassign to anonym for the review of the branch.

Thanks in advance!

#5 Updated by sajolida 2 months ago

  • Assignee changed from sajolida to anonym

Ack. I don't think that anything on the website relies on the name of the folder inside the BitTorrent download.

#6 Updated by anonym 2 months ago

  • Status changed from Needs Validation to In Progress
  • Assignee changed from anonym to intrigeri

intrigeri wrote:

My branch renames these directories so their names ends with "-iso" or "-img" instead. Good enough?

Good enough, yes, but I wonder I think we could do even better by dropping the suffix completely. Is there a reason we are keeping it (i.e. use separate directories for .iso and .img)? To me it seems they were added to make the use of mktorrent more straightforward. Personally I'd prefer to just have a single folder, however.

I propose we just create one directory tails-amd64-x.y.z for both the .iso and .img. When generating the .torrent:s we create a temporary tails-amd64-x.y.z folder somewhere else, symlink in the files we want in there and run mktorrent (which dereferences). I'm happy to implement this, if you aren't.

#7 Updated by intrigeri 2 months ago

  • Assignee changed from intrigeri to anonym

anonym wrote:

I think we could do even better by dropping the suffix completely. Is there a reason we are keeping it (i.e. use separate directories for .iso and .img)?

Apart of "no ambiguity when downloading the two torrents", indeed, implementation simplicity was the sole reason for giving these two directories different names.

I propose we just create one directory tails-amd64-x.y.z for both the .iso and .img. When generating the .torrent:s we create a temporary tails-amd64-x.y.z folder somewhere else, symlink in the files we want in there and run mktorrent (which dereferences). I'm happy to implement this […]

If sajolida is happy with that, feel free to implement it.

(Personally I feel I/we've already spent enough time on what I see as a relatively minor issue. But I don't want to discourage you from improving it further.)

#8 Updated by anonym 2 months ago

intrigeri wrote:

If sajolida is happy with that, feel free to implement it.

@sajolida?

(Personally I feel I/we've already spent enough time on what I see as a relatively minor issue. But I don't want to discourage you from improving it further.)

Understood! More context: as an RM I have hated this, so for my sanity this issue is subjectively worse than "minor". :)

#9 Updated by sajolida 2 months ago

If this only impacts what people using BitTorrent will see in their
download folder, I'm fine with anything.

#10 Updated by intrigeri 2 months ago

If this only impacts what people using BitTorrent will see in their download folder, I'm fine with anything.

It only impacts the name of that download folder, not its content.

#11 Updated by anonym about 2 months ago

  • Status changed from In Progress to Needs Validation
  • Assignee changed from anonym to intrigeri
  • % Done changed from 0 to 60

Done!

#12 Updated by intrigeri about 2 months ago

  • Status changed from Needs Validation to Resolved

Nice, thank you.

@CyrilBrulebois, note that the changes brought by this branch will require one manual adjustment when preparing 3.16: the new --old-iso argument won't work (it'll point to a path where the 3.15 ISO cannot be found), so you'll need to instead pass:

--old-iso \"${ISOS:?}/tails-amd64-${source_version:?}.iso/tails-amd64-${source_version:?}.iso\" 

@anonym, same for 4.0~beta2.

This should be a one-time annoyance: the updated doc will work as-is for the following releases.

#13 Updated by intrigeri about 1 month ago

  • Status changed from Resolved to In Progress

Well, I should have tested anonym's change, because it does not work: the .iso torrent is correct but the .img one includes both the ISO and IMG.

#14 Updated by intrigeri about 1 month ago

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

#15 Updated by intrigeri about 1 month ago

  • Status changed from Resolved to In Progress

The "Announce, seed and test the Torrents" step was also broken by this change.

#16 Updated by intrigeri about 1 month ago

  • Status changed from In Progress to Resolved

#17 Updated by intrigeri about 1 month ago

  • Status changed from Resolved to In Progress
  • Assignee deleted (intrigeri)
  • Target version changed from Tails_3.16 to Tails_3.17
  • Feature Branch deleted (doc/16902-no-image-type-extension-in-torrent-directories)

intrigeri wrote:

If this only impacts what people using BitTorrent will see in their download folder, I'm fine with anything.

It only impacts the name of that download folder, not its content.

I'm reopening this because the impact of the change proposed and implemented by anonym (giving both Torrents the same name) is larger than expected. If someone downloads both Torrents at the same time (USB image + ISO):

  • The UI in a Bittorrent client does not allow to tell, at a glance, which is which.
  • If they use a BitTorrent client configured to download first to a temporary folder and then move the downloaded files elsewhere (e.g. kibi tells me most documentations for rtorrent recommend that), then when the 1st Torrent download completes, it breaks the 2nd one, deleting all files that were partially downloaded already.

To fix this, we could revert to what I did initially (s/.iso/-iso/ etc.), which is less nice, but has less side effects.

@sajolida, what do you think?

#18 Updated by intrigeri about 1 month ago

  • % Done changed from 100 to 50

#19 Updated by intrigeri about 1 month ago

  • Target version changed from Tails_3.17 to Tails_4.0

#20 Updated by sajolida about 1 month ago

Let's do that!

#21 Updated by intrigeri about 1 month ago

  • Assignee set to intrigeri

Will do (directly in master since I'll be the first RM to deal with whatever bugs I introduce, instead of making other folks grumpy).

#22 Updated by intrigeri 17 days ago

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

Also available in: Atom PDF