13/05/14 11:47, intrigeri wrote:
> Hi,
>
> The results of our UEFI call for testing are very good:
>
> https://tails.boum.org/blueprint/UEFI/syslinux/
>
> ... and the release after 1.1 will likely be a point-release, so I'd
> like us to ship UEFI support, at least as a "technology preview", in
> Tails 1.1. Else, this will have to wait for the early
> September release.
>
> I think the current state of feature/uefi is good enough, and I have
> just merged it into experimental, *but* there are a few bits I'd like
> to improve before 1.1 is out.
>
> Unfortunately, I won't be available until May 24 to work on this, so
> I'd like to ask a kind special process, that is 1. merge feature/uefi
> in its current state; 2. trust me to deal in due time with the bits
> listed below. Note that the freeze is on May 29, so I'm picking dates
> bellow so that there are a few days left to merge my last bits:
>
> * It would be good to have #6562 at least partly resolved in 1.1.
> I can work on the most important bits by June 3, that is 5 days
> before the final 1.1 ISO is built. IMO, the most important bits
> are: "Start Tails", "Tails does not start", "Known issues", and
> "Hardware requirements" and Mac installation doc. I think that's
> the main blocker, but given it's "only" documentation, I think
> it's fine if I do it only post-RC, and can anyway be improved
> after 1.1 is out, if needed.
>
> * It would be good to address #6577 ("Convert existing Tails devices
> to UEFI on full upgrade") before the release. If feature/uefi is
> merged by then, I commit to work on this ticket, hopefully leading
> it to a good resolution, by May 26. If this doesn't work, I don't
> think it's a critical blocker.
>
> * It would be good to support older VirtualBox (#7173). The version
> of syslinux that has the fix won't be in Debian in time, and
> anyway I think it's too late to risk a major syslinux update -pre5
> might have serious regressions (even if it does tons of bugs)
> compared to the -pre1 we've had a lot of feedback about. So, I'll
> try to backport the relevant upstream commit, to support older
> VirtualBox, by May 26. If this doesn't work, I don't think it's
> a critical blocker.
>
> If the release manager agrees with this course of action, then I'll
> update the set of UEFI tickets accordingly, either later today (if
> I get a super-quick answer), or on May 24.
As the RM, I agree with all this. I've been using experimental builds
(which includes feature/uefi) for a while now and only noticed the
regression in old versions of VirtualBox. I trust you'll deal with the
rest in time for the release.
I'd like to start merging now (for the "super-quick" resolution), but I
have issues building liveusb-creator, after it being adapted for Wheezy,
and with the new version scheme. What I did was:
1. merge feature/uefi into master
2. merge master into debian
3. checkout debian
4. add changelog entry for 3.11.6+tails1-2
5. git-buildpackage, but I get:
fatal: Not a valid object name upstream/3.11.6+tails1
and --git-no-pristine-tar doesn't help (and
../liveusb-creator_3.11.6.orig.tar.gz exists)
I can work around this by
cp ../liveusb-creator_3.11.6.orig.tar.gz \
../liveusb-creator_3.11.6+tails1-1.orig.tar.gz
but I'm not sure this is the way to go.
Any ideas?
Cheers!
