Merge lp:~pfalcon/linaro-android-build-tools/control-setup-fix into lp:linaro-android-build-tools

[Paul Sokolovsky]

Fixes based on setting up stuff locally.

[James Westby (james-w)]

24 +sudo chmod 0600 /etc/ssl/private/android-build.linaro.org.crt

Didn't you want to use the new $VARIABLE here too?

Otherwise this looks good.

Thanks,

James

review: Approve

[Paul Sokolovsky (pfalcon)]

> 24 +sudo chmod 0600 /etc/ssl/private/android-build.linaro.org.crt
>
> Didn't you want to use the new $VARIABLE here too?
>

Oh, yes, sure. So, I'll try to research bzr commit squash support before merging this ;-).

[Michael Hudson-Doyle (mwhudson)]

On Thu, 14 Apr 2011 15:39:40 -0000, Paul Sokolovsky <email address hidden> wrote:
> > 24 +sudo chmod 0600 /etc/ssl/private/android-build.linaro.org.crt
> >
> > Didn't you want to use the new $VARIABLE here too?
> >
>
> Oh, yes, sure. So, I'll try to research bzr commit squash support before merging this ;-).

FWIW, "the bazaar way" is to not bother about things like this. Just
commit your fix.

Cheers,
mwh

[lp:~pfalcon/linaro-android-build-tools/control-setup-fix]

142. By Paul Sokolovsky on 2011-04-15

Use CERT_PATH var for certificate location.

[Paul Sokolovsky (pfalcon)]

> FWIW, "the bazaar way" is to not bother about things like this. Just
> commit your fix.

Well, just to understand bzr featureset and workflow better. And I see that (feature) branch merge *is* essentially a kind of hierarchical squash, that's why there's explicit commit message for merge - all commits of the branch will be by default shown squashed with this merge commit message, and it will be possible to drill down to the history of original commits if needed. Neat. At the same time, it seems that intra-branch interactively selective squash a-la "git rebase -i" is not supported. Ok, if bzr people don't care for each single commit to be oh-so-perfect, less trouble (git spoils, yeah ;-) ).

[Mattias Backman (mabac)]

On 15 April 2011 19:19, Paul Sokolovsky <email address hidden> wrote:
>> FWIW, "the bazaar way" is to not bother about things like this.  Just
>> commit your fix.
>
> Well, just to understand bzr featureset and workflow better. And I see that (feature) branch merge *is* essentially a kind of hierarchical squash, that's why there's explicit commit message for merge - all commits of the branch will be by default shown squashed with this merge commit message, and it will be possible to drill down to the history of original commits if needed. Neat. At the same time, it seems that intra-branch interactively selective squash a-la "git rebase -i" is not supported. Ok, if bzr people don't care for each single commit to be oh-so-perfect, less trouble (git spoils, yeah ;-) ).

I had real issues with this for a couple of weeks when starting to use
bzr too. With no rebase, I felt like getting stuck and being hindered
from doing work. After a while though, it's really easy getting used
to not having to clean up the commit history etc. And now, I can't
remember why it felt important in the first place. It seems no-one has
a problem with a few extra commits and perhaps some messy merging in
my changes (at lest no-one told me about it). :) Everyone can see
exactly how I did it and the end result is the same, actually with
less meta work.

Thanks,

Mattias

[Paul Sokolovsky (pfalcon)]

[]
> I had real issues with this for a couple of weeks when starting to use
> bzr too. With no rebase, I felt like getting stuck and being hindered
> from doing work. After a while though, it's really easy getting used
> to not having to clean up the commit history etc. And now, I can't
> remember why it felt important in the first place. It seems no-one has
> a problem with a few extra commits and perhaps some messy merging in
> my changes (at lest no-one told me about it). :) Everyone can see
> exactly how I did it and the end result is the same, actually with
> less meta work.

Yes, it at first take quite some time to get used to rebase-based
model, and I guess, it's indeed useful for big projects with large
codebase and lot of commit traffic. But with bzr it seems one
needs to "unlearn" using this workflow for all the things. Thanks for
this perspective, Mattias.

>
> Thanks,
>
> Mattias
>

--
Best Regards,
Paul

=== modified file 'control/setup-control-node'
--- control/setup-control-node	2011-03-21 00:01:55 +0000
+++ control/setup-control-node	2011-04-15 16:50:29 +0000
@@ -60,9 +60,10 @@
 sudo a2enmod headers
 sudo a2enmod rewrite
 sudo a2enmod expires
+sudo a2enmod ssl
 
 # make self-signed certificate
-cat <<EOF > /tmp/ssleay.conf
+cat <<EOF > /tmp/ssleay.cnf
 RANDFILE                = /dev/urandom
 [ req ]
 default_bits            = 1024
@@ -73,9 +74,10 @@
 [ req_distinguished_name ]
 commonName                      = android-build.linaro.org
 EOF
-sudo openssl req -config /tmp/ssleay.cnf -new -x509 -days 3650 -nodes -out /etc/ssl/private/android-build.linaro.org.crt
-sudo chmod go-a /etc/ssl/private/android-build.linaro.org.crt
-rm /tmp/ssleay.conf
+CERT_PATH=/etc/ssl/private/android-build.linaro.org.crt
+sudo openssl req -config /tmp/ssleay.cnf -new -x509 -days 3650 -nodes -out $CERT_PATH -keyout $CERT_PATH
+sudo chmod 0600 $CERT_PATH
+rm /tmp/ssleay.cnf
 
 cat <<EOF | sudo tee /etc/apache2/conf.d/extra-port > /dev/null
 Listen 127.0.0.1:600