[01:22] <dobey> wgrant: great, thanks
[02:10] <dobey> wgrant: oh, except i can't rename a team that has a mailing list or PPA. :-/
[02:37] <wgrant> dobey: not without removing those first, no. but if it permits a rename it will rename everything.
[07:35] <Terry__> hi there, I host a website on Launchpad at https://launchpad.net/gcc-arm-embedded. When view its page source, I saw something like google-analytics/ga.js". Does this mean my website is enabled for google analytics?
[07:38] <wgrant> Terry__: Launchpad.net as a whole uses Google Analytics. It's not accessible on a per-project basis.
[07:39] <Terry__> Thanks for help. Is it possible to extract or recognize results for my site from the whole result of Launchpad?
[07:40] <wgrant> We don't have a way to provide that information to project owners today.
[07:40] <Terry__> OK. I got it.
[12:53] <Rituooos> Hey could somebody help me out??
[12:53] <Rituooos> I am having issues while trying to pull the original file using bazar
[12:56] <wgrant> Rituooos: What exactly isn't working?
[12:57] <Rituooos> the build
[12:58] <Rituooos>  bzr builddeb
[12:58] <Rituooos> i'll send you the pastebin id.
[12:58] <wgrant> That would be helpful.
[13:00] <Rituooos> http://pastebin.com/QnX6HCNv
[13:01] <wgrant> Rituooos: That worked fine, except it wasn't able to use gpg to sign the build result, because it can't find a key to use.
[13:01] <wgrant> Rituooos: Is that your name and email address?
[13:02] <Rituooos> no it isnt
[13:02] <Rituooos> but i did login with lp login rituspaks
[13:02] <Rituooos> ritusparks
[13:02] <Rituooos> but its the same result evry time
[13:03] <wgrant> You probably don't care about the signature for a local build, anyway. So try 'bzr builddeb -- -us -uc' to tell it not to try to sign anything.
[13:04] <Rituooos> okay! Let me try
[13:05] <Rituooos> I got a clean build! Thank you
[13:05] <wgrant> Excellent.
[16:53] <cgregan> hello Launchpad team....who is the best one to talk to about enabling privacy on a project?
[16:55] <dobey> cgregan: you need someone on the webops team, i think.
[16:56] <cgregan> dobey: I think it is just a matter of a commercial licence
[16:57] <dobey> cgregan: i don't know if i have enough permissions to tweak those bits. anyone on webops should though.
[16:58] <cgregan> ah..ok dobey
[16:58] <cgregan> thanks
[16:58] <dobey> and most of the people dealing with lp bugs and such are in .au/.nz area anyway, so it'd be a few more hours before they show up
[16:59] <cgregan> noted..thanks
[18:09] <KaZeR> hi there. i want to automate the synchronization between our translation template and what we have in launchpad, but my template always go as 'needs review', so it kinda break the automation
[18:09] <KaZeR> i'm using "translations-lp-upload -p navit -e trunk -t navit po/navit.pot "
[18:09] <KaZeR> what am i doing wrong?
[18:09] <KaZeR> also, when uploading .po files, they also go "needs review" and i have to update the template manually from the form (from "nothing selected" to "navit")
[19:59] <lifeless> dobey: sorry I wasn't more help in #bzr, bad timing :)
[19:59] <dobey> lifeless: it's ok. i figured it out, and i think it works
[19:59] <dobey> lifeless: https://code.launchpad.net/~dobey/tarmac/bzr-export/+merge/193130 <- does the use of export() make sense there?
[20:01] <lifeless> dobey: do you want just the source code and no bzr metadata? If so, yes
[20:01] <dobey> lifeless: yes, to prevent someone submitting a branch that uses bzrlib (or bzr cli) in the tests to commit their changes anyway, or do nasty things
[20:02] <dobey> and it also helps make people write cleaner code by not writing code that depends on the vcs for the tests to pass
[20:03] <lifeless> dobey: fair enough. I'll note that a fair number of projects use their VCS to generate changelogs etc
[20:03] <lifeless> dobey: which this would prevent
[20:04] <lifeless> dobey: I would be inclined to let individual projects make this choice, rather than forcing it in the framework
[20:04] <dobey> lifeless: right. but that's also not something that should be happening during testing of the project itself though, but rather during release or something
[20:05] <lifeless> dobey: more comprehensive CI systems often don't draw a hard line between those things
[20:05] <lifeless> dobey: it's a pipeline, with artifacts gathered as you go
[20:05] <lifeless> dobey: anyhow, just my 2c :)
[20:07] <dobey> lifeless: yes, finding a good balance isn't easy. i'm trying to make it more secure for people to run tarmac to handle branch merges in their projects, right now. if there are things that need to be more lenient as features get added, i'll revisit that when the time comes
[20:08] <dobey> but making an apparmor profile for a thing that runs arbitrary code anywhere on the system, is very hard to do, so trying to confine it a bit to improve security and usability, and will relax stuff as needed in the future
[20:09] <lifeless> dobey: interesting
[20:09] <lifeless> dobey: so, what about just spinning up an openstack vm
[20:09] <lifeless> dobey: then do the merge locally, and then rsync the merged tree up into the vm
[20:11] <dobey> lifeless: that's possible, but would be better to just run tarmac in throwaway VMs that you manage with juju/puppet/etc at that point, too, if you have the resources to do that
[20:11] <dobey> lifeless: so trying to make it easier for people who don't have those resources, or don't want to spend time setting up a VM/lxc/chroot to do it all in
[20:11] <dobey> but will also make it easy to do that when it can be done, as well
[20:12] <lifeless> dobey: well, no, because a throwaway vm with permissions to push to your trunk is no longer secure
[20:13] <dobey> lifeless: it's exactly as secure as anything else with permissions to push to your trunk
[20:13] <lifeless> dobey: that I suggested above didn't have permissions to push to your trunk
[20:13] <lifeless> dobey: because the merge logic was decoupled from the test execution logic
[20:15] <dobey> lifeless: well if you rsync the whole tree with the bzr metadata, then it does. the merge happens before the tests are run, and the merged-into tree is the target remote branch (a lightweight checkout) with permissions to commit
[20:15] <lifeless> dobey: surely the ssh key isn't stored within that tree?
[20:15] <lifeless> dobey: and I wasn't proposing that you rsync it *back*
[20:16] <dobey> no, it's not
[20:16] <lifeless> then I'm not sure how one would commit on that basis
[20:16] <dobey> but still, it requires the infrastrcture to do it
[20:16] <lifeless> sure