Hi,
anonym wrote (01 Jul 2014 16:38:12 GMT) :
> 'apt' is not a source dir, but 'apt/cache' and 'apt/lists' are. Also, no
> exception was added for (the incorrect) 'apt' in the "persistent
> directories have safe access rights" step (like was done for
> 'nm-system-connections' and 'cups').
Indeed, I was surprised that the test passed.
> I think I cleaned this up quite a bit in commit a59e28a, and
> future-proofed it for new persistent non-amnesia-user directories.
Thanks! Quickly reviewed, looks good.
>> commit 86da95283669545219492d6f4921eb9cb66dd2eb
>> Author: Tails developers <amnesia@???>
>> Date: Mon Jun 30 09:42:07 2014 +0000
>>
>> Remove files as the parent directory's owner.
>>
>> Else, it can't possibly succeed.
> [...]
>> - assert(@vm.execute("rm #{dir}/XXX_persist").success?,
>> + owner = @vm.execute("stat -c %U #{dir}").stdout.chomp
>> + assert(@vm.execute("rm #{dir}/XXX_persist", user=owner).success?,
> I do not get this. @vm.execute runs the command as root by default, so
> the owner stuff seems unnecessary.
I had a test failure that was fixed after adding this commit, but it
might have been for unrelated reasons. Feel free to revert, assuming
the tests pass without that commit.
> Next (and I think this is unrealted to this branch) in "Scenario:
> Upgrading an old Tails USB installation from an ISO image, running on
> the old version" I get:
> Then Tails is installed on USB drive "to_upgrade"
> # features/step_definitions/usb.rb:163
> USB drive 'to_upgrade' has differences in /live:
> Files /lib/live/mount/medium/live/filesystem.packages and
> /mnt/new/live/filesystem.packages differ
> Files /lib/live/mount/medium/live/filesystem.squashfs and
> /mnt/new/live/filesystem.squashfs differ
> Files /lib/live/mount/medium/live/initrd.img and
> /mnt/new/live/initrd.img differ
> Files /lib/live/mount/medium/live/initrd2.img and
> /mnt/new/live/initrd2.img differ
> I'll get back to this.
I'm curious.
> With the current state of bugfix/7443-persistent-files-permission, all
> tests are green except the above one,
:)
> if I run with the following uncommitted fix:
> [...]
> since my --old-iso doesn't have the permission fix, that step will
> otherwise fail. Let's just ignore that.
Indeed.
Cheers!
--
intrigeri