Tails

#2 Updated by intrigeri 2014-05-14 13:36:38

Sorry if I’m overly naive and missing the point, but… when we’ve (hopefully correctly) detected that we are building from a branch, can’t we just initialize GIT_BRANCH in the same way as it’s done in auto/scripts/tails-custom-apt-sources, that is with trivial git branch | awk ... trickery?

We could even use the same logic as tails-custom-apt-sources uses to detect wether we should be building from a tag or not: using different logics, and implementations, for these two scripts, is prone to the kind of mismatch we’re experiencing here. Both scripts are supposed to detect and sort apart the exact same set of situations, right?

#3 Updated by kytv 2014-08-05 23:49:37

anonym wrote:
> Don’t think I’ll have time to fix this in time for 1.1. Let’s call it a Hole in the Roof, since it only affects Tails developers that can push stuff to our APT repo, and it seems I’m the only one that actually uses Vagrant among us.

FWIW I’ve been bitten by this and I also use Vagrant. It’s quite convenient. (Of course, I don’t have push rights either).

When I’m working in a branch of my own creation (let’s say feature/some-feature) the build can’t be done because

auto/scripts/tails-custom-apt-sources

will output an apt-sources line for a repository that doesn’t exist—it’s my branch and deb.tails.boum.org doesn’t and shouldn’t have a deb repo for my feature branch, some-feature.

For this reason I may want to create a new branch outside of feature/ which will only be on my local box, to prevent adding the file containing a reference to the non-existent repo.

So in the meantime, in my temporary, local-only branch I will apply the following and check it in, making sure that my branch will be used.

-if on_topic_branch; then
-       output_apt_binary_source "$(branch_name_to_suite $(current_branch))"
-fi

#4 Updated by intrigeri 2014-08-06 07:37:56

> So in the meantime, in my temporary, local-only branch I will apply the following and
> check it in, making sure that my branch will be used.

Another option would be to locally merge your branch into stable or devel (depending on where it’s supposed to be merged) and build from there.

#5 Updated by kytv 2014-08-07 22:38:09

What I’ve started doing is working entirely outside of feature/* then moving it back to feature/ when I’m ready to have more eyes on it. This way the non-existent apt repository source file isn’t created and the squashfs creation defaults to compressing with gzip.

So far this “workflow” is working out OK.

#8 Updated by intrigeri 2016-04-26 02:34:00

> * now, when there is no more branches that doesn’t encode changes of APT suite in Git, the problem is mostly not relevant

Indeed, the way I get it that’s a non-issue nowadays.

> * there is one instance of this which I frequently encounter (but can easily deal with manually), and this is that when I rebuild the each release the second time from the force-updated tag — our current implementation does not fetch tags, but likely that is fixed simply by: […]

> So, perhaps we can just push that last tiny change, and forget about this.

Yes.

> I’ll try to make time to check intrigeri’s suggestion first, though.

Only if you think it’s worth the additional effort :)

Beware, though: tails-custom-apt-sources will be modified quite a bit for Feature #10748, that really needs to go into Tails 2.4