Merge lp:~jtv/launchpad/bug-527170 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Jeroen T. Vermeulen on 2010-03-02 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | not available |
| Proposed branch: | lp:~jtv/launchpad/bug-527170 |
| Merge into: | lp:launchpad |
| Diff against target: |
413 lines (+228/-18) 4 files modified
lib/canonical/testing/layers.py (+1/-1) lib/lp/soyuz/doc/sampledata-setup.txt (+6/-5) utilities/soyuz-sampledata-cleanup.py (+200/-12) utilities/start-dev-soyuz.sh (+21/-0) |
| To merge this branch: | bzr merge lp:~jtv/launchpad/bug-527170 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Jeroen T. Vermeulen (community) | code | Approve on 2010-03-02 | |
| Michael Nelson (community) | code | Approve on 2010-03-02 | |
|
Review via email:
|
|||
This proposal supersedes a proposal from 2010-03-02.
Commit Message
Automate much of manual Soyuz setup on dev systems.
| Jeroen T. Vermeulen (jtv) wrote : | # |
| Jeroen T. Vermeulen (jtv) wrote : | # |
There's still a problem with this that escaped my notice because zeca was retaining my GPG key from previous tests.
| Jeroen T. Vermeulen (jtv) wrote : | # |
Done. A feature I had previously neglected to document: the script now goes through the steps of adding and validating your real GPG key to ppa-user for you. Saves more hassle.
| Michael Nelson (michael.nelson) wrote : | # |
Thanks Jeroen!
So there were a few suggestions, (1) adding the amd arch by default, (2) creating the PPA for the person and (3) adding the external dependencies. You've done (1) and were going to see how much effort is involved for (2) and (3).
12:35 < noodles775> jtv: what would be the problem with just adding amd64 as an arch always? the user still needs to target a specific series?
12:36 < jtv> noodles775: dunno frankly; I figured the safe thing to do was to stay faithful to what we already had.
12:36 < noodles775> jtv: also, do you think it should be possible to run this twice? (ie. the first time I didn't set my email, so I need to make schema before re-running right?)
12:36 < jtv> noodles775: right now you'll have to "make schema" between runs.
12:36 < jtv> wgrant: is there any conceivable reason not to add amd64 support when setting up the sampledata for soyuz?
12:37 < wgrant> jtv: No.
12:37 < jtv> noodles775: there's your answer. No reason. Fixing.
12:37 < noodles775> jtv: great.
12:39 < jtv> noodles775: testing the fix.
12:39 < noodles775> jtv: I wonder if in the future we should separate out utilities/
12:40 < noodles775> (ie. it could be run multiple times).
12:41 < jtv> noodles775: we have that option. But I think we'll get a lot of documentation benefit out of sticking with ppa-user for now.
12:41 < noodles775> Right.
12:42 < noodles775> Wow... automatic addition of my GPG key :)
12:42 < jtv> yup
12:44 < jtv> noodles775: It was hard, but I hope worth it. I just pushed the version that always includes amd64 support.
12:46 < noodles775> jtv: it seems to have added a third key, in addition to the two identified by my email?
12:46 < jtv> noodles775: the bogus one is for signing the Code of Conduct. Please don't make me rework that to use the proper key (and prompt you for a passphrase)
12:46 < noodles775> jtv: ah, no worries :)
12:47 < jtv> noodles775: but glad to hear that it picked up both keys for someone who had two. :-)
12:47 < noodles775> jtv: and none of them are found in zeca when clicking on the key id?
12:48 < noodles775> jtv: actually, if I modify the final url param to op=get it finds it.
12:48 < jtv> noodles775: yup
12:48 < jtv> that would've happened with a manual upload as well, app'ly
12:48 < noodles775> but not op=index.... ok, but it's there :)
12:51 < noodles775> jtv: Another thought, it'd only be an extra 1 line to create a default PPA for the user in create_ppa_user? (you could just use factory.
12:51 < jtv> noodles775: I thought that'd be a nice next feature, but I think you just saved me the research.
12:51 < noodles775> jtv: great!
12:52 -!- salgado [~salgado@
12:53 -!- gmb changed the topic of #launchpad-reviews to: on call: gmb || reviewing: adiroiban || queue [adeuring] || This channel is logged: http://
12:53 < jtv> noodles775: should I add virtualized=False?
12:54 < noodles775> jtv: yes, definitely.
12:54 < jtv> noodles775: running tests...
12:55 * noodles775 tries uploading a package with the new setup.
12:56 -!-...
| Jeroen T. Vermeulen (jtv) wrote : | # |
Okay, I've added creation of the PPA ("test-ppa") and addition of an external dependency on Lucid.
| Jeroen T. Vermeulen (jtv) wrote : | # |
Not sure how this got turned into a review request for myself, but I approve.

= Bug 527170 =
This branch automates more of the manual work needed to get a working
local Soyuz setup. For the current process, see:
https:/ /dev.launchpad. net/Soyuz/ HowToUseSoyuzLo cally
I already implemented a script that does part of the work needed on the
dev sample data, based on wgrant's original, but some features are
added:
* --amd64 option automates setup of amd64 support.
* Creates a user ppa-user, with a fixed name.
* Signs the Ubuntu Code of Conduct for ppa-user (with a fake key).
* Gives you a fixed URL for adding your own GPG key.
* --email option lets you specify your email address of choice.
* Adds ppa-user to ubuntu-team.
The dev server won't actually be able to send email to your chosen email
address (although it will try, see the wiki page) but the choice makes
it easier for you to attach your GPG key. This is needed when you sign
uploads.
I tried automating the registration of a GPG key, or use of a dedicated
one, but no solution was really satisfactory. Well, working with gpgme
to get the real key based on your email address would have been, but it
seems that our scripting environment forces gpg to live in a temporary
directory rather than in ~/.gnupg.
This is a utilities script acting on the dev playground database, so
there's no real testing. But at least the script is exercised by the
test suite so we can detect obvious breakage:
{{{
./bin/test -vv -t sampledata-cleanup
}}}
No lint.
There's also a new script utilities/ start-dev- soyuz.sh, also based on
wgrant's original. I regularlized it a bit and made sure the necessary
directories in /var/tmp are created. I have no idea how to test this
second script without (1) upsetting the test environment, or (2) porting
it to python and adding a lot of weight. For this script, used in
manual testing only and easy enough to edit, I don't think that's worth
the trouble.
Jeroen