[01:01] <nigelb> wallyworld_: \o/
[01:01] <nigelb> It works, except for the anonymous user case, which I'm fix0ring now :)
[01:17] <lifeless> can has review? https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71794
[01:18] <lifeless> can has review two? https://code.launchpad.net/~lifeless/python-oops-datedir-repo/extraction/+merge/71795
[01:18] <lifeless> can has review three? https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71796
[01:19] <lifeless> was there any objection to just nuking 2011-08-17 01:12:19 WARNING Found 2 competing templates with translation domain 'javascript': "openerp-javascript in OpenERP Web Client 6.0"; "view-calendar-javascript in OpenERP Web Client 6.0".
[01:19] <lifeless>  ?
[01:21] <wgrant> lifeless: Why has that started spamming us now, anyway?
[01:21] <wgrant> lifeless: I wonder if somebody broke asuka's mail capturing.
[01:22] <lifeless> probably puppetisation
[01:24] <lifeless> rt 47413
[01:24] <lifeless> and set to prior 90
[01:24] <wgrant> Would be nice if we were warned when nasty machines like that were puppetised, so we could watch for breakage.
[01:25] <wgrant> Only 90?
[01:25] <wgrant> We may be spamming innocents.
[01:25] <lifeless> 90 is zomg
[01:25] <wgrant> All Zopeless mail is probably untrapped.
[01:25] <lifeless> drop-everything
[01:25] <wgrant> Ah
[01:25] <lifeless> the only higher thing I can sanely do is ring the escalation phone at 2:25am
[01:26] <lifeless> This hasn't been picked up on for several days.
[01:26] <wgrant> Yeah.
[01:26] <lifeless> so I think that would be overkill
[01:26] <wgrant> Indeed.
[01:27]  * lifeless looks around for a revuer
[01:32] <StevenK> lifeless: Hm?
[01:33] <lifeless> StevenK: oh hai; I have three small reviews up ^
[01:33] <lifeless> StevenK: (they really are small. The Genuine Article.)
[01:43] <jtv> StevenK, wgrant: mind if I update & restart dogfood?
[01:44] <StevenK> jtv: Go ahead
[01:44] <jtv> OK
[02:09] <lifeless> StevenK: thanks!
[02:10]  * StevenK tries to get his eyes unglazed after reading 4,000 lines of diffs
[02:10] <lifeless> time for a vodka tonic ?
[02:10] <StevenK> At midday?
[02:11] <lifeless> every 4000 lines :P
[02:11] <lifeless> code review drinking game
[02:12] <StevenK> Oh, I was going to go with "Every time you mark an MP as approve, take a drink. Every time you mark an MP as Needs Fixing, finish the glass."
[02:12] <lifeless> ah, thank you internet: http://movieboozer.com/2011/07/04/source-code-2011-drinking-game/ close enough
[02:13] <lifeless> StevenK: that works too
[02:23] <lifeless> fun
[02:23] <lifeless> http://www.depesz.com/index.php/2011/07/06/bloat-happens/#more-2231
[03:01] <jtv> btw StevenK, wgrant: I put a script on dogfood that updates the code / dependencies / db permissions, rebuilds the current branch, and restarts the app server.
[03:02] <jtv> Takes a few minutes but it's convenient, and can save us the "damn this time a partial update doesn't quite do it" exceptions.
[03:02] <jtv> *Unfortunately* it breaks at the "make" where the Makefile tries to rm -rf /var/tmp/mailman, which is root-owned on dogfood.
[03:03] <wgrant> A few minutes?
[03:03] <wgrant> You mean a few hours?
[03:04] <jtv> Although… no, /var/tmp/mailman's been fixed.
[03:04] <jtv> wgrant: no, a few minutes.
[03:04] <jtv> It doesn't update the database (though it does update the schema)
[03:05] <jtv> Of course if you didn't run it for months on end, it'd probably take a lot longer.  But having it be easy to run would also solve that.  :
[03:05] <jtv> :)
[03:05] <jtv> I just ran the thing, actually.
[03:06] <jtv> wgrant: have a look — ~launchpad/bin/upgrade-dogfood-launchpad
[03:07] <wgrant> I've only SSHed into the DC once this week, and I'm trying to not do it again :)
[03:07] <jtv> OK OK OK
[03:07] <jtv> Just try it sometime.  :)
[03:08] <StevenK> Haha
[03:09] <jtv> Uh-oh.  StevenK's laughing at me.  This can't be good.
[03:09] <nigelb> wgrant: Are you still on vacation?
[03:10] <jtv> nigelb: if you have to ask, I guess that means he never was.
[03:11] <nigelb> jtv: haha. I think he needs to vacation in some small island without internet.
[03:11] <jtv> I thought he lived on one?
[03:11] <nigelb> "small"
[03:11] <jtv> It's that blip just off the cost of Asia, isn't it?  It has that airport where you refuel on the way to South America.
[03:11] <StevenK> jtv: You can talk
[03:12] <jtv> Yes.
[03:12] <nigelb> haha
[03:12] <jtv> Yes, I can.
[03:12] <StevenK> jtv: I think Australia has more Internet than Thailand
[03:12] <jtv> That can't be right.  Thailand has more internet than any other country in the world.
[03:12] <jtv> Measured by the number of sites the government censored, at least.
[03:12] <nigelb> jtv: is in Thailand?
[03:13] <jtv> More than China.  Come on, who's laughing now?
[03:13] <nigelb> I thought it was stub in Thailand.
[03:13] <jtv> Yes, yes, you're right.  I'm mistaken.
[03:19] <lifeless> nigelb: we are allowed > 1 person in a country :)
[03:20] <lifeless> jamesh: hi
[03:20] <jamesh> hi lifeless
[03:20] <lifeless> jamesh: did you release that python-gpg update?
[03:20] <nigelb> lifeless: haha
[03:20] <jamesh> no I haven't.  I may as well sort that out now.
[03:21] <lifeless> jamesh: I can put a nag into cron if thats better for you :P
[03:22] <lifeless> jamesh: also how much do you know about wsgi-oops
[03:23] <jamesh> lifeless: I've only made a few small changes to it.  It started out with the Landscape team trying to extract the LP OOPS system, and then we added some WSGI glue to that
[03:24] <lifeless> jamesh: yeah
[03:24] <jamesh> what did you want to know?
[03:24] <lifeless> jamesh: I'm redoing that but differently... and migrating LP at the same time rather than never :)
[03:24] <lifeless> jamesh: well, the traceback extract grabs an awful lot of data
[03:24] <lifeless> jamesh: thats not marshallable in a sane way into the current rfc822 format
[03:25] <lifeless> jamesh: but I'm wondering whether its been useful to folk; should I file a wishlist bug on python-oops to port that code across ?
[03:26] <jamesh> lifeless: back when I was on the LP team, one of the long term goals was to switch to storing OOPS reports as zip files, as a way to make it easy to represent attachments like the traceback and sql statement log.  Obviously that has never happened
[03:27] <jamesh> lifeless: at this point, if the reports are readable by oops-tools, I don't think many people would care what format they are stored in
[03:27] <lifeless> jamesh: right; I'm more talking about the stack-walking variable extraction code than format
[03:28] <jamesh> oh.
[03:28] <lifeless> jamesh: porting oops-tools to use lp:python-oops-datedir-repo/serializer_rfc822 is fairly straight forward - and once thats done migration to e.g. bson dicts is trivial.
[03:30] <jamesh> lifeless: are you talking about wsgi-oops, or the LP oops code here?
[03:31] <lifeless> jamesh: wsgi-oops has stack-variable-extraction, LP oops doesn't (it just uses zope.exceptions.format_exception), oops (the new module) doesn't, (It just uses traceback.format_traceback)
[03:31] <jamesh> I remember the LP oops code used zope's traceback collection API, but the wsgi-oops one seems fairly simple
[03:33] <jamesh> oh.  I see what you're talking about.
[03:35] <jamesh> I don't think the locals or globals dictionaries from the traceback frames ever make it into the serialised oops report
[03:35] <lifeless> jamesh: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/createhooks.py#L91
[03:35] <lifeless> jamesh: right, because the rfc822 format is so limited ;)
[03:35] <jamesh> I know the LP code used Zope's traceback formatter, which did include some locals in the output
[03:36] <lifeless> jamesh: yeah, so the lp errorlog module now installs its own exc_info grabber
[03:36] <lifeless> which is about the same as the code I just linked to, but usin the zope thingy
[03:38] <jamesh> lifeless: so, given that we aren't storing this data, perhaps it would be okay to leave it out of the new system you're building.  If it is useful, then perhaps we can work out a way of storing it later.
[03:39] <lifeless> jamesh: thanks
[03:39] <lifeless> jamesh: I had tentatively concluded that
[03:39] <lifeless> time to register yet another lp project
[03:39] <lifeless> python-oops-wsgi, to avoid confusion :P
[03:39] <jamesh> lifeless: it might be worth checking up with the Landscape folks to see if they are using a different serialiser that does actually store the data though.
[03:40] <jamesh> (or you might have already done that)
[03:40] <lifeless> jamesh: I've chatted with them about this project, not about that specific bit of detail.
[03:40] <lifeless> it should be easy enough to port the logic later
[03:41] <lifeless> my first goal is a generic, used by LP, and used by a non-LP wsgi app (the gpgverify one by choice), implementation
[03:41] <lifeless> with strict dependency boundaries - for folk shipping it, don't want to bring in the universe
[03:42] <lifeless> second goal will be updating oops-tools to use the parser module from datedir-repo to replace its homegrown one
[03:42] <lifeless> then we can add a new serialiser to datedir-repo and win.
[03:56] <jamesh> lifeless: https://launchpad.net/pygpgme/trunk/0.2
[03:57] <lifeless> jamesh: sweet
[03:57] <lifeless> now to get it uploaded $everywhere :)
[03:57] <lifeless> jamesh: http://pypi.python.org/pypi/pygpgme
[03:57] <jamesh> I'm doing that.
[03:58] <lifeless> jamesh: heh, sorry!
[04:00] <jamesh> http://pypi.python.org/pypi/pygpgme/0.2
[04:04] <lifeless> jamesh: awesome
[04:04] <lifeless> I'll chase up lp's dep versions a little layer
[04:08] <poolie> lifeless: hi; how would we go about getting a release of restfulclient and co
[04:08]  * poolie is hoping for something better than 'do it myself'
[04:13] <lifeless> https://dev.launchpad.net/ReleaseChecklist
[04:13] <lifeless> poolie: it is do it yourself
[04:13] <poolie> lifeless: what i really meant is, can't the lp core team do it?
[04:14] <lifeless> modulo the pypi permissions (we -really- would benefit from a teams module there)
[04:14] <lifeless> and I can grant pypi permissions as needed, I think flacoste added me to everything
[04:15] <lifeless> this checklist needs trimming and automation, rather desperately, but it is functional
[04:18] <poolie> phut
[04:18] <poolie> i feel like i'm already kind of doing at least half the work by fixing the bug
[04:19] <poolie> oh well
[04:19] <lifeless> sure
[04:20] <lifeless> I mean, thats what bzr contributors expect - they fix, core team releases on $whatever schedule
[04:20] <lifeless> are you asking because a release is long overdue? or its particularly urgent?
[04:21] <poolie> the first
[04:22] <poolie> let me check if this is actually true though
[04:25] <poolie> not all that long
[04:26] <poolie> perhaps the difference is there's no obvious schedule
[04:26] <lifeless> how much merged work is sitting unreleased?
[04:26] <poolie> though, that's also somewhat true for bzr plugins
[04:26] <poolie> just two https://launchpad.net/lazr.restfulclient/+milestone/0.11.3
[04:27] <poolie> it's not urgent, it just would be a shame to have them sit for a long time
[04:27] <poolie> i thought there were more in other lp dependencies
[04:29] <lifeless> so one possibility is that the system is working
[04:29] <lifeless> another possibility is that with leonard gone, folk are not releasing-on-land, nor will anyone release-on-schedule
[04:30] <jtv> \o/ I think I've figured out what's breaking rocketfuel-get on dogfood.  When it looks for "sourcecode" dirs to re-link, in dogfood's setup it also finds lp-sourcedeps.  Maybe rocketfuel-get should exclude lp-sourcedeps explicitly.
[04:31] <poolie> that's the uncertainty that was in my mind
[04:32] <lifeless> I think some discussion on list is in order
[04:32] <lifeless> I'm not sure what (or even whether) we have a policy about doing-releases-of-things-we-garden [and perhaps we don't need one... but perhaps we do]
[04:34] <lifeless> jtv: isn't lp-sourcedeps normally a level up ?
[04:34] <jtv> Normally, yes.
[04:35] <jtv> But these scripts evolve over time.
[04:35] <jtv> So it depends on the age of the LP installation.
[04:35] <jtv> And in this case, permissions and responsibilities.
[04:35] <jtv> If my hunch is right, fixing up rocketfuel-get is the least invasive.
[04:49] <lifeless> ugh
[04:49] <lifeless> failing buildmaster tests
[04:50] <lifeless> could not stab /var/tmp/buildd/build-slave.pid
[04:50] <StevenK> Oh, screw you, testrepository
[04:50] <lifeless> StevenK: ?
[04:51] <lifeless> oh, and for bonus I have a test fail in there too
[04:51] <StevenK> testr failing --list => no output, testr run --failing => I'll just run every single test, lol
[04:51] <lifeless> StevenK: heh
[04:51] <StevenK> With no output
[04:51] <lifeless> StevenK: bit of a foot-gun event, I guess.
[04:51] <StevenK> steven@liquified:~/launchpad/lp-branches/denorm-bspph% testr run --failing
[04:51] <StevenK> running=xvfb-run ./bin/test --subunit
[05:09] <lifeless> jamesh: do you happen to know how I can reset gnome-gpg to ask for my passphrase again ?!
[05:10] <lifeless> and preferrably nuke the silly thing that ever captured it
[05:10] <jamesh> lifeless: delete the passphrase from the keyring using the "Passwords  and Encryption Keys" app
[05:10] <jamesh> I haven't used gnome-gpg in years (gnupg-agent seems to do a good job)
[05:11] <lifeless> jamesh: that seems to want to change the actual gpg managed passphrase
[05:12] <lifeless> jamesh: which isn't what I intend
[05:12] <jamesh> lifeless: you're looking on the passwords tab, right?
[05:12] <jamesh> not the "My Personal Keys" or "Other Keys" tabs
[05:13] <lifeless> jamesh: it shows 'passwords: default and 'Passwords: login'
[05:14] <jamesh> lifeless: right.  expand those and find the entry gnome-gpg added.
[05:14] <lifeless> there isn't one :)
[05:14] <jamesh> well, that's where gnome-gpg would be storing the passphrase
[05:14] <lifeless> ah
[05:14] <lifeless> I had to click 'unlock'
[05:14] <lifeless> to unlock the first folder, before it would show me its contents.
[05:14] <lifeless> ui win!
[05:15] <lifeless> jamesh: thanks!
[05:15] <jamesh> "passwords: default" would be a keyring from before the PAM integrated login keyring
[05:15] <jamesh> if it doesn't hold anything interesting you would probably be best off deleting it.
[05:15] <lifeless> jamesh: I've been running this homedir uninterrupted since, uhm, 2000
[05:16] <lifeless> jamesh: it appears to have a lot of semi interesting things
[05:16] <jamesh> the login keyring is locked and unlocked automatically by pam
[05:17] <jamesh> the default one requires manual password entry (assuming it has a password set)
[05:19] <lifeless> thanks
[05:19] <lifeless> bbiab
[05:31] <StevenK> jtv: O hai. Do you have time for a small review?
[05:32] <jtv> Yes, okay
[05:32] <StevenK> jtv: https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-qualified/+merge/71812
[05:32] <jtv> I find it odd that you should come to me with this request, after all my hard work to scare you off.
[05:33] <StevenK> jtv: lifeless owed me, but he's buggered off. And you're supposed to be OCR anyway
[05:33] <jtv> ah yes
[05:34] <jtv> Anyway, I see a familiar pattern: it's as if someone has tried to make the SQL harder to figure out.
[05:34] <StevenK> Hah
[05:34] <jtv> By arbitrarily turning some keywords into lower-case, and putting the line breaks in odd places.
[05:35] <jtv> Could you please just put the FROM, in all caps, at the beginning of the line?
[05:35] <StevenK> jtv: In bugtask?
[05:35] <jtv> Yes.  And maybe make the other SQL keywords consistently upper-case as well?
[05:36] <wgrant> I wish it was practical to write a lint check to force that.
[05:36] <jtv> Yes!  Oh God, yes!
[05:36] <jtv> And go away.
[05:37] <StevenK> jtv: Anything else?
[05:38] <jtv> AFAICT it's all cosmetic.  Am I missing something?
[05:38] <StevenK> wgrant: I'd solve the bloody problem and storm-ify the methods, but they make my eyes bleed.
[05:38] <StevenK> jtv: It's lead-up to adding a sourcepackagename column to SPPH
[05:39] <lifeless> if you can make a lint check for it, you can make an automated fixer for it.
[05:39] <jtv> Then go forth and land ye your branches, that they may be merged.
[05:41] <jtv> lifeless: you can, but lately I've really come to appreciate the affirmative power of manual formatting: "yes I've thought about this, yes I mean this to be in the source code as it is."
[05:42] <jtv> I even rely on it by not inserting proper spacing into temporary debug statements etc, as an extra safeguard against accidentally leaving them in.
[05:44] <lifeless> mmm, I can see an argument for that, but I'm not convinced
[05:46] <jtv> I'm not making an argument, I'm telling you how it is.  It helps.
[05:46] <wgrant> Let's just version control the AST.
[05:47] <lifeless> if python was just a little less fragile
[05:47] <lifeless> now where, was I, thats right, housework. Then extracting code to oops-wsgi
[05:48]  * jtv wonders if that is pronounced "oopski"
[06:49] <LPCIBot> Project db-devel build #814: FAILURE in 5 hr 47 min: https://lpci.wedontsleep.org/job/db-devel/814/
[07:07] <jtv> thanks for the surprise review, lifeless :)
[07:12] <lifeless> jtv: de nada
[07:25] <rvba> StevenK: Hi! Thanks for the review Steven, I made the corrections you suggested.
[07:36] <adeuring> good morning
[07:40] <jtv> morning adeuring
[07:41] <adeuring> hi jtv!
[07:52] <jtv> StevenK: you're not still reviewing, are you?  Because I've got this: https://code.launchpad.net/~jtv/launchpad/bug-824553/+merge/71823
[08:05] <bigjools> morning all
[08:07] <mrevell> Good morning
[08:15] <StevenK> rvba: r=me
[08:16] <rvba> StevenK: Thanks!
[09:33] <stub> lifeless: Was the reason pqm results weigh in at 400k for a single test failure because of the Librarian logs not being cycled between tests, or something else?
[09:33] <lifeless> librarian
[09:33] <lifeless> there is a bug open I think; all that needs to happen is the fixture glue to be tweaked to only attach new rows from the log, rather than all of it.
[09:33]  * stub wonders how the Librarian would cope with that many HUPs
[09:34] <lifeless> or truncate the log, or something.
[09:34] <lifeless> stub: stress test time!
[09:34] <stub> HUP HUP HUP HUP HUP OH JUST FSCK OFF
[09:34] <lifeless> stub: one easy way would be to diff the log in memory - read or stat at the start, and etc
[09:35] <stub> Maintain an open file, seeking to the end after each test.
[09:35] <stub> fsync before the seek if you care.
[09:36] <stub> somehow handle the tests that test Librarian log file rotation :-)
[09:39] <stub> How good is the bzr cherry picking story now? If I merge a revision from db-stable into devel, will it cause a conflict when stable is merged to db-devel?
[09:45] <poolie> hi all
[09:45] <poolie> any lazr or lplib experts that could look at https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832 ?
[09:45] <poolie> is there a more kosher way to do it?
[09:47] <lifeless> stub: it may; but if the texts are identical it should never.
[09:47] <lifeless> and -woo- we have a wsgi layer.
[09:47] <stub> So as long as I don't have to resolve conflicts should be fine.
[09:47] <lifeless> and its (at least to me) a lot cleaner than the launchpad-loggerhead on. I may be biased.
[09:51] <cjwatson> jtv: sorry, I know I still owe you an assessment of your custom upload plans, and I promise to figure out what I think today - but any chance you could review https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection/+merge/71840 for me?  there was a regression when IS tried to deploy my previous meta-lp-deps change last night
[09:52] <jtv> cjwatson: funnily enough I was just composing another IRC message for you.  :)
[09:52] <jtv> I'm having a look.
[09:52] <lifeless> poolie: whats your cli for pqm called again ?
[09:52] <lifeless> (and bugs etc, your nih api client :P)
[09:53] <jml> lifeless: hydrazine?
[09:53] <lifeless> yes!
[09:53] <jml> lifeless: not to be confused with lptools or ubuntu-dev-tools ("ubuntu-dev" being code for "launchpad" there)
[09:54] <poolie> feed-pqm
[09:54] <poolie> in hydrazine
[09:54] <poolie> the nih api client is 'wrested'
[09:54] <lifeless> poolie: I needed it to do that review for you :)
[09:54] <poolie> which?
[09:55] <lifeless> hydrazine
[09:58] <jtv> cjwatson: taking a while for the MP to update.  Did you get a failure email by any chance?
[09:58] <cjwatson> not yet ...
[09:59]  * cjwatson pokes offlineimap just in case
[09:59] <cjwatson> jtv: it seems to be up to date when I look from here
[10:00] <jtv> cjwatson: yup, just got it at last.
[10:04] <jtv> cjwatson: not much I can do with this one, but reviewed.
[10:04] <jtv> Meanwhile, about those custom uploads...  :)
[10:05] <jtv> cjwatson: can you land it yourself?  I'm not even sure I can, tbh
[10:05] <jtv> Your MP I mean, not mine.
[10:06] <danilos> jtv, heya, I've got a branch up for review: https://code.launchpad.net/~danilo/launchpad/bug-826692/+merge/71836
[10:07] <jtv> danilos: do you now?  Good for you mate!
[10:07] <cjwatson> jtv: I can't; it should just involve merging it into lp:meta-lp-deps, which is owned by ~launchpad-committers and which apparently you just push stuff to directly rather than via PQM
[10:07] <danilos> jtv, yeah, I am just bragging around, thanks
[10:07] <cjwatson> judging from the commit history
[10:07] <jtv> cjwatson: yes, that's how it happens with the less well-managed branches.  Can't say I'm familiar with this one.
[10:07] <cjwatson> jtv: I can deal with talking to IS about the actual deployment stuff after that
[10:08] <jtv> danilos: let me just help colin out here, and then I'll get to your branch
[10:08] <jtv> Or maybe the other OCR… oh.
[10:08] <danilos> jtv, sure, thanks
[10:08] <danilos> :)
[10:09] <jtv> Oh wow, I've worked with meta-lp-deps in the distant past.
[10:09] <danilos> jtv, yesterday?
[10:09] <cjwatson> jtv: going to try to get my head round your mail now
[10:10] <jtv> Your considerable head.
[10:10] <jtv> Shouldn't be too hard.
[10:19] <stub> Can someone else run bin/test.py -vv test_garbo , and tell me if it hangs for over a minute on test_HWSubmissionEmailLinker and test_ObsoleteBugAttachmentPruner ?
[10:21] <danilos> stub, sure, need it on latest stable/devel/db-stable/db-devel?
[10:22] <stub> danilos: stable or whatever. I think it is an old problem nobody noticed.
[10:24] <danilos> stub, running now, you got me confused for a moment with bin/test.py instead of bin/test :)
[10:24] <stub> DWIM
[10:25] <jelmer> poolie: btw, can you land my branches on lp:lptools, or should I apply for members?
[10:25] <stub> Actually, needs to be stable or devel - I think a cherry pick from db-devel -> devel killed it.
[10:25] <jelmer> *membership
[10:25] <stub> danilos: ^^
[10:26] <poolie> there's already a bug for https://code.launchpad.net/~ubuntu-branches/ timing out right?
[10:27] <jtv> cjwatson: your change has landed.
[10:27] <poolie> jelmer: i'll look
[10:27] <danilos> stub, right, I am trying with stable
[10:27] <jelmer> poolie: thanks :)
[10:27] <poolie> you have the power!
[10:30] <danilos> stub, I am having some troubles with tests actually failing
[10:31] <stub> danilos: database in use errors?
[10:33] <danilos> stub, nope, LaunchpadSilentFailure or something :/
[10:33] <danilos> let me check my dependencies
[10:35] <danilos> (it's likely my download-cache is out of date)
[10:35] <cjwatson> jtv: thanks!  and replied (though whether you'll like the reply I'm not sure ...)
[10:35] <jtv> danilos: can't the preloading you're doing be done with load_related?
[10:35] <jtv> cjwatson: argh!
[10:36] <jtv> danilos: thinking specifically of do_eager_load (I understand you probably don't want to mess with that other code in detail)
[10:36] <danilos> jtv, not that I know of, since I need to do a bunch of "get me this and then stuff that is related to it" (I did start with a bunch of load_related and load_referencing initially)
[10:36] <danilos> jtv, i.e. I need double "related" indirection
[10:36] <jtv> Can't you pass a result set to load_related?
[10:36] <stub> So on stable, database/schema/trusted.sql no longer has _killall_backends - this removed in db-devel along with code changes. Looks like trusted.sql has ended up in stable without the code changes, which makes the db teardown rather flakey and slow for tests that used the librarian.
[10:37] <jtv> danilos: ahhh, iswym
[10:37] <jtv> you're starting out with a python-constructed nontrivial set of ids, not of objects.
[10:38] <stub> oh... nm. it is still in stable. It is in testfuncs.sql, not trusted.sql
[10:39] <stub> Running stable tests with a db-devel database... and it sometimes works!
[10:39] <jtv> danilos: done
[10:39] <danilos> jtv, thanks
[10:42] <jtv> cjwatson: aren't ddtp-translations tarballs flushed from the librarian after a while?
[10:43] <jtv> I mean, it's GC'ed automatically.
[10:43] <jtv> And AFAIK fairly aggressively.
[10:43] <jtv> (Also note that dsync isn't currently used.)
[10:46] <cjwatson> jtv: surely not *that* frequently?  there's usually a ddtp-tarball upload not very long before release
[10:46] <jtv> cjwatson: are we talking hours, days..?
[10:46] <danilos> stub, ok, finally got it all to a clean state, I don't see the lag: https://pastebin.canonical.com/51339/
[10:47] <stub> danilos: ta
[10:47] <cjwatson> jtv: for natty it was about two weeks (https://lists.ubuntu.com/archives/natty-changes/2011-April/011309.html)
[10:48] <cjwatson> jtv: but we could copy them if they're available and not worry if they aren't, I'd have thought
[10:48] <cjwatson> jtv: dsync> that's a shame
[10:48] <jtv> cjwatson: stub will correct me on this if needed but I think Librarian is on a much tighter GC schedule than that.  IIRC wgrant said flat-out that it would be impossible to do the copying for ddtp-translations.
[10:49] <wgrant> jtv: ddtp-translations is probably not expired.
[10:49] <cjwatson> jtv: what generates the md5sums index then?
[10:49] <wgrant> jtv: Rosetta translations are.
[10:49] <jtv> ahh
[10:49] <cjwatson> lp_archive@cocoplum:~$ ls -l /srv/launchpad.net/ubuntu-archive/ubuntu/indices/md5sums.gz
[10:49] <cjwatson> -rw-r--r-- 1 lp_publish lp_publish 29926782 Aug  8 10:23 /srv/launchpad.net/ubuntu-archive/ubuntu/indices/md5sums.gz
[10:49] <jtv> Okay, so we could add ddtp-translations.
[10:49] <cjwatson> that looks unfortunate
[10:49] <jtv> However
[10:49] <wgrant> cjwatson: It was generated by dsync.
[10:49] <cjwatson> (I'm fairly sure that there exist mirroring tools which look at indices/md5sums.gz)
[10:49] <stub> If the LibraryFileAlias is linked to another row in the DB, it is not garbage collected. If it is not linked, it will be removed in <72hours IIRC.
[10:49] <wgrant> Which we should really running again.
[10:49] <cjwatson> wgrant: yes, that's my point :)
[10:50] <stub> We can change that timeout easily enough, although we pay for it in disk space.
[10:51] <jtv> cjwatson: I have no doubt that it could be improved in lots of ways, but unless there's something decidedly wrong or unsafe I'd much prefer to get a partial solution in now and improve on it later, than drag this out further.  It's already sat around bit-rotting for longer than is usual nowadays.
[10:51] <cjwatson> jtv: that's fair enough, but I would like to see those comments addressed at some point
[10:51] <jtv> Absolutely.
[10:51] <cjwatson> I wasn't intending these to be blockers, but you did ask for a review :-)
[10:52] <jtv> But since this was originally billed as "if you think there's something you can do about it easily, you know, in a day or so..."
[10:52] <cjwatson> I *think* your date comparison approach is safe, even if IMO not the right thing
[10:52] <jtv> Well it was more a "if you know of any reason why this should not land, speak now or forever hold your peace" kind of thing.
[10:52] <cjwatson> perhaps you can turn it into bugs
[10:53] <jtv> Sure.
[10:53] <jtv> I was thinking kanban cards, but I can do both.
[10:53] <cjwatson> or that, I don't know your processes :)
[10:53] <cjwatson> just avoid being forgotten
[10:53] <jtv> An advantage of splitting these off is that other people can work on them, who knows, maybe even at the same time.  :)
[10:53] <cjwatson> :-)
[10:53] <cjwatson> thanks
[10:53] <jtv> Glad to help.  If you'll let me.  :-P
[10:56] <jtv> cjwatson: by the way, any idea where in LP these tarball names are already being parsed?
[10:56] <cjwatson> jtv: lib/lp/archivepublisher/{debian_installer,dist_upgrader,ddtp_tarball}.py
[10:56] <poolie> hello
[10:56] <jtv> Great, thanks.
[10:57] <poolie> if there's anyone on maintenance good at sql perhaps they could look at bug 827935
[10:57] <_mup_> Bug #827935: consistent timeout on user branch listing page <Launchpad itself:New> < https://launchpad.net/bugs/827935 >
[10:57] <cjwatson> which is what processes those uploads in the first place
[10:57] <cjwatson> # This code is mostly owned by Colin Watson and is partly refactored by
[10:57] <cjwatson> # Daniel Silverstone who should be the first point of contact for it.
[10:57] <cjwatson> current comments 'r' us
[10:57] <poolie> :)
[10:58] <poolie> i love how many old names still appear in the lp test data
[10:58] <poolie> daf, daniels,
[10:58] <poolie> stevea
[10:58] <cjwatson> (custom uploads used to be processed entirely by hand.  it was horrendous)
[10:59] <jtv> cjwatson: and you're saying that the first parameter in the tarball name is not needed for disambiguation?  It can change in the next upload while still being a complete replacement for the current one with a different prefix to the tarball name?
[11:00] <jtv> I've been assuming that architecture _if present in the tarball name_ does disambiguate, i.e. a ppc dist-upgrader does not replace an i386 dist-upgrader with otherwise the same tarball name.
[11:01] <jtv> And that if there's no architecture, that means "all."
[11:02] <cjwatson> the upload code disambiguates the tarball type by a field in the .changes file ('raw-debian-installer' etc.) rather than by the tarball prefix.  Ideally that would be preserved somewhere in the database too, and I thought it was
[11:02] <cjwatson> ISTR an enum for it
[11:03] <jtv> Hmmm
[11:03] <jtv> bigjools, do you know about this?  ^^
[11:03] <cjwatson> all the current parsers just ignore the first component
[11:03] <cjwatson> lib/lp/soyuz/enums.py:PackageUploadCustomFormat
[11:03] <cjwatson> existence of that suggests to me that the type is stored in the db somewhere
[11:04] <cjwatson> though I guess that could just be queue rows
[11:04] <bigjools> it is somewhere
[11:04] <cjwatson> if it isn't stored, then in practice you can probably get away with looking at the first component of the tarball name, since AFAIK they've never changed yet
[11:05] <cjwatson> jtv: TBH I have no idea what would happen if we ever tried to upload architecture-dependent dist-upgrader tarballs
[11:05] <bigjools> jtv: see PackageUpload.contains_*
[11:05] <cjwatson> jtv: but certainly a powerpc version of the debian-installer images tarball does not replace an i386 one with otherwise the same tarball name
[11:05] <jtv> cjwatson: PackageUploadCustomFormat just distinguishes between debian-installer, ddtp-translations, dist-upgrader, rosetta-translations.  Much coarser.
[11:05] <cjwatson> jtv: then I do not know what you mean by "the first parameter in the tarball name"
[11:06] <bigjools> which uses PackageUploadCustom.customformat
[11:06] <jtv> So again, not what we're looking for.
[11:07] <jtv> The PackageUploadCustom is already fully accounted for.
[11:07] <bigjools> can you re-state the question in simple terms then so I don't have to wade through backscroll
[11:07] <cjwatson> the tarballs are debian-installer-images_VERSION_ARCH.tar.gz, dist-upgrader_VERSION_ARCH.tar.gz, or translations_COMPONENT_VERSION.tar.gz; I assumed you meant the "debian-installer-images", "dist-upgrader", or "translations" part when you said "the first parameter"
[11:08] <jtv> OK: if we get two custom uploads of the same type for the same distroseries, what information should I take into account to determine whether the one supersedes the other, or is a separate thing that may also need to be copied?
[11:08] <jtv> And I understand that this differs by custom type, but I'd like to know the specifics for debian-installer; dist-upgrader; and ddtp-translations.
[11:08] <cjwatson> For debian-installer-images and dist-upgrader, different version + same arch means it supersedes.  For translations, different version + same component means it supersedes.
[11:09] <cjwatson> i.e. we want the most current version of (debian-installer-images/per-arch, dist-upgrader/per-arch, translations/per-component)
[11:10] <jtv> OK
[11:10] <bigjools> jtv: in lp/archivepublisher/ there are custom file handlers for publishing
[11:10] <jtv> That's not too far off what I have now, except (1) I currently don't have support for ddtp translations and (2) I currently also disambiguate by the "name" part (e.g. "debian-installer-images" vs. "dist-upgrader").
[11:11] <jtv> bigjools: yes, colin just pointed those out.
[11:11] <bigjools> jtv: they are called via PackageUploadCustom.publish...
[11:11] <bigjools> the whole custom file thing is hideous
[11:11] <jtv> Does that logic encode anything about what supersedes what?  If so, it may be better to extract and reuse.
[11:12] <cjwatson> yes, to some extent
[11:12] <bigjools> it does, somewhere, trying to find it
[11:12] <cjwatson> e.g. I pointed to the fixCurrentSymlink stuff which does version comparison
[11:12] <bigjools> right
[11:13] <cjwatson> jtv: if the name changes, then the version will also change, so there isn't really much point in disambiguating on it
[11:13] <cjwatson> this is guaranteed because if you don't change the version then you don't get a new directory under /dists/$SERIES/main/$BLAH/
[11:13] <jtv> That's fine then.  It's just that for one of the upload types I ended up not supporting (translations I guess), the name part seemed to be a package name.
[11:14] <cjwatson> no, it's NAME_COMPONENT_VERSION in that case
[11:14] <cjwatson> where NAME == "translations" (not enforced/required but in practice true right now), COMPONENT in ("main", "restricted", "universe", "multiverse")
[11:14] <cjwatson> that's the ddtp-tarball type
[11:15] <cjwatson> rosetta-translations might have a package name there, but we don't care about rosetta-translations for this because they aren't published to dists/
[11:17] <jtv> So only custom type & architecture matter for now, and for ddtp, component will also matter.
[11:19] <jtv> Ah, I have some examples in the database now.  That helps.
[11:19] <cjwatson> jtv: and ddtp isn't per-architecture, *only* per-component
[11:20] <cjwatson> I expect at least part of the code for this ought to live in the DebianInstaller etc. classes ...
[11:20] <jtv> Well I treat "no architecture" as "all" for genericity.
[11:20] <cjwatson> err, DebianInstallerUpload I mean
[11:21] <cjwatson> that sounds like an encapsulation bug, if you're having to consider architecture in generic code that suggests that actually the decision ought to be pushed down to the classes that know about the specific upload format
[11:21] <cjwatson> IYSWIM
[11:21] <jtv> Nah.
[11:21] <nigelb> mrevell: Hi!
[11:22] <jtv> The point is to isolate the format-specific part, so that it only extracts enough information to group the uploads such that of each group, only the latest matters.
[11:22] <henninge> jtv: here is a fun branch to review for you  ;-) https://code.launchpad.net/~henninge/launchpad/devel-update-testtools-r228/+merge/71659
[11:23] <jtv> henninge: sorry, past eod
[11:23] <mrevell> nigelb, Hi, on the phone just now.
[11:23] <henninge> jtv: np
[11:23] <jtv> Thanks.
[11:23] <henninge> danilos:: here is a fun branch to review for you  ;-) https://code.launchpad.net/~henninge/launchpad/devel-update-testtools-r228/+merge/71659
[11:23] <wgrant> jtv: Regretting your evil endeavour yet?
[11:23] <nigelb> mrevell: cool, can you please poke me once youre done? :)
[11:24] <jtv> wgrant: not at all—it turns out not to be impossible at all and my design can stay largely intact.
[11:24] <nigelb> Seeing how much wgrant is failing to disappear from here during vacation, I'd suggest a +b from #launchpad-* during vacation time ;)
[11:24] <jtv> Ooooh good idea
[11:25] <wgrant> I only drop in occasionally!
[11:25] <nigelb> where ocassionaly = ~2 hours
[11:26] <jtv> …and then stay for how long, would you say?
[11:27] <jtv> bigjools, cjwatson: different concern…  I notice that the uniqueness check for debian-installer uploads distinguishes between uploads with ".0." in them and ones without!
[11:28] <cjwatson> jtv: true, although we haven't used that for years
[11:29] <cjwatson> perhaps we should just ditch that, it is a rather bizarre way to do it
[11:29] <jtv> Aye, that it is
[11:29] <jtv> Question is, what should be done about it?
[11:29] <cjwatson> in fact I don't think we've used it since we switched to LP
[11:29] <cjwatson> it dates from the similar dak code
[11:30] <cjwatson> so if it's causing problems I suggest just binning it
[11:31]  * jtv files separate bug
[11:31] <nigelb> Does rocketfuel setup a password for postgres after I install postgres with that?
[11:32] <cjwatson> I mean, in theory I suppose daily builds of d-i would be kind of nice ... but they were a lot more useful in the early days than they are now, and in practice just uploading d-i again whenever I need to works out fine
[11:32] <cjwatson> definitely not worth awkward infrastructure to support it
[11:33] <danilos> jam: hi, do you think you could have a go at https://code.launchpad.net/~danilo/loggerhead/bug-718566/+merge/71849
[11:34] <danilos> henninge, looking at your branch now
[11:34] <jtv> nigelb: it configures a trusted TCP login from localhost.
[11:34] <henninge> danilos: thanks
[11:34] <nigelb> jtv: so, can I safely do sudo passwd postgres and not break my lp install?
[11:35] <jtv> nigelb: oh, a system password for the postgres user?  I don't see any reason why it should have a password at all.
[11:35] <nigelb> oh.
[11:35] <jtv> nigelb: sorry, I thought you were talking about a password for logging into the postgres databases.
[11:35] <jtv> System users generally shouldn't have passwords.  No good for anyone but attackers.  :)
[11:36] <nigelb> I'm just following instructions for hacking on harvest, which I think maybe a bit overzealous
[11:37] <danilos> henninge, that was an easy one, r=me :)
[11:38] <jam> danilos: commented
[11:38] <henninge> danilos: indeed. Thanks ;-)
[11:39] <danilos> jam: thanks, I'll try it out on a LP branch (I suppose you are suggesting doing it locally)
[11:40] <jam> yeah
[11:40] <jam> note that the *first* request is going to be uncached as well
[11:40] <jam> since it has to do the work
[11:40] <jam> my feeling is that it is already fast enough that we don't need the cache at all anymore
[11:43] <danilos> jam: yeah, I can't really tell the difference between the two (trunk and the branch with removed changes), I'll do something more scientific from the terminal :)
[11:46] <jam> danilos: probably try to find a revision with a particularly large number of changes
[11:46] <jam> like when you merge into db-devel or whatever it is called now
[11:46] <danilos> jam: right, I'll do that, and use "ab" to get actual data
[11:53] <danilos> jam: fwiw, I got the following exception with trunk when benchmarking: https://pastebin.canonical.com/51341/
[11:54] <jam> danilos: I've seen ScopeReplacer issues when running a lot of multithreaded requests as the "first" requests on a new loggerhead startup
[11:54] <jam> danilos: so you can try starting loggerhead, making a single request
[11:54] <jam> then running ab
[11:54] <danilos> jam: right, thanks
[11:54] <jam> ScopeReplacer happens at 'import' times, and it is known not to be threadsafe
[11:55] <danilos> ah, makes sense, should I file a bug about it somewhere?
[12:13] <LPCIBot> Project devel build #979: FAILURE in 5 hr 23 min: https://lpci.wedontsleep.org/job/devel/979/
[12:15] <jam> danilos: there is a bug already
[12:16] <danilos> jam: cool, I've added benchmarking results with a summary on https://code.launchpad.net/~danilo/loggerhead/bug-718566/+merge/71849
[12:16] <danilos> jam: tell me if you think I should land this considering the "mild" performance degradation
[12:18] <jam> danilos: going from the Launchpad discussion. Which is "things MUST complete in <9s (or 5s, ymmv), and SHOULD complete in <1s". We are still well underneath satisfying the 5s rule, and even the 1s rule.
[12:18] <jam> btw, I wouldn't expect /changes to differ
[12:18] <jam> let me grab a URL, just a sec
[12:19] <danilos> jam: sure, I wasn't sure if /changes used this cache as well
[12:20] <jam> it is the +revlog URLs that would be affected, I think
[12:20] <jam><EMAIL_ADDRESS>[12:20] <jam>  /changes doesn't show you the file changes until you expand something
[12:24] <danilos> jam: ok, I'll test it directly as well
[12:24] <jam> danilos: updated the mp with my comment
[12:25] <jam> I think I have a URL for you to try
[12:25] <jam> (posted to the mp)
[12:25] <jtv> cjwatson: see email.  All that needed immediate fixing then was that the "name" part of those tarball filenames is irrelevant, right?  I just fixed that.
[12:25] <jtv> (And cross-referenced to all those bugs I filed, *pant*)
[12:25] <danilos> jam: right, I was already benchmarking that URL
[12:26] <jam> danilos: I'm expected that to regress approximately the same as /revision, which would still put it in the "fully acceptable" realm.
[12:27] <danilos> jam, that's right, 325ms vs 267ms for the trunk
[12:27] <danilos> (trunk with cache populated, already accessed the page from the browser first)
[12:28] <jam> danilos: right. And ultimately a cache will always be faster, so what is "enough". And I think using SQUID to cache these pages is far superior to trying to do a file-change cache.
[12:28] <jam> you might also try one more URL
[12:28] <jam> something with a small change
[12:28] <jam> which should be much less sensitive
[12:29] <danilos> jam: yep, I'll do that too
[12:45] <rvba> danilos: Hi, can I add this MP to your queue? https://code.launchpad.net/~rvb/launchpad/desc-header-827893/+merge/71842
[12:47] <danilos> jam: anyway, smaller revision is actually faster in the few runs I did (259ms vs 264ms), so all good
[12:47] <danilos> rvba, a queue, there's a queue? :)
[12:47] <jam> danilos: good deal
[12:47] <rvba> danilos: :)
[12:48] <cjwatson> jtv: yep
[12:48] <cjwatson> jtv: thanks for the attention to detail :-)
[12:49] <danilos> rvba, nice, simple and clean, r=me (and thanks for the formatting fixes as well)
[12:49] <rvba> danilos: Thanks!
[12:51] <danilos> jam: now, how do I go land loggerhead changes? just merge into trunk (I see nobody is using [r=...] tags)
[12:51] <jam> danilos: yeah, merge it to trunk, comimt
[12:51] <jam> then make a proposal against Launchpad to use the new loggerhead code.
[12:51] <jam> utilities/source_deps I believe
[12:54] <StevenK> utilities/sourcedeps.conf
[12:54] <StevenK> jam: ^
[13:04] <deryck> Morning, all.
[13:12] <StevenK> stub: If you're still around, can you please re-rubber stamp https://code.launchpad.net/~stevenk/launchpad/denorm-bspph/+merge/71811 ? I've had to resubmit due to the addition of a pre-req branch.
[13:47] <deryck> abentley, let's chat about this shortly:  https://code.launchpad.net/~deryck/launchpad/bug-heat-wonky-recent-activity-check-688364/+merge/71756
[13:47] <deryck> abentley, and thanks! :)
[13:47] <abentley> deryck: np
[14:04] <deryck> abentley, I'm free now, if you have a minute to chat about that MP.
[14:04] <deryck> abentley, mumble 1 o 1?
[14:04] <abentley> deryck: sure
[14:38] <LPCIBot> Project devel build #980: STILL FAILING in 2 hr 25 min: https://lpci.wedontsleep.org/job/devel/980/
[14:54]  * barry sees lots of timeouts today
[15:08] <rvba> deryck: Hi, do you have a few minutes for a small JS question?
[15:10] <LPCIBot> Project devel build #981: STILL FAILING in 31 min: https://lpci.wedontsleep.org/job/devel/981/
[15:11] <barry> has anybody else noticed a high number of timeouts today?
[15:11] <nigelb> mrevell: are you free-er?
[15:12] <benji> Is anyone else seeing "ImportError: No module named html5browser" on devel?
[15:12] <benji> the last buildbot run that wasn't killed by a KeyboardInterrupt was clean and I don't see any bugs filed about it
[15:13] <barry> here are two urls that are consistently timing out for me today, but were fine yesterday:
[15:13] <barry> https://bugs.launchpad.net/ubuntu/+source/zeitgeist/+bug/807950
[15:13] <_mup_> Bug #807950: zeitgeist-daemon crashed with LookupError in remove_from_connection(): <_zeitgeist.engine.remote.RemoteInterface at /org/gnome/zeitgeist/log/activity at 0xb74ee2cc> is not exported at a location matching (None,None) <apport-crash> <bugpattern-needed> <i386> <oneiric> <running-unity> <unity-2d> <zeitgeist (Ubuntu):Triaged> <zeitgeist (Ubuntu Oneiric):Triaged> < https://launchpad.net/bugs/807950 >
[15:13] <barry> https://launchpad.net/ubuntu/+search?text=chromium-browser
[15:13] <mrevell> Hi nigelb, sure. How can I help?
[15:14] <nigelb> mrevell: I'm looking to see if you have suggestions on how the subscription could be improved
[15:14] <nigelb> I found it non-intuitive
[15:14] <deryck> rvba, sure.  voice or chat?
[15:14] <nigelb> fixing it would be trivial, but the UX is probably of more concern here than the actual patch
[15:14] <benji> the ImportError can be reproduced with "bin/test -c -t test_archivesubscribers_index"
[15:14] <nigelb> *comparitively trivial
[15:15] <rvba> deryck: great, I think chat is ok ... I'll paste my understanding of the problem ..
[15:15] <timrc> calling addArchiveDependency() on PPA's (belonging to my LP user ~timrchavez) via the web service is resulting in OOPses in the web UI
[15:15] <rvba> deryck: It's weird problem with FormOverlay. Basically, when the overlay is closed (for instance 'cancelled') it stays in the page (which is normal) but since it's only hidden using "visibility: hidden" it prevents me from clicking on the radio button that is underneath it.
[15:15] <rvba> Here is the real example:
[15:15] <rvba> If you open up a row on this page https://dogfood.launchpad.net/ubuntu/oneiric/+localpackagediffs then changed the "Ignored" status using the radio buttons, you'll get an overlay to enter a comment (to describe *why* you changed the ignored status). Cancel the overlay and you will see that now you can't click on the radio buttons any more.
[15:15] <rvba> I'm not the only one to have this problem it seems: http://stackoverflow.com/questions/1751861/do-controls-in-firefox-receive-mouse-events-when-their-css-visible-property-is-fa
[15:16] <rvba> This fixes it: http://paste.ubuntu.com/668072/
[15:16] <rvba> deryck: But obviously I don't want to mess with that without the advice of a JS expert ;)
[15:16] <mrevell> nigelb, Subscription to what? Sorry, I've not really been following this channel much today.
[15:16] <deryck> rvba, reading back, thinking.....
[15:17] <nigelb> mrevell: Oh, I should have been clearer. I meant bug subscription, more specifically, subscribing  myself to a bug
[15:17] <timrc> Here is a script that should allow you to reproduce the problem (replace the PPA with a PPA you own): https://pastebin.canonical.com/51356/
[15:19] <deryck> rvba, yes, display none is what I would prefer.  I always wondered why we used visibility anyway.
[15:19] <deryck> rvba, I couldn't think of this exact issue, but I knew there was something with invisibility vs display like this.
[15:20] <bigjools> timrc: an OOPS code is more useful
[15:20] <timrc> bigjools, certainly, OOPS-2055AU68
[15:20] <bigjools> thanks
[15:21] <rvba> Looks much saner to me to use "display: none" too ... I'll do the change then ... I hope it won't break other overlays ;)
[15:21] <bigjools> timrc: FTR you can't add 2 dependencies on Ubuntu like that
[15:21] <bigjools> just the latter one will do
[15:21] <timrc> bigjools, it was originally a test to verify that... however
[15:21] <timrc> bigjools, the first call to add the dep is what blows these ppas up
[15:21] <rvba> deryck: thanks for looking into it.
[15:21] <bigjools> ah
[15:21] <timrc> bigjools, just did it again on a ppa owned by ~oem-archive user, OOPS-2055AR56
[15:22] <bigjools> I need to wait for the oops to sync
[15:22] <deryck> rvba, np
[15:22] <timrc> bigjools, our goal is to try to figure out how to get this option via the web service, http://i.imgur.com/ewHzM.png
[15:22] <timrc> bigjools, maybe you know off hand :)?
[15:23] <timrc> not specifying any component gives us the second option
[15:23] <bigjools> timrc: it defaults to that, no?
[15:23] <timrc> bigjools, when we call addArchiveDepedency without a component specified, it defaults to "Use all the same components..." I believe
[15:24] <bigjools> timrc: don't call addArchiveDependency at all, it defaults to use everything
[15:25] <timrc> bigjools, but need to chang the Ubuntu Dependency...
[15:25] <timrc> bigjools, we need to set the equivalent of "Basic" from "Default" in the web ui
[15:26] <bigjools> timrc: ok your image paste didn't make that clear
[15:27] <timrc> bigjools, sorry :)
[15:27] <bigjools> ummm
[15:27] <bigjools> not sure you can change this over the API tbh
[15:27] <timrc> http://i.imgur.com/aDHjJ.png
[15:28] <timrc> bigjools, would you consider this a bug then?
[15:28] <bigjools> timrc: let me investigate a little
[15:28] <mrevell> nigelb, We have a bug report ... bug 816105 ... I agree it's not easy to find the "subscribe me" option right now
[15:28] <_mup_> Bug #816105: UI for subscribing to a bug is confusing <bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/816105 >
[15:28] <mrevell> nigelb, Was there something else you found non-intuitive?
[15:29] <nigelb> mrevell: the other bits are great. I'd love to fix the bug if there's a consensus on what needs to be done.
[15:30] <mrevell> nigelb, I'm about to go into another phone call ... I'd love to read your thoughts in a comment on that bug and then talk to you again later int he week, if that's okay.
[15:30] <nigelb> mrevell: that sounds good.
[15:30] <mrevell> great :)
[15:30] <timrc> Two bugs, 1) using addArchiveDependency() is causing OOPses (which seems like a regression); and 2) Cannot express "Use all components availalbe" via the web service for addArchiveDependency()
[15:30] <timrc> bigjools, ^
[15:35] <cody-somerville> bigjools, https://lp-oops.canonical.com/?oopsid=OOPS-2055AZ51
[15:44] <adeuring> abentley: fancy a "double review"? https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-slicing-only-in-factory/+merge/71913 and https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-slicing-only-in-factory/+merge/71913
[15:45] <abentley> adeuring: sure, I'll have a look.
[15:45] <adeuring> abentley: one link should be https://code.launchpad.net/~adeuring/launchpad/bug-739052-6/+merge/71912
[15:50] <bigjools> timrc: grar, ok please stop adding those, we need SQL to clean the DB
[15:50] <bigjools> timrc: can you get me a complete list of PPAs where you've done this and I will wipe all their dependencies
[15:51] <timrc> bigjools, lol, okay
[15:54] <timrc> bigjools, https://pastebin.canonical.com/51366/
[15:55] <allenap> matsubara: Are you the person to talk to about qa-tagger?
[15:58] <matsubara> allenap, I'd be happy to talk to you about it. Anyone in the maintenance teams is encouraged to fix bugs there too.
[15:58] <bigjools> timrc, cody-somerville: FYI: https://bugs.launchpad.net/launchpad/+bug/828133
[15:58] <_mup_> Bug #828133: Archive:+edit-dependencies OOPS <oops> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/828133 >
[15:59] <allenap> matsubara: Ah, okay. Well, I'm wondering if it has missed a bug. The branches in https://bugs.launchpad.net/launchpad/+bug/824499 seem to have landed in stable but qa-tagger has not updated the bug. I'm trying to figure out why.
[15:59] <_mup_> Bug #824499: "All derived distros" option for publish-ftpmaster <derivation> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/824499 >
[16:00] <timrc> bigjools, this bug was Fixed Release, so it seems to imply the interface should be usable for adding Ubuntu deps... https://bugs.launchpad.net/launchpad/+bug/776449, no?
[16:00] <_mup_> Bug #776449: Set Ubuntu dependencies for PPA via API <api> <bad-commit-13157> <escalated> <not-pie-critical> <oem-services> <ppa> <qa-ok> <Launchpad itself:Fix Released by abentley> < https://launchpad.net/bugs/776449 >
[16:00] <allenap> matsubara: Ah, I think I've figured it out. The wrong bug number was used in the commit message.
[16:01] <allenap> Sorry for the noise.
[16:01] <bigjools> timrc: I forgot about that
[16:01] <bigjools> timrc: I guess it has a bug
[16:02] <timrc> bigjools, I should note that this was working (at least setting the Dep) up until recently (not sure when it went bad)... what wasn't working was the ability to achieve the first Components option in the web ui from the web service
[16:03] <matsubara> np allenap
[16:09] <abentley> adeuring: r=me
[16:09] <adeuring> abentley: thanks!
[16:17] <timrc> bigjools, here's the other bug
[16:17] <timrc> https://bugs.launchpad.net/launchpad/+bug/828145
[16:17] <_mup_> Bug #828145: Cannot add an archive dependency that uses all Ubuntu components available via the web service <oem-services> <Launchpad itself:New> < https://launchpad.net/bugs/828145 >
[16:18] <bigjools> timrc: I think you misunderstand
[16:19]  * bigjools writes on bug
[16:19] <timrc> bigjools, probably :)
[16:19] <timrc> bigjools, all I know is addArchiveDependency() will change the what's displayed in that view
[16:19] <timrc> bigjools, so I expect to be able to do everything via the API that I can do in that view :)... is that too much to expect?
[16:20] <bigjools> timrc: yeah :)
[16:20] <bigjools> the addArchiveDependency does not allow you to change the ubuntu dependencies
[16:20] <bigjools> just add new ones
[16:21] <timrc> bigjools, when I create a PPA and use addArchiveDependency() to add an ubuntu dependency, it alters what's displayed in "Ubuntu dependencies"...
[16:21] <bigjools> timrc: you're trying to change the ubuntu dependency to just "main" aren't you?
[16:21] <bigjools> timrc: ah ok
[16:21] <bigjools> right, I remember how it works internally now
[16:22] <timrc> bigjools, here's our actual method... this will change the selection to the "Basic" Ubuntu dependency
[16:23] <timrc> bigjools, http://paste.ubuntu.com/668400/
[16:23] <timrc> bigjools, however, it assumes the wrong Components choice
[16:23] <bigjools> timrc: see my comments on the bug
[16:24] <timrc> bigjools, ah
[16:26] <timrc> bigjools, works like a charm
[16:26] <bigjools> great!
[16:26] <timrc> cody-somerville, honestly a little surprised you didn't catch that... tsk
[16:26] <timrc> :P
[16:27] <mrevell> Hey, sinzui, have you seen bug 827902?
[16:27] <_mup_> Bug #827902: Private teams not able to subscribe to bugs or blueprints for email updates <disclosure> <privacy> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/827902 >
[16:38] <bigjools> abentley: you know you did that change so that PPA dependencies can be set on the API?  Can you have a look at this bug that it's causing:  https://bugs.launchpad.net/launchpad/+bug/828133
[16:38] <_mup_> Bug #828133: Archive:+edit-dependencies OOPS <oem-services> <oops> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/828133 >
[16:41] <abentley> bigjools: I don't think I have any special insight.
[16:41] <bigjools> abentley: it's extremely weird
[16:42] <bigjools> the data looks sane
[16:45] <abentley> bigjools: It looks like a lp.soyuz.model.component.Component is the input to the getTerm.  Is that correct?
[16:46] <bigjools> abentley: should be, it's worked for ages with no changes
[16:49] <bigjools> shame Component doesn't have a __repr__ :/
[16:50] <bigjools> oh it does
[16:50] <bigjools> so it doesn't get used when the security proxy is in the way
[16:55] <cody-somerville> timrc, catch what?
[16:56] <bigjools> abentley: I see what's wrong
[16:56] <sinzui> mrevell, I have. I added the disclosure tag
[16:56] <bigjools> abentley: the API allows you to add data that the form cannot cope with
[16:58] <bigjools> timrc: set that component to "multiverse" and it'll be OK.
[16:58] <timrc> cody-somerville, that by specifying 'multiverse' as the component, for example, it pulls in 'main', 'restricted', and 'universe' as well
[16:58] <bigjools> the form code for the page only knows about multiverse and None :)
[18:28] <abentley> deryck: Why aren't comments 8 and 9 showing? https://bugs.qastaging.launchpad.net/launchpad/+bug/1000
[18:28] <_mup_> Bug #1000: There are too many bug reports in Malone <lp-foundations> <Launchpad itself:Invalid> <Ubuntu:Invalid> < https://launchpad.net/bugs/1000 >
[18:29]  * deryck looks
[18:29] <abentley> deryck: These are comments I created using the 'macintosh' charset, but I wouldn't expect that to hide them...
[18:30] <deryck> abentley, hmmm, I have no idea.  I wouldn't expect them to be hidden either.
[18:31] <deryck> abentley, I can get to them directly, too.  Weird.
[18:32] <abentley> deryck: They are missing the Subject line, unlike 7 which was the same except it used the 'mac-roman' charset.
[18:33] <deryck> abentley, ah, good catch.  curious that a missing subject line on an email generated comment would cause the comment to hide.
[18:34] <abentley> deryck: The Subject was present on the email, though.
[18:35] <deryck> abentley, right, I followed.  I assumed we tripped over it somehow and didn't store it in the db.
[18:36] <abentley> deryck: Yeah, I suspect.
[18:36] <deryck> abentley, seems like another bug that the comment won't display without a subject.
[18:37] <abentley> deryck: I doubt it's just any missing subject.
[18:37] <abentley> deryck: I bet it's related to the charset.
[18:39] <abentley> deryck: I've sent a latin-1 email with absolutely no subject, to see what happens.
[18:39] <deryck> abentley, good idea
[19:05] <abentley> deryck: subject-free comment is not hidden.
[19:07] <deryck> abentley, ok, good to know.  Thanks for confirming.
[19:08] <abentley> deryck: I am marking bug 820039 qa-ok, and filing a new critical bug for "bug comments with macintosh encoding not displayed".
[19:08] <_mup_> Bug #820039: process-mail.py fails with a LookupError: unknown encoding: macintosh error <mail> <oops> <qa-needstesting> <Launchpad itself:Fix Committed by abentley> < https://launchpad.net/bugs/820039 >
[19:08] <deryck> abentley, sounds good.
[20:01] <benji> abentley: do you have a minute for a review? https://code.launchpad.net/~benji/launchpad/bug-162868-2/+merge/71942
[20:01] <abentley> benji: sure.
[20:01] <benji> abentley: here's the soundtrack: http://www.youtube.com/watch?v=0O2aH4XLbto&feature=channel_video_title
[20:08] <abentley> benji: The change looks reasonable.  The docstring on Macro is sort-of obsoleted by the branch.
[20:08] <abentley> benji: it talks about the present state, rather than the state we'll have once the branch lands.
[20:08] <benji> abentley: hmm, you might be right; I'll take a second look
[20:09] <abentley> benji: e.g. "that pattern also has the side effect of making the template URL traversable from any object" could be "without this class, that pattern would make the template URL traversable..."
[20:11] <abentley> benji: r=me.
[20:11] <benji> abentley: sounds good, I'll change that;  I'd like to keep the docstring though, I like that it provides both a justification for why the class exists and describes how it should be used.  I often wish someone had written something like that when reading code.
[20:11] <abentley> benji: yes, I agree.
[20:12] <benji> cool
[20:13] <abentley> benji: You might want to update this page: https://dev.launchpad.net/Web/TemplateCodeReuse
[20:14] <benji> abentley: ooh, thanks
[20:45] <sinzui> jcsackett, mumble?
[20:46] <jcsackett> sinzui: sure, one moment.
[21:11] <lifeless> allenap: hi
[21:14] <lifeless> allenap: I've commented on the review; I have to run now to a hospital visit; I hope I haven't been too brief with my description.
[21:14] <lifeless> allenap: if I have, please ask here or there and we can refine our understanding of whats going on
[21:35] <lifeless> ok, popping out to my monthly allergy injection, at l'hopital, back in ~ 3hr


[04:12] <studiobot> SamuelBanya was added by: SamuelBanya
 Hey there Ubuntu Studio Dev team. I spoke to Erich over the Lubuntu Dev IRC channel and he said that you guys might need some help with a Python installer. I've worked on several Python based projects seen on my site, www.musimatic.net and I've even helped automate my actual day job with a related webscraper. I was wondering if I
[16:06] <studiobot> could help with making the Python based installer a reality.
 Feel free to @ ping me so I can see your related post here on Telegram and my email is<EMAIL_ADDRESS> @SamuelBanya [Hey there Ubuntu Studio Dev team. I spoke to Erich over the Lubuntu Dev IRC chan …], Take a look at https://launchpad.net/ubuntustudio-installer. We have it ready for release into Disco, but we do eventually want to make it a Python-based installer.
 Okay great
 Ill take a look sometime this weekend
 It has actually been a thing since forever, but we just got done retooling it.
 Ah I see
 Good to know
 Yeah Lubuntu team uses launch pad with phabricator so I'm familiar with it
 Do you guys use arc as well?
 Cool.
 Arc?
 It's like git
 No, we use git.
 Do you guys have a main repo?
 Great I prefer git anyway
 https://launchpad.net/~ubuntustudio-dev
 What is required for push access or basic commits
 What's your launchpad account?
 I probably have to follow a related guide and make an account right?
 Id have to see
 I linked it to my github
 So it's probably the same as the one on my github aka github.com/sbanya
 I think, until Disco is released, I'd rather you didn't push to it. We can make Python a goal for 19.10.
 Thats fine too
 When is 19.10 scheduled for release? Fall right?
 @SamuelBanya [So it's probably the same as the one on my github aka github.com/sbanya], That's not it. Got a 404 from Launchpad.
 I see
 Yes. the number is yy.mm (Year/Month)
 I probably linked my phab account then
 Ah good to know. Makes sense
 Thanks for clarifying
 That's standard fo all Ubuntu flavors.
[16:21] <Eickmeyer> OvenWerk1: I found you someone to convert the code to Python. Figured after -installer gets updated in Disco would be the time to make major changes like that.
[22:23] <hb756> Hello. I'm a developer, and I'm looking for something to do. I am an ubuntu studio user, so I thought I'd try to contribute. I've followed some of the directions on the ubuntu site for setting up, ssh and gpg keys, launchpad login, etc, but as far as actually getting started, I can't seem to find that specifically, or what's there seems out of date. Can anyone here point me in a direction? Thanks.
[22:24] <Eickmeyer> hb756: What do you wish to develop?
[22:26] <hb756> well, I'm not sure exactly. I guess simple things at first just to get used to the process, using the right environment, packaging, .. so a simple text change or something to start off?
[22:26] <hb756> I mean I really don't know what all is involved. Like, version control? I guess it's not git?
[22:27] <Eickmeyer> Perhaps. You do know that the Ubuntu Studio team doesn't develop any of the apps included, the user interface, or even the underlying operating system, right?
[22:28] <Eickmeyer> We do develop a couple of utilities for configuration (Ubuntu Studio Controls, Ubuntu Studio Installer), but that's about it.
[22:28] <Eickmeyer> For Ubuntu Studio, we do use git, but the rest of Ubuntu varies.
[22:28] <hb756> I don't really know where the separation is. Sorry if I seem dense.
[22:29] <hb756> So do I need to target a specific application, I guess, then?
[22:29] <Eickmeyer> There is no separation. Ubuntu Studio is merely a customized version of Ubuntu. The User Interface (Xfce) is mostly worked-on by the Xubuntu team, and the underlying operating system is the Ubuntu Core team with Canonical.
[22:30] <Eickmeyer> If you want to target a specific application, you need to work with the upstream developer.
[22:30] <Eickmeyer> Most of what we need with Ubuntu Studio, at this time, is documentation.
[22:31] <hb756> Yeah, I really am looking to make coding contributions
[22:32] <hb756> I guess I'm open to what exactly I would be doing. Just looking for a list of things that need to be done, then picking one I think I can do, an doing it.
[22:32] <Eickmeyer> Okay, then that's fairly easy. Do me a favor and look over https://help.ubuntu.com/community/UbuntuStudio, scour around there, and let me know where you see need for improvement or changes.
[22:32] <Eickmeyer> If you feel you can contribute that way, let me know, and I'll add you to the team. :)
[22:33] <Eickmeyer> Then you'll be allowed to make changes directly to that wiki.
[22:34] <hb756> I think you are talking about refining some documentation?
[22:34] <Eickmeyer> Yes, or adding some.
[22:34] <Eickmeyer> But, that's up to you.
[22:35] <hb756> I think I might have misled you somehow. I am wanting to do software development contributions.
[22:35] <Eickmeyer> Okay. Do you have anything in mind?
[22:37] <hb756> I was hoping that someone could suggest good first issues
[22:37] <Eickmeyer> Well, aside from everything I told you about, everything else is pretty much outside of the scope of the Ubuntu Studio project.
[22:38] <Eickmeyer> Some of us develop for other projects that are included. For instance, OvenWerk1 is an Ardour developer in addition to developing for Ubuntu Studio. I package Carla from KXStudio (working on getting it into Ubuntu right now).
[22:38] <Eickmeyer> Do you know of any applications you would like to see in Ubuntu Studio?
[22:42] <hb756> Well actually, if it doesn't already exist, there should be a simple application that allows audio loops to easily be created. Example, I am a lead guitar player, and I need to record a progression to practice with. It's of course possible with ardour or audacity, but I'd like to see an app that is dedicated to that and simple to use for that.
[22:43] <hb756> Like being able to guess very closely to keep the tempo correct at the loop point
[22:43] <hb756> and be right more times than not
[22:44] <hb756> keep a list of past saves
[22:44] <Eickmeyer> Well, we have SooperLooper...
[22:45] <hb756> oh? I'll try it
[22:45] <Eickmeyer> It pretty much does exactly what you're describing.
[22:45] <hb756> awesome
[23:19] <hb756> Hey, not sure if this is the right place for this or not, but in trying to check out that software sooperlooper, now I'm running into the "how the heck do I get audio to it" problem, or if there is no audio, how is the best way to troubleshoot it problem. any guidance?
[23:22] <hb756> It would be nice if qjactctl had some visual indication that this or that feed had some signal
[23:23] <hb756> In audio, you have lights, or you can unplug something and put your finger on it to inject a small signal, and listen, or see the lights, you know?
[23:50] <celesteh> Hello, I use evolution for my email client and it'#s stopped showing any of my folders. MY email does show up in searches, so I'm fairly sure it's still getting the email, but I can't see it unless I search for it
[23:53] <Eickmeyer> !support | celesteh
[23:53] <celesteh> ty
[23:53] <Eickmeyer> celesteh: Additionally, I'd actually go to #ubuntu for that problem since it's not specific to Ubuntu Studio.
[23:54] <celesteh> cheers


[17:51] <AdianAntilles> Hey there. Is there a channel on the freenode server for questions about website hosting, website maintenance or suchalike? I am having trouble with a site.
[17:54] <OvenWerks> AdianAntilles: That is kind of vague. Do you mean how to set up a website? do you mean you found a website with a problem? Is it a freenode website?
[17:56] <AdianAntilles> No, its a website some friends are hosting. We're trying to set up https, but there is a ERR_SSL_PROTOCOL_ERROR when some people visit that site. I kinda exprected an self-issued cert error, but this error is different and has only user-site workarounds, it seems.
[17:59] <OvenWerks> AdianAntilles: weird There is on https://wiki.ubuntu.com/IRC/ChannelList no channel listed for server.
[18:00] <OvenWerks> There is #ubuntu-server
[18:00] <OvenWerks> and #ubuntu-stack
[18:01] <OvenWerks> Both of these assume you are running ubuntu-server or a server on a ubuntu base
[18:02] <OvenWerks> because it will be based on the webservers and software that come with ubuntu
[18:07] <AdianAntilles> Oh, okay, that isn't the case, afaik. I try to find another irc server then. Thanks for your help :-)


[10:08] <CIA-6> ubiquity: evand * r4485 trunk/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[10:08] <CIA-6> ubiquity: If a session indicator gconf key starts unset, make sure it ends
[10:08] <CIA-6> ubiquity: that way (LP: #684052).
[10:25] <ara> Good morning guys!
[10:25] <ara> Daniel filed the bug about the preseeded installations in ubiquity on Friday
[10:25] <ara> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/706117
[10:25] <ubot2> Launchpad bug 706117 in ubiquity "Installation fails using preseed file and network install" [Undecided,New]
[10:26] <ara> Could you please have a look to it whenever you have time?
[10:26] <ara> thanks!
[10:28] <cjwatson> I've added a comment asking for more info
[11:57] <tjaalton> hmm, I've mirrored lucid-proposed, got the netboot image from there, but the installer still says "no kernel modules were found".. what am I missing?
[11:57] <tjaalton> also mirror/suite is lucid-proposed
[11:57] <tjaalton> "d-i mirror/suite" that is
[11:58] <cjwatson> apt-setup/proposed=true
[11:58] <cjwatson> ?
[11:58] <tjaalton> oh that one.. will check
[12:03] <tjaalton> yeah, thanks
[13:39] <ev> bzr index is having quite the struggle with ubiquity trunk
[14:16] <CIA-6> ubiquity: evand * r4485 trunk/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[14:16] <CIA-6> ubiquity: If a session indicator gconf key starts unset, make sure it ends
[14:16] <CIA-6> ubiquity: that way (LP: #684052).
[14:16] <CIA-6> ubiquity: evand * r4486 trunk/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[14:16] <CIA-6> ubiquity: Fix mistake in the cleanup branch merge that broke translations
[14:16] <CIA-6> ubiquity: (LP: #691671).
[14:48] <CIA-6> ubiquity: evand * r4487 trunk/po/LINGUAS: Update LINGUAS.
[16:51] <CIA-6> console-setup: evand * r376 ubuntu/debian/ (changelog rules): Include pc105.tree for ubiquity.
[17:01] <CIA-6> ubiquity: evand * r4488 trunk/ (debian/changelog debian/rules ubiquity/keyboard_detector.py):
[17:01] <CIA-6> ubiquity: pc105.tree is included in console-setup now, which speeds up
[17:01] <CIA-6> ubiquity: ubiquity builds.
[21:04] <yofel> hey, are there plans to make the installers set 'force-unsafe-io' for dpkg in natty? It does speed up the unpacking process.
[21:04] <yofel> during installation I mean
[21:34] <cjwatson> yofel: already does
[21:34] <cjwatson> (in d-i, anyway)
[21:46] <yofel> oh great :D


[01:48] <ccheney> OOo master mirror server apparently died so 3.2.1rc2 is delayed :-\
[10:21] <Riddell> ccheney: hmm, I don't know if we can add packages as a SRU.  pitti is it allowed?
[20:26] <bdrung> new packages in debian will be synced automatically? what to do with sync requests for new debian packages?
[20:51] <Laney> eventually. If you want them done now then you should ask an AA directly
[23:46] <latenite> hi anyone in here have clue how to set "abcde" so artists get their own subdirectory??


[02:25] <askjd> Hi, what is the default password for a Ubuntu Budgie live system?
[10:06] <nexus55> my ubuntu Budgie suddenly starts very slowly, except i use my mouse during starting.
[10:07] <nexus55> may somebody help?


[08:59] <UNIm95> apw: Hi. I got kernel panic again. Where should i paste photos?
[09:01] <apw> UNIm95, file a bug, and add them to that bug: use 'ubuntu-bug linux' to make the bug
[09:01] <UNIm95> apw: what is ubuntu-bug linux? Console program? Website?
[09:01] <apw> something to run in a terminal yes
[09:17] <UNIm95> apw: Damn. I got Launchpad error =)
[09:20] <UNIm95> apw: I have submitted this. What should i do next? Wait?
[09:28] <apw> UNIm95, let us know the LP# here for one
[09:31] <UNIm95> apw: What do you mean with LP#?  if you mean bug number under launchpad it is #1497184. Link here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497184
[09:31] <apw> yep that
[09:34] <apw> henrix, ^ looks like a regression in trusty-proposed kernel ...
[09:34] <apw> UNIm95, does that trace seem consistent in your failures ?
[09:35] <apw> UNIm95, particuarly is that "BUG: ..../skbuff.c:1290" part appear in other ones
[09:36] <UNIm95> apw: Not sure. Now I'm still using *-64- kernel and wait for another panic. When it happens i post more photos.
[09:36] <apw> UNIm95, thanks that is exactly what we need, you are not the only person "feeling" there is an issue in here
[09:37] <apw> UNIm95, and thanks for 1) testing -proposed and 2) reporting the issues to us
[09:38] <UNIm95> apw: Please. I is not a problem for me. I have backups =)
[09:38] <apw> heh, thanks
[09:47]  * smb feels a disturbance in the coffee namespace
[09:55] <henrix> smb: ok, i *may* have found something related with this bug.  if your bored, here's what i found:
[09:55] <henrix> smb: trysty -64 kernel includes commit 738ac1ebb96d ("net: Clone skb before setting peeked flag")
[09:55] <apw> that sounds suspicious indeed
[09:56] <henrix> smb: however, there's an upstream commit (not included in trusty yet): a0a2a6602496 ("net: Fix skb_set_peeked use-after-free bug")
[09:56] <henrix> which fixes the other one
[09:56] <apw> nnng
[09:56] <smb> henrix, yeah. I am currently trying to cause it to crash with -64 in a VM. If that succeeds I can have a look with that added
[09:57] <henrix> smb: cool, thanks
[09:57] <smb> henrix, but use-after-free sounds a lot like what may happen
[09:58] <henrix> smb: yeah, the only thing is that none of these functions actually show up in the kernel trace.  but since the kernel is tainted, it could have happen before
[09:58] <henrix> *don't show
[09:58] <smb> henrix, absolutely. the pain with use-after-free
[10:03] <henrix> smb: btw, if the issue you're hitting is really due to this commit, it seems to be related with broadcast/multicast ;-)
[10:03] <henrix> (according to the commit msg)
[10:04] <smb> henrix, hmmm... so the method to trigger it is actually the dhcp client running... likely...
[11:17] <henrix> smb: build on-going in gloin:/tmp/kernel-henrix-RVtd9xTj
[12:39] <henrix> UNIm95: i've commented on the bug with a link to a test kernel
[12:39] <henrix> UNIm95: The comment points to the possible issue (and the fix)
[12:39] <UNIm95> henrix: ok.
[12:40] <apw> UNIm95, how long did it take to reproduce in general ?
[12:40] <henrix> apw: smb: btw, looks like this also impacs vivid
[12:42] <UNIm95> apw: At home laptop worked for 4 hours, than sleep for 8 hours and, finally, after 2 hours word panic.
[12:42] <UNIm95> work*
[12:44] <UNIm95> apw: one time a got this after ~30min uptime
[12:45] <apw> henrix, gah
[12:45] <UNIm95> henrix: i will try this kernel a later. I need to do my work
[12:45] <apw> henrix, i've nom'd it to those two for now
[12:46] <UNIm95> henrix: i have downloaded this kernel
[12:46] <apw> UNIm95, let us know how you get on
[12:46] <UNIm95> Sure
[12:46] <henrix> UNIm95: ack, thanks!
[12:46] <apw> but i am suspicious this is the issue and fix
[12:49] <UNIm95> henrix: the only question: "and introduces a use-after-free bug, fixed with upstream commit"
[12:49] <UNIm95> It means than this bug appers with high memory load?
[12:50] <henrix> UNIm95: from these commits description it should occur in the broadcast and multicast packages receive paths, so not really a memory stress issue
[12:51] <henrix> s/packages/packets
[12:51] <UNIm95> henrix: network packets?
[12:52] <henrix> UNIm95: yep
[12:52] <UNIm95> should i emulate DDOS?
[12:52] <UNIm95> on my own laptop?
[12:53] <UNIm95> Or is possible to make some thing like this.
[12:53] <apw> UNIm95, it is predicted taht dhcpclient would tickle the bug
[12:53] <apw> UNIm95, so setting your dhcp refresh time on your router to 5m might make it a lot more likley to occur
[12:53] <apw> lots of packets not so likley to trigger it, as tehy are normally unicast
[12:55] <UNIm95> apw: and doesn't matter Wlan or ethernet?
[12:55] <apw> i don't believe so from the description
[12:55] <apw> henrix, ^
[12:57] <henrix> apw: i... don't think so either, it's in the core network code.  anyway, looking at UNIm95 photos, it seems to have occurred while using ethernet (e1000e)
[12:57] <apw> good point
[12:57] <henrix> but again, i believe that's irrelevant -- if this is the issue, it's in the core code, so it doesn't matter
[12:58] <UNIm95> henrix: apw yesterday at home i used wlan and got only kernel oops that was catched with apport-gtk.
[12:59] <UNIm95> do you have access to ubuntu's apport infrastructure?
[12:59] <apw> UNIm95, the symptoms of this would be pretty random, as it is a use after free which could literally break anything
[12:59] <apw> UNIm95, we may be able to find it yes
[13:00] <UNIm95> look for toshiba tecra laptop a11
[13:01] <UNIm95> It was at evening. 20:00<x<22:00 Berlin time
[13:19] <smb> apw, henrix, so far not been able to hit it in a more artificial environment but I guess its random by nature
[13:43] <apw> tjaalton, hey are you fixing this initramfs-tools thing for the firmware ... i was about to, but i see you ahve it assigned
[13:44] <tjaalton> apw: that's when it was a kernel bug, you can have it :)
[13:44] <apw> tjaalton, ack
[13:44] <tjaalton> thanks
[14:42] <psivaa> cking_: hello, it's me again :)
[14:42] <psivaa> Just was going to disable the memory threshold for NM health check but noticed that it's been passing for a few days.
[14:42] <psivaa> *memory threshold tests
[14:42] <psivaa> https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-i386-smoke-health-check/
[14:43] <psivaa> so i'm wondering if that's OK to let that run for a few more days to see if this has really settled
[14:43] <cking_> psivaa, ok, lets see how it runs over the next few days
[14:43] <psivaa> cking_: ack, thanks
[15:47] <t3hSteve> hey all, is anyone around that could help me with a cpuacct cgroup question/issue/bug?
[17:20] <apw> t3hSteve, it is eod for me, but it is just best to ask the question and see who responds
[17:22] <t3hSteve> ok, so basically I notice that on (at least up to) 3.13.0-64, the cpu usage reported in cpuacct.stat is significantly lower than the actual CPU usage as reported by say, top or /proc/<pid>/stat
[17:25] <t3hSteve> this is on ubuntu 12.04, I seem to recall on 14.04 it was correct, but oddly enough I think it was on the same kernel version
[17:40] <apw> t3hSteve, hrm, that sounds odd if the kernle version is the same
[17:40] <t3hSteve> yeah, its very odd =/
[17:40] <t3hSteve> looking around bug trackers I cant see any reference to anything like this
[17:41] <t3hSteve> but its a significant under-reporting from the cgroup
[17:41] <apw> t3hSteve, sounds like some repeatable test is required, if you could file a bug against the kernel "ubuntu-bug linux", and could detail the two platforms that produce different numbers, and how to get the numbers
[17:41] <t3hSteve> ex top reports 120% and the cgroup reports .9
[17:41] <apw> t3hSteve, then someone might be able to repro it
[17:41] <t3hSteve> I can do that
[17:41] <t3hSteve> althought we'll see how easy it is to reproduce :P
[17:42] <apw> t3hSteve, heh .. i know ... things like this normaly go away when you try and make them reproducible
[17:43] <t3hSteve> :P
[17:43] <t3hSteve> the full context is we're running mesos in AWS
[17:43] <apw> t3hSteve, drop the LP#number in here when you have done so, so we can find it
[17:43] <t3hSteve> and the numbers I get out of mesos (which just reads the cgroup) are way different from what I see on the machine itself (top, /proc, etc)
[18:34] <UNIm95> henrix: apw damn. without kernel change i have 10 hours uptime without panic.
[19:59] <t3hSteve> so re: my cgroup issue, it looks like the more threads a process has the more the cpuacct.stats numbers diverge
[20:36] <t3hSteve> apw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-raring/+bug/1497447
[20:36] <t3hSteve> I'm not sure if I filed it against the right package?
[20:43] <old_benz> Hi all, I think the "flo" branch needs to be patched to support newer Nexus 7 devices with an updated eMMC controller, I need to compile a new kernel and patch my boot.img and recovery.img in order to get Ubuntu Touch to install on my Nexus 7
[20:43] <old_benz> details are here: https://github.com/ddagunts/UTCWM_N7_patch
[21:41] <apw> old_benz, if you could file a bug against linux-flo with that information and drop the bug # in here ...
[22:27] <old_benz> apw: will do, need to make an account


[01:05] <cmaloney> AA CHC was tonight. Was a lot of fun to chat with folks
[01:06] <cmaloney> vitrual, still
[02:00] <greg-g> Good to hear it's still going
[02:06] <cmaloney> Yeah, they're doing a great job.


[01:57] <amejia> superm1: hi, actually it never built on debian ppc
[01:57] <amejia> superm1: which is strange since the same packaging builds fine on ubuntu ppc
[01:58] <amejia> superm1: if you want to sync the package from experimental to precise, it's fine
[01:59] <amejia> superm1: nothing else has changed that would lead me to believe the ppc build will fail for precise
[02:24] <red_one> anybody know if the mythbuntu 12.04 daily images are close enough to "release" to be used reliably?
[03:21] <superm1> amejia: maybe i mentioned that wrong.  the 4/7 build built on ubuntu PPC.  the 4/23 failed on ubuntu PPC
[03:21] <superm1> maybe it's a GCC change between then and now though
[03:21] <superm1> that seems more likely
[03:21] <superm1> red_one: yes, it's about to release in 2 days
[03:21] <superm1> if you find any issues, please raise them immediately
[03:21] <superm1> so they can be fixed before then
[03:33] <qwebirc80591> Hi all, just trying an install of mythbuntu 64 bit on intel platform. Install seemed OK but the update manager seems to be freezing. I am very new to linux so am struggling on where to look. Have checked term.log. last line in that log is "Setting up Samba (2:3.5.11~dfsg-1ubuntu2.2) ...
[03:34] <qwebirc80591> Have also checked history.log in /var/log/apt and it seems to have a lot of text with amd64 in it? could this be related?
[03:35] <superm1> qwebirc80591: is this a fresh 12.04 install?
[03:35] <superm1> or is this an older version?
[03:37] <qwebirc80591> This is a 11.10 install from the mythbuntu iso
[03:49] <qwebirc80591> version is at http://pastebin.com/Tp3zyh8a
[03:49] <Zinn> [pastebin.com] Spam Detection For Paste ID: Tp3zyh8a
[04:02] <qwebirc80591> !help
[04:02] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[04:14] <qwebirc80591> Am going to retry install again. Will be back if it fails a second time.
[05:07] <mycosys1> !release
[05:07] <Zinn> Sorry I don't know about release
[05:08] <mycosys1> !iso
[05:08] <Zinn> Storage Groups are a streaming method of transmitting material to a frontend, meaning they don't provide block-level access to the file in question. An ISO is a disk image, and requires block-level access. This issue is fixed for unencrytped ISOs in 0.24. the following workaround will help in all other cases: http://www.baablogic.net/drupal/node/7
[05:09] <superm1> !daily
[05:09] <mycosys1> ok - so my question is actually when 12.04LTS ISOs are likely to turn up lol
[05:09] <Zinn> zsync http://cdimages.ubuntu.com/mythbuntu/daily-live/current/maverick-desktop-i386.iso.zsync  <+|+>   zsync http://cdimages.ubuntu.com/mythbuntu/daily-live/current/maverick-desktop-amd64.iso.zsync
[05:09] <superm1> i think that's what you are looking for
[05:09] <superm1> oh those are old links
[05:09] <superm1> man we gotta update the bot
[05:09] <superm1> mycosys1: http://cdimages.ubuntu.com/mythbuntu/daily-live/current/
[05:09] <Zinn> [cdimages.ubuntu.com] Mythbuntu 12.04 (Precise Pangolin) Daily Build
[05:10] <superm1> mycosys: they're about to be turned into 12.04 ISOs, just doing final testing.  if you are going to test, please add your test results at http://iso.qa.ubuntu.com/qatracker/milestones/214/builds
[05:10] <Zinn> [iso.qa.ubuntu.com] Precise Pre-release | Ubuntu QA
[05:10] <mycosys> superm1: as always - i mean years of always - u rock superm1
[05:10] <superm1> thanks :)
[05:11] <mycosys> will feed that info to my FIL
[05:11] <mycosys> i am likely to do a full rebuild in June when semester breaks
[05:12] <mycosys> he sounded like he wanted to go on it sooner
[05:12] <mycosys> and the thanks should be going to u :P
[07:05] <red_one> hi
[07:05] <red_one> i'm using the latest build of precise
[07:05] <red_one> in capture card setup
[07:05] <red_one> it's not picking up any video devices
[07:07] <red_one> lspci says multimedia controller: Phillips semiconductor SAA7130 Video Broadcast Decoder (rev 01)
[07:07] <red_one> 05:0a.0
[14:03]  * sabhain wonders if anyone here runs dual monitors w/ separate x-sessions using Gnome3.
[22:19] <Batshua> So, I have a problem. My HDMI output is acting weird. (It's off-center, but only after Xfce starts.) I'm running Natty. I was told to upgrade my kernel to at least 3.0 to fix it. However, when I was running Oneiric, my wireless card didn't work. Any ideas on what to do? (Including the proper channels for complaining about a wireless card that works under Natty but not Oneiric…)
[22:19] <Batshua> I'm off to do grocery shopping, but I welcome ideas in privmsg.


[10:57] <meeting> * meeting_-es has joined
[10:57] <meeting> * meeting_-es changed topic to Este es un espejo de #ubuntu-sugarteam. Lo que usted escribe en Español aquí, se traducirá a English, luego se enviará a #ubuntu-sugarteam, y viceversa. http://wiki.sugarlabs.org/go/Service/meeting/Usage
 * The translation has begun for #ubuntu-sugarteam
 <*meeting-In> * meeting_ has joined
 <*meeting-In> * meeting_ subject changed to *East *is *a *mirror *of #ubuntu-sugarteam. *The *that *you *writes *in *Spanish *here, *will translate * an English, *afterwards *will send * a #ubuntu-sugarteam, *and *vice versa. http://wiki.sugarlabs.org/go/service/meeting/usage
 <*meeting-In> <Meeting_-*is> * The translation has begun for #ubuntu-sugarteam
 <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ has joined
 <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ subject changed to *the east *is *a *mirror *of #ubuntu-sugarteam. *The *that * *writes *in *Spanish *here, *will translate * an English, *afterwards *will send * a #ubuntu-sugarteam, *and *vice versa. http://wiki.sugarlabs.org/go/service/meeting/usage
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> * The translation has begun for #ubuntu-sugarteam
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ has joined
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ subject changed to *the east *is *a *mirror *of #ubuntu-sugarteam. *The *that * *writes *in *Spanish *here, *will translate * an English, *afterwards *will send * a #ubuntu-sugarteam, *and *vice versa. http://wiki.sugarlabs.org/go/service/meeting/usage
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> * The translation has begun for #ubuntu-sugarteam
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ has joined
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ subject changed to *the east *is *a *mirror *of #ubuntu-sugarteam. *The *that * *writes *in *Spanish *here, *will translate * an English, *afterwards *will send * a #ubuntu-sugarteam, *and *vice versa. http://wiki.sugarlabs.org/go/service/meeting/usage
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> * The translation has begun for #ubuntu-sugarteam
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ has joined
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> * meeting_ subject changed to *the east *is *a *mirror *of #ubuntu-sugarteam. *The *that * *writes *in *Spanish *here, *will translate * an English, *afterwards *will send * a #ubuntu-sugarteam, *and *vice versa. http://wiki.sugarlabs.org/go/service/meeting/usage
 <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> <*meeting-In> <Meeting_-*is> * The translation has begun for #ubuntu-sugarteam


[09:07] <jhunt> PuffTheMagic: http://upstart.ubuntu.com/cookbook/#running-upstart-as-a-non-privileged-user