[12:43] <SynrG> re
[12:44] <SynrG> still seeking an admin to fix wiki access for me
[12:47] <SynrG> summary if you weren't around for this earlier: 1) i registered with launchpad today, but found it was a duplicate becase I'm a DD and was autoregistered before.  daf assigned an email address to the autoregistered identity, which sent me an automatic confirmation.
[12:48] <SynrG> 2) i couldn't confirm, but i could use the forgotten password feature, which i confirmed, logged in, and then tried to confirm the email address.  the system prevented me, saying i was already confirmed under that address.
[12:49] <SynrG> 3) i logged in under the rescued autoregistered identity (now has email addr<EMAIL_ADDRESS>assigned) and merged the identity i created today successfully.
[12:50] <SynrG> 4) now i can login to launchpad with either identity, but the wiki doesn't accept my password to change anything on my UserPreferences.  it tells me it doesn't match.  in spite of this, i appear to be logged into the wiki when i login via dashboard.
[12:50] <SynrG> so ... I need an admin to unconfuse Moin about my password, apparently.
[12:53] <SynrG> i have just now retried, and i have the same problem again.  i can login to dashboard, which in turn logs me into the wiki, but the wiki doesn't seem to like my password when I change something on UserPreferences (timezone) and press "Save")
[01:07] <mpt> SynrG, now's a bad time unfortunately, most people are asleep
[01:08] <mpt> If you can be awake sometime between 8 and 16 hours from now, that would be a better time to ask
[01:11] <ddaa> SynrG: talking launchpad wiki right?
[01:11] <ddaa> once you are logged in, just _clear_ the password field in the UserPreferences page and you will be able to POST it.
[01:12] <ddaa> Got bitten by the bug, it's in malone somewhere. I think spiv is the man to fix it one day.
[01:12] <ddaa> Then, generally use Launchpad if you want to change the password.
[01:16] <ddaa> SynrG: Mh... actually, I cannot find it in Malone. Would you be kind enough to file the bug?
[01:19] <SynrG> ddaa: wiki.ubuntu.com
[01:20] <SynrG> mpt: noted. but tomorrow i'm getting married, so it's kind of inconvenient to be here then :)
[01:23] <SynrG> ddaa's tip solved it
[02:42] <lt_zaq> testing
[03:14] <stub> jamesh: Want to run the bug contact importer now?
[03:15] <jamesh> stub: okay.
[03:16] <jamesh> stub: I've got permission to read the mysql database on macquarie
[03:16] <stub> I assume you need to run it, as it will need access to the Bugzilla database
[03:16] <stub> I'll open up access to production from there. Any particular DB user?
[03:16] <jamesh> for testing, I've just been running as the default "launchpad" user.
[03:17] <jamesh> which is probably okay, since it is a one off script
[03:17] <stub> We can run it against that user. I'll just keep it open for a small window.
[03:17] <jamesh> I'll just update my tree on macquarie
[03:19] <stub> jamesh: jamesh@macquarie should now be able to connect as launchpad to the production db
[03:21] <jamesh> thanks.
[03:27] <jamesh> stub: so what $LPCONFIG should I run with?
[03:28] <jamesh> production?
[03:28] <stub> You might need to make one. Production might work, but might need a bit of hacking if there are any non-existant, required paths.
[03:29] <stub> The database connection settings can be pulled from production though
[03:59] <jamesh> stub: okay.  Looks like everything went okay.  You can remove the permission grant
[04:00] <stub> Cool :-)
[04:04] <jamesh> so now https://launchpad.net/distros/ubuntu/+source/gnome-panel/+subscribe says seb128 will get bug mail
[04:55] <jamesh> morning mpt
[04:56] <mpt> afternoon jamesh :-)
[04:56] <jamesh> it is still morning here for another 3 minutes
[05:01] <mpt> good afternoon now, then
[09:28] <Simira> hey
[09:54] <SteveA> hello Simira
[09:54] <SteveA> hello world
[09:55] <Simira> can someone put up koffice for translation in Rosetta?
[09:55] <Simira> morning SteveA
[10:02] <SteveA> Simira: jordi or carlos can do that.  carlos should be around in a few hours.
[10:03] <Simira> mhm, I couldn't see any of them. I'll give a mail
[10:56] <SteveA> daf: hello
[10:57] <daf> hi Steve
[11:02] <SteveA> do we have more bugs to look through?
[11:07] <daf> we have the "Communication" and "Other" categories to look through
[11:09] <daf> I'm really looking forward to bug keywords
[11:09] <daf> I'm going to get some breakfast
[11:10] <SteveA> when shall we start? 20 mins?
[11:10] <daf> how about we look at them at 13:00 your time?
[11:10] <SteveA> okay, 50 mins from now
[11:10] <daf> cool
[11:20] <jblack> stevea: ping
[11:39] <SteveA> hey jblack.  i just read your email.  thanks for sorting this all out.
[11:40] <SynrG> morning
[11:41] <SynrG> daf: thanks.  got it sorted out yesterday.  daaa said this is a known problem, but not filed in Malone.  he asked if i'd file it, but i didn't get a chance to yet (first i have to find malone ;)
[11:42] <SynrG> daf: solution: leave the wiki password blank.  press save.
[11:44] <sabdfl> has mpt been and gone?
[11:46] <SteveA> sabdfl: yes
[11:47] <SteveA> i'll be talking with him monday morning
[11:47] <SteveA> is there something i can bring up with him?
[11:50] <sabdfl> SteveA: i sent him mail about wordpress as a blogging frontend for launchpad users
[11:50] <sabdfl> currently wordpress uses mysql
[11:51] <sabdfl> i suspect that's fine to keep as-is, as long as we can do the user storage in LP
[11:51] <sabdfl> auth-to-lp
[11:51] <SteveA> i see
[11:51] <SteveA> i guess it depends how modular the wordpress storage code is
[11:51] <daf> SynrG: https://launchpad.net/products/launchpad/+bug/3987 -- is this the problem you saw?
[11:52] <Ubugtu> Malone bug 3987: "Launchpad wiki UserPreferences causes mismatched passwords" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Andrew Bennetts, Status: NeedInfo http://launchpad.net/bugs/3987
[11:52] <SteveA> whether it treats it as all-or-nothing, or if it allows plugging in user sources
[11:52] <SteveA> it's quite a common requirement to plug in user sources independently of other data.  so you can link it with ldap things, for example.
[11:53] <daf> http://www.weblogs.uhi.ac.uk/sm00ay/?p=18
[11:53] <SynrG> daf: checking
[11:53] <daf> if they can do it with LDAP, I suspect using the authserver would not be too hard
[11:54] <SynrG> daf: yes.  that's apparently the same problem.  thanks.
[11:54] <SteveA> sabdfl: i've made a note about wordpress for my call with mpt on monday
[11:55] <SteveA> daf: 5 mins?
[11:55] <sabdfl> cool, thanks
[11:55] <daf> SteveA: I expect that Andrew wlil reply to my question when he gets back
[11:55] <daf> er
[11:55] <daf> SynrG: ^^^
[11:55] <daf> hopefully we can get that fixed soon
[11:55] <SynrG> god
[11:55] <SynrG> er, good, too
[11:55] <daf> feel free to subscribe to the bug in the meantime
[11:55] <sabdfl> oops
[11:55] <sabdfl> https://staging.ubuntu.com/distros/ubuntu/+bugs
[11:55] <daf> SteveA: yes
[11:56] <sabdfl> that shouldn't happen
[11:56] <sabdfl> BjornT: is that a known issue?
[11:56] <SynrG> daf: subscribed.
[11:57] <daf> sabdfl: are you getting a traceback?
[11:57] <daf> sabdfl: I'm not
[11:57] <daf> (just an OOPS page)
[11:58] <BjornT> sabdfl: hmm, no, i didn't know about it. i'll have to check what's causing the oops.
[11:58] <sabdfl> daf: i also see an oops
[11:58] <sabdfl> it works on production
[11:58] <stu1> The patch to let launchpad developers see exceptions hasn't landed yet.
[11:58] <daf> at any rate, we can get the tb from chinstrap when it's synced
[11:58] <daf> hmm, I could have sworn I saw a traceback somewhere the other day
[11:58] <daf> on Launchpad
[11:59] <stu1> You see them - it just isn't consistant
[11:59] <daf> ah, I see
[11:59] <stub> That particular issue is that I havn't run the data migration for brads bugtaskstatus update on staging
[11:59] <daf> ah, so the tests would have passed on the sample data
[12:00] <BjornT> ok, good
[12:01] <stub> sabdfl: Working now
[12:01] <daf> stub: what's the word on bug 1433?
[12:02] <sabdfl> aha
[12:02] <sabdfl> thanks stub
[12:02] <daf> I'm guessing it's not so much a problem for PQM these days
[12:02] <daf> Ubugtu: wake up
[12:02] <sabdfl> stub: are you expecting a performance jump with pg 8.0? any reason not to wait for 8.1?
[12:02] <daf> https://launchpad.net/products/launchpad/+bug/1433
[12:02] <Ubugtu> Malone bug 1433: "existing /var/tmp/fatsam.test breaks the test suite" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/1433
[12:03] <stub> sabdfl: It will be a performance boost. We could wait until 8.1 has been packaged and we have tested it if we want to minimize downtime
[12:03] <stub> (each major release will cost us several hours)
[12:03] <sabdfl> 8.1 is packaged in dapper
[12:03] <SteveA> yes, kiko talked to pitti about it yesterday
[12:04] <stub> You want elmo to upgrade emperor to dapper ? :-)
[12:04] <SteveA> kiko, stub and i had a long meeting about database versions and a performance plan yesterday
[12:04] <SteveA> the outcome was that we move to 8.0 as planned next week, ask pitti to package a breezy backport of 8.1, test this, and maybe do an 8.1 upgrade in a few weeks
[12:04] <stub> daf: You sure about that bug number? I havn't looked at that one
[12:05] <daf> uh, it has a comment from you on it
[12:05] <SteveA> there were other outcomes to do with some work jamesh is doing towards logging problematic queries for timeouts
[12:06] <SteveA> and changing some of the tables that are involved in caches (such as the karma cache) so that we're not locking important tables like Person so much
[12:06] <stub> daf: Yup - just a comment for whoever gets around to fixing it
[12:06] <SteveA> when the cron scripts are running
[12:06] <SteveA> the main timeout problem we have that we need to look into more closely is to do with translation pages
[12:06] <daf> stub: fair enough, ta
[12:07] <SteveA> even with suggestions turned off, they still time out sometimes
[12:07] <stub> daf: It doesn't bite often so I don't think anyone has been bothered enough to fix it.
[12:07] <SteveA> the other problems will be addressed by things stuart will be doing shortly
[12:07] <daf> stub: oh, ok, "serious PQM downtime" is a bit misleading then
[12:08] <SteveA> stub: is postgres 8.0 to 8.1 a major version upgrade?
[12:08] <stub> daf: erm... yeah ;-) I don't think PQM has had a problem with this for a while, and it should be impossible now it is running in a chroot
[12:08] <stub> SteveA: Yes. I will need to do a full backup/restore which takes time.
[12:10] <daf> would a 7.x -> 8.1 upgrade be faster than 7.x -> 8.0 + 8.0 -> 8.1?
[12:10] <SynrG> the launchpad site center panel is quite constrained in width.  some pages look terrible in firefox 1.5 in 800x600
[12:10] <SteveA> you need to define "faster", daf
[12:10] <daf> "faster" == "less downtime"
[12:10] <SynrG> fortunately, reducing the font size a couple of increments fixes this problem
[12:10] <SteveA> one is one upgrade, the other is two upgrades
[12:11] <SynrG> but it's a bit of a pain
[12:11] <SteveA> it's going to take us a while to test 8.1 and become confident with it
[12:11] <SteveA> the 7.x upgrade to 8.x is risky in that it is a major version upgrade
[12:11] <stub> daf: Yes. We would half our downtime if we jumped to 8.1.
[12:12] <SynrG> i was just trying to read the code of conduct.  it was unreadable until i did this.  the text did not fit within the right margin and was truncated
[12:12] <daf> I'm wondering if skipping 8.0 would save one dump+restore cycle or whether we'll need to do two anyway
[12:12] <daf> stub: right, that's a fairly big incentive
[12:12] <daf> SynrG: URL?
[12:12] <jblack> stevea: ok. ~/ubuntu changed to ~/launchpad, 10,000 foot summary of Whats Going on written for RocketfuelSetup
[12:12] <daf> jblack: no, you changed it to ~/rocketfuel :)
[12:12] <SteveA> we halve the downtime over the period of several weeks.  this is planned downtime though, not random downtime.
[12:12] <jblack> I mean ~/rocketfuel
[12:13] <SteveA> hello mpt
[12:13] <SteveA> mark was asking about the email he sent you about getting wordpress working with launchpad
[12:14] <SteveA> i proposed that you and i talk about that in our call on monday
[12:14] <daf> I don't think users are picky about the distinction :)
[12:14] <mpt> SteveA, ok
[12:14] <jblack> daf: I betchabetchabetcha they'd complain about ~/launchpad/launchpad
[12:15] <daf> jblack: prob'ly :)
[12:15] <SteveA> also... if we get a better machine for the database, there will be downtime then
[12:15] <SteveA> jblack: how long are you around for today?
[12:15] <jblack> I'm late for yesterday, actually.
[12:15] <jblack> What's up?
[12:15] <SteveA> jblack: i'd like to talk with you about these docs some more, and i've arranged to do some bug work with daf right now
[12:16] <SteveA> i'll work through the docs, and we can talk some other time, okay?
[12:16] <stub> SteveA: I've replied to a query elmo sent me (emperor load spike) about the server. I'll bounce you a copy.
[12:16] <daf> if jblack is going to go offline, I'm happy to postpone
[12:16] <jblack> Give me an offset from now() and I'll be here
[12:16] <mpt> SteveA, I remembered why the summary of actions needed to be above the bug comment: so that it can contain the expander that expands the comment (e.g. an original bug description that's collapsed by default)
[12:16] <SteveA> thanks stub
[12:16] <daf> mpt, SteveA: https://launchpad.net/products/launchpad/+bug/5578 needs a UI decision
[12:16] <Ubugtu> Malone bug 5578: "Should "Create Branch" be on the overview page of a product?" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/5578
[12:16] <stub> SteveA: I suspect the load spike was caused by some cron jobs treading on each other, causing excessive timeouts in Launchpad
[12:17] <stub> SteveA: And the ones we saw after that were just 'normal' timeouts.
[12:17] <SteveA> mpt: i don't follow immediately and i'm in too many conversations at once... do what you think is best in the spec, and we'll talk about it monday
[12:17] <mpt> daf, I'm not at work, it's midnight and I just popped on to see if kiko was here
[12:17] <SteveA> mpt: a bit early for kiko, by 1 hour
[12:18] <mpt> mail me about it if there's been no bugmail in the past couple of days, and I'll get to it
[12:18] <daf> mpt: sure thing
[12:18] <mpt> thanks daf
[12:19] <stub> I'm off to grab dinner in moment
[12:19] <SteveA> stub: will you make the cache updater cron scripts run serially ?
[12:19] <SteveA> i'm thinking to have one cache update script that itself updates caches in series
[12:20] <SteveA> daf: voip?
[12:20] <daf> SteveA: ready
[12:21] <jblack> stevea: offset?
[12:21] <stub> SteveA: That would be a good idea for all the dailies.
[12:21] <SteveA> jblack: pardon?
[12:22] <jblack> offset from now() that you want me for?
[12:22] <jblack> 10 minutes, 1 hour, next thursday...
[12:22] <SteveA> jblack: did you say that you're about done for this workday ?
[12:22] <stub> SteveA: Just a shell script on production though - as we grow servers, various scripts may end up on different boxes (eg. gina is running daily on drescher)
[12:23] <jblack> I'll stay up if you don't want 4 hours from now.
[12:23] <SteveA> stub: they all have contention on the master database
[12:23] <SteveA> jblack: i'll be working for the next 6-7 hours i expect
[12:23] <SteveA> so later is fine
[12:23] <stub> SteveA: If that is a problem, we can keep the master on emperor which runs them via ssh on the relevant boxes.
[12:24] <SteveA> stub: i don't mind so much how it works, just that we have a sane way of not having scripts running at the same time
[12:24] <SteveA> jblack: just ping me when you're around after sleeping etc.
[12:24] <stub> Sure.
[12:24] <SteveA> it will give me some time to look through the docs again
[12:24] <jblack> sure. email me your concerns and I'll read them when I get up.
[12:24] <stub> Back in an hour
[12:25] <SteveA> jblack: ok, ta
[12:27] <SynrG> daf: https://launchpad.net/codeofconduct/1.0
[12:40] <matsubara> good morning!
[12:59] <SynrG> daf: also, after adding my image to my profile, my irc and jabber ids overwrite the image in 800x600 mode: https://launchpad.net/people/synrg
[12:59] <SynrG> daf: i can fix this by reducing font size, but now the font is unreadable
[01:00] <SynrG> if i could configure launchpad to not have a right sidebar, i'd probably be ok
[01:00] <SynrG> left sidebar, even
[01:01] <SynrG> well, actually, whichever one suits the user best
[01:07] <SynrG> mind you, now that I've added content, there is no longer a problem.  The text flows around the photo.
[01:07] <SynrG> that's an acceptable workaround.
[01:21] <SteveA> stub: when you're back, i want to point you at carlos' code reviews
[01:21] <stub> SteveA: Yup.
[01:22] <stub> Took 1.5 hours to bzr pull --overwrite the first branch :-/
[01:25] <SteveA> stub: there's a description of how to do review kinda things on the new Rocketfuel docs on the wiki that jblack has been working on
[01:25] <SteveA> are you using that process, i wonder, or a different one
[01:26] <kiko> hello guys
[01:28] <stub> I need local branches so I can test database patches
[01:28] <stub> Which is normally quicker :-/
[01:29] <kiko> hey stub
[01:29] <kiko> how's it going?
[01:29] <stub> fine. nothing much thrilling today.
[01:30] <SteveA> stub: maybe a merge into a RF branch would be quicker than a pull --overwrite
[01:30] <stub> Mmm.... yes. I'll try that next time.
[01:31] <daf> kiko: do you know when Carlos is planning to land POMsgSetView?
[01:38] <SteveA> i think POMsgSetView is being worked on right now
[01:42] <kiko> daf, SteveA: carlos started on that end of last year
[01:56] <daf> SteveA: ?
[02:05] <daf> ah, Steve's DSL is down
[02:05] <kiko> it happened yesterday too, bummer
[02:06] <daf> if there's anybody going to land a change soon, there's a trivial fix you can do
[02:06] <daf> otherwise, I'll do it myself
[02:13] <stub> I  just approved one of carlos' branches
[02:13] <daf> carlos is on holiday today
[02:13] <daf> which branch, by the way?
[02:18] <daf> ah, I see it
[02:31] <kiko> I miss stevea
[02:38] <daf> kiko: any idea if gneuman will be around today?
[02:39] <kiko> daf, yeah, he should be
[02:39] <daf> cool
[02:41] <kiko> damn
[02:43] <cprov> BjornT: ping
[02:45] <tuhl> where can I find documentation about the build environment?
[02:48] <daf> tuhl: I don't understand
[02:48] <daf> the build environment of what?
[02:49] <tuhl> the new lauchpad based build environemnt
[02:50] <tuhl> for ubuntu based distros
[02:50] <daf> ah, I don't know much about that
[02:50] <cprov> tuhl: try https://wiki.launchpad.canonical.com/AutoBuildManagement
[02:54] <tuhl> cprov: thanks - when will the plattform opened?
[02:57] <cprov> tuhl: I'm not sure, this decision isn't up to me, "when it's ready" kind of fits ;)
[02:59] <tuhl> Mark told me that some bugs have to be resolved first but it should be possible to start soon
[03:00] <daf> well, I think from the package maintainer's point of view, it will work much like the old system
[03:00] <daf> except that build logs will show up in Launchpad
[03:00] <cprov> tuhl: "soon" can vary a lot, I'm doing my best to make it ready ASAP (next month)
[03:00] <cprov> daf: indeed
[03:00] <tuhl> cprov: that is soon :-)
[03:01] <cprov> tuhl: I'm glad it makes you happy
[03:05] <cprov> daf:  maybe you can help me, just did a rollout in mawson and LP is desperately trying to send emails for foobar/test/etc from<EMAIL_ADDRESS>do you know what is it ?
[03:06] <daf> hmm
[03:09] <daf> bounce@ or bounces?
[03:11] <daf> ah<EMAIL_ADDRESS>is the standard bounce address in schema.xml
[03:11] <cprov> daf: yup, any clue ?
[03:12] <daf> well, I'd guess it's a cron script
[03:12] <daf> then again, I didn't think any cron jobs ran on staging
[03:16] <cprov> uhmm ... cron ? don't think so, it just happens when LP is running
[03:16] <dilys> Merge to devel/launchpad: [r=SteveA]  Reenable exception display when logging in as a launchpad developer, fixing Bug 5339 (r2957: Stuart Bishop)
[03:17] <cprov> daf: the error mensages are in launchpad.log
[03:18] <cprov> daf: see some of them at https://chinstrap.ubuntu.com/~dsilvers/paste/file9J7daL.html
[03:20] <cprov> daf: hopefully mawsons smtpd is off ;)
[03:20] <kiko> hopefully or thankfully? :)
[03:22] <daf> cprov: looks like it :)
[03:22] <BjornT> cprov: pong (i'm not paying much attention to irc atm)
[03:22] <cprov> kiko: much like thankfully, thanks
[03:23] <daf> cprov: by the way, I've noticed your English has been really good recently
[03:23] <cprov> BjornT: np, maybe you can help me with this mysterious email issue at mawson, what is sending email in LP ?
[03:24] <daf> well, something must be running the delivery process
[03:24] <cprov> daf: it's not true, who did say that ? ;)
[03:24] <daf> lib/zope/app/mail/delivery.py
[03:24] <daf> the thing which put the messages into the queue is probably no longer running
[03:26] <cprov> I'm happy with any solution either destroy the queue content or stop the dispatcher ... don't know how
[03:26] <BjornT> cprov: hmm, not quite sure. do you want emails to be sent at all?
[03:27] <cprov> BjornT: no, can live w/o them
[03:28] <BjornT> cprov: ok, then it should be enough if you add a mail:stubMailer in mail-configure-normal.zcml. you can look how it's done for staging.
[03:28] <cprov> BjornT: I was expecting something in lp.conf to disable it
[03:28] <cprov> aha
[03:28] <cprov> new conf file ...
[03:33] <cprov> BjornT: great, solved, thank you
[03:34] <cprov> BjornT: sorry for disrupt you with suck dummy question ... didn't notice the new config file
[03:35] <BjornT> np. ideally everything should be in launchpad.conf, but there's still a few things that aren't
[03:41] <stub> cprov: Fixed auth for the session user on mawson.
[03:41] <kiko> thanks stub
[03:42] <stub> cprov: Have you created a database for the session data yet? If not, give me the name of the database you are using in the launchpad.conf
[03:42] <cprov> stub: thanks, seesion DB is already there
[03:43] <cprov> stub: was created via make schema, it that a problem ?
[03:43] <stub> That should be fine
[03:43] <cprov> stub:  it might point to lp_dev
[03:44] <cprov> stub: and I'm using lp_dogfood
[03:44] <stub> I'll rename it to session_dogfood
[03:44] <cprov> stub: never mind, it works
[03:45] <cprov> stub: if you say so, I'll fix the lp.conf fo DF
[03:45] <stub> I'll leave it
[03:45] <cprov> stub:  ok
[03:48] <cprov> stub: can you mark  RT # 1616 as resolved ?
[03:48] <stub> Nope.
[03:48] <stub> Znarl or SteveA have the power
[03:49] <cprov> stub: ok, I'll poke karl, thanks for the help, saved my day .
[04:04] <ddaa> stub: you around?
[04:05] <stub> ddaa: Yes
[04:05] <ddaa> would be nice if we could sort of pair-deploy the updatebranches script today
[04:05] <ddaa> I think most/all the pieces are in place now
[04:05] <stub> That would need to be soon - it is 10pm here.
[04:06] <stub> What needs to be done from my end?
[04:08] <ddaa> Mh, nothing except the db access (I don't remember the user to su to right now, so cannot check)
[04:08] <ddaa> just got the impression mgmt wanted us both familiar with the set up
[04:08] <SynrG> ddaa: that fixed my problem.  also, as daf has pointed out, it *is* in malone: https://launchpad.net/products/launchpad/+bug/3987
[04:08] <Ubugtu> Malone bug 3987: "Launchpad wiki UserPreferences causes mismatched passwords" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Andrew Bennetts, Status: NeedInfo http://launchpad.net/bugs/3987
[04:09] <ddaa> and since we have different ways of doing rollouts...
[04:11] <ddaa> stub: okay, I can "psql -U importd -h emperor launchpad_prod" from bzrsyncd@gandwana
[04:11] <ddaa> I think I can handle the rest by myself
[04:11] <ddaa> good night
[04:12] <stub> Ok. I'll be around a while still if you need me.
[04:13] <stub> Is importd the correct user to use in the long term?
[04:13] <stub> I think we already had this discussion, and it is in my mailbox
[04:18] <ddaa> stub: I guess whatever we said is vaguely incorrect
[04:18] <ddaa> the whole buttsource/importd design has become largely obsolete
[04:18] <ddaa> I guess you are the one to make the call at whether we need new and different users
[04:19] <ddaa> As long as my scripts can poke the DB as needed, and that I have a login with some broad permissions to do diagnostic and fixup, I'm happy.
[04:20] <stub> I'll worry about it once I've put together some auditing tools to determine what access particular processes need - it is too slow and painful to do it manually
[04:30] <SteveA_> stub: hello
[04:31] <daf> hi Steve
[04:31] <SteveA_> stub: carlos knows that the `sftp://chinstrap/home/warthogs/archives/carlos/launchpad/bug-5751-2` contains the other stuff.  he couldn't work out how to get baz to do this well.
[04:31] <daf> gneuman: yo
[04:31] <SteveA_> hi daf
[04:31] <gneuman> daf,
[04:31] <gneuman> yo
[04:32] <daf> I was looking at this: https://launchpad.net/products/launchpad/+bug/3068
[04:32] <Ubugtu> Malone bug 3068: "Adding poll with the same name in the same team causes ops..." Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: marisa, Status: Accepted http://launchpad.net/bugs/3068
[04:32] <gneuman> yes
[04:32] <daf> have you spoken to marisa about it recently?
[04:32] <gneuman> no
[04:32] <gneuman> i got no answer
[04:33] <daf> ok -- perhaps you should go ahead with your fix rather than waiting
[04:33] <stub> SteveA_: Merge them into one branch and put that up for review would have worked
[04:33] <gneuman> ok
[04:33] <daf> I don't know who marisa is
[04:33] <daf> maybe they misunderstood what assigning means
[04:34] <daf> I'll assign it to you
[04:34] <gneuman> ok
[04:34] <daf> thanks
[04:34] <SteveA_> stub: i asked him to offer it as two separate reviews originally, because it looked like it would be messy to review otherwise
[04:35] <daf> SteveA_: where would you like me to put the bug/milestone assignement doc?
[04:35] <daf> SteveA_: LaunchpadMilestoneManagement?
[04:36] <daf> LaunchpadBugManagement?
[04:36] <ddaa> grah... it's snowing again!
[04:36] <daf> lucky you
[04:36] <ddaa> I've been wanting to go to the roller night for _months_!
[04:36] <ddaa> It's always raining or snowing on fridays when I'm free :(
[04:37] <ddaa> beside's it's not cold enough for the snow not to melt
[04:37] <daf> ah, shame
[04:42] <daf> honestly, who calls their project 'bum'?
[04:43] <SynrG> a purile nerd?
[04:43] <ddaa> some people call their command line tools baz...
[04:43] <daf> maybe English wasn't their native language
[04:43] <SynrG> puerile, even
[04:47] <Nafallo> bootupmanager ;-)
[04:47] <Nafallo> or rather BootUpManager :-P
[04:47] <daf> Nafallo: yes: https://launchpad.net/products/bum
[04:48] <SteveA_> daf: the thing is, this is about our processes for assigning bugs to launchpad milestones, and managing bugs filed on the launchpad project
[04:48] <SteveA_> daf: we must try to not confuse people with a too general title
[04:48] <Nafallo> so bum in short then :-)
[04:48] <jblack> SteveA: Somehow, I'm still up
[04:48] <SteveA_> daf: maybe LaunchpadProjectMilestones ?
[04:48] <SteveA_> hi jblack
[04:48] <daf> SteveA_: sounds good to me
[04:49] <SteveA_> jblack: my dsl connection is not working.  i'm currently on gprs, which isn't a very fat or fast pipe
[04:50] <jblack> Ok. Tomorrow perhaps
[04:50] <SteveA_> daf: tramp - remote file access in Emacs
[04:50] <SteveA_> daf: so, "bum" has company
[04:50] <SteveA_> jblack: yeah... my day has been a bit thrown off by the DSL outage
[04:50] <daf> hmm, hadn't thought of the en_US sense
[04:51] <Nafallo> well, alacarte was named smeg before so... ;-)
[04:52] <jblack> stevea: If you still want to talk though, I do have skype. I can do pots over that.
[04:55] <daf> SteveA_: here's a draft: https://wiki.launchpad.canonical.com/LaunchpadProjectMilestones
[04:55] <daf> SteveA_: shall I send a mail?
[04:55] <SynrG> speaking of package names and profanity, don't forget that apt used to be called deity
[04:56] <SynrG> bum is mild by comparison
[04:56] <daf> well, profanity is in the eye of the beholder
[04:57] <SynrG> bum is a line of clothing too.
[04:58] <SteveA_> daf: i will read it
[04:58] <SteveA_> daf: I always found the en_US idiom "it's a bum rap" very confusing
[04:59] <daf> I can see why
[04:59] <SteveA_> SynrG: a friend and i were drinking in a pub, and saw our boss come into the pub, with his brother visiting from the US.  this was about 12 years ago.  The brother was wearing a sweater that loudly announced "BUM EQUIPMENT".  My friend and I fell about laughing for a very long time.
[05:00] <SynrG> SteveA_: :)
[05:00] <jblack> I have no idea where that term comes from, though I know what it means.
[05:00] <SteveA_> i only found out later that it is a brand of clothing
[05:00] <SteveA_> jblack: does it mean "a telling off"
[05:00] <SteveA_> like "he was given a telling off by his boss" == "he was given a bum rap by his boss" ?
[05:01] <SteveA_> verbal discipline...
[05:01] <jblack> Nope. It means that one got punished/blamed for something they didn't do, or punished much more than the crime deserved.
[05:02] <jblack> Its since evolved a bit to also mean "a bad reputation"
[05:02] <SteveA_> i have no idea how to say that in en_GB
[05:02] <SynrG> well, rap, as in "rap sheet".  "bum" as in "bad"
[05:03] <daf> usatoday.com: "Is fat getting a bum rap?"
[05:03] <jblack> There's three or four meaning for the word "rap", none of which has to do with knocking on things.
[05:03] <jblack> daf: that woudl be the "undeservedly bad reputation" definition
[05:03] <daf> indeed
[05:03] <SteveA_> bradb: milestones are going to be increasingly important to us.  do you think a bug's page can display what milestone it is assigned to?
[05:04] <daf> SteveA_: I've filed a bug on that
[05:04] <daf> bug 6014
[05:04] <bradb> SteveA_: Sure. Thinking required.
[05:04] <Ubugtu> Malone bug 6014: "milestone should be displayed on bug page" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/6014
[05:04] <SteveA_> it still sounds like something vaguely obscene to me
[05:04] <jblack> oh, you have no idea.
[05:05] <daf> some preposterious conjunction of music and posterior
[05:05] <daf> SteveA_: if there is a bug open about finding bugs not assigned ot milestones, I can't find it
[05:06] <bradb> daf: Use Google to find bugs filed in Malone.
[05:06] <daf> hmm, ok
[05:06] <daf> using Malone's own search usually works for me
[05:06] <bradb> :)
[05:07] <bradb> I use Google for bugs that I'm sure were filed, that I can't find via Malone's search.
[05:08] <daf> perhaps the advanced search syntax could support it
[05:08] <daf> but it's not explicitly mentioned there
[05:09] <daf> oh, something I noticed: of the 1123 oopses that happened yesterday, 252 were from googlebot
[05:10] <SteveA_> daf: good stuff on the milestones doc.  I've made a few small changes.  you can announce it now.  i discussed it with kiko on the phone a couple of hours ago.
[05:10] <daf> cool, thanks
[05:11] <SteveA_> daf: have you see jamesh's script to analyze oops reports?
[05:11] <daf> no
[05:15] <daf> many of the failures seem to be on build pages
[05:15] <daf> https://chinstrap.warthogs.hbd.com/~daf/googlebot-oopses
[05:15] <daf> SteveA_: where's James' script?
[05:16] <daf> cprov-lunch: maybe these mean something to you
[05:16] <SteveA_> daf: in /scripts.  but, there is a copy in ~stevea on chinstrap
[05:17] <SteveA_> daf: stevea@chinstrap:~$ ./analyse-error-reports.py /srv/gangotri-logs/2006-01-06/ > public_html/friday-so-far.txt
[05:17] <daf> got it
[05:18] <SteveA_> daf: chinstrap.warthogs.hbd.com/~stevea/friday-so-far.txt
[05:19] <daf> that's very nice
[05:19] <SteveA_> jamesh is continuing to develop the script
[05:20] <SteveA_> to distinguish between worrisome 404s and expected ones
[05:20] <SteveA_> worrisome ones are where it isn't a robot, and it has a referer that is a site we care about
[05:20] <SteveA_> as that indicates a broken linkn
[05:20] <SteveA_> such a site could be the wiki, for example, or shipit or launchpad
[05:20] <daf> well, robot ones are not so great either
[05:20] <daf> it might indicate a broken link
[05:21] <SteveA_> maybe, but robots look over links that were there last time the robot went around
[05:21] <daf> true
[05:21] <SteveA_> so, simply renaming something can lead to 404s
[05:21] <daf> I didn't think we had many pages that disappeared
[05:21] <SteveA_> or changing the URL hierarchy for some pages that we don't expect people to bookmark
[05:22] <SteveA_> sometime, we'll look into using the google site APIs to leave structured information to tell google how to best crawl the site
[05:26] <SteveA_> ooh
[05:26] <SteveA_> DSL came back
[05:27] <SteveA_> with a blast of polish pop music
[05:27] <SteveA_>  watch "ping -c 1 <IP_ADDRESS> && xmms music/Zanim\ Slonce\ Wstanie.mp3 "
[05:27] <SteveA_> has been running since lunchtime
[05:28] <jordi> Simira, SteveA_: I think koffice, and the rest of gnome and kde would be waiting for carlos' autoimport system for both
[05:28] <jordi> dunno how he wants to handle it in the meanwhile
[05:41] <cprov> daf: reading it
[05:47] <cprov> daf:  it might be generated by failures/missing on gina production run, I'm waiting the error-log sync on chinstrap to read the full traceback
[05:50] <jordi> SteveA_, kiko-fud: got email
[05:58] <ddaa> why does production deployment have to feel like trying to hit an elephant in the eye using a straw as an aim _and_ as a sarbacane?
[05:58] <ddaa> I mean s/sarbacane/pea-shooter/
[06:02] <kiko> thanks jordi
[06:03] <jordi> hey man
[06:05] <Simira> jordi :does that autoimport system have an eta?
[06:05] <jordi> Simira: I don't know, carlos will know
[06:05] <jordi> today is a holiday in Spain
[06:06] <jordi> dunno if he's on holiday
[06:06] <Simira> ok
[06:06] <jordi> the three wise men came last night and left presents for the kids :)
[06:07] <Simira> oh, right. We had that couple of weeks ago ;p
[06:07] <jordi> I heard ;P
[06:10] <kiko> and disassembling the christmas tree
[06:11] <jordi> xmas ends today in Spain :)
[06:11] <jordi> makes it long and annoying
[06:11] <kiko> it's always annoying
[06:12] <Simira> we are going over to some people to have a "christmas-tree-disassembling-party" tonight.
[06:12] <jordi> gah
[06:12] <jordi> the import queue is oopsing on me all the time
[06:13] <jordi> kiko: is there anything obvious in OOPS-A298?
[06:13] <jordi> Simira: is that disassembling violent?
[06:13] <jordi> like people pulling and tearing the tree
[06:13] <Simira> jordi : I hope not. This is my first time on that occation
[06:14] <jordi> and jumping on it, while yelling "wOOOHOOO!!"
[06:14] <jordi> Simira: boring!
[06:16] <jordi> kiko: I'm going to my town in the solitary mountains. I'll be networkless, but I'll bring my laptop to see if I can start writing something up.
[06:17] <jordi> kiko: any kind of suggestions before I elave?
[06:17] <kiko> ok, cool
[06:17] <jordi> mostly about how to focus the docs
[06:17] <kiko> hmm
[06:17] <kiko> not really I guess
[06:17] <jordi> I'll see what I come up with.
[06:17] <jordi> I'll make it a manual, I guess.
[06:18] <kiko> jordi, what day was that oops generated?
[06:18] <jordi> 5 mins ago
[06:20] <kiko> hmmm
[06:20] <kiko> ForbiddenAttribute: ('pofile', <TranslationImportQueueEntry at 0x2ab22c2c50>)
[06:20] <kiko> it's very odd
[06:20] <kiko> jordi, how did you get that?
[06:21] <jordi> kiko: trying to edit something in the import queue.
[06:21] <jordi> ie, setting the required fields to values, and pressing ok
[06:21] <kiko> jordi, it's a bug, probably easy to fix
[06:22] <kiko> jordi, wanna file it, and I'll get somebody to look at it?
[06:24] <jordi> k
[06:26] <jordi> pfft
[06:26] <jordi> what I import doesn't seem to appear in the product translations
[06:29] <kiko> ddaa, do you know the answer to mark's recent question on apt personal branches?
[06:30] <ddaa> I would probably have I knew what his expectations were.
[06:30] <kiko> yeah me too
[06:30] <ddaa> So the option looks like "say nothing", "hip shoot", "ask for clarifications an look stupid"...
[06:31] <SteveA> we can display bzr branches in launchpad... their metadata anyway, right?
[06:31] <jordi> ah, it did work
[06:31] <kiko> ddaa, hip shot then?
[06:31] <SteveA> we have some code that can get the metadata out of a bzr branch
[06:31] <kiko> it worked for doc
[06:31] <SteveA> we can register the 'apt' upstream bzr branch in launchpad
[06:31] <ddaa> SteveA: nope, I've been fighting to get the bits in place for a long time, right now I'm trying to get the metadata scanning cronjob online.
[06:31] <SteveA> and run the code on it to make its metadata appear in launchpad
[06:32] <SteveA> maybe not even as a cronjob
[06:32] <SteveA> just as a oneoff so we can see the stuff in launchpad
[06:32] <ddaa> Well, anyway, I'm trying to make it run _anyhow_.
[06:32] <SteveA> okay
[06:32] <kiko> heh
[06:32] <SteveA> so, seeing the bzr info for 'apt' in launchpad is a milestone
[06:32] <SteveA> and as soon as that milestone is achievable, go for it
[06:32] <ddaa> one nagging issue is that it does not look that any stuff served by the supermirror is sane... and I have no error feedback to look for good data...
[06:33] <kiko> I think ddaa has a good idea of what's necessary
[06:33] <kiko> ddaa, what does spiv say?
[06:33] <SteveA> spiv is back monday
[06:33] <ddaa> kiko: one of the things I've been planning to do since I'm back is writing requirement for crude error reporting to jblack.
[06:33] <ddaa> I'm better off asking jblack since he has at least some TZ overlap with me.
[06:34] <ddaa> also, spiv already has too much tech work on his plate, while jblack is willing to do more.
[06:34] <kiko> fair enough
[06:34] <kiko> but keeps tabs on how it's going
[06:35] <kiko> and tell me if it slips
[06:35] <ddaa> It has been slipping for about two weeks before christmas...
[06:35] <kiko> so stop the bleeding
[06:35] <ddaa> trying hard
[06:36] <ddaa> as I understand it, it has been largely coordination and communication issues
[06:36] <ddaa> nothing that can be fixed by the application of more hands
[06:36] <kiko> which we can help with if you tell us what's bothering you
[06:36] <ddaa> I've been doing that every monday with SteveA and lifeless :)
[06:36] <kiko> or I can send you a dvd of the lost episode where jack tries to save boone
[06:37] <kiko> cprov, yo?
[06:37] <cprov> kiko: yo
[06:37] <ddaa> don't worry, the situation is getting under control, I expect to get bzr metadata displayed before thursday.
[06:41] <kiko> cprov:
 kiko: gcj-4.0-base isn't in universe, it's in main
 kiko: on ftp-master and 2 x archive.u.c
[06:42] <kiko> cprov, also, tell me about our buildds. do we have at least two architectures?
[06:42] <cprov> kiko: this is bad ...
[06:42] <cprov> kiko: no only 2x i386,
[06:44] <kiko> cprov, what is bad?
[06:44] <kiko> cprov, what are their names?
[06:44] <cprov> chroot is looking for pkgs in the wrong component ... I wonder how ? which tag file is broken
[06:45] <cprov> kiko: molodezhnaya and ferraz
[06:46] <kiko> cprov, maybe it's one of the broken Sections?
[06:47] <cprov> kiko: yup ..
[07:02] <kiko> jordi, gone?
[07:18] <ddaa> kiko: can you review a small patch (that I intend to test live...)?
[07:18] <ddaa> https://chinstrap.ubuntu.com/~dsilvers/paste/file48Qjl6.html
[07:18] <kiko> daf, is carlos taking bug 1681?
[07:21] <kiko> ddaa, explain this config change to me?
[07:21] <ddaa> the previous value was a placeholder
[07:22] <kiko> okay
[07:22] <kiko> and what's the difference between
[07:22] <kiko> -                logger_object.warning("Branch not found: %s" % branch_url)
[07:22] <kiko> +                logger_object.warning("Branch not found: %s", branch_url)
[07:23] <ddaa> If I understand correctly, that just means that the interpolation is only done if the warning gets logged
[07:23] <ddaa> it's just better logging style
[07:30] <kiko> ddaa, if you test the traceback logging (is there no better way of logging tracebacks?) then r=kiko
[07:31] <kiko> that branch url no longer looks like a URL, btw
[07:32] <ddaa> Yeah, I tested traceback.exc_format() in an interactive python.
[07:32] <ddaa> what do you mean "no longer looks like a URL"?
[07:33] <ddaa> what sort of "better" logging of tracebacks would you like?
[07:34] <ddaa> exc_format() does exactly what I want: give me the string that python displays for uncaught exceptions
[07:44] <kiko> okay, great
[07:44] <kiko> ddaa, I meant that it used to be foo/232 now it's foo0000232
[07:45] <ddaa> nah, the urlprefix has a trailing slash in the config
[07:45] <ddaa> previously, it introduced a redundant slash
[07:46] <ddaa> But thanks for mentioning it. That might have been a bug.
[07:59] <kiko> ah, okay.
[07:59] <kiko> make a comment on that perhaps?
[07:59] <kiko> aar r=kiko of course
[08:02] <ddaa> okay, thanks
[08:11] <jordi> kiko: back for like 5m
[08:13] <kiko> jordi, ah, never mind
[08:13] <kiko> jordi, what was your bug #?
[08:14] <jblack> ddaa: I think we need a three way handshake. :)
[08:14] <jblack> ddaa: what did you need before?
[08:14] <ddaa> jblack: what do you mean?
[08:14] <jblack> You pinged me not too long ago.
[08:15] <ddaa> I would like to know why every branch I try to get from bazaar.launchpad.net gives me
[08:15] <ddaa> bzr: ERROR: exceptions.AttributeError: 'BzrBranch' object has no attribute '_branch_format'
[08:15] <jordi> kiko: hmm, let me dig
[08:15] <jblack> ddaa: Because most of them are bad branches at source.
[08:15] <jblack> There's a few good ones in there. I can find a couple if you need.
[08:16] <kiko> jblack, is bzr push broken again?
[08:16] <kiko>     push_file = file (filename, "rb")
[08:16] <kiko>     (location,) = [f.rstrip('\n') for f in push_file]
[08:16] <ddaa> jblack: if they are bad branches at sources, they should not be get onto bazaar.launchpad.net, right?
[08:16] <kiko> how can that be guaranteed to return two items?
[08:16] <jblack> kiko: I'm not aware of bzr push being broken at the moment, but I haven't read email in a couple hours
[08:16] <jblack> kiko: I can look into it after I talk to ddaa
[08:16] <ddaa> jblack: what is there is stuff the mirroring script has written, one of the purpose of this setup is to sanitize the data.
[08:16] <kiko> I'll pester #bzr meanwhile
[08:17] <jordi> 6499
[08:17] <jblack> ddaa: There will always be things that by defintion are "bad" at one point or another if you include inconsistancy
[08:17] <ddaa> jblack: try getting any _sane_ branch, for example http://bazaar.launchpad.net/00/00/02/24, that _used_ to work
[08:17] <kiko> thanks jordi
[08:18] <jblack> trying
[08:18] <jblack> ddaa: i see the errror
[08:18] <jordi> kiko: np
[08:18] <ddaa> and 1. there should not be any transient inconsistency error, the fetching code is designed defensively against that issue
[08:19] <ddaa> 2. these errors are not transient, and seem to affect all branches that look otherwise good
[08:19] <jblack> Odd. branch-format is empty
[08:19] <jblack> ddaa: its ok buddy. Relax. stage 2 gives you error reporting
[08:20] <ddaa> I'm _almost_ ready to do the first bzrsyncd run, but it looks like I'm going to be blocked on that issue.
[08:20] <jblack> but you're always going to potentially see inconsistant things.
[08:20] <ddaa> sure, that's not what I'm talking about
[08:20] <jblack> consider a branch that has started mirroring, but never finished the first time.
[08:20] <jblack> I define inconsistant as bad.
[08:22] <jblack> yeah. branch-format in every single one is empty
[08:22] <jblack> that looks like a bzr bug to me
[08:22] <ddaa> yes, that's the issue
[08:22] <jblack> elmo: ping
[08:24] <elmo> jblack: ?
[08:25] <jblack> Is anything changing _right now_ ?
[08:26] <elmo> jblack: nope
[08:26] <jblack> ddaa: give me moment. I'll upgrade bzr
[08:26] <elmo> I'll talk to you before it does
[08:26] <jblack> after I test it
[08:27] <SynrG> my friend's Safari browser hates launchpad :(
[08:27] <ddaa> anyway, I'm being overriden by the cat :)
[08:27] <SynrG> has trouble with the certificate
[08:27] <ddaa> jblack: the sky is not going to fall over
[08:27] <SynrG> NSURLErrorDomain:-1205
[08:27] <ddaa> go to sleep if it's too late for you
[08:27] <jblack> No worries. I'll take care of this.
[08:28] <jblack> Take care of your cat before it chews up your mouse =)
[08:29] <jblack> ddaa: in the meantime, I'll try remirroring the whole lot.
[08:29] <ddaa> he just want me to stroke it... meaning he's resting on my hands while I type...
[08:29] <bradb> SynrG: What URL?
[08:29] <bradb> SynrG: I don't have trouble with it in Safari. Neither does mpt (our UI designer who uses Safari.)
[08:30] <SynrG> trying to access my profile
[08:30] <SynrG> i suspect it is the same with all others
[08:30] <bradb> SynrG: I'm running Version 2.0.2 (416.13)
[08:30] <jblack> stevea: ping
[08:30] <SynrG> https://launchpad.net/people/synrg
[08:30] <bradb> SynrG: Works fine here.
[08:32] <bradb> SynrG: And does it work for him in FF from the same machine?
[08:40] <SteveA> jblack: hello
[08:42] <jblack> stevea: still up
[08:45] <SteveA> jblack: okay
[08:45] <SteveA> shall we talk?
[08:45] <jblack> sure
[08:45] <jblack> sounds like fun
[08:46] <jblack> are you waiting for me to ring?
[08:46] <SteveA> i was distracted for a sec
[08:47] <SteveA> go ahead and ring the voip
[09:04] <ddaa> yeeeeeeehaw!
[09:04] <ddaa> SteveA: http://bazaar.launchpad.net/00/00/02/24
[09:04] <ddaa> oops
[09:04] <ddaa> SteveA: https://launchpad.net/people/mdz/+branch/ltsp/ubuntu-main
[09:05] <kiko> ddaa, rock and rolling!
[09:05] <mdz> ddaa: nice
[09:05] <ddaa> not yet cronjobbed, but at least it _can_ work
[09:05] <kiko> wow, that is quite cool
[09:06] <dilys> Merge to devel/launchpad/sourcecode/pygettextpo: [trivial]  Add a clean target (that actually does a distclean) (r17: kiko)
[09:09] <ddaa> thanks jblack
[09:09] <SteveA> ddaa: nice!
[09:11] <sivang> hi folks, what's up?
[09:11] <sivang> jblack: I see RFS is getting there, right? not so far before it's ready?
[09:22] <gneuman> can anyone here review for me?
[09:27] <dilys> Merge to devel/launchpad: [trivial]   Make sure we /really/ clean up pygettextpo, and any libtool cruft, when make cleaning (r2958: kiko)
[09:27] <kiko> gneuman, what's up?
[09:30] <gneuman> kiko,
[09:30] <gneuman> just need review
[09:30] <gneuman> 1 trivial
[09:30] <gneuman> 1 easy and small
[09:30] <kiko> sure
[09:31] <gneuman> sending to you then
[09:41] <jblack> sivang: I think its very close, and very good.
[09:41] <jblack> SteveA has a keen eye for catching ambiguities.
[09:42] <jblack> I just realized on the phone with him that there's one significant part missing. After that it should be ready for test and usage.
[09:43] <ddaa> where's is the new pqm status page?
[09:43] <jblack> You tell me.
[09:43] <jblack> ddaa: the full remirror is running with a fresh copy of bzr.
[09:44] <ddaa> jblack: update-branches is running, when I kick it manually
[09:44] <ddaa> uploading final logging fixes right now, then I'll cron it.
[09:45] <bradb> What can I do to get my branch pushed up to chinstrap as quickly as possible in this scenario:
[09:45] <bradb> bradb@oxygen:~/canonical/status-notes-as-comment $ bzr push chinstrap:/home/warthogs/archives/bradb/launchpad/status-notes-as-comment
[09:45] <bradb> bzr: ERROR: Local branch is not a newer version of remote branch.
[09:45] <ddaa> You'll probably want to keep an eye out for it in launchpad-error-reports@
[09:45] <jblack> ddaa: Bear in mind that I haven't found the problem. I'm hoping its a non-reproducable bug from some mind bent on eggnog
[09:45] <ddaa> if that should happen again, you should see it on launchpad-error-reports@
[09:45] <jblack> ddaa: Hmm. I'm not on that, and would prefer not to be unless its necessary.
[09:46] <jblack> would it be possible to procmail certain reports to me?
[09:46] <ddaa> I think it is necessary... we can get stub to set up topics for stuff we are interested in (that is _not_ the insane rosetta spam!)
[09:47] <ddaa> this functionality crosses responsibility boundaries, all responsible (that is you and I) should look out for problems (and fix them quickly).
[09:48] <ddaa> jblack: I'd rather not, my mail setup is procmail free and I'd like to keep it that way.
[09:48] <jblack> you already have to watch it?
[09:49] <ddaa> sure, I have to look out for my cronjob logs...
[09:49] <jblack> Does it not report if there's not a problem? ]
[09:50] <ddaa> depends on the set up, right now I'll have it report for missing branches, at least until we have some SM error handlding.
[09:50] <ddaa> Eventually, it should not report if there is no problem.
[09:51] <jblack> ddaa: Hmm. Would you mind if we discuss this at another time?
[09:51] <ddaa> no hurry
[09:51] <ddaa> I'm just being a bit over-enthusiastic.
[09:51] <jblack> Ahh. I'm at over 30 hours.
[09:52] <ddaa> You know, sleep is useful.
[09:52] <jblack> I've seen people wake up, work, go to bed and wake up again. :)
[09:52] <jblack> So lets put this off
[10:00] <sivang> jblack: cool then, it's sure looks like it from the wiki subscription notification.
[10:19] <jblack> If anybody really needs anything from me before I go, this is the time
[10:19] <kiko> ddaa, where does that branch of mdz come from? not the supermirror, right?
[10:20] <ddaa> as far as bzrsyncd is concerned, it comes from the supermirror
[10:20] <ddaa> but the SM has pulled it from somewhere else (sftp for bzr is not there yet)
[10:21] <dilys> Merge to devel/launchpad: [trivial]    Visual fixes to expander; improve icon positioning and don't underline it (r2959: kiko, Christian Reis)
[10:22] <ddaa> yay, that's cronjobbed
[10:22] <ddaa> 0030 and 1230 every day
[10:24] <kiko> ddaa, hey
[10:24] <kiko> before doing that
[10:24] <kiko> why don't you answer to mark's message?
[10:25] <ddaa> hu... why about doing that monday when everything has been scanned right?
[10:25] <kiko> ddaa, sure.
[10:25] <kiko> sounds safe.
[10:25] <kiko> I like to keep the man happy..
[10:25] <ddaa> well, if there is an apt branch, I would not be able to resisit
[10:26] <ddaa> "you means something like THAT?"
[10:26] <ddaa> Mh... not any apt branch there ATM...
[10:29] <kiko> ddaa, how much time do we have to wait?
[10:29] <ddaa> until somebody register them :)
[10:29] <ddaa> then the SM has to mirror them
[10:29] <ddaa> and bzrsyncd has not scan them
[10:29] <kiko> mdz, do you have any apt branches to register?
[10:29] <ddaa> all that is doing with crons
[10:30] <ddaa> we have plans to reduce latency later on, but right now the latency will still by of the order of one day
[10:40] <mdz> kiko: yes
[10:40] <mdz> I have all sorts of branches
[10:43] <kiko> can you register one for apt?
[10:43] <ddaa> mdz: the sabdfl sounded it would make him happy to see a bunch of apt branches in Launchpad, since we just finished to get the whole chaing _somewhat_ working, that would be a good time to put some data in :)
[10:47] <mdz> ddaa: he's not happy with my ltsp branches eh?
[10:48] <mdz> hmm, actually I don't have any bzr apt branches.  they're still baz
[10:48] <ddaa> ah... that's a good reason for not showing them, I guess...
[10:49] <mdz> mvo's branch is converted to bzr
[10:49] <mdz> http://people.debian.org/~mvo/bzr/apt--main.bzr/
[10:52] <ddaa> added
[10:53] <ddaa> It should be scanned tomorrow.
[10:54] <ddaa> I'm going to play some wesnoth now :)
[10:55] <sivang> ddaa: have fun :)
[11:10] <kiko> time to move out too
[11:10] <kiko> catch you all later


[13:16] <brendand> herton, bjf, sconklin - is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/760131 going to be rolled back?
[13:16] <ubot2> Launchpad bug 760131 in linux "Power consumption raised significantly in natty" [High,Fix committed]
[13:18] <herton> brendand: yep, probably natty will be respinned tomorrow to revert the patch from this one, no one verified (and given current state of the bug of mixed issues, I think hardly someone will verify it I think)
[13:19] <brendand> herton - ok, thanks
[13:34] <bjf> ##
[13:34] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[13:34] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[13:34] <bjf> ##
[13:45] <tgardner> herton, brendand: https://bugs.launchpad.net/ubuntu-release-notes/+bug/760131/comments/200
[13:45] <ubot2> Launchpad bug 760131 in linux "Power consumption raised significantly in natty" [High,Fix committed]
[13:53] <herton> tgardner: yes it's a good fix to have, and we had some reports of improvements for some like comment #168. If no one is against, someone could just mark it verification-done, if comment 168 is good enough, just trying to follow SRU policy here.
[13:55] <brendand> herton - that's the key isn't it? no-one has yet.
[14:02] <brendand> personally i'd love someone to verify it, so we can get started testing the SRU
[14:03] <tgardner> brendand, herton: I marked it verification-done
[14:08]  * brendand waits for the certification-testing task to go to In Progress
[14:09] <herton> brendand: I'm "releasing" that kernel, should be ready for testing soon
[14:19] <herton> tgardner, brendand: natty update released from verification, ready for testing (bug 860832)
[14:19] <ubot2> Launchpad bug 860832 in kernel-sru-workflow "linux: 2.6.38-12.51 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/860832
[14:23]  * ogasawara back in 20
[15:27] <ogasawara> bjf: I'll post the CVE bits for apw in the meeting.  that way I can almost dominate the entire meeting :)
[15:27] <bjf> ogasawara: wfm
[15:39] <bjf> ogasawara: i think the meeting is you, me, sconklin
[15:39] <ogasawara> bjf: heh, really?
[15:40] <bjf> ogasawara: ppisati if he has anything
[15:41] <bjf> ogasawara: i'm driving, you and sconklin are doing most / all of the reporting
[15:41] <ogasawara> bjf: we could cancel, or we could go for the record of shortest meeting ever :)
[15:41] <bjf> start-meeting; ogasawara dump; sconklin dump; end-meeting
[15:41] <sconklin> there's not any big news to report
[15:42] <bjf> ogasawara: this is the last one til post-uds anyway, nothing really to report
[15:42]  * ogasawara nods
[15:43] <bjf> ogasawara: you could announce at the last minute we've switched to 3.1 for oneiric
[15:43] <ogasawara> hehe
[15:55] <bjf> smb: will you be around for the meeting?
[15:56] <bjf> ppisati: you?
[15:58] <bjf> ogasawara: i'm thinking of canceling the meeting, there just aren't going to be any of us around for it
[15:58] <bjf> ogasawara: if you have no objections ...
[15:58] <ogasawara> bjf: fine by me
[15:59] <cking> bjf, you just want to get some beers in early
[15:59]  * ppisati is here (even if is always silent...)
[16:00] <ppisati> and no
[16:00] <ppisati> nothing new to report this week
[16:00] <bjf> cking: that would mean starting at 10:00 a.m. (which is a little early even for the kernel team)
[16:00] <ogasawara> bjf: awww, I was going to be impressed if you had a beer by 10am
[16:01] <cking> 10am is too early, the previous night's beer session hasn't worn off by then
[16:02] <bjf> ##
[16:02] <bjf> ## Today's Kernel team meeting has been canceled
[16:02] <bjf> ##
[16:02] <ppisati> ack
[16:02] <cking> nack ;-)
[16:06] <sconklin> bjf: of course, because I just finished editing the weekly report . . .
[16:06] <bjf> sconklin: i could run it just so you could report out
[16:06] <ppisati> post UDS?
[16:06] <ppisati> November?
[16:06] <bjf> ppisati: yes
[16:07] <ppisati> ah ok
[16:07] <sconklin> bjf, nah. There's nothing to report that you can't get from the kernel SRU report pages
[16:38]  * ppisati -> gym
[17:06] <herton> GrueMaster: bug 862554 misses the qa-testing-* tag for QA (if it failed or passed)
[17:06] <ubot2> Launchpad bug 862554 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.38-1209.16 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/862554
[17:09] <GrueMaster> herton: It doesn't help when I have two separate launchpad bugs to track the same kernel and am expected to test it during release time.  The added tag sometimes gets lost in the shuffle.
[17:13] <herton> GrueMaster: which two bugs, I thought there was only this one opened?
[17:14] <GrueMaster> herton: bug 709245
[17:14] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Fix committed] https://launchpad.net/bugs/709245
[17:14] <GrueMaster> See Comment #48.
[17:16] <herton> GrueMaster: ah, this is a different case, the 709245 is not a tracking bug, it's a SRU. By SRU policy, all fixes must be verified, in addition to the QA done on the tracking bug. but verification any one can do, if they can reproduce and test the bug
[17:18] <GrueMaster> Well, anyone usually only means me when it comes to ubuntu-arm testing.
[17:49] <smoser> smb, around ?
[18:01] <smoser> ogasawara, how would i best request that bug 794570 be fixed in early precise ?
[18:01] <ubot2> Launchpad bug 794570 in linux "igbvf driver is missing from virtual-flavored kernel" [Undecided,Confirmed] https://launchpad.net/bugs/794570
[18:02] <ogasawara> smoser: I'll take a look
[18:03] <ogasawara> smoser: is that not provided by the new linux-image-extra-virtual package?
[18:04] <smoser> it is
[18:04] <smoser> but, per shattered, these drivers are 100% virtual only. so it makes sense for them to be in the base.
[18:05] <shattered> there may be more, I only have use for igbvf
[18:05] <shattered> maybe vmxnet too
[18:07] <ogasawara> smoser, shattered: could we get separate bug reports per config request?  Makes it easier tracking wise.
[18:08] <smoser> ogasawara, and if shattered opens them, how should he mark them such that you'll see them?
[18:08] <ogasawara> smoser, shattered: ping me with the bug #'s
[18:09] <shattered> so, one report for each driver?
[18:09] <ogasawara> shattered: yes please
[18:09] <ogasawara> shattered: then I can do one patch per bug
[18:10] <shattered> ok
[18:20] <shattered> bug 872411
[18:20] <ubot2> Launchpad bug 872411 in linux "ixgbevf driver is missing from virtual-flavored kernel" [Undecided,New] https://launchpad.net/bugs/872411
[18:24] <shattered> another one, bug 250549
[18:24] <ubot2> Launchpad bug 250549 in linux "Wrong interface speed from snmpd running as snmp user" [Undecided,Fix released] https://launchpad.net/bugs/250549
[18:25] <jsalisbury> ogasawara, bjf, I'm  seeing lots of duplicate bugs being reported for bug 844957
[18:25] <ubot2> Launchpad bug 844957 in linux "Safely removing external (usb) hdd's can cause a kernel panic or system freeze" [Medium,Confirmed] https://launchpad.net/bugs/844957
[18:25] <ogasawara> smoser: you mentioned you wanted it fixed for Precise, did you want an Oneiric SRU as well or will the linux-image-extra-virtaul package suffice for Oneiric?
[18:25] <jsalisbury> ogasawara, bjf, bug 863092 has a possible patch.
[18:25] <ubot2> Launchpad bug 863092 in linux "kernel panic on "safely remove" USB 3.0 HDD (dup-of: 844957)" [Undecided,Confirmed] https://launchpad.net/bugs/863092
[18:26] <ogasawara> jsalisbury: thanks, I'll take a look
[18:26] <jsalisbury> ogasawara, thanks
[18:26] <smoser> shattered, ^ ? ogasawara shattered is the one affected. i only know of it from there.  shattered has said most important thing is to have in LTS.
[18:26] <ogasawara> jsalisbury: we'll likely want to get them all dup'ed to a master bug
[18:27] <ogasawara> smoser, shattered: ack.  so I'm going to target for Precise and suggest shattered use the linux-image-extra-virtual package for Oneiric.
[18:27] <jsalisbury> ogasawara, ok, so mark each bug similar to 844957 as duplicates?  Does anything need to be done to the master bug(844957)?
[18:31] <ogasawara> jsalisbury: hrm, so I don't see any output of what the actual panic is in the master bug, so you might want to hold off on marking dup's until you can confirm they are all indeed seeing the same panic
[18:31] <jsalisbury> ogasawara, ok.  I can request the additional details in all the bugs.
[18:32] <ogasawara> jsalisbury: cool thanks.  gimme a bit to get these other bugs sorted for smoser and shattered and then I'll look at the possible patch for this panic.
[18:33] <jsalisbury> ogasawara, great, thanks!
[18:48] <Q-FUNK> jsalisbury: just to double-check, is the kernel you want me to test for bug #848864 v3.1-rc9-oneiric ?
[18:48] <ubot2> Launchpad bug 848864 in linux "BUG: unable to handle kernel paging request at ffffb4ff // ext4_get_acl+0x80/0x210" [High,Confirmed] https://launchpad.net/bugs/848864
[18:50] <jsalisbury> Q-FUNK, yes that would help.  The test is to see if the issue is already resolved upstream.
[18:50] <Q-FUNK> jsalisbury: or is it whatever currently sits in http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ ?
[18:50] <Q-FUNK> jsalisbury: yes, I already understand the purpose of the test. :) I just need to make sure that I won't be wasting anyone's time by testing the wrong kernel.
[18:52] <jsalisbury> Q-FUNK, the mainline kernel
[18:53] <jsalisbury> Q-FUNK, actually, let me double check with ogasawara
[18:53] <Q-FUNK> jsalisbury: that doesn't answer my question. do you mean the daily build or v3.1-rc9-oneiric ?
[18:54] <Q-FUNK> jsalisbury: alright. standing by. :)
[18:54] <jsalisbury> ogasawara, What is the primary differance between http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-rc9-oneiric/ and http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
[18:54] <ogasawara> Q-FUNK: v3.1-rc9
[18:54] <ogasawara> jsalisbury: v3.1-rc9 is the latest upstream release candidate, current I believe is the latest tip of the tree?
[18:55] <ogasawara> jsalisbury: so usually best to have the try the latest release candidate (whatever that is at the time)
[18:55] <Q-FUNK> alright. testing 3.1-rc9, then.
[18:55] <jsalisbury> ogasawara, OK, thanks.  And the daily has ubuntu specific patches on top?
[18:55] <ogasawara> jsalisbury: as the tip of the tree is a moving target and harder then to determine what they actually tested at the time
[18:55] <ogasawara> jsalisbury: no Ubuntu patches, purely mainline
[18:56] <jsalisbury> ogasawara, ahh, understood.
[18:56] <ogasawara> jsalisbury: so to clarify its the tip of the mainline tree
[18:56] <jsalisbury> ogasawara, thanks, that clears it up for me :-)
[18:57] <jsalisbury> Q-FUNK, thanks for testing the 3.1-rc9 kernel.  It would be great if you could update the bug with your findings
[19:01] <Q-FUNK> jsalisbury: sure. Just installed and mentioned which one I picked on the bug. Rebooting the target host now.
[19:25] <Q-FUNK> jsalisbury: that kernel seems to completely miss vesafb.  that makes seeing what happens harder.
[19:27] <Q-FUNK> ogasawara: any particular reason why VESAFB is not set?
[19:28] <jsalisbury> Q-FUNK, ok, thanks for the update.  I'm not sure why it is not set in that kernel.  Can you set it manually?
[19:28] <ogasawara> Q-FUNK: not sure, would have to look at the configs being used to generate the mainline builds
[19:29] <Q-FUNK> jsalisbury: no, since the kernel is built without it.
[19:29] <Q-FUNK> $ grep FB /boot/config-3.1.0-0301rc9-generic  | grep VESA
[19:29] <Q-FUNK> # CONFIG_FB_BOOT_VESA_SUPPORT is not set
[19:29] <Q-FUNK> CONFIG_FB_UVESA=m
[19:29] <Q-FUNK> # CONFIG_FB_VESA is not set
[19:29] <jsalisbury> Q-FUNK, ahh right.
[19:29] <Q-FUNK> no bootfb support and no vesafb.
[19:31] <jsalisbury> Q-FUNK, on thing to try would be previous release candidates, until you find where vesafb as changed, or review the build config files.
[19:31] <jsalisbury> Q-FUNK, that could take some time though.
[19:43] <Lekensteyn> Hi all, how do I get a mainline kernel built with a more recent toolset so that I can unload modules which are now marked as "permanent in use"?
[19:49] <Q-FUNK> slangasek: was it you that said that vesafb is being phased out in favor of using native fb?
[20:29] <Q-FUNK> 3.1.0-0301rc9-generic is scary.  not only does it not have vesafb at all, uvesafb fails to reserve video memory where 3.0 did (yes, v86d is installed).
[20:39] <slangasek> Q-FUNK: hrm, I wouldn't have said that; kms-capable fb drivers are preferred, but vesafb is still our fallback
[20:40] <Q-FUNK> slangasek: vesafb is not compiled into mainline anymore, it seems.
[20:41] <slangasek> Q-FUNK: that sounds like a configuration error with that particular package
[20:41] <Q-FUNK> slangasek: could be :)
[20:41] <Q-FUNK> that would be 3.1.0-0301rc9-generic
[20:43] <Q-FUNK> what exactly causes those "Waiting for network configuration..." displayed by plymouth since Oneiric?
[20:46] <Q-FUNK> nice. adding uvesafb to /etc/initramfs.d/modules and dpkg-reconfigure finally loads it at reboot, but it ignores GRUB_GFXMODE even though GRUB_GFXPAYLOAD_LINUX=keep is set.
[21:11] <slangasek> "Waiting for network configuration" means that something in /etc/network/interfaces is configured but didn't come up at boot, so the failsafe job that's on a timer is waiting for those to finish coming up before giving up and continuing the boot anyway
[21:12] <Q-FUNK> that one only has 'lo' in it.
[21:14] <Lekensteyn> Is there an Ubuntu mainline kernel build with a toolset from Oneiric?
[21:17] <Q-FUNK> Lekensteyn: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-rc9-oneiric/
[21:19] <Lekensteyn> Q-FUNK: I tried that one, but if I compile a module for it, it cannot be unloaded anymore. And according to the ubuntu wiki, it's still built with the toolset from hardy
[21:23] <slangasek> Q-FUNK: in that case it sounds like you need to upgrade to the current upstart package in oneiric
[21:26] <Q-FUNK> slangasek: everything is up-to-date, unless there's been a new one within the last 24 hours.  mind you, this is with 3.1.0-0301rc9-generic, which seems to be broken in many ways.
[21:27] <slangasek> that's entirely unrelated to the kernel
[21:28] <Q-FUNK> slangasek: I'd asume so too, but I don't see that message with older kernels.
[21:28] <slangasek> Q-FUNK: is lo listed as 'auto lo'?
[21:28] <Q-FUNK> yup
[21:47] <Q-FUNK> slangasek: and I'd somehow expect 'lo' to not require over 1 minute to bring up. :)
[21:56] <slangasek> Q-FUNK: sudo initctl list | grep network-interface ?
[22:27] <Q-FUNK> slangasek: http://paste.ubuntu.com/706363/
[22:40] <slangasek> Q-FUNK: right, no idea why you would have seen the 'waiting for network' if you're up to date
[22:43] <Q-FUNK> slangasek: me neither, but I was wondering if there was anything I overlooked.
[22:44] <Q-FUNK> slangasek: interesting. flat out deleting /etc/network/interfaces seems to fix it.
[22:47] <Q-FUNK> slangasek: and 'lo' appears in the output of 'sudo initctl list | grep network-interface' regardless.
[22:56] <Q-FUNK> or not.
[22:57] <Q-FUNK> I still get the "waiting for network connection..."
[22:57] <slangasek> /etc/init/network-interface.conf has a failsafe for lo.
[22:57] <Q-FUNK> with older kernels too, now.
[22:57] <slangasek> what version of upstart is installed?
[22:58] <Q-FUNK> 1.3-0ubuntu10
[22:59] <slangasek> that's the right version; and /etc/init/failsafe.conf in that version will only show that message if it takes 20s more to bring up the interfaces in /etc/network/interfaces than it takes to mount the filesystem
[22:59] <slangasek> pastebin /etc/network/interfaces?
[23:00] <Q-FUNK> slangasek: currently an empty file.
[23:00] <slangasek> hrm
[23:01] <slangasek> oh.  what *does* bring up your network?
[23:01] <slangasek> if you have no interfaces at all in there, the 'static-network-up' event will never be emitted
[23:01] <slangasek> if you have lo in there, the event should be emitted when lo comes up
[23:02] <Q-FUNK> network-manager
[23:05] <Q-FUNK> odd. on the static host I'm currently testing the mainline kernel, renaming /etc/network/interfaces to /etc/network/interfaces.bak solved it and it even made the boot faster than before.
[23:05] <Q-FUNK> but on my laptop, doing the same it introduced a "waiting for network connection..." that never showed before.
[23:08] <Q-FUNK> [   45.988594] init: network-interface (lo) pre-start process (608) terminated with status 1
[23:08] <Q-FUNK> [   46.050353] init: network-interface (lo) post-stop process (623) terminated with status 1
[23:09] <Q-FUNK> slangasek: could this be it?
[23:09] <Q-FUNK> or is status 1 the expected outcome?
[23:09] <slangasek> it is not
[23:09] <slangasek> and yes, that sounds like the problem
[23:10] <slangasek> what happens if you run 'ifup --allow auto lo'?
[23:11] <Q-FUNK> ifup: couldn't read interfaces file "/etc/network/interfaces"
[23:15] <slangasek> Q-FUNK: right, which is why it exits 1... and why /etc/network/if-up.d/upstart doesn't get run.
[23:16] <Q-FUNK> slangasek: what then? put back all the interfaces in, then comment all the lines?
[23:16] <Q-FUNK> or just one comment line?
[23:16] <slangasek> Q-FUNK: you should have the lines 'auto lo' and 'iface lo inet loopback' for proper operation
[23:18] <Q-FUNK> slangasek: adding them back makes the "waiting for network connection..." appear again.
[23:19] <slangasek> yes, but what happens now when you run that ifup command?
[23:19] <Q-FUNK> slangasek: it returns nothing, if I have the file present, but with only comments.
[23:20] <slangasek> well, I don't know what to tell you
[23:20] <slangasek> /etc/network/interfaces is supposed to exist and have an entry for lo as an auto interface
[23:21] <slangasek> if something's not working right when doing that, you'll have to trace why
[23:22] <slangasek> the 'ifup --allow auto lo' needs to *succeed* when called, or else you'll get the network failsafe delay
[23:22] <Q-FUNK> slangasek: if it exists but only contains comments, the "waiting..." stops to appear, ifup no longer returns an error, and 'dmesg | grep status' returns 4 lines less.
[23:23] <Q-FUNK> the minute I add the 'lo' entry back, the "waiting..." returns.
[23:23] <slangasek> yes, you'll have to debug why
[23:23] <slangasek> but the lo entry *has* to be there
[23:23] <Q-FUNK> ok
[23:23] <Q-FUNK> brb
[23:39] <Q-FUNK> slangasek: seems to work again, now. *shrugs*
[23:39] <Q-FUNK> however:  http://paste.ubuntu.com/706382/
[23:41] <Q-FUNK> not necessarily kernel-related, though, so if you prefer moving this conversation to a more appopriate channel, please tell me.


[01:04] <Arnautovic> anybody speaking english here?
[01:08] <Emmanuel_Chanel> Yes. Where are you from? Croatia?
[01:12] <Arnautovic> Emmanuel_Chanel From Germany
[01:12] <Arnautovic> Where are you from?
[01:12] <Emmanuel_Chanel> From Japan. I'm Japanese. Emmanuel CHanel is just a nick.
[01:13] <Arnautovic> Pleased to meet you. I have this sword that has japanese written on it could you possibly tell me what it reads?
[01:14] <Emmanuel_Chanel> I hear that many from former Yugoslavia have a surname with -vic. So I asked that.
[01:14] <Arnautovic> Its just a football player that I like :D
[01:14] <Arnautovic> He is from former Yugoslavia
[01:14] <Emmanuel_Chanel> ok.
[01:15] <Emmanuel_Chanel> Ich spreche nicht gut Deutsch.
[01:15] <Arnautovic> :)
[01:15] <Arnautovic> Its alright
[01:15] <Arnautovic> Can you read whats written on the sword I told you about and translate it for me please?
[01:15] <Arnautovic> http://i.imgur.com/LkKDb.jpg
[01:15] <Arnautovic> http://i.imgur.com/5pbwe.jpg
[01:15] <Arnautovic> Both sides.
[01:18] <Emmanuel_Chanel> The former: 越中守(= Govornor of Ecchu)藤原(= Fujiwara)高平(=Takahira, Kouhei, or so on...)
[01:19] <Arnautovic> Is that name of the owner?
[01:20] <Emmanuel_Chanel> Maybe...
[01:22] <Emmanuel_Chanel> The latter: 元和八年六月??? = Year Genwa 8, Month 6. Now Japan, Month 6(六月) is June. But probably, the author of that phrase didn't use Gregorian calender.
[01:35] <Emmanuel_Chanel> Hello!
[01:50] <Arnautovic> What calendar is used here?
[01:52] <Arnautovic> http://i.imgur.com/FrWVA.jpg
[01:52] <Arnautovic> Here is the entire blade
[01:53] <Arnautovic> 92.8 cm
[01:53] <Arnautovic> and to the edge its 71.5 cm
[01:53] <Emmanuel_Chanel> Correction. 元和 = げんな http://ja.wikipedia.org/wiki/%E5%85%83%E5%92%8C_%28%E6%97%A5%E6%9C%AC%29
[01:54] <Emmanuel_Chanel> But I don't find what calender.
[01:54] <Arnautovic> so Genna?
[01:54] <Arnautovic> 17th century basically?
[01:55] <Emmanuel_Chanel> Yes.
[01:55] <Arnautovic> Very interesting
[01:55] <Arnautovic> The first side mentions a specific person and a place yes?
[01:57] <Arnautovic> The guy who sold it to me said its 200 years old
[01:58] <Arnautovic> He wasnt a japanese though
[02:02] <Arnautovic> Thanks Emmanuel_Chanel
[02:02] <Arnautovic> :)


[00:04] <JackFrost> bluesabre: ...I linked you to https://lists.debian.org/debian-devel-announce/2017/12/msg00004.html right?
[05:52] <flocculant> well I read it so I'm guessing you linked it here :p
[05:53] <JackFrost> :(
[05:53] <JackFrost> It's a boring read for anyone that..>Doesn't care.
[05:54] <flocculant> I found that out :D
[05:55] <JackFrost> That's OK, I poked him elsewhere too!
[05:55] <flocculant> :)
[07:28] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-whiskermenu-plugin 1.7.5 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-whiskermenu-plugin-1-7-5-released-tp50384.html (by Graeme Gott)
[07:28] <flocculant> caught up then ...
[07:34] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-whiskermenu-plugin 2.1.5 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-whiskermenu-plugin-2-1-5-released-tp50385.html (by Graeme Gott)
[07:34] <JackFrost> flocculant: ....Nope still didn't see 'em! :34
[07:46] <flocculant> hah
[11:12] <bluesabre> Hello everyone!
[11:13] <bluesabre> I'm almost done ignoring everything as the year winds down, hoping to get back to work here this weekend
[11:21] <flocculant> bluesabre: I hope you had a good time ignoring everything :)
[11:22] <bluesabre> :D
[11:22] <bluesabre> Work's been too busy. Go to work, work on project, head home, continue working on project, go to bed, repeat.
[11:22] <flocculant> :(
[13:43] <pleia2> bluesabre: that's the life
[20:17] <ochosi> look what a nice baseline we gave ppl here http://www.omgubuntu.co.uk/2017/12/how-popular-was-ubuntu-in-2017
[20:18] <pleia2> heh
[20:18] <flocculant> lol
[20:18] <flocculant> hi ochosi pleia2
[20:27] <flocculant> https://trends.google.co.uk/trends/explore?q=xubuntu,ubuntu%20budgie,kubuntu,Lubuntu,ubuntu%20mate
[20:37] <ochosi> interesting
[20:37] <ochosi> and not bad
[22:08] <bluesabre> Surprised by the relative popularity of lubuntu in that
[22:17] <knome> otoh they are the ligthest in weight
[22:17] <bluesabre> indeed
[22:17] <knome> if 2017 wasn't the year of the linux desktop (again), it was the year of linux in the old, otherwise abandoned desktop (again)
[22:18] <knome> and even ignoring that fact, they still can support non-PAE stuff, right?
[22:18] <bluesabre> yup
[22:19] <bluesabre> I think
[22:19] <JackFrost> Not if they use the same Ubuntu kernel, soo. :P
[22:21] <JackFrost> You could "easily" do so, just pick up the liquorix kernel and run with it. :P
[22:22] <knome> searches do not necessarily match real life as we've seen with people who come and ask why xubuntu doesn't work with their 20yo computer even if we support old computers
[22:22] <knome> :P
[22:25] <knome> xfce wins lxde and lxqt combined though


[02:17] <smspillaz> duflu: hollyyyy ... did you see the new nvidia driver release ?
[02:18] <smspillaz> Improved performance of OpenGL framebuffer object binds with Xinerama enabled by 2000-3000% when the application's windows do not span screen boundaries.
[02:18] <smspillaz> lol
[02:19] <duflu> Hah
[02:19] <duflu> Nice
[02:19] <smspillaz> duflu: buffer age support too!
[02:19]  * smspillaz cracks open his branch to try it out to see how much faster it is
[02:22] <smspillaz> duflu: buffer_age means that we can finally use glXSwapBuffers without redrawing the whole backbuffer on every frame
[02:22] <duflu> That's handy, but not if only 1 or 2 drivers do it
[02:22] <duflu> smspillaz^
[02:23] <smspillaz> still great if at least one does!
[02:23] <smspillaz> the free drivers will support it in the next kernel release from what I've heard
[02:24] <duflu> smspillaz: Mesa claimed to implement GLX_OML_swap_method but it never really worked. So I'm not holding my breath
[02:24] <smspillaz> duflu: buffer age is different
[02:24] <smspillaz> its really easy to implement driver side
[02:24] <duflu> My point still holds. I'll believe it when it's released and working
[02:24] <smspillaz> :)
[02:25]  * smspillaz adds xorg-edges
[02:25] <smspillaz> *xorg-edgers
[03:42] <smspillaz> duflu: seems to work OK, though I suspect their implementation is a bit slow atm
[03:42] <smspillaz> maybe they do the buffer age tracking server side
[03:55] <smspillaz> duflu: nope, scratch that, forgot to enable lazy positioning :)
[03:55] <smspillaz> duflu: so awesome, it works great. I'll have something up for you /others to test tomorrowish
[03:58] <duflu> smspillaz: Tomorrow is my last day before vacation. No promise of any more large reviews this year :/
[04:00] <smspillaz> duflu: no problem, it needs lots of testing anyways, it can wait
[04:01] <smspillaz> duflu: anyways, we no longer need to worry about the performance impact of doing that fbo bind on every frame, at least on nvidia \o/
[04:01] <smspillaz> I think nvidia is going to go from our worst performing driver to our best
[04:01] <duflu> smspillaz: Cool. I thought I modified the FBO class to be smart enough to never rebind until absolutely required though
[04:02] <duflu> (when it needs a different FBO)
[04:02] <smspillaz> duflu: ah, when was that ?
[04:02] <duflu> smspillaz: Before GLES landed
[04:02] <smspillaz> right
[04:02] <smspillaz> duflu: althoguh you still have to switch between fbo and backbuffer to draw a frame
[04:03] <duflu> smspillaz: But that is only optimal for that class. If you can make the calling code (opengl plugin) rebind to different FBOs less often then that could still help
[04:03] <smspillaz> indeed, although for most frames we only do it once
[04:03] <smspillaz> erm, twice
[04:03] <smspillaz> once to fbo, once to back
[04:03] <smspillaz> glxswapbuffers
[04:03] <smspillaz> with buffer_age we don't even have to do that
[04:04] <smspillaz> I wrote some code a few days ago to track damage regions across old backbuffers, so gl tells you how old (in frames) your backbuffer is and then you just repair the relevant regions
[04:04] <duflu> smspillaz: Also worth checking Nux to see if and where it does its own rebinds. I suspect it does too much but don't really know
[04:04] <smspillaz> duflu: it does do way too much :(
[04:05] <duflu> smspillaz: Which history says is a significant bottleneck :(
[04:05] <duflu> smspillaz: I am curious because Nux+Unity works with all Compiz rendering modes now. If you're already using FBO then Nux should rebind less
[04:06] <smspillaz> duflu: the best thing we can do
[04:06] <smspillaz> duflu: is to determine when you're using a framebuffer object of the same size
[04:06] <smspillaz> and then switch between the color attachments
[04:06] <smspillaz> thats basically free
[04:07] <smspillaz> it'll require a bit more infrastructure between nux and compiz
[04:07] <duflu> smspillaz: Nux seems flexible enough that it *should* be able to work without FBOs. I don't understand why it needs them at all. Just give it a backbuffer...
[04:07] <smspillaz> duflu: you need fbos to do gaussian blurs
[04:07] <duflu> smspillaz: Oh, I forgot
[04:07] <smspillaz> well, you can do them without fbos but its much slower :)
[04:09] <duflu> smspillaz: I think it should be much faster. The need for FBOs in blurring is to only ensure there is no "drift" like you see with an in-situ blur
[04:10] <duflu> But regardless, if Unity turns off active blur, that should in the least prevent Nux using FBOs. People should have the option of making things faster even if it's not the default
[04:10] <smspillaz> duflu: also nux uses fbos becauses its convenient really
[04:10] <smspillaz> even though it shouldn't
[04:12] <smspillaz> duflu: anyways, the thing with gaussian blurs is that you need to do the 2nd pass using the results of the first
[04:12] <smspillaz> there might be ways to have pseudo-gaussian blurs which don't use 2 passes, but at the moment we use 2 passes
[04:12] <smspillaz> multiple color buffers are the best way to do that - reading off the backbuffer is expensive
[04:12] <duflu> smspillaz: Yes true for Gaussian. However there other countless other algorithms that don't require multiple orthogonal passes.
[04:12] <smspillaz> indeed
[04:13] <smspillaz> gaussian looks the best though
[04:13] <smspillaz> anways gottan run
[04:13] <duflu> Yeah Gaussian looks best but in a real-time UI, people will never tell the difference
[04:14] <duflu> Sorry, I don't mean to be one who abuses the term "real-time". I know Linux is not a real-time OS
[08:37] <didrocks> sil2100: hey! when you get some time, do you mind updating me on the failing tests?
[08:55] <sil2100> didrocks: sure thing! I already have a branch prepared, when I'm done with this one more fix I will give it out for review - we this should fix 2 failing tests at least
[08:56] <didrocks> sil2100: sweet! do you think we'll be able to get down to 0 from this list failing?
[08:56] <didrocks> sil2100: as it's only a subpart of tests for non regressing other stacks, I would love setting the value to 0
[08:59] <sil2100> I would hope to get it down to 0, but some test failures are hard to track down, especially when they're hard to reproduce or some singular cases - I tried one of them yesterday and didn't yet find the root cause for the 'accidental' failure ;/
[08:59] <didrocks> sil2100: maybe fghinter can give you access to the machine? as we are not using them, we can keep them in a fail case maybe so that it's easier for you to run them by hand?
[09:05] <sil2100> didrocks: hm, I guess it wouldn't mind to try, I'll ping Francis when he's online
[10:05] <niktto> hi all! I have one quick question about AppIndicator3 in python. I'm using it as an alternative to GtkStatusIcon and I'm connecting same GtkMenu to it but it seems that I can't catch 'button-press-event' on GtkMenuItem
[10:06] <niktto> is there any road around this without using 'activate' signal?
[11:04] <smspillaz> duflu: hey, see my comment on the MRQ - I think the checks for nBounding < 1 and nInput < 1 are wrong and the source of the problem
[11:05] <duflu> smspillaz: Ah yes, good point. But we still want to support !XShape
[11:05] <smspillaz> duflu: indeed, see my comment for an idea on how to do that
[11:05] <duflu> So feel free to propose something that solves it
[11:05] <duflu> Night
[11:06] <smspillaz> duflu: are you working tomorrow ?
[11:06] <duflu> Yep
[11:06] <smspillaz> duflu: ok, well, I guess you can probably handle it
[14:36] <didrocks> mterry: hey, thanks on the testapp MP! Feel free to get it merged, but I think we shouldn't automate it for daily process until we settle down on the name :)
[14:36] <mterry> didrocks, yeah
[14:36] <didrocks> mterry: something else, I think you saw that libunity-misc is not merging :/
[14:36]  * didrocks keeps seeing autolanding branch being stalled
[14:36] <mterry> didrocks, oh?  wait I thought it did
[14:36] <didrocks> https://code.launchpad.net/~mterry/libunity-misc/modernize-build/+merge/139499
[14:37] <didrocks> still approved
[14:37] <didrocks> fginther: ^
[14:37] <didrocks> fginther: do you have anything to spot those branches? I keep having 3/4 a days in that stalled situation
[14:37] <mterry> didrocks, ah right. But not rejected due to jenkins.  Just no jenkins around
[14:37] <didrocks> not really efficient to have to ping you or mmrazik every time
[14:38] <didrocks> mterry: ah, something else (and sorry to add more to your plate), but there will maybe be some SRU on webapps for youtube which changed its layout, so the script broke
[14:39] <didrocks> mterry: robru will do the packaging, but he will need a sponsor next week I guess
[14:39] <mterry> didrocks, OK
[14:39] <didrocks> so if you can have a look at it when it will be time :
[14:39] <fginther> didrocks, yes, we have job that checks for these. It's probably emailing marting, but not me...
[14:39] <fginther> s/marting/maring/
[14:39] <fginther> s/maring/martin/
[14:39] <didrocks> thanks mterry ;) FYI, I don't really know how the source packages are created (there is one source package for each script, but the real source is webapps-applications)
[14:40] <mterry> didrocks, yeah, they generate them somehow.  also not sure how
[14:40] <didrocks> mterry: so for this security fix, mdeslaur and I just apt-get source and distro-patch until ken is back and we know how it works with their pkgme
[14:40] <didrocks> (the one we uploaded less than an hour ago)
[14:40] <didrocks> I guess you will have to do the same for the youtube one
[14:40] <didrocks> fginther: it needs patching then! :)
[14:43] <fginther> didrocks, mterry. sorry about that. It should be building shortly
[14:43] <didrocks> fginther: no worry, thanks! :)
[14:43] <didrocks> and one more on the autolanding list (even if the unity stack is not scheduled)
[14:44] <mterry> didrocks, what's the blocker for the unity stack?  autopilot still?
[14:44] <mterry> (in terms of turning on autopublishing)
[14:44] <didrocks> mterry: yeah, we just got the first reliable results yesterday
[14:45] <didrocks> mterry: so, trying that + adding the dependencies between stacks (more on that in a publishing doc) once sil2100 will have few tests ironed out
[14:45] <didrocks> we'll probably do "one blank shot" tomorrow (without really releasing) with jibel
[14:45] <didrocks> but I don't feel confortable enabling that just before going on vacations :)
[14:46] <didrocks> mterry: I think I'll disable all the jobs btw. I don't think that in what is bootstrapped and running already, we'll have emergency fix
[14:46] <sil2100> didrocks: yes, and I also probably found a bug in appmenu in the meantime as well
[14:46] <didrocks> sil2100: \o/
[14:46] <didrocks> larsu: ^
[14:46] <sil2100> Trevinho is helping me out here as well
[14:46] <didrocks> oh sweet!
[14:47] <fginther> mhr3, can you review https://code.launchpad.net/~fginther/dee/add-code-coverage/+merge/139586 or suggest someone?
[14:47] <larsu> didrocks, what do you mean? The appmenu bug?
[14:47] <didrocks> mterry: not sure you were able to talk to cyphermox yesterday, I didn't get any feedback, did you have a chance to work with him on the failing tests in a chroot?
[14:48] <didrocks> larsu: not sure it's the same than Trevinho and sil2100 are looking at
[14:48] <cyphermox> didrocks: I was out cold all day yesterday
[14:48] <didrocks> so maybe better that the 3 of you sync!
[14:48] <cyphermox> I poked mterry this morning
[14:48] <mterry> didrocks, huh.  I can't mark the testapp branch approved.  Can you do that?
[14:48] <didrocks> cyphermox: yeah, hello btw! do you feel better?
[14:48] <cyphermox> didrocks: a little, yeah
[14:48] <didrocks> mterry: do you want that power?
[14:48] <didrocks> cyphermox: thé + miel? :)
[14:49] <mterry> didrocks, sure (muhahaha!   more power!)
[14:49] <cyphermox> at least now I can actually stick to one physical location at home... ykwim
[14:49] <didrocks> ykwim?
[14:49] <didrocks> you know what I mean
[14:49] <didrocks> I guess :)
[14:49] <cyphermox> ;)
[14:49] <didrocks> cyphermox: take it easy! :)
[14:50] <cyphermox> meh, things still need to get done, and it's been taking way too long already
[14:50] <didrocks> mterry: waow! you are an autopilot hacker now, impressive! :p
[14:51] <didrocks> fginther: mterry: libunity-misc merged now and adding to the bootstrapped list! awesome :)
[14:55] <mhr3> fginther, configure.ac:146: cannot open `build/autotools/gcov.m4': No such file or directory
[14:55] <mhr3> fginther, looks like it doesn't support non-srcdir build
[14:56] <fginther> mhr3, thanks I'll fixt that
[15:21] <fginther> mhr3, how are you doing the non-srcdir build?
[15:24] <mhr3> fginther, mkdir builddir; cd builddir; ../autogen.sh; make
[15:24] <fginther> mhr3, thanks
[16:00] <didrocks> larsu: sil2100: sweet a fix and perf improvments!
[16:01] <larsu> didrocks, the performance increase was rather tongue-in-cheek ... it's only 4 empty indicators not being transferred over the bus
[16:01] <sil2100> :)
[16:01] <larsu> but otherwise: yeah! I love how easy this was to fix
[16:01] <didrocks> larsu: ah ok, I thought it was for all exported menus :)
[16:01] <sil2100> I'm testing larsu's solution now
[16:01] <larsu> didrocks, yes, all exported menus (that are GMenuModels)
[16:01] <larsu> didrocks, 4 is the number for charmap, it's really the amount of toplevel menu items
[16:02] <larsu> but still, since the indicators are empty, there's not much data ...
[16:02] <didrocks> ah ok, only toplevel menu indicators ;)
[16:02] <didrocks> yep
[16:03] <larsu> yeah but it's more Right now :)
[16:14] <sil2100> larsu: tested, works! Can I approve globally, or do you want someone else to also review it before that?
[16:15] <larsu> sil2100, I want tedg to have a look as well, it's his code
[16:15] <larsu> sil2100, thanks for testing!
[16:16] <sil2100> Would be awesome to have it merged in, I won't have to push the autopilot test-hack otherwise ;)
[16:43] <Zhenech> ?window 36
[16:56] <tedg> larsu, Any clue on why GtkMenu inserts separators?
[16:57] <tedg> larsu, Seems kinda ridiculous.
[16:58] <larsu> tedg, that's the only way to do separators with GMenuModel (have them between all toplevel sections/items)
[16:59] <tedg> larsu, Ha, okay.  Feeling sorry for who ever has to write appmenu-gtk for GMenuModel.  :-)
[16:59] <larsu> otherwise you'd never have any separators
[16:59] <larsu> tedg, attente? :)
[16:59] <larsu> aww, he's not in here
[16:59] <tedg> Ah, didn't realize someone was on it.
[17:00] <tedg> It's going to be super painful as GMenuModel is so inflexible.
[17:00] <larsu> tedg, I hear he's making good progress, though :) Let's see how it turns out
[17:01] <larsu> tedg, thanks for approving
[17:01] <larsu> sil2100, should land soonish
[17:01] <tedg> larsu, No problem, finding it is harder than approving it :-)
[17:02] <larsu> tedg, right...
[17:02]  * larsu was searching in unity-panel-service at first
[17:02] <tedg> larsu, I'm sure he will, just inferring what the app was trying to do is going to be tricky.  A lot of fakery.  Plus you have to deal with lots of things changing that GMenuModel doesn't allow.
[17:05] <larsu> tedg, ya, when I first heard about it I thought it was an impossible job :)
[17:09] <sil2100> \o/
[17:09] <sil2100> Thanks :)
[17:10]  * larsu <-- dinner
[17:11]  * tedg is a little concerned that larsu just got turned into dinner, but is hoping for the best.
[17:12] <didrocks> tedg: you know, on those countries…
[17:15]  * tedg is a little concerned that didrocks is going to be turned into wine, but is hoping it is a nice wine ;-)
[17:15] <didrocks> tedg: who will be the cheese then? :)
[17:15] <tedg> didrocks, seb128!
[17:16] <seb128> tedg, heh, are you saying that I smell?
[17:17] <didrocks> seb128: I would find that offensive as well
[17:17] <tedg> Heh
[17:17] <tedg> I'm saying you age nicely.
[17:17] <didrocks> :)
[17:18] <seb128> lol
[22:19] <alo21> hi all..
[22:19] <alo21> I read some ideas here: https://wiki.ubuntu.com/Unity/Lenses/Ideas
[22:20] <alo21> and I would to implement one of them. What should I do?


[14:20] <CarlFK> I am getting a kernel panic trying to boot the live cds (jaunty, ibex and kam, bug report coming monday)  What are the kernel parms to turn off 'everything' ?
[14:21] <CarlFK> it's a P3, so nothing new
[16:38] <cjwatson> CarlFK: I don't know of any kernel parameters that turn off everything, short of not booting the kernel :-) The most common ones are accessible from F6 at the CD boot menu. If that doesn't work then kernel folks are likely to be much more qualified to help you than us