[06:28] <davide> hi all
[06:29] <davide> I have a problem with utilities/make-lp-user
[06:29] <davide> ./make-lp-user  -e davide@davide.galletti.name davide
[06:29] <davide> gpg: sending key E0206B3F to hkp server keyserver.launchpad.dev
[06:30] <davide> if I issue the command:
[06:30] <davide> ...
[06:30] <davide> gpgkeys: HTTP post error 7: couldn't connect to host
[06:30] <davide> ...
[06:31] <davide> any hints?
[07:01] <StevenK> davide: Are the Launchpad services running on the machine?
[07:16] <davide> yes I guess they are running;  https://launchpad.dev works
[08:28] <wgrant> jtv: Morning.
[08:28] <jtv> wgrant: I'd answer the same thing but let's be honest, we're both well past morning.  :-)
[08:28] <jtv> Hi!
[08:28] <wgrant> Shh.
[08:29] <jtv> Oh... sorry.  :)
[08:29] <wgrant> So, I've had a few people complain to me that Rosetta spams them too much for package uploads.
[08:29] <wgrant> They are really not interested in success notifications.
[08:29] <wgrant> And really wish they would go away.
[08:29] <wgrant> Some normalish uploads result in hundreds of emails.
[08:29] <wgrant> This is considered suboptimal.
[08:30] <henninge> wgrant: Hi! Thanks for relaying that.
[08:30] <henninge> wgrant: what would be considered optimal, then?
[08:31] <dpm> ah, that's bug 353648
[08:31] <_mup_> Bug #353648: Template import success notifications shouldn't be sent to package uploaders <Launchpad Translations:Triaged by danilo> <https://launchpad.net/bugs/353648>
[08:31] <wgrant> henninge: Failures only.
[08:31] <jtv> Not surprising.
[08:31] <jtv> In fact I think it was anticipated.
[08:32] <henninge> jtv: It also is not a new problem, is it?
[08:32] <jtv> No, not a new problem.
[08:33] <jtv> Success notifications were reasonable when the normal thing to do was upload a file or tarball, manually.
[08:33] <adeuring> good morning
[08:33] <henninge> jtv: but we can tell success by simply looking at the queue, can't we?
[08:34] <henninge> do we know of anybody that depends or works with these success emails?
[08:34] <henninge> adeuring: moin
[08:34] <adeuring> hi henninge1
[08:36] <jtv> hi adeuring
[08:36] <adeuring> hi jtv!
[08:36] <jtv> henninge: we used to get some Ubuntu import statistics that way, but that's a long time ago.
[08:36] <wgrant> It's not a new problem, no. It's been a point of concern for a long time now.
[08:37] <jtv> I think the reasonable assumption is that unless you hear otherwise, a change goes in—and soon.  That too has improved a lot.
[08:38] <wgrant> That's what we do for the builds themselves.
[08:38] <wgrant> It works well.
[08:40] <jtv> The only case I can think of where they could really be nice to have is for uploads that get held up.  So a "you have entries stuck in needs-review" email could well be enough to replace success messages.
[08:41] <jtv> Maybe it's also helpful to have a "the overall queue has 213,561 enrtries and the backlog is 3 days" message, like I did for the export queue.
[08:42] <jtv> (You won't usually see that because it only shows up when there's something noteworthy to say)
[08:42] <henninge> jtv: Also, our idea about mailing queue review comments could fix some of that.
[08:43] <jtv> Only very indirectly, I think, in that they speed up the interaction.  But we'd only be sending those when we were indeed reviewing the entries.
[08:58] <henninge> jtv: recife branch has a new revision! ;)
[08:58] <henninge> jtv: do we tag bugs on the integration branch as qa-needstesting?
[08:58] <jtv> henninge: not automatically, no...
[08:59] <henninge> I noticed that ...
[08:59] <henninge> I mean, manually.
[08:59] <jtv> henninge: as long as we keep the full list then we can leave that until we start integrating.
[09:00] <henninge> jtv: well, we have the full list in form of the commits to the integration branch.
[09:01] <jtv> Not ideal.
[09:01] <jtv> We should make sure the bugs are attached to the blueprint, and maybe tagged.
[09:02] <jtv> The kanban board can be a distraction from that sort of housekeeping.
[09:04] <henninge> We have not been using a tag and I am not sure we reliably attached them to the blueprint.
[09:06] <jtv> henninge: I'll just check my own ones...
[09:07] <henninge> jtv: I wonder what will happen when we merge the integration branch into .... db-devel(?) Won't the qa-tagging script pick them up anyway?
[09:08] <jtv> henninge: probably, that's true...
[09:08] <henninge> jtv: so we need to make sure to have bugs on branches - which we usually do.
[09:08] <jtv> There are a few that we can't Q/A individually anyway, such as "rename the flags"
[09:09] <henninge> yes, I think I remember we already agreed that QA will have to wait until then. We will have to land that early in a cycle.
[10:42] <james_w> bigjools: could you give me a pointer to a test using a "script hook"? I haven't heard of them before.
[10:42] <bigjools> james_w: sure, it's pretty simple, hag on
[10:42] <bigjools> hang, even
[10:43] <bigjools> james_w: see lib/lp/archivepublisher/tests/test_generate_ppa_htaccess.py
[10:43] <james_w> thanks
[10:43] <bigjools> james_w: it has getScript and a runScript helpers
[10:43] <bigjools> one of them calls Popen, the other grabs the script class and calls its main()
[10:44] <bigjools> james_w: see cronscripts/generate-ppa-htaccess.py for the top-level script
[10:44] <bigjools> it doesn't do much other than instantiate the script class and run it
[10:57] <james_w> yay, tests that aren't run in lp.soyuz.adapters
[10:57] <bigjools> :/
[10:58] <james_w> how does the runner find tests?
[10:59] <bigjools> I thought it looked for anything called test_*
[10:59] <bigjools> seems not
[10:59] <james_w> it does
[10:59] <james_w> missing __init__.py
[11:00] <bigjools> gargh
[11:00] <bigjools> that is such a stupid Python feature
[11:01] <lifeless> discovert can work around it a bit
[11:01] <lifeless> namespace packags can too
[11:01] <lifeless> also there is some magic/aweful coming up in newer pythons too
[11:09] <deryck> Morning, all.
[11:22] <lifeless> deryck: 'lo
[11:23] <deryck> hi lifeless
[11:25] <ajmitch> hi
[11:30] <ajmitch> mrevell: out of interest, when's the cutoff for landing code for 10.06?
[11:31] <mrevell> ajmitch, Friday this week, AFAIK
[11:31]  * ajmitch might try & get the blueprint api stuff reviewed at least
[11:31] <ajmitch> ok
[11:32] <james_w> "Confirm this transaction? [yes, no]"
[11:32] <james_w> just want you want from a webservice, an command line prompt
[11:33] <wgrant> That's a webservice?
[13:15] <james_w> why isn't packagecopyrequest just part of the job system?
[14:56] <cakofony> Is there any way to get the "uses launchpad for" information from the api?
[14:59] <bigjools> james_w: the job system wasn't mature enough when copy archives were written
[14:59] <james_w> bigjools: so you would have no problem with making it a job?
[14:59] <bigjools> it was done in a way to make it possible though
[14:59] <bigjools> nope
[14:59] <james_w> ok
[15:00] <bigjools> that's the intention
[15:11] <cakofony> Using the api, is it possible to iterate through all the developers? or count them?  It only returns up to 50 for me
[15:14] <james_w> cakofony: it's set to return the 50 top contributors to LP, and not iterate through all people, presumably to prevent abuse
[15:16] <cakofony> james_w: is there any way to get the full list of developers?  I'm working on an open source project that gathers data from forge sites (with sleeps, we dont want to ddos anybody)
[15:16] <james_w> no, there isn't
[15:17] <cakofony> can I search for all the people who have contributed to each project?
[15:18] <james_w> cakofony: as for "uses launchpad for", I don't think that's exposed right now, you can file a bug requesting it
[15:18] <james_w> no, you can't do that either as far as I know
[15:18] <cakofony> Alright, thanks for your help! ^.^
[16:05] <sinzui> jml, talk>
[16:05] <sinzui> talk?
[16:27] <jml> sinzui, hi
[16:28] <sinzui> hi jml
[16:28] <jml> sinzui, sorry, meeting ran over time
[16:28] <jml> sinzui, still up for a quick mumble?
[16:28] <sinzui> yes
[16:55] <sinzui> jml: http://changelogs.ubuntu.com/changelogs/pool/universe/w/wsjt/wsjt_5.9.7.r383-1.4/copyright
[19:20] <james_w> are there docs on creating a db patch?
[19:21] <james_w> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[20:09] <james_w> is changing security.cfg an entirely manual thing? How do I know what is appropriate to add?
[20:09] <lifeless> yes
[20:09] <lifeless> uhm
[20:10] <lifeless> generally you add 'just enough' permissions
[20:10] <lifeless> and if they seem broad reconsider the design
[20:13] <james_w> luckily most of the role names actually make sense
[20:21] <lifeless> \o/
[23:18] <james_w> anyone around who knows the job system and can provide some advice?
[23:18] <james_w> I would like to know the preferred way to implement a new job
[23:20] <james_w> Whether a fairly generic job with json, implying serialising some things to strings to lookup as keys when the job is run, or a more-specific job type that can have References to the other models, saving that serialisation step, would be preferred.