[01:10] <sabdfl> hey lifeless
[01:10] <sabdfl> lifeless: do you know what time the staging update happens?
[01:37] <lifeless> sabdfl: not offhand
[01:38] <lifeless> sabdfl: sorry
[01:38] <sabdfl> ok thanks
[01:38] <sabdfl> night all
[01:38] <lifeless> I'm pretty sure stub has mailed that to the lp list
[01:38] <lifeless> gnight
[03:22] <jamesh> good morning
[03:23] <spiv> jamesh: morning.
[03:23] <spiv> jamesh: your laptop made it home ok?
[03:23] <jamesh> yeah
[03:23] <jamesh> seems to be working fine
[03:25] <jamesh> how's the smart server stuff going?
[03:26] <spiv> Slowly, but making progress.  There are quite a few tests that assume a local transport, and other little issues.
[04:45] <WebMaven> what's smart server?
[04:58] <spiv> WebMaven: http://bazaar-vcs.org/SmartServer
[04:58] <jamesh> WebMaven: something to speed up bzr's network performance
[04:59] <jamesh> WebMaven: at the moment, bzr uses a "dumb server" (i.e. plain SFTP or HTTP, so the server needs no special knowledge of bzr branches)
[05:00] <jamesh> a smart server would know what a bzr branch is and know how best to send the client what it needs in minimal round trips and download size
[05:00] <jamesh> (hopefully)
[05:20] <imbrandon> hrm any LP admins arround i can poke for a second
[05:23] <imbrandon> ok well heres my deal incase anyone wakes up, got a slight problem and dunno if i need to poke yall or Riddell , but a few days ago i changed my main contact email on LP to a new address but my alias's<EMAIL_ADDRESS>/ kubuntu.org are still trying to send to the old adress , normaly this wouldent be a problem but the dns entry for the domain my old address is at seems to be cached too so basicly all my mailing list mail and b
[05:24] <imbrandon> can someone poke the dns to refresh or at very leaste update the alias file to point to my new contact email
[05:24] <imbrandon> heh
[05:30] <jamesh> imbrandon: the alias sync stuff isn't automatic at the moment.  I'm not sure who you have to ping to get it fixed.
[05:30] <jamesh> morning stub
[05:30] <imbrandon> ahh jamesh thanks , probably riddell he who set me up the first time
[05:30] <imbrandon> thanks
[05:30] <ausimage> Hello, I would like to request the package xdg-utils be added to the ubuntu distro on launchpad... It is a dependency of Lyx now.... bug #56282 and will not upgrade in Edgy. Thanks.
[05:30] <Ubugtu> Malone bug 56282 in lyx "Edgy Dependency Issue" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56282
[05:31] <stub> Morning
[05:31] <imbrandon> ausimage: try in #ubuntu-motu for info about getting new packages in edgy
[05:31] <jamesh> stub: no problems with your luggage?
[05:31] <ausimage> K crimsun sent me here...
[05:32] <stub> imbrandon: elmo or possibly Znarl or Spads are the only ones who can poke the email address aliases.
[05:32] <stub> jamesh: Thankfully no.
[05:32] <imbrandon> stub: ahh ok, since i'm not arround #launchpad that much whats the "normal" times they are awake/alive ?
[05:33] <stub> jamesh: I couldn't hear the usual thumps as the Thai baggage handlers toss luggage from the truck to the conveyor belt so maybe they were under special instructions, or maybe feeling generous since it was the queens birthday the day before.
[05:33] <jamesh> stub: my flight from Heathrow was almost 2 hours late departing.  Thankfully Qantas delayed the Singapore -> Perth flight so that people coming from London could get on
[05:34] <jamesh> yeah.  I think they were under special instructions everywhere :)
[05:34] <stub> imbrandon: I'd suggest opening a bug report and assigning it to elmo. They are all on UK time, Znarl earlyish and elmo lateish generally.
[05:34] <imbrandon> stub: good idea thanks again for yall time for something trivial ;)
[05:34] <stub> jamesh: same same. Arrived at terminal 3 hours before scheduled departure time. 4 hours to get on plane. 5 hours before it started taxiing.
[05:35] <jamesh> stub: it took me a while to find the end of the checkin queue because there was another queue in front of it (for passport control)
[05:35] <jamesh> stub: by the time I'd checked in, the passport control had gone out the door of the terminal ...
[05:36] <stub> Hmm... I went straight to checking, then onto the security queue which was like something out of a terry gilliam movie
[05:36] <stub> (passport queue)
[05:36] <stub> Every time you turned a corner, it stretched away into the distance. I expected it to go right around and form a loop.
[05:36] <imbrandon> stub: one last dumbish question , file it against the LP product ? or does it realy matter ......
[05:37] <stub> Thankfully, after going the entire length of terminal 3, through a lengthy set of passages, it eventually stopped in the multistory carpark.
[05:37] <crimsun> hi, all, just discussed bug 56282 (with ausimage), which will need a sync from Debian Sid, so to file a bug against that source package in LP the name needs to exist. Could 'xdg-utils' be added?
[05:37] <Ubugtu> Malone bug 56282 in lyx "Edgy Dependency Issue" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56282
[05:37] <stub> imbrandon: Yes
[05:37] <jamesh> after getting my boarding pass/passport checked, it took about 40 minutes or so to make it the last 20-30 metres to the security screening
[05:37] <imbrandon> stub: ok thanks
[05:38] <stub> jamesh: same. passport control wasn't the bottleneck for me either - they were letting people through as fast as the queue to screening would let them.
[05:39] <stub> They seemed too busy to check with dogs or more than a good pat down, so it would have been a good day to be a drug smuggler.
[05:39] <stub> (Not that anyone would be smuggling drugs out of the UK)
[05:40] <jamesh> crimsun: the guys who could answer your question won't be up for a while yet
[05:40] <crimsun> jamesh: np, thanks.
[05:42] <jamesh> I got my "don't destroy this person's luggage" silver frequent flyer luggage tags in the mail while I was away
[05:49] <lifeless> woo
[06:05] <lifeless> stub: sounds traumatic
[06:05] <lifeless> stub: and we want a conference in the US after this ?!
[06:06] <stub> I doubt it as they are even more paranoid than the UK. I'll stick that wiki page up (already drafted)
[06:28] <lifeless> stub: now we need some publicity
[06:28] <lifeless> ;)
[06:40] <jamesh> stub: nice page title
[06:49] <jamesh> lifeless: are we still planning on moving the LP branches from /home/warthogs/archives/... to somewhere else on the filesystem with shorter paths?
[06:49] <lifeless> yes
[06:49] <lifeless> I'd love someone else to do that, its not high on my priority list
[06:49] <lifeless> - because bzr needs much luv
[06:50] <jamesh> I saw the performance comparison page for bzr 0.9
[06:50] <jamesh> congratulations
[06:50] <lifeless> thanks
[06:50] <lifeless> still a lot to do though
[06:51] <lifeless> has anyone done work to teach oprofile how to get python stack frame data ?
[06:52] <lifeless> or any vm based machine for that matter (mono etc)
[06:52] <spiv> Hmm, not that I know of.
[06:53] <lifeless> I got to grips with it in the weekend
[06:53] <lifeless> its really quite nice
[06:53] <jamesh> spiv: did you see the review of your short posix-shell-happy branch?
[06:54] <spiv> jamesh: yeah, I did.
[06:54] <spiv> jamesh: that seems like a nice solution.
[06:57] <jamesh> spiv: any particular reason you wanted to build launchpad with dash? :)
[07:00] <spiv> jamesh: it is (was?) the default shell on edgy, apparently.
[07:00] <spiv> sivang reported the problem.
[07:00] <spiv> I'm not much of a shell pedant normally, but I figured it would be good to be prepared for when launchpad devs start upgrading to edgy.
[07:02] <jamesh> I suppose having a basic bourne shell as /bin/sh isn't that bad an idea :)
[07:04] <spiv> Yeah, and dash is supposed to be considerably faster than bash, so I suppose it might make a measurable difference to boot times and the like.  So I'm not shocked that edgy's doing that.
[07:05] <spiv> I guess the other solution would have been an explicit "SHELL=/bin/bash" in that Makefile, come to think of it.  That doesn't feel as nice making the shell code cleaner, though.
[07:08] <lifeless> dash is definately much faster
[07:13] <jamesh> faster startup or faster at running scripts or both?
[07:16] <lifeless> both
[07:16] <lifeless> its less functional though
[07:22] <jamesh> if you call /bin/sh and expect features of bash, your code is broken
[07:22] <lifeless> right
[08:22] <stub> spiv: Does this fix under edgy database/schema/Makefile too? Mark emailed me earlier about it
[08:25] <jamesh> stub: sounds like it.
[08:31] <spiv> stub: that's the Makefile it changes, yep.
[08:35] <jamesh> spiv: so you'd make sabdfl happy by landing it :)
[08:49] <sabdfl> thanks spivomatic!
[08:53] <sabdfl> stub: for future reference, what time does the staging update happen?
[08:54] <stub> after the daily backup is done and copied to the staging server.
[08:55] <stub> About 1:20 UTC at the moment, give or take 10 mins
[08:55] <stub> erm... BST.
[09:01] <sabdfl> ok, thanks
[09:25] <carlos> morning
[09:26] <carlos> stub: hi, around?
[10:22] <stub> carlos: ping
[10:22] <carlos> stub: hi
[10:22] <carlos> stub: what's the status of the migration ?
[10:23] <stub> carlos: I tried running it on a mirror of the production database. The first run (breezy -> dapper) went fine, and should be fast if I drop the distribution statistics rebuilding. The second run (breezy ->edgy) died with an excepion and I opened a bug on it.
[10:23] <carlos> hmmm
[10:23] <carlos> my fault?
[10:24] <carlos> stub: bug number ?
[10:27] <stub> Hmm... I have the outgoing email, but it looks like Malone dropped it
[10:31] <carlos> stub: what's it about?
[10:42] <SteveA> lifeless: ping
[10:58] <SteveA> lifeless: ping
[10:58] <lifeless> pong
[10:58] <SteveA> hi
[11:08] <lifeless> jamesh: SteveA: tickcount is packaged and should be in NEW now
[11:08] <lifeless> I'll do an ITP for debian sometime this week
[11:09] <jamesh> lifeless: cool.
[11:09] <lifeless> sources are http://people.ubuntu.com/~robertc/tickcount/ if you want to fiddle
[11:09] <lifeless> edgy and dapper are quite different for python now - this is packaged for edgy and beyond
[11:11] <danilos> stub: ping
[11:11] <SteveA> lifeless: way cool.  we need it for both dapper and edgy.
[11:11] <danilos> carlos: edgy migration issues (by stub): https://launchpad.net/bugs/56314
[11:11] <lifeless> ok. I'll need to package it separately for dapper. Do you need 'a binary for dapper' or 'it uploaded to dapper-updates' ?
[11:12] <carlos> danilos: I know, I already talked with him about it
[11:12] <SteveA> because the whole point is to deploy it in the DC.
[11:12] <carlos> I'm fixing it right now
[11:12] <danilos> carlos: ok :)
[11:12] <SteveA> lifeless: a binary for dapper is okay.
[11:12] <carlos> danilos: sorry for not told you about it
[11:12] <danilos> carlos: np, I've just got the email about it
[11:12] <SteveA> lifeless: so I can just ask the admins and launchpad developers to install it
[11:12] <lifeless> I'll talk to the sysadmins about their preference then
[11:12] <SteveA> thanks lifeless
[11:12] <lifeless> they build their own anyway
[11:12] <lifeless> so its really whats easiest for them
[11:13] <SteveA> also, there is some interest from the support team on taking on small packaging tasks
[11:13] <SteveA> so, if you're already fully booked, see if you can pass it along to etienne
[11:14] <ddaa> Good morning
[11:15] <lifeless> I'm happy to maintain tickcount in ubuntu and debian indefinately
[11:15] <danilos> stub: have you had a chance to look at my bug 30602 mail?
[11:15] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Critical,Confirmed]  https://launchpad.net/bugs/30602
[11:15] <lifeless> it keeps my hand in to have some packages to care for
[11:16] <SteveA> lifeless: fine with me
[11:16] <lifeless> however, for doing the dapper backport, I may offer that to etienne as a small task - I dont think hes done binary python modules yet
[11:17] <ddaa> SteveA: re lifeless being fully booked: you should know he never travels without at least half a dozen brick-sized books, he's pretty much fully booked all the time :)
[11:28] <carlos> danilos: I found the problem and It's fixed. I'm going to test it on staging now
[11:28] <danilos> carlos: great, hopefully we'll get farther away this time
[11:28] <danilos> carlos: do you have a test for the problem as well?
[11:29] <carlos> It will require sampledata changes so I'm working on it
[11:56] <ddaa> lifeless: SteveA: mpool: jamesh: spiv: meeting in 4 mins
[12:01] <jamesh> ddaa: on #launchpad-meeting?
[12:02] <ddaa> Yes, as usual
[12:02] <ddaa> mpool: SteveA: please report to astrometrics^W #launchpad-meeting
[12:07] <carlos> lifeless: hi, could you restart staging's database? I left some tables locked when I killed an external script and I cannot wait until the psql client dies
[12:07] <carlos> well, and Stuart is not around to fix it...
[12:09] <carlos> lifeless: it's unlocked now
[12:09] <carlos> so don't worry about it. Thanks
[12:47] <lifeless> reviewer meeting in 13
[12:47] <SteveA> lifeless: can you turn off the regex [r=who]  thing for the launchpad/ui-one-zero branch please?
[12:48] <lifeless> sure
[12:48] <SteveA> tell me when you have and I'll resubmit my merge
[12:49] <lifeless> done
[12:52] <SteveA> ta
[01:00] <lifeless>  reviewer meeting time
[01:00] <lifeless> whos here ?
[01:00] <spiv> me
[01:01] <jamesh> me
[01:01] <lifeless>  * Next meeting
[01:01] <lifeless>  * Queue status.
[01:01] <BjornT> me
[01:01] <SteveA> hi
[01:02] <lifeless> cool
[01:02] <lifeless> 10 items in the queue
[01:03] <lifeless> 2 I think shouldn't be there, because they have to go through the bzr process - its double handling to have the lp team review
[01:03] <SteveA> not really paying attention, as i'm in meetings
[01:03] <lifeless> SteveA: thats fine
[01:03] <lifeless> SteveA: you're optional anyhow ;)
[01:03] <lifeless> kiko-fud: your branch is reallly getting old - the tt-search branch
[01:04] <lifeless> spiv, you have  abrnach that is getting a little old
[01:04] <lifeless> other than that its all looking fine to me
[01:05] <lifeless> oh, next meeting, this time - is that ok ?
[01:05] <jamesh> sure.
[01:05] <BjornT> sure
[01:06] <lifeless> any new business? general problems? PITA branches ?
[01:07] <BjornT> nothing from me
[01:07] <SteveA> are people doing pre-implemenation calls?
[01:07] <SteveA> i haven't seen many p= tags in merges
[01:07] <lifeless> good question.
[01:07] <SteveA> I WANT MORE!
[01:08] <lifeless> I haven't had any requests for them
[01:08] <SteveA> or something like that
[01:08] <lifeless> I think like reviews, we need to make it mandatory
[01:08] <jamesh> kiko asked me what the "p=" bit was when I merged a branch with one ...
[01:08] <SteveA> reviewers should be doing one each day at least
[01:08] <lifeless> with a special opt-OUT
[01:08] <SteveA> FFS
[01:08] <SteveA> kiko has been "allergic" to voice calls recently, it seems
[01:08] <lifeless> like the trivial merge is an opt out
[01:08] <SteveA> voice calls are important for makeing people work together effectively
[01:09] <SteveA> I want the launchpad team to have more voice calls, about the code people are working on
[01:09] <SteveA> about the features they're working on
[01:09] <lifeless> btw what is your asterisk voice quality like ?
[01:09] <SteveA> maybe it's a time planning thing
[01:09] <lifeless> [I agree with what you are saying and share that desire]
[01:10] <SteveA> I think many people like to get various organisational things done in the morning
[01:10] <lifeless> the review process suffered when reviewers grabbed their own reviews - which is very much a time management thing
[01:10] <SteveA> before getting on with other work
[01:10] <SteveA> but that means that guys in the americas won't get calls with guys further east
[01:10] <SteveA> how about this...
[01:11] <SteveA> get everyone to set aside 1hr a day for such calls
[01:11] <SteveA> it won't necessarily be used every day
[01:11] <SteveA> but have a more fixed time for it
[01:11] <lifeless> by everyone, you mean 'all reviewers' or 'all lp team members' ?
[01:11] <SteveA> everyone
[01:11] <lifeless> ok
[01:11] <SteveA> bjorn and brad should have voice calls
[01:11] <SteveA> cprov and malcc should have voice calls
[01:12] <SteveA> reviewers and everyone else should have voice calls
[01:12] <lifeless> so the idea is that the person you are ringing has a guaranteed time slot
[01:12] <SteveA> a 20 minute focussed voice call can be worth a lot
[01:12] <lifeless> if you want their time, you just look them up on the world clock
[01:12] <SteveA> yeah, something like that
[01:12] <lifeless> like we have the staff schedule
[01:12] <SteveA> their "open office" hour
[01:12] <BjornT> brad and i used to have voice calls, but stopped for some reason. i'll make sure we'll start having them regularly again.
[01:12] <lifeless> I think this is a good idea
[01:13] <cprov> SteveA: we have weekly voice calls, since 3 or 4 weeks ago
[01:13] <SteveA> cprov: you were having daily ones a while back
[01:14] <lifeless> SteveA: can you bring this up in the lp meeting ?
[01:14] <lifeless> its in the minuts for this one.
[01:14] <SteveA> please someone add it
[01:14] <SteveA> I really must get back to this meeting
[01:14] <lifeless> I'll add it
[01:14] <SteveA> ta
[01:14] <lifeless> I want to put your name beside it :)
[01:15] <SteveA> reviewers can be proactive
[01:15] <SteveA> and tell people that they haven't spoken with them in a while
[01:15] <SteveA> and that they have interesting code ideas
[01:15] <SteveA> so would like to takl
[01:15] <lifeless> yes
[01:15] <SteveA> in a sense, reviewers are the condiut of coding knowledge around the company
[01:16] <SteveA> I'd like to encourage reviewers to grab people for 20-30 minute talks about the coding they're doing
[01:16] <cprov> SteveA: yes, during some critical time we have more than one call a week, when dsilvers were leaving. Do you think it's worth to document it, I mean, send and email to lp ML with summarized topics discussed in the call ?
[01:16] <SteveA> or cool features they're doing
[01:16] <SteveA> or talking about the new forms facilities, and how to best use them
[01:16] <SteveA> etc.
[01:16] <SteveA> cprov: yes, that is a good discipline
[01:16] <SteveA> and shows people that you're leading the field on having useful calls
[01:17] <cprov> SteveA: right, will do this week.
[01:17] <SteveA> ok, great
[01:17] <lifeless> ok
[01:17] <lifeless> anything else ?
[01:17] <jamesh> there are two dsilvers branches in needs-reply state
[01:18] <jamesh> a 1 month old branch and a 2 month old branch
[01:18] <lifeless> ok
[01:18] <lifeless> just change them to be malcc
[01:18] <lifeless> i.e. nag him
[01:18] <jamesh> I assume he isn't going to finish them off, so some decision needs to be made on whether they are to be abandoned or adopted
[01:19] <jamesh> I'll email him about them then.
[01:19] <malcc> lifeless: Good call, I'll get those branches off PendingReviews today; we've discussed them with Daniel last week and they're to be abandoned
[01:19] <lifeless> ok
[01:19] <lifeless> 5
[01:19] <lifeless> (end of meeting
[01:19] <lifeless> 4
[01:19] <jamesh> malcc: cool.  Could you update PendingReviews page then?
[01:19] <lifeless> (counting down
[01:19] <lifeless> 3
[01:19] <malcc> jamesh: Will do
[01:19] <lifeless> (really soon now
[01:19] <lifeless> 2
[01:19] <lifeless> (it will be over
[01:19] <lifeless> 1
[01:19] <lifeless> (it is over
[01:20] <lifeless> thanks for coming
[01:20] <jamesh> malcc: there is also dsilvers/launchpad-repo/launchpad/bug-47770 -- I suppose that needs to be adopted by someone?
[01:22] <malcc> jamesh: cprov's taken over the bug and marked it fix released, I'll have a poke around and find out if that's just a misunderstanding and we do actually need the code which was in review
[01:23] <cprov> jamesh, malcc: the bug fix itself was merged in one of my branches and released
[01:23] <malcc> cprov: Cool
[01:23] <cprov> I'm not sure about what is inside now
[01:26] <cprov> malcc: a new test for the bug, but I've already done one before committing, do you think it's worth to add this new one ?
[01:27] <malcc> cprov: I'd say, only if it takes a different approach we might want in the code so we can copy it for other tests. Otherwise, one test is the right number :)
[01:28] <lifeless> ok, gnight all
[01:28] <cprov> malcc: so, discard it, it's doing exactly what I did inside drq-dist-upgrader.txt.
[01:28] <lifeless> I'm off
[01:29] <malcc> cprov: Cool, thanks for double checking
[01:29] <cprov> malcc: np
[01:34] <carlos> danilos: congratulations, your first merges!
[01:34] <carlos> :-P
[01:35] <danilos> carlos: thanks :)
[01:35] <danilos> btw, what's the thing with holidays? I don't even know what are all official holidays in Serbia :)
[01:37] <carlos> danilos: you should know them ;-)
[01:37] <carlos> danilos: you put them on StaffCalendar
[01:37] <carlos> and you don't work those days
[01:47] <danilos> carlos: ha, nice one :)
[01:52] <ddaa> how interesting
[01:53] <ddaa> the nautilus import causes the gnome cvs to sigbus...
[01:53] <ddaa> first time I come across that signal
[01:54] <ddaa> Let's do the bus warp again!
[01:55] <LarstiQ> ddaa: lucky you
[02:18] <cprov> stub: ping ?
[02:52] <stub> cprov: pong
[02:53] <cprov> stub: I'm facing problem related with DB transaction in one of the soyuz tests, can you help me ?
[02:54] <stub> perhaps
[02:55] <cprov> stub: fine, DB updates are not visible for external scripts, even after commit() & flush_database_updates(). any clue ?
[02:56] <stub> The external script must have already opened a connection and started a transaction for that to have happened, or the external script is connecting to a different database. btw. flush_database_updates() should be done before the commit()
[02:58] <cprov> stub: the former would be impossible, because the new item was inserted in the test, it's visible, but not the update on it. the second, maybe, let me check
[03:00] <cprov> stub: aha, fixed ;) I'm a little concerned about the need of these call. Can't we have something like auto-commit for tests ?
[03:02] <stub> cprov: Then you would not be testing the real behavior. Also, we only want to commit when necessary as a test which doesn't make and commit changes means the next test can reuse the existing database, saving a few seconds.
[03:02] <stub> Needing flush_database_updates is an open bug though.
[03:03] <cprov> stub: yes, I see your point and yes, I've seen your note on drq-dist-upgrade.txt
[03:03] <cprov> stub: fine by me, thank you for helping me.
[03:03] <stub> If it is a pita for a particular test, I think it means you need a helper (eg. commit all outstanding changes and run this script)
[03:05] <cprov> stub: good point, It makes sense for most of the soyuz end-to-end tests
[03:13] <cprov> stub: uhm, caches needs to be invalidate as well, Content.get() returns the old instance in this context, how does it sound to you ?
[03:14] <cprov> stub: and what exactly does this error mean ?:
[03:14] <cprov> Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0xb520d7ec>> ignored
[03:20] <jamesh> cprov: garbage collection problems
[03:20] <jamesh> cprov: the function the __del__ method is trying to call has been replaced with a reference to "None"
[03:22] <cprov> jamesh: yup, I got more or less the meaning of it, but what can be causing it ? badly handling "transaction" module ?
[03:23] <kiko-fud> morning
[03:52] <BjornT> any reviewer up for a trivial review?
[03:52] <kiko> carlos, don't you think it would be worth refactoring the browser code for translation before doing the TranslationReview work?
[03:53] <kiko> carlos, I think you'll end up with a terrible mess if you try to extend that code further..
[03:53] <kiko> BjornT, sure,
[03:53] <carlos> kiko: I need to finish the form changes as soon as possible
[03:53] <carlos> kiko: so the UI sprint gives us some love there
[03:53] <carlos> about the functionality (browser.py) yes, I will be happy if you give me what you have and finish it
[03:54] <BjornT> kiko: https://sodium.ubuntu.com/~andrew/paste/filesBq2tS.html
[03:54] <kiko> I don't have that branch anymore, it bitrotted to death
[03:54] <carlos> kiko: so I should start again?
[03:54] <BjornT> kiko: it's a fix for bug 53903
[03:54] <Ubugtu> Malone bug 53903 in malone "Attached files no longer linked in mails " [Untriaged,In progress]  https://launchpad.net/bugs/53903
[03:54] <carlos> ok, the idea was to use a common parent, right?
[03:54] <kiko> carlos, well, I never got too far there -- the idea was basically to avoid duplication in it.
[03:54] <kiko> carlos, now, two things
[03:54] <kiko> carlos, a) I can write to you a suggested class-and-template structure
[03:55] <kiko> carlos, b) this should be done as a separate branch, because reviewing the two things at once will be crazy
[03:55] <kiko> BjornT, was that a bug, or what?
[03:55] <carlos> kiko: ok
[03:55] <kiko> heh
[03:56] <kiko> BjornT, are there other spots in database/bug that we should be notify()ing but aren't?
[03:56] <carlos> kiko: anyway, I think I remember more or less your initial patch (the idea behind it at least)
[03:56] <kiko> carlos, it had flaws. I'll email you today with a set of comments on how I think they should be refactored. thanks!
[03:57] <carlos> ok
[03:57] <carlos> kiko: thanks to you
[03:59] <BjornT> kiko: probably. currently we're not consistent, sometimes we notify outside the db code, sometimes inside. i'm not sure whether there is a reason for those places where we notify outside the db code, though.
[03:59] <kiko> BjornT, those sound like bugs :-(
[03:59] <kiko> BjornT, so did we just not test the fact that  we sent email for new attachments?
[04:00] <BjornT> kiko: yeah. we did have tests that the notification is correctly generated if there are attachments in the BugDelta.
[04:01] <kiko> BjornT, hmmm. are we not emitting the even twice?
[04:01] <kiko> BjornT, is there a bug # for this change?
[04:02] <BjornT> kiko: according to the test i just added, we're emitting it only once. how come you think we do it twice?
[04:02] <BjornT> 16:54 < BjornT> kiko: it's a fix for bug 53903
[04:02] <Ubugtu> Malone bug 53903 in malone "Attached files no longer linked in mails " [Untriaged,In progress]  https://launchpad.net/bugs/53903
[04:02] <kiko> BjornT, well..
[04:02] <kiko> sorry, didn't see that.
[04:06] <kiko> BjornT, the bug says "no longer". did this regress? or did we never send email if attaching was the only thing that you did?
[04:07] <BjornT> kiko: it did regress. i think the view was changed from an AddView to a GeneralFormView, but no event notification was added.
[04:08] <kiko> ah. AddView emits an event notification?
[04:08] <BjornT> yeah
[04:08] <kiko> so if the DB class emits an event and the addview does as well.. does that mean two events get emitted?
[04:09] <BjornT> yes it does. OTOH, we'll be moving away from SQLObjectAddView to LaunchpadFormView, which doesn't emit any events at all by default.
[04:11] <kiko> BjornT, s/by default// right? I mean, the emission would be done in browser/ code, correct?
[04:13] <BjornT> kiko: yeah. what i meant was that we will not have any form class that will automatically emit events, you have to do it yourself, either in browser/ code, or somewhere else.
[04:13] <BjornT> that makes you more aware of the events, preventing event duplications.
[04:14] <kiko> BjornT, right. last question: is the test in bugattachments now robust over changes of this type?
[04:15] <kiko> I am confused as to why this test didn't contain attachment notifications
[04:15] <kiko> since the document /is/ called bugattachments.txt :)
[04:15] <kiko> BjornT, I get the feeling there is a functional test we are missing
[04:15] <kiko> BjornT, something that doesn't require TestEventListener()
[04:15] <kiko> but perhaps I am wrong
[04:16] <BjornT> kiko: yes, it should prevent similar regressions. it makes sure that adding an attachment via the view class causes a notification to be added in BugNotification.
[04:17] <BjornT> kiko: the test that really prevents the regression isn't dependent on TestEventListener.
[04:17] <kiko> ah, ok, I see
[04:17] <BjornT> +    >>> print latest_notification.message.text_contents
[04:17] <BjornT> +    ** Attachment added: "blah"
[04:17] <BjornT> +       http://.../foo.txt
[04:17] <kiko> you query BugNotification
[04:17] <kiko> sorry, missed that
[04:17] <kiko> r=kiko
[04:17] <BjornT> thanks
[04:29] <SteveA> kiko
[04:30] <kiko> SteveA,
[04:37] <ddaa> Will Launchpad be eventually able to start sending page data before the page rendering is complete?
[04:38] <ddaa> Streaming the page contents in that way, along with moving as much stuff as possible out of https, should do a lot to help the perceived slowness of launchpad.
[04:49] <carlos> stub: I'm not sure whether my testing on staging is being slow or it's stalled, are you able to check it?
[05:01] <stub> carlos: what testing?
[05:01] <carlos> the edgy opening
[05:01] <carlos> I'm testing my latest changes
[05:06] <stub> carlos: disks are being thrashed. Not sure what is doing it - might be you.
[05:06] <carlos> should I kill my process?
[05:09] <stub> It is your script that is thrashing it as far as I can tell. I'd just leave it running. If it doesn't complete, I can test it on Carbon tomorrow.
[05:13] <stub> carlos: From your account on asuka, please try 'psql -d launchpad_test -h carbon -U rosettaadmin'
[05:14] <carlos> psql: FATAL:  Ident authentication failed for user "rosettaadmin"
[05:14] <carlos> stub: I usually connect from the launchpad account on asuka
[05:14] <carlos> using sudo
[05:15] <stub> You can test the script quickly against that db, but you won't be able to see the results so I wouldn't kill the staging run just yet.
[05:15] <stub> My bad - typo. Try again.
[05:15] <stub> Should work from either 'carlos' or 'launchpad' accounts.
[05:15] <stub> carlos: ^^^
[05:16] <carlos> stub: I'm connected now
[05:16] <carlos> ok, so I should get another tree on asuka to connect to that database, right?
[05:16] <stub> ok. Do what you want with that db. Don't run more than one script at a time though or you might affect demo.launchpad.net
[05:17] <stub> carlos: You can use the same tree. You just need to duplicate the staging/* config
[05:17] <stub> And change the 'dbhost'
[05:22] <carlos> stub: ok, thanks
[05:23] <milosz> hey guys, i'm having problems importing new translation templates
[05:23] <milosz> i tried adding them in twice now (over the coure of last week) and they still haven't apeared yet
[05:23] <carlos> milosz: hi, give me just one minute and I will be all yours
[05:23] <carlos> BjornT: about your email
[05:24] <carlos> BjornT: I'm not 'complaining' about two emails, but that the first one already says that I'm the assignee of that bug
[05:25] <carlos> and the second email says that I was not until that second email
[05:26] <carlos> milosz: hi, what URL are you using to do the upload ?
[05:27] <BjornT> carlos: well, i'd say that's part of bug 51046. you shouldn't get a 'public bug reported' email, you should get a mail that isn't so confusing.
[05:27] <Ubugtu> Malone bug 51046 in malone "The newbug-style email a new bug contact receives on product/package reassignment is confusing" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/51046
[05:27] <kiko> oh
[05:27] <carlos> ok
[05:27] <BjornT> carlos:  bug 41063 is also somewhat related
[05:28] <Ubugtu> Malone bug 41063 in malone "Mail notification of bug creation includes things that haven't happened yet" [Medium,Confirmed]  https://launchpad.net/bugs/41063
[05:28] <carlos> BjornT: yeah, that one sounds more like what I was trying to point at
[05:28] <kiko> BjornT, is bug 50906 a dupe of that one then?
[05:28] <Ubugtu> Malone bug 50906 in malone "Malone sent me a copy of a bug report two days after it was reported" [Untriaged,Confirmed]  https://launchpad.net/bugs/50906
[05:29] <carlos> well that one is about being late
[05:29] <carlos> we are talking about giving future actions
[05:29] <kiko> carlos, no, read the description.
[05:30] <BjornT> kiko: yeah, it's a dupe.
[05:30] <carlos> for me 'two days after...'  is being late, isn't it ?
[05:30] <kiko> carlos, no, read the description.
[05:30] <carlos> is the word 'copy' the key here ?
[05:30] <carlos> ;-)
[05:30] <kiko> yes
[05:30] <kiko> well
[05:31] <kiko> the summary is misleading
[05:31] <kiko> but the description is clear
[05:31] <carlos> I got that bug too
[05:32] <milosz> carls i just go to my project (drapes) -> translations -> template -> upload template
[05:33] <carlos> milosz: I see, it's a new upload request
[05:33] <carlos> milosz: It requires manual review the first time you do the upload
[05:33] <carlos> jordi: Could you take a look? ^^^
[05:37] <milosz> well i uploaded the orginial template before
[05:37] <milosz> this is an updated one with new strings
[05:39] <kiko> argh, stub's gone
[05:39] <milosz> and it tells me to look throught the import queue but the import queue is long and there is no way to search it
[05:42] <kiko> carlos, danilos: please don't forget my email requesting that information for today!
[05:43] <carlos> kiko: don't worry, I have most of it done
[05:43] <carlos> just waiting for some testing to send you it
[05:43] <kiko> thanks, most appreciated
[05:43] <danilos> kiko: sure, though I got in right in the middle of edgy migration :)
[05:43] <danilos> carlos: if you need any help, just let me know
[05:47] <milosz> carlos: what do i need to do?
[05:47] <carlos> milosz: just one minute, phone...
[05:54] <Sp4rKy_> please when start edgy translation ?
[05:54] <milosz> carlos: okay, i really appereciate the help
[05:56] <carlos> milosz: I'm back
[05:56] <carlos> milosz: I will approve now your files
[05:56] <carlos> milosz: but that URL should be used only when you do the initial import
[05:56] <carlos> next time use https://launchpad.net/products/drapes/trunk/+pots/drapes/+upload
[05:57] <carlos> milosz: that one will get your .pot and .po files automatically (if the .po files use the language code as its filename)
[05:57] <carlos> otherwise you need an admin to review your uploads
[05:57] <Sp4rKy_> carlos, please when start edgy translation ?
[05:57] <carlos> Sp4rKy_: we are working on it atm testing latest details to open it based on what we have in dapper
[05:58] <milosz> carlos: okay, i didn't find that information anywhere
[05:58] <carlos> kiko: when do you plan to send the status email about edgy, tomorrow?
[05:58] <carlos> milosz: ok, I will note that to jordi so we try to improve the documentation about that.
[06:00] <milosz> maybe you should have it automaticaly update the package tempates if you click it again, and you are the project owner?
[06:01] <carlos> milosz: we support more than one template for a given product
[06:01] <carlos> so we need to know which one should get the upload
[06:02] <carlos> milosz: it's approved now
[06:03] <carlos> Sp4rKy_: please, just wait a couple of days and we will give you much more details of its status, but the initial plan is to open it with next production update this week
[06:04] <Sp4rKy_> carlos, k thx
[06:07] <mpt> Goooooooooooooooooooooooooooooood afternoon Launchpadders!
[06:07] <milosz> carlos: thx
[06:07] <malcc> I'm not sure the afternoon has been quite *that* good
[06:07] <carlos> np
[06:09] <ieskantis_kazko> hi
[06:16] <kiko> BjornT, have time for a quick review?
[06:22] <BjornT> kiko: sure
[06:26] <kiko> BjornT, https://sodium.ubuntu.com/~andrew/paste/filehFrYUL.html
[06:27] <kiko> BjornT, it always hides comment zero and offers a link to it when the description has changed
[06:28] <kiko> BjornT, I don't know what tests I need to update but I will as soon as make check will return and then I'll add explicit checks for this.
[06:30] <neutrinomass> I've been having some problems lately with adding upstream tasks to Ubuntu bugs. For example bug 2740 - when adding an upstream task to the gnome bugzilla I get an invalid value in the product field . Am I doing something wrong ?
[06:30] <Ubugtu> Malone bug 2740 in gnome-pim "gnomecal crashes in breezy" [Medium,Unconfirmed]  https://launchpad.net/bugs/2740
[06:31] <BjornT> kiko: that 'assert comments > 0' doesn't look like it does the right thing.
[06:31] <kiko> yeah
[06:31] <kiko> good point
[06:31] <kiko>         assert len(comments) > 0, "A bug should have at least one comment."
[06:31] <kiko> what's wrong with me today, sigh
[06:31] <BjornT> kiko: do we have problems with duplicated comments? is it common?
[06:32] <seb128> neutrinomass: what do you enter to that field?
[06:32] <neutrinomass> seb128: I tried both "gnomecal" and "gnome-pim" and got the same error with both
[06:32] <kiko> BjornT, yeah, it's fairly common.
[06:32] <seb128> neutrinomass: maybe there is no such upstream product listed on launchpad?
[06:32] <kiko> BjornT, I saw it in a number of ubuntu bugs when researching last week
[06:33] <seb128> neutrinomass: products need to be created, that's the case for most of the GNOME desktop but not everything in the world
[06:33] <neutrinomass> seb128: Likely - I'm not exactly sure how the system works.... should this be reported somewhere ?
[06:34] <kiko> BjornT, we could avoid the comments being submitted, but that's a lot more work than omitting them during output.
[06:34] <BjornT> kiko: well, i know that we had some duplicated comments when the bug page was handling the comment adding. now that a separate page does that, we shouldn't add duplicate comments any more.
[06:34] <seb128> kiko: are users supposed to create upstream products? or is a team doing that? or is that something for upstream to ask?
[06:34] <neutrinomass> Indeed - no gnome-pim and no gnomecal exist in launchpad
[06:34] <kiko> seb128, users are supposed to create products, yes. they can later reassign them.
[06:35] <seb128> kiko: do you have the URL for that handy? :)
[06:35] <kiko> BjornT, yeah. I don't think it hurts to have that code there, though
[06:35] <kiko> seb128, /products/+add
[06:35] <seb128> thank you
[06:35] <kiko> and product/foo/+reassign
[06:35] <neutrinomass> Isn't it  https://launchpad.net/products/+new ?
[06:35] <kiko> or something like that. :)
[06:35] <seb128> yeah, looks the right place
[06:35] <seb128> it was easier to find that I thought :p
[06:35] <neutrinomass> So I just add any products missing when I come across them ?
[06:36] <kiko> BjornT, the user can still submit, stop, submit again, though (click twice on button, etc)
[06:36] <seb128> neutrinomass: feel free yep ;)
[06:36] <neutrinomass> seb128, kiko: Thanks :)
[06:36] <seb128> np, thank you for your work ;)
[06:37] <neutrinomass> Last thing: I add the "product" or the "component" ?
[06:38] <BjornT> kiko: ok, the code looks good. as for tests, i'd like a test for the duplicate comment handling in bug-pages.txt. you should also add a pagetest (don't know where), which checks that the link to the original comment is there, and ensures that the link isn't broken.
[06:38] <kiko> BjornT, I'll add those.
[06:38] <BjornT> kiko: cool, r=me after that
[06:38] <kiko> mmm, will need to add some sampledata too
[06:38] <kiko> okay thanks
[06:40] <milosz> carlos: i uploaded a even newer pot + update po files, and it still says in the queue need review, and that's using the url you gave me
[06:41] <carlos> danilos: could you join #ubuntu-meeting, please ?
[06:41] <carlos> milosz: there is a delay
[06:41] <danilos> carlos: sure
[06:41] <carlos> give it a couple of hours and if it's not imported, ping me, please
[06:47] <neutrinomass> seb128_ : Actually, I'm not sure I should add it after all. It's on the list of "deprecated" products ....
[06:47] <seb128_> neutrinomass: deprecated from where?
[06:49] <neutrinomass> seb128_: http://bugzilla.gnome.org/browse.cgi . See the products list... its under "deprecated" and the homepage http://www.gnome.org/gnome-office/gnome-pim.shtml reveals as much...
[06:49] <seb128_> neutrinomass: right, maybe no need to bother opening upstream tasks then
[06:50] <neutrinomass> seb128_ : Ok... thanks again
[06:50] <seb128_> np
[06:59] <milosz> carlos: how big of a delay is it?
[06:59] <carlos> milosz: it usually is fast
[07:00] <carlos> but the queue has a bunch of entries for Ubuntu, so it takes a bit more time now
[07:23] <mpt> carlos, has jordi been around recently?
[07:23] <carlos> mpt: he's on vacations until Wednesday
[07:23] <mpt> There are community things that need doing
[07:23] <mpt> ok
[07:23] <mpt> I'll ping him then
[08:33] <kiko> BjornT, I'm finding that my bug-pages test is now randomly failing. eek
[08:34] <kiko> hmmm
[08:34] <kiko> could it be because I'm not committing the transactions..
[08:35] <kiko> the ordering is by datecreated, after all
[08:35] <kiko> yeah
[08:36] <kiko> that was it
[08:36] <kiko> how weird.
[09:04] <danilout> carlos: ping
[09:19] <carlos> danilout: pong
[09:20] <kiko> BjornT, ping?
[09:20] <kiko> or bradb
[09:20] <kiko> or SteveA
[09:20] <kiko> or jamesh
[09:20] <bradb> pong
[09:21] <kiko> bradb, so I want to validate/process the data entered for the remote bug field
[09:21] <kiko> bradb, removing, for instance, leading hashes
[09:22] <kiko> bradb, and allowing URLs to be entered
[09:22] <kiko> and then chopping them up accordingly
[09:22] <kiko> bradb, where should I do that, though?
[09:22] <kiko> should I use a validator or a widget?
[09:23] <BjornT> kiko: a widget. look at StrippedTextWidget for an example.
[09:23] <bradb> kiko: I /think/ it might be nice if you can do it inside the widget, so that calling getInputValue returns only the value that will get stored in the db.
[09:23] <kiko> BjornT, does the widget have access to the context? in this specific case, to the bugtracker we're using?
[09:24] <BjornT> kiko: yeah, via self.context.context. self.context is the field.
[09:25] <kiko> BjornT, even if the watch hasn't been created yet?
[09:28] <BjornT> kiko: well, it depends on where you want to add this. in BugTaskBugWatchWidget, you can get the bugtracker using self.bugtracker_widget.getInputValue()
[09:29] <kiko> BjornT, hmmm. I wish this worked everywhere. :-/
[09:34] <BjornT> kiko: it would be possible to create a new BugWatchWidget, which would make it easier making it work everywhere. but it might be more work than it's worth...
[09:36] <BjornT> kiko: basically that widget would consist of a bugtracker widget, and a remote bug widget, so it's actually not that hard to do. it's adapting the forms/widgets to use it that is the most work.
[09:36] <kiko> hmmm
[09:37] <kiko> hmmm
[09:37] <kiko> basically
[09:37] <kiko> what I want to do is if the end-user inputs a URL
[09:37] <kiko> validate the URL against the bugtracker URL
[09:37] <kiko> and then truncate it to the remote bug id
[09:37] <kiko> which shouldn't be difficult
[09:37] <kiko> if the URL doesn't match I want to raise an error
[09:38] <kiko> and if it does I want to modify the value
[09:38] <kiko> BjornT, would a simple RemoteBugWidget allow me to do that?
[09:38] <kiko> considering the fact that it needs to know the bugtracker type and URL?
[09:39] <BjornT> kiko: no. it needs to be a BugWatchWidget, which would have access to both the remote bug, and the bug tracker.
[09:40] <kiko> BjornT, which wouldn't be usable in the edit task form, right?
[09:41] <BjornT> it wouldn't be usable directly, but BugTaskBugWatchWidget could use BugWatchWidget in order to benefit from it. that's an easy change.
[09:42] <kiko> BjornT, s/use/inherit from/ ?
[09:43] <BjornT> kiko: no, use. currently it has sub-widget, it uses a bug tracker widget, and a remote bug widget to do its work.
[09:48] <BjornT> kiko: btw, if you'd do the validation/truncation in one place, i'd be happy to create and modify the necessary widgets to make it work later.
[09:48] <kiko> BjornT, hmmm. okay. but what place would that be?
[09:52] <BjornT> kiko: what place do you think needs it the most? actually, it's probably easiest to do it in the bugtask edit page, BugTaskBugWatchWidget._toFieldValue. the other option would be on +upstreamtask, but that's quite tricky to do. i think i need to convert BugAlsoReportInView to a LaunchpadFormView in order to make it simpler first.
[09:53] <kiko> BjornT, I'll look at doing it there, then.
[10:06] <elmo> is l.c.c the wrong place to look for remotely recent rocketfuel instructions?
[10:06] <elmo> it seems to still all be about the chinstrap
[10:06] <kiko> elmo, it's the right place, but perhaps we haven't done the s/chinstrap/sodium change
[10:06] <elmo> kiko: what about the lightweight checkout stuff?
[10:07] <kiko> elmo, using repositories? there's a page up for that as well, I believe. one sec.
[10:07] <kiko> you don't need to use them, though
[10:07] <elmo> I thought they were mandatory given the lack of space on sodium
[10:07] <elmo> but if I don't, super
[10:08] <kiko> https://launchpad.canonical.com/WorkingWithSharedRepositories?highlight=%28repositories%29
[10:11] <LarstiQ> elmo: repositories also improve speed (branch, push, pull, basically whenever a revision is already present)
[10:12] <elmo> kiko/larstiQ: thanks
[10:18] <WebMaven> SteveA: AYT?
[10:33] <sabdfl> hey kikomatic
[10:34] <sabdfl> ui team on amphetamines over here
[10:34] <sabdfl> newz2000 is suggesting stored procedures and EVERYTHING
[10:34] <sabdfl> it's going to rock
[10:47] <WebMaven> SteveA: AYT?
[10:47] <kiko> sabdfl, stored procedures?!
[10:47] <LarstiQ> WebMaven: at this hour, I wouldn't be surprised if he was asleep.
[10:48] <WebMaven> Sleep? We can sleep when we're dead.
[10:51] <LarstiQ> While I appreciate the sentiment, I also prefer SteveA not terminating prematurely.
[10:51] <kiko> WebMaven, I gave a Warren Zevon album to SteveA, coincidentally.
[10:54] <WebMaven> See? this is why vampires make the best developers.
[10:54] <kiko> he's probably offline now though
[10:55] <WebMaven> yeah, I guess. Although he's showing as online.
[10:55] <WebMaven> Not even as 'away'.
[10:55] <WebMaven> Ah well. I'll catch him later.
[10:55] <kiko> I can /kick him from #launchpad if you like though
[10:56] <WebMaven> no, let him collect the scrollback if he wants it.
[10:58] <WebMaven> Are there any Ubuntu+Python or Ubuntu+Zope channels or mailing lists?
[10:58] <kiko> hmmm, I'm not sure. I suspect not!
[11:00] <kiko> WebMaven, he's currently in London, which is why he's kind of unresponsive on IRC. I think that will be fixed this week though
[11:02] <WebMaven> Ok.
[11:04] <sabdfl> kiko: yeah ;-)
[11:04] <kiko> sabdfl, I think I am -ECONTEXT now
[11:06] <sabdfl> stored procedures
[11:06] <kiko> sabdfl, I know what they are in the SQL context. but in the UI context?
[11:06] <sabdfl> we were cooking up the mother of all charts for a bug page somewhere, which i said would crawl, and newz2k said "oh that's ok just make a stored procedure!"
[11:06] <sabdfl> crack me up
[11:06] <kiko> heh
[11:07] <sabdfl> otherwise, good progress
[11:07] <sabdfl> at the very least, 1.0 will be crisp
[11:07] <sabdfl> and clean
[11:07] <sabdfl> though not optimal
[11:08] <cbx33> Hi all, quick question regarding bug statu
[11:08] <kiko> sabdfl, as long as we're moving forward. :)
[11:08] <kiko> yes cbx33?
[11:08] <cbx33> I'm working on a package for edubuntu
[11:09] <sabdfl> sivang: ping
[11:09] <cbx33> found two bugs
[11:09] <cbx33> fixed two bugs
[11:09] <cbx33> I host a bzr branch which is registered on LP
[11:09] <cbx33> what status do I change those bugs to?
[11:10] <kiko> cbx33, the fix committed means that the fix has been committed to the product's main code repository, but no fix has been made available under a publically released version
[11:10] <kiko> cbx33, fix released means that end-users have access to released version which contains the fix.
[11:10] <cbx33> right ok
[11:10] <cbx33> that's what I thoguht
[11:10] <cbx33> thanks kiko
[11:11] <kiko> cbx33, the main functional difference between them is that fix released makes the bug "disappear" from the default bug listings.
[11:11] <kiko> cbx33, you're welcome.
[11:11] <cbx33> yes I realised that
[11:11] <LarstiQ> which might be part of the reason why bzr uses fix released for bzr.dev
[11:12] <kiko> LarstiQ, if you do that, users may keep on filing dupes on bugs which are already fixed.
[11:12] <sabdfl> kiko: r=sabdfl on sivang's patch, i'm going to reply to him, could you land it for him, please, or delegate that?
[11:12] <LarstiQ> kiko: not happening yet
[11:12] <kiko> unless bzr.dev is what your users are using.
[11:12] <sabdfl> he will need to merge to rf head, though, after my landing
[11:12] <lifeless> morning
[11:12] <sabdfl> hi robert
[11:12] <LarstiQ> kiko: but there is a need for a 'fix merged' I think.
[11:13] <kiko> LarstiQ, that's fix committed. :)
[11:13] <kiko> sabdfl, is this the s/BRAINDUMP/NEW patch you are talking about?
[11:13] <LarstiQ> kiko: so what do you call fixes committed to a non-trunk branch?
[11:13] <kiko> LarstiQ, In Progress.
[11:13] <kiko> LarstiQ, because essentially, they are not yet final or "approved".
[11:13] <sabdfl> kiko: yes
[11:14] <lifeless> hiya sabdfl
[11:14] <elmo> is it safe to use 0.9 for LP dev?
[11:14] <lifeless> yes
[11:14] <sabdfl> elmo: yes
[11:14] <sabdfl> encouraged
[11:14] <kiko> sabdfl, I believe I already r+ed that. I told him to get somebody to do it for him, though I can if he doesn't find anyone else
[11:14] <LarstiQ> kiko: feh, how about features/bugs _really_ in progress?
[11:14] <lifeless> kiko: we're fine with them filing dups, have you seen the wiki page where we describe how we use malone ?
[11:14] <elmo> oh, that's not what I actually wanted to ask
[11:15] <kiko> lifeless, one thing at a time.
[11:15] <kiko> LarstiQ, committing a fix to a non-trunk branch /is/ in-progress
[11:15] <kiko> LarstiQ, once the fix is generally approved and merged to the common repository, it is fix committed.
[11:15] <lifeless> kiko: okok. BTW, are you going to get that review done ? its 20 days old
[11:16] <kiko> LarstiQ, and once it is available in a public release, then it is fixed releasedd.
[11:16] <kiko> lifeless, yes, but francis is on vacation this week.
[11:16] <kiko> LarstiQ, I mean, once you have started working on something, it's fair to assume you will have committed to a non-trunk branch, right? this is bzr, after all :)
[11:16] <LarstiQ> kiko: I find the usage at http://bazaar-vcs.org/BugGuidelines more natural, apart from the abuse of Fix released, due to a missing Fix merged
[11:17] <LarstiQ> kiko: true, but finishing fixing the bug and merging it to trunk are two very distinct phases
[11:17] <bradb> bug statuses are what you make of them
[11:17] <kiko> LarstiQ, why?
[11:17] <lifeless> bradb: :)
[11:17] <kiko> LarstiQ, the fact is that until this fix has been merged into the trunk, there is no guarantee that people have actually agreed with it.
[11:18] <kiko> bradb, well, we /do/ have some semantics attached to them :-P
[11:18] <LarstiQ> kiko: people can merge the feature branch and have a working solution, instead of having to wait for it to be in trunk
[11:19] <kiko> LarstiQ, who says it's working? I suspect most projects would not feel happy with endorsing something to be "fixed" by an unofficial patch.
[11:19] <lifeless> kiko: fix committed lets mergers search for unmerged bug fixes
[11:19] <bradb> kiko: sure, but we can only try and reach a mutual understanding with our users, rather than expect they'll follow the One True Path.
[11:19] <kiko> lifeless, ah, a use case.
[11:19] <elmo> oh, gar, bzr 0.9 isn't dapper happy
[11:19] <kiko> lifeless, interesting
[11:19] <lifeless> elmo: welcome to the new python policy
[11:19] <LarstiQ> kiko: I'm really only thinking of regular contributors
[11:19] <lifeless> kiko: Martin and I spent some time working through what we need, to use malone efficiently, and we laid it out on the lp-dev list
[11:19] <kiko> LarstiQ, ISWYM, but lifeless' use case is really what I was fishing for
[11:20] <LarstiQ> kiko: I'll have to learn to that better
[11:20] <lifeless> so there is some existing discussion on that
[11:20] <kiko> his use case is "fix available"
[11:20] <kiko> I guess
[11:20] <elmo> lifeless: *whine*
[11:20] <lifeless> elmo: dude, beat up the python-bof @ debconf
[11:20] <kiko> bradb, oh, I wasn't disagreeing with LarstiQ or lifeless, but fishing for a use case as to why they used a different model
[11:21] <LarstiQ> kiko: ah hmm, I'd then make it 'Fix available' and 'Fix merged', doing away with committed
[11:21] <lifeless> we're going to do a 0.9 version for dapper-updates shortly
[11:21] <kiko> LarstiQ, yeah, but not everybody uses an RCS in which "merged" means what you do. :)
[11:21] <LarstiQ> kiko: what, there are non-bzr malone users? Heresy! :)
[11:21] <kiko> I wasn't suggesting "fix available" as a status name yet though
[11:21] <kiko> fix-in-branch, fix-on-trunk
[11:22] <kiko> fixed-in-branch, fixed-on-trunk
[11:22] <LarstiQ> fix-in-patch
[11:22] <kiko> yes, bradb, we know
[11:22] <kiko> I like the idea too
[11:22] <kiko> but it isn't as trivial as it sounds
[11:22] <kiko> I find it interesting though that they use fix committed to communicate a fix is available for merging
[11:23] <bradb> if my brain were wired for distribution version control, i think i'd eat the definition up too
[11:24] <bradb> s/the def/that def/
[11:24] <lifeless> so
[11:24] <lifeless> lets look at it
[11:24] <lifeless> we expect 'in progress' to mean that there is at least one branch working on the bug
[11:24] <lifeless> i.e. linked branches
[11:24] <kiko> right
[11:25] <lifeless> and once someone is finished they say that the bug-branch relationship is 'fix ready'
[11:25] <kiko> (mpool, lifeless, for BugGuidelines, btw, priority is gone)
[11:25] <kiko> right
[11:25] <lifeless> that does not mean its 'fix committed' yet
[11:25] <bradb> there's a "Fix Available" bug branch status, fwiw
[11:26] <lifeless> at this point someone/people will bless the branch, usually via the review process on the main list
[11:26] <bluefoxicy> I like bradb's idea
[11:26] <lifeless> once its blessed its 'fix committed'
[11:26] <lifeless> bradb: I meant fix available
[11:26] <bluefoxicy> fix-in-stfu-and-get-back-to-writing-patches
[11:26] <lifeless> because we are saying two specific things at this point:
[11:27] <lifeless> a) users have a branch they can merge to get a bugfix that is considered 'ok'.
[11:27] <bluefoxicy> but that would require a patch system
[11:27] <lifeless> b) there is  abranch that needs merging to the mainline
[11:27] <bluefoxicy> which would recirculate the problem
[11:27] <lifeless> bluefoxicy: uhm, can you hang on a second
[11:27] <lifeless> bluefoxicy: as you seemto be off on a tangent
[11:27] <bluefoxicy> kay
[11:28] <kiko> lifeless, do the end-users merge themselves?
[11:28] <lifeless> so fix committed shows up on https://launchpad.net/products/bzr/+milestone/0.10
[11:28] <kiko> I find it really weird to use fix committed to indicate that it is blessed.
[11:28] <lifeless> for example 55783 needs to be merged
[11:28] <kiko> errr
[11:29] <kiko> I meant to ask
[11:29] <kiko> if branch owners merged their own work into the trunk, or if somebody else merges on their behalf
[11:29] <lifeless> and for release management, this works really well
[11:29] <bradb> kiko: I don't find it confusing. Their mental model, and what's actually happened, is consistent with the status name, tbh.
[11:29] <lifeless> if the owner has pqm access then they do their own merge
[11:30] <bradb> s/confusing/weird/
[11:30] <lucasvo> how comes that on https://launchpad.net/products/harmony/trunk it says: No revision control details recorded for trunk  even though https://launchpad.net/people/harmony-dev/+branch/harmony/trunk exists?
[11:30] <lifeless> lucasvo: https://launchpad.net/products/harmony/trunk is a release series
[11:31] <lifeless> lucasvo: https://launchpad.net/people/harmony-dev/+branch/harmony/trunk is a branch
[11:31] <kiko> lucasvo, because the UI is confusing, and because the latter is a branch called trunk under the harmony-dev team, the the former is a trunk branch on the release series.
[11:31] <lifeless> currently you cannot connect the two properly. I'm writing up the shortterm fix for that today as it happens
[11:31] <lucasvo> lifeless: you guys managed to implement cvs import before linking it to bazaar? funny thing.
[11:32] <kiko> lifeless, ah, so you'll be able to say that the project is bzr-natively-hosted?
[11:32] <lifeless> kiko: yes
[11:32] <kiko> very nice
[11:33] <kiko> fixes major wart
[11:33] <lifeless> lucasvo: other way around
[11:33] <lucasvo> kiko: but one is not able to upload a bzr repo to a release series?
[11:34] <lifeless> lucasvo: cvs imports *are* linked, but you cannot use a native bzr branch as the branch for a release series yet
[11:34] <kiko> lucasvo, what lifeless just said :)
[11:35] <lucasvo> lifeless: yes, that's what I meant. How come that one cannot use a native bzr branch? are there any complications?
[11:35] <lucasvo> lifeless: importing cvs must be harder to implement. or was it needed by an important project?
[11:35] <lucasvo> *required
[11:36] <lifeless> lucasvo: we started this without intending to write a VCS
[11:36] <lifeless> back in 2004 nearly noone used distributed VCS of any sort
[11:36] <lucasvo> oh.
[11:36] <lucasvo> lifeless: I did :)
[11:36] <lifeless> you may have
[11:36] <lucasvo> I was fighting with gnu-arch all the time
[11:37] <lifeless> ah right :)
[11:37] <lifeless> so, anyhow, our models and how things relate have changed as we got better and more flexible vcs support logic
[11:37] <lucasvo> lifeless: ok, that makes sense
[11:37] <lifeless> we've only just turned off our use of gnu-arch in the cvs import process!
[11:37] <lifeless> so now we need to take advantage of the flexability bzr offers
[11:38] <lucasvo> lifeless: you mean, you were using gnu-arch for imported cvs ?
[11:38] <lucasvo> well, even without it, lp is still a lot better than source forge
[11:39] <lifeless> we were going CVS - baz1 - bzr
[11:39] <lifeless> LOTS of backend machinery to update - took some time to be sure it was solid
[11:39] <lifeless> now its CVS - bzr
[11:40] <lucasvo> nice
[11:41] <lucasvo> lifeless: when will your apply the patch?
[11:42] <lifeless> I'm not writing a patch, I'm documenting the rules a patch should enforce
[11:42] <lifeless> we have a number of states that need to be preserved/move data around on disk etc
[11:42] <lifeless> ddaa will probably be the one writing the patch, hes the one that asked me to spec it
[11:42] <lucasvo> oh, ok.
[11:43] <ddaa> what patch?
[11:45] <ddaa> lifeless: you noticed I braindumped about that on the launchpad mailing list?
[11:46] <ddaa> And that the discussion about "one or two branches in productseries" was about fixing that issue?
[11:47] <ddaa> and that since we are apparently going to go with "two branches in productseries" there's no moving around of data needed
[11:48] <lifeless> ddaa: do you still need me to spec the transitions out ?
[11:48] <ddaa> The whole point of having import_branch and explicit_main_branch in productseries is NOT to have to worry about any of those transitions.
[11:49] <ddaa> since then you can have an import and a native branch coexisting peacefully in the same series.
[11:49] <ddaa> There's going to be DB schema transition involved, but that's the only one I can think of.
[11:49] <lifeless> is that a no ?
[11:50] <ddaa> yes, that's a no
[11:50] <lifeless> so I can remove my name from the bug
[11:50] <ddaa> I already did that I think
[11:50] <ddaa> bug 31308
[11:50] <Ubugtu> Malone bug 31308 in launchpad-bazaar "Cannot set branch associated to a product series" [Critical,Confirmed]  https://launchpad.net/bugs/31308
[11:51] <ddaa> changed assignee at 2006-08-10 14:18:32 CEST
[11:51] <lifeless> ok


[00:03] <bluesabre> flocculant: thanks
[00:04] <flocculant> np
[00:06] <flocculant> jjfrv8 left his hw info on there
[10:52] <flocculant> bluesabre: ok did some more testing - pavucontrol issue not seeing that on laptop, nor desktop in previous releases. So only see that in wily on this machine.
[10:53] <flocculant> the vbox power thing - see that in 15.04 but not Ubuntu unfortunately
[11:25] <bluesabre> morning all
[11:25] <bluesabre> slickymaster, Unit193, knome: is this an issue?
[11:25] <bluesabre> warning: failed to load external entity "C/translator-credits.xml"
[11:25] <bluesabre> warning: failed to load external entity "C/translators.xml"
[11:30] <flocculant> morning bluesabre
[11:30] <bluesabre> morning flocculant
[11:31] <bluesabre> so pavucontrol is not a consistent issue... seemingly hardware specific
[11:31] <bluesabre> (on wily)
[11:31] <flocculant> looking that way
[11:31] <flocculant> well
[11:31] <flocculant> I don't see it with the same hardware on previous releases
[11:32] <bluesabre> right
[11:32] <bluesabre> thats why I added the (on wily)
[11:32] <bluesabre> :D
[11:32] <flocculant> ha ha ha
[11:32] <flocculant> yep - that sums it up then :)
[11:33] <bluesabre> things like that are a pain to test... but if we can get it to show on ubuntu, we can hand it off to them or blame the kernel :D
[11:34] <flocculant> yea that was my hope :D
[11:35] <flocculant> it's certainly going to end up with a xubuntu-exp XX tag on it :p
[11:35] <bluesabre> :D
[11:36] <flocculant> I'd say it's probably one of those we can hope to see other people finding - might help to narrow it down a bit
[11:41] <flocculant> well it didn't miraculously disappear with a new kernel :p
[11:41] <slickymasterWork> no bluesabre, that's not an issue
[11:42] <slickymasterWork> that was a sort of a workaround knome came up with
[11:56] <bluesabre> slickymasterWork: good to head, will upload in a few minutes
[11:56] <bluesabre> s/head/hear/
[11:56] <SwissBot> bluesabre meant: "slickymasterWork: good to hear, will upload in a few minutes"
[11:56] <slickymasterWork> thanks bluesabre
[11:57] <slickymasterWork> and I did get that sutpid SwissBot
[11:57] <slickymasterWork> s/sutpid/stupid
[12:02] <bluesabre> knome, slickymasterWork: if you guys want to merge the updated changelog back in, https://code.launchpad.net/~bluesabre/xubuntu-docs/15.10.1/+merge/273970
[13:07] <slickymasterWork> bluesabre, unable to do it here (behind a proxy) but I'll do it later on, at home
[19:48] <knome> bluesabre, slickymaster: not really even a workaround, that's how it's documented
[19:48] <knome> bluesabre, we have an empty fallback so it's just a warning; if we didn't have the fallback, it would be an error and the compiling would stop at that
[21:19] <flocculant> thunar appears to be causing some problems of late
[21:19] <flocculant> crashing when copying, changing folder path all a bit random
[21:20] <drc> yup...been there couldn't do that 'cause it crashed.
[21:24] <flocculant> slow to see changes in folders too
[21:31] <drc> Anyone else have troubles burning a Daily USB today? Tried 5 times (with 3 different ISO images and all md5sums checked out) today with DD...checked media on usb boot and always came up with 1 error.  In the middle I tried a LM iso and it worked fine.  Finally tried unetboot and voila...all was well.
[21:32] <flocculant> don't actually burn daily - tend to vm them
[21:32] <drc> Gee...it must be nice to have modern hardware :)
[21:32] <flocculant> :D
[21:33] <Unit193> As close to hardware as they get is grml-rescueboot.
[21:45] <ochosi> knome, Unit193: so what was the outcome of the discussion regarding -core? (in a nutshell)
[21:48] <knome> ochosi, slangasek would rather see us do two ISOs under the same product
[21:48] <ochosi> right, that's what he suggested before i took off
[21:48] <knome> ochosi, the convention with the naming is currently to have "desktop" and "dvd" named versions
[21:48] <ochosi> i don't see any downsides to that, apart from the naming
[21:49] <ochosi> which is highly misleading in our case
[21:49] <knome> ochosi, but he said we can propose a different naming scheme, as long as we did the changes to the script
[21:49] <knome> ochosi, and that he wouldn't veto it, so was generally not negative about us wanting something else
[21:49] <knome> and that's pretty much the whole thing
[21:51] <knome> it makes sense to me to put them under the same product
[22:02] <ochosi> knome: yeah, does
[22:02] <ochosi> Unit193: any thoughts on this from your side?
[22:17] <Unit193> ochosi: https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
[22:19] <ochosi> Unit193: looks good
[22:19] <ochosi> krytarik: care to ask slangasek for another review?
[22:21] <krytarik> ochosi: Some yet another guy popping up all of sudden? I'd rather any of you do. :D
[22:21] <ochosi> since i'm not the author of the MR i can't do anything there
[22:21] <Unit193> FWIW, ochosi and knome have done the most talking to him.
[22:21] <ochosi> so actually maybe only Unit193 can do that
[22:22] <knome> sigh
[22:23] <knome> just join #ubuntu-devel and poke him.
[22:23] <knome> krytarik, please even join so we can direct questions at you if needed
[22:24] <krytarik> Alright.
[22:24] <knome> thanks
[22:24] <Unit193> Thanks, knome.
[22:25] <knome> np
[22:25] <Unit193> Sadly, this time I'm not literally walking out the door, so no good excuse. :P
[22:25] <krytarik> But I have - making dinner. :D
[22:46] <bluesabre> evening all
[22:48] <Unit193> Howdy.
[22:50] <bluesabre> hi Unit193
[22:55] <knome> heya seany
[23:00] <bluesabre> hey gnome
[23:00] <knome> :Ð


[14:19] <mterry> XMir still opens input devices itself it seems.  Is there a way to disable that yet and just use Mir input directly?
[15:52] <kenvandine> greyback_, any chance of getting your window-close-support branch landed soon?
[15:53] <greyback_> kenvandine: it's not been on my list of priorities tbh. qtmir needs work to enable first asking window to close politely, then waiting a bit, before timing out and killing it
[15:54] <greyback_> so that branch cannot be landed alone
[15:54] <kenvandine> bummer
[15:54] <kenvandine> ok
[15:54] <kenvandine> i've been quietly watching and hoping :)
[15:54] <greyback_> kenvandine: welcome to add a card to our scrum backlog, that'll get it moved along
[15:54] <kenvandine> not sure i have access to do that
[15:54] <greyback_> I'll do it
[15:54] <kenvandine> thx
[16:43] <mterry> XMir doesn't seem to get the screen size right -- can it not talk to Mir correctly to query that?


[08:31] <Riddell> shadeslayer: other people have that too where the file is a directory, I'm not sure what caused it, it's a file in the packaging
[09:25] <lordievader> Good morning.
[09:29] <soee__> against what such bug should be reported: https://www.youtube.com/watch?v=n2DIHGhJIeg&feature=youtu.be
[09:38] <soee__> woho lates owncloud client update makes it work with plasma 5.1 systray :)
[11:28] <BluesKaj> Hiyas all
[11:34] <Antisound> hi people!
[11:35] <Antisound> can you please tell me how to config my printer in plasma5? there's no printer config icon in system settings
[11:38] <soee> Antisound: im not sure, but thers not module ported to plasma 5
[11:38] <soee> but you can type in terminal: kcmshell4 kcm_printer_manager
[11:38] <Antisound> soee: ok. i try. thx :)
[11:38] <soee> this should launch old printer manager configuration
[11:38] <Antisound> soee: nice!
[11:38] <soee> hi BluesKaj
[11:39] <soee> Antisound: also if some other modules are missing in *5, type kcmshell4 --list
[11:39] <Antisound> soee: you've got to know that command ;-)
[11:39] <Antisound> thx
[11:39] <Antisound> works fine
[11:39] <soee> this will show you list of all *4
[11:39] <Antisound> ok
[11:39] <Antisound> thx a lot
[11:39] <soee> np
[11:40] <soee> Antisound: btw can you do me a favour and do some test ?
[11:40] <Antisound> soee: of course
[11:40] <Antisound> tell me
[11:41] <soee> can you add to your panel homerun kicker and see if it crashes for you like for me when ehckind deeper level of navigation: https://www.youtube.com/watch?v=n2DIHGhJIeg&feature=youtu.be
[11:42] <Antisound> i'm using kicker
[11:42] <Antisound> buuuuut
[11:42] <Antisound> i think i have no deeper level
[11:43] <soee> you can install ksudoku :D
[11:43] <soee> and it will be placed games -> logical -> ksudoku
[11:43] <Antisound> i try
[11:43] <soee> liek on my video
[11:43] <Antisound> ok
[11:44] <Antisound> nope
[11:44] <Antisound> nothing crashes
[11:44] <Antisound> everything works fine
[11:44] <soee> ;o
[11:44] <soee> interesting
[11:44] <Antisound> soee: do you homerun kicker or native kde plasma5 kicker?
[11:44] <Antisound> i think there's a difference
[11:44] <Antisound> or?
[11:44] <soee> its from plasma5
[11:45] <Antisound> so, no there's no crash ;-)
[11:45] <soee> ok, thank you for your help
[11:45] <Antisound> soee: you're welcome ;-)
[11:45] <Antisound> soee: what to do if plasmashell crashes?
[11:46] <soee> depends :) if you are lucky it restarts autoamticaly ;)
[11:46] <Antisound> i made the experience that i can do nothing anymore
[11:46] <soee> if not, if krunner works you can start it manually by typing: plasmashell
[11:46] <Antisound> soee: for me my whole system crashed
[11:46] <soee> or from terminal
[11:46] <Antisound> once my plasmashell crashed
[11:47] <soee> oh its a long time since i had a whjole system crash :)
[11:47] <Antisound> hehe ok
[11:47] <Antisound> isn't there a shortcut for a terminal?
[11:47] <Antisound> something about ctrl alt + ?
[11:47] <soee> check in temrinal settings :D
[11:47] <soee> im using yakuake
[11:47] <Antisound> ok
[11:48] <soee> so it starts with system and is available when pressing F12
[11:48] <Antisound> k
[11:49] <Antisound> soee: do you have an idea how to change an entry in the kicker?
[11:49] <soee> change what exactly ?
[11:49] <Antisound> the kde menu editor doesn't save changes
[11:49] <Antisound> an entry
[11:49] <Antisound> to rename it e.g.
[11:50] <Antisound> soee: or does it work for you?
[11:51] <soee> it saves chnages for me if i rename some entry
[11:51] <Antisound> soee: unbelivable!
[11:51] <Antisound> wtf is going on ;)
[11:51] <soee> do you click Save button ?
[11:51] <Antisound> of course :)
[11:51] <Antisound> hehe
[11:52] <soee> Plasma maginc :)
[11:52] <Antisound> seems so
[11:52] <Antisound> can't belive it isn't working for me
[11:52] <Antisound> either in opensuse factory with plasma5 nor in kubuntu 14.10 plasma5
[11:53] <soee> ;o
[11:53] <Antisound> do you know how to manually change the entry?
[11:53] <Antisound> where the config file is stored?
[11:55] <soee> nope ;)
[11:55] <Antisound> k
[11:55] <Antisound> worth a try :)
[12:04] <BluesKaj> is breeze the only colour theme we can use in plasma 5 ? trying different colours doesn't change the settings at all
[12:06] <BluesKaj> suppose a bug has already been filed on that
[12:06] <soee> i have no idea
[12:08] <BluesKaj> soee, system settings>colour
[12:10] <soee> BluesKaj: it changed color, for example it works for Dolpgin, though in System settings it only changed window decoration color
[12:12] <BluesKaj> soee, not her, as soon as I apply and close then relaunch sys settings the colour defaults to breeze \
[12:12] <BluesKaj> not here
[12:13] <Antisound> BluesKaj: as soee mentioned before,... plasma magic :D
[12:14] <soee> But for example, Breeze dark does nto work for me at all
[12:16] <Antisound_> soee: for me not at all too...
[12:16] <Antisound_> breeze dark suckz ;)
[12:17] <soee> well teh theme is nice
[12:17] <Antisound_> thats right
[12:17] <Antisound_> :)
[12:17] <soee> the color scheme - dunno
[12:17] <BluesKaj> hmm, norway works here, but marble doesn't, guess the downloaded colours aren't liniking
[12:42] <Antisound> completly off topic, but do you know a good tag editor with an database to automatically update the tags?
[12:51] <Antisound> unbelivable thats in amarok included, wow
[14:23] <BluesKaj> hmm. most are gone for the weekend I bet.
[14:29] <ScottK> Riddell: you can't just replace a directory with a file.  You have to rm the old one in preinst.
[15:22] <soee> !package libsdl
[15:41] <lordievader> !info libsdl1.2debian
[15:41] <lordievader> soee: Perhaps you ment that one ;)
[15:41] <soee> lordievader: yeah, thanks
[17:43] <soee> lordievader: ping
[18:00] <lordievader> soee: What's up?
[18:18] <BluesKaj> where's the scroller size setting in system settings, it seems to be missing
[18:18] <BluesKaj> used to be in app appearance I think , now it's gone in plasma 5
[20:23] <Riddell> ScottK: but why is it a directory at all?!
[22:20] <ScottK> Dunno.
[22:20] <ScottK> Just that's what the error seems to be related to.


[00:16] <thumper> ec0: heh
[08:13] <manadart> achilleasa: Need a review on a purely mechanical patch: https://github.com/juju/juju/pull/10653
[08:14] <achilleasa> manadart: looking
[08:57] <achilleasa> manadart: you also need to update the import paths for some other tests: https://jenkins.juju.canonical.com/job/github-make-check-juju/1152/console
[08:58] <manadart> achilleasa: Yeah, they are fixed; just running the tests now.
[09:12] <nammn_de> manadart: as we were talking about that before. Mind taking a quick look and review? https://github.com/juju/juju/pull/10652
[09:12] <manadart> nammn_de: Sure.
[09:23] <manadart> nammn_de: Reviewed.
[09:29] <achilleasa> manadart: overall LGTM; just have two questions (see comments)
[09:29] <nammn_de> thanks manadart and stickupkid
[09:31] <nammn_de> gonna add a test for the sorting case, manadart: regarding the openstack provider. Would it be worthwhile to update the "flavor" of openstack? As we are using it's struct https://github.com/juju/juju/blob/26d73876d4daedca2a39c3f385f98ac5040f27e0/provider/openstack/provider.go#L557 , my implementation used cost as the second value to sort. Here i
[09:31] <nammn_de> could use ram though
[09:37] <stickupkid> manadart, you'll like this update i'm about to post to your discourse post :D
[09:38] <stickupkid> manadart, once i've written it
[09:38] <stickupkid> haha
[09:38] <achilleasa> stickupkid: can you post on discourse or are you getting back 500 errors?
[09:38] <stickupkid> achilleasa, argh, not thought about that, let me check
[09:42] <achilleasa> manadart: got a few sec for a quick question re charm upgrades?
[09:49] <stickupkid> manadart, achilleasa https://discourse.jujucharms.com/t/thoughts-on-unit-testing/1451/9
[09:49] <stickupkid> achilleasa worked for me
[09:49] <manadart> achilleasa: One sec.
[09:54] <achilleasa> stickupkid: can you post in internal?
[09:54] <stickupkid> achilleasa let me check
[09:56] <stickupkid> achilleasa yeah i can
[09:57] <achilleasa> manadart: changes approved
[09:59] <achilleasa> stickupkid: hmmm... maybe I don't have post permissions? :D
[10:01] <stickupkid> achilleasa, https://media.tenor.com/images/ea2db29e89e34daa1b3d9716a7644208/tenor.gif
[10:02] <manadart> achilleasa: Thanks. HO on the charm thing?
[10:03] <achilleasa> manadart: omw
[10:09] <achilleasa> stickupkid: so I can create a post but when I try to paste the template and save I get an internal server error :-(
[10:09] <stickupkid> lol
[10:10] <achilleasa> stickupkid: can you try to paste https://pastebin.canonical.com/p/twG4txHRJX/ in https://discourse.jujucharms.com/t/juju-release-process-2-6-9/2091 ?
[10:11] <stickupkid> achilleasa legit 500
[10:11] <achilleasa> is there a max post size limit or something?
[10:11] <stickupkid> achilleasa don't think so
[10:12] <stickupkid> achilleasa surely it would tell you
[10:13] <achilleasa> stickupkid: pasting half the text seems to work though...
[10:13] <stickupkid> achilleasa the response from XHR, is the worst - 500, killed the server
[10:13] <stickupkid> achilleasa not much information to help diagnose
[10:13] <achilleasa> yeap...
[10:19] <achilleasa> stickupkid: it does seem like a max size limit... I managed to post up to the "homebrew" sections. Any attempts to append text after that point cause a 500
[10:19] <stickupkid> lol
[10:19] <stickupkid> let's check what discourse says
[10:20] <stickupkid> 99k max char limit
[10:20] <stickupkid> unless an admin has restricted it
[10:21] <achilleasa> I could render the markdown into an image and paste that in the post :D
[10:21] <stickupkid> HAHA
[10:22] <stickupkid> achilleasa i know why
[10:26] <stickupkid> achilleasa HO?
[10:26] <achilleasa> stickupkid: omw
[11:40] <manadart> achilleasa, stickupkid: Anyone able to review another trivial mechanical one? I started on the substantive patch, but thought I'd add another one to ease eventual review.
[11:41] <manadart> https://github.com/juju/juju/pull/10655
[15:23] <manadart> stickupkid: Were you going to have a look at https://github.com/juju/juju/pull/10655 ?
[15:24] <stickupkid> manadart, aye, was fighting with mocks
[15:24] <stickupkid> I won
[15:24] <manadart> Did ye ay?
[15:24] <stickupkid> HAHAHA
[15:24] <manadart> Forgot to pull that out at the sprint.
[15:25] <stickupkid> i wonder what the response to that is tbh
[15:25]  * manadart realises the innuendo possibilities too late.
[15:27] <stickupkid> manadart, done
[15:28] <manadart> stickupkid: Ta.
[15:37] <gnuoy> Could anyone tell me when 2.7 is likely to move to candidate ?
[15:37] <rick_h> gnuoy:  end of Oct
[15:37] <gnuoy> thanks rick_h
[17:18] <rick_h> magicalt1out:  any thought on putting your post on discourse? or mind if I do? https://www.spicule.co.uk/news/post/2019-09-25-how-to-deploy-applications-at-scale-in-kubernetes
[17:31] <magicalt1out> i don't mind rick_h go ahead


 Is that a blackberry?
 Actually people have been disappointed by the keyboard. The initial reviews have overwhelmingly said the keyboard is not it's strong point. The messenging center and some of the blackberry apps are the stand out


[08:13] <dholbach> good morning
[09:43] <davmor2> hey ogra_ question you're g+ is there a reason not to integrate the account sign in to online accounts? Do you know how hard that would be?
[09:49] <zzarr> hello! is there a way to install a 16.04 framework (kit) in Qt (Ubuntu SDK)?
[09:50] <zzarr> a better question yet is there a way to get QT += bluetooth to work? (build)
[10:02] <ogra_> davmor2, a bit of work ... why do you think thats needed ?
[10:03] <ogra_> (beyond obviously being more confortable on first login)
[10:03] <davmor2> ogra_: it's nicer if you already have an account
[10:04] <ogra_> the current setup allows multiple accounts even if you dont want all of them as system accounts
[10:04] <ogra_> if i tie it into the system accounts i cant keep that functionality
[10:05] <ogra_> so there is a tradeoff that kept me from looking into it yet
[10:06] <ogra_> (i also expect the CSS will soon change a lot so the app might break til i have adjusted everything ... so time to put into new stuff will be short)
[10:08] <davmor2> ogra_: ah fair enough
[10:17] <popey> dholbach, I have uploaded a new docviewer to the store, could you please review it when you get a moment?
[10:18] <dholbach> ep
[10:18] <dholbach> yep
[10:18] <dholbach> popey, I can't see it
[10:18] <popey> oh, I'm probably an idiot then
[10:18] <popey> I need to submit for manual review, one mo
[10:18] <dholbach> ok
[10:20] <popey> dholbach, which I have now done :)
[10:21] <dholbach> ok cool
[10:21] <dholbach> will check
[10:22] <popey> thanks
[10:24] <dholbach> popey, you're going from multi to armhf?
[10:24] <popey> yes
[10:24] <popey> it has libreoffice bundled in
[10:24] <popey> it's too big as a multi
[10:24] <dholbach> so it will leave some users on the old version, right?
[10:24] <popey> x86 users, of which I suspect there are near zero
[10:25] <popey> but yes.
[10:25] <dholbach> it crashes click-review for me
[10:25] <dholbach> so I'll have to debug that first
[10:25] <popey> hah, great :)
[10:25] <dholbach> I was in the middle of something else, but I'll take a look at it now
[10:26] <popey> sorry :(
[10:27] <popey> I didn't expect this to be any more than a button press
[10:27] <dholbach> no worries
[10:31] <dholbach> popey, are you sure the .url-dispatcher file is correct?
[10:31]  * popey looks
[10:31] <dholbach> shouldn't it specify 'urls' somewhere?
[10:32] <dholbach> it's what makes click-reviewers-tools explode
[10:32] <popey> sverzegnassi, ^
[10:32] <popey> dholbach, other apps don't have a urls line
[10:33] <dholbach> have an example click for me?
[10:33] <dholbach> I'm no expert on this at all
[10:33] <popey> me either
[10:33] <popey> just looking at other url-dispatcher files on my pc
[10:33] <popey> s/pc/phone/
[10:34] <popey> the music app doesn't have one.
[10:34] <popey> is click-review expecting the url-dispatcher file to be _in_ a folder called urls?
[10:34] <popey> because that's where it is in gallery.
[10:35] <popey> but music, calendar and reminders have the same format as docviewer
[10:36] <dholbach> how can I view the manifest of the click?
[10:36] <sverzegnassi> mmh... having a look. We've moved the .url-dispatcher file recently in another folder.
[10:36] <sverzegnassi> I probably forgot to update something in the CMake files
[10:36] <dholbach> ah, click info
[10:36] <dholbach>     "hooks": {
[10:36] <dholbach>         "docviewer": {
[10:36] <dholbach>             "apparmor": "docviewer.apparmor",
[10:36] <dholbach>             "content-hub": "docviewer-content.json",
[10:36] <dholbach>             "desktop": "com.ubuntu.docviewer.desktop",
[10:36] <dholbach>             "urls": ""
[10:36] <dholbach>         }
[10:36] <dholbach>     },
[10:37] <dholbach> so 'urls' is empty
[10:37] <dholbach> that might be a problem
[10:37] <popey> where does that come from?
[10:37] <dholbach> click info com.ubuntu.docviewer_2.0.223_armhf.click
[10:37] <popey> neat, never knew about that :)
[10:38] <sverzegnassi> dholbach: ok, i forgot to set @URLS_FILE@ variable
[10:38] <popey> sverzegnassi,             "urls": "@URLS_FILE@"
[10:38] <popey> heh :)
[10:38] <popey> \o/ thanks dholbach
[10:38] <popey> sverzegnassi, got time to make a merge now and I'll test and approve?
[10:38] <sverzegnassi> popey: I only need 5 minutes :)
[10:38] <popey> \o/
[10:39] <popey> I'll get some coffee :)
[10:39]  * popey hugs dholbach
[10:39] <sverzegnassi> popey: haha
[10:39]  * dholbach hugs popey back
[10:44] <sverzegnassi> thanks dholbach!
[10:52] <dholbach> sverzegnassi, popey: I wrote a patch for the reviewers tools (https://bugs.launchpad.net/click-reviewers-tools/+bug/1522777) - thanks for bringing it up
[10:52] <popey> hah, fixes all round!
[10:52] <dholbach> jdstrand, ^ I wasn't quite sure how to write a test for it - maybe you can take a quick look later on?
[12:12]  * popey gently tickles dholbach with a new app in the store :)
[13:32] <dholbach> popey, checking
[13:32] <popey> dholbach, ignore me, all done, as you were :)
[13:33] <dholbach> ok
[14:18] <jdstrand> dholbach: there isn't a good way to test those because _extract_url_dispatcher() is mocked. one could create a fake package to test it, but I don't think it is strictly required for this
[14:18] <jdstrand> dholbach: I committed the change
[14:19] <dholbach> thanks jdstrand
[15:12] <bartbes> popey: had a chance to look at my terminal patch yet?
[15:13] <popey> bartbes, sorry, not yet. Will take a look a little later, Had a couple of app updates to get out the door
[15:13] <popey> bartbes, you're (near) the top of the list though :)
[15:14] <bartbes> ok cool
[16:40] <bartbes> popey: you seem to be the person to ask, how can I stop the terminal app from sending SIGSTOP to my active process when it is backgrounded?
[16:40] <bartbes> or is that something ubuntu phone does, rather than the terminal app?
[16:40] <popey> it's the phone
[16:40] <popey> however, there is a workaround :)
[16:40] <popey> Install TweakGeek from the Open Store. https://open.uappexplorer.com/
[16:41] <popey> it has an option to let you let apps run forever
[16:41] <popey> btw, we have a good build of SDL2 which we could try getting love2d working with if you fancy it :)
[16:43] <bartbes> does it also have an option to not tie the compositor to whatever's on screen, the framerate dips are annoying
[17:09] <popey> bartbes, pass
[17:10] <popey> mzanetti, do you know if we'll have that qtmir fix in for ota8.5 (I know I mentioned to pmcgowan about this, but thought you might know technical details)
[17:10] <popey> https://bugs.launchpad.net/music-app/+bug/1518764
[17:11] <pmcgowan> popey, yes it is
[17:11] <ahayzen> \o/
[17:11] <mzanetti> popey, https://code.launchpad.net/~mterry/unity8/fix-wakelocks/+merge/279502
[17:11] <mzanetti> popey, there's 2 related branches. see the MP description
[17:11] <popey> Excellent work chaps!
[17:34] <mhall119> can someone tell me location of the vivid-phone-overlay PPA?
[17:34] <bartbes> hah, so I just installed openstore "summary goes here"
[17:35] <mhall119> is it https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay ?
[19:12] <popey> mhall119, deb-src http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu vivid main
[19:12] <popey> thats what's on my phone
[19:13] <davmor2> mhall119: sure it's just over there /me points
[19:29] <mhall119> davmor2: :-P
[19:29] <mhall119> thanks popey
[19:30] <davmor2> mhall119: you're only jealous that my ability to point is so accurate ;)
[19:57] <rickspencer3> silly question, but I can't find the answer!
[19:58] <rickspencer3> how do I access my app's data directory in a touch app?
[19:58] <rickspencer3> for context, I am using content hub to import sound files which get saved under /home/phablet/.local/share/flash.rickspencer3
[19:58] <rickspencer3> well, under /home/phablet/.local/share/flash.rickspencer3/Music
[19:59] <rickspencer3> I assume there must be some variable that I can use to access the dir rather than hard coding the full path?
[20:00] <mcphail> rickspencer3: $XDG_DATA_HOME
[20:00] <rickspencer3> that works in QML?
[20:00] <rickspencer3> interesting
[20:00] <mcphail> rickspencer3: that gets you the ~/.local/share bit, at least
[20:01] <mcphail> rickspencer3: not sure QML has any way for file i/o. Don't you need a c++ backend for that?
[20:02] <rickspencer3> hmm, don't know
[20:02] <mcphail> rickspencer3: anyway, for paths see https://developer.ubuntu.com/en/start/platform/guides/app-confinement/ and scroll down to Runtime Environment
[20:02]  * rickspencer3 looks
[20:40] <DanChapman> rickspencer3, AFAIK there isn't any variables exposed that define those XDG_* locations in qml. You would either need to hard code them or move into c++ and use something like QStandardPaths (which is probably overkill in your usecase)
[20:40] <rickspencer3> hi DanChapman
[20:40] <rickspencer3> yeah, I think I'll just go the "hardcode" route
[20:40] <rickspencer3> :/
[20:41] <rickspencer3> too bad, but ...
[20:41]  * rickspencer3 shrugs
[20:47] <DanChapman> yeah it's not ideal. :-/
[20:57] <mcphail> rickspencer3: best check you can create a valid .click package with hardcoded paths. I have a vague feeling that may fail click validation
[21:07] <mhall119> rickspencer3: http://stackoverflow.com/questions/16408691/get-home-and-or-username-in-qml might be helpful
[21:16] <JanC> maybe the Ubuntu SDK should provide an easy-to-include/use module with functionality like that...  :)
[21:20] <mhall119> yes, I would like to see a pre-install library to manage local files, it could include properties for all of the XDG paths
[21:21] <mhall119> one of my apps is dead-in-the-water right now because I don't have that, and I haven't bothered to add a C++ plugin to do it
[21:27] <JanC> and there might be other commonly-needed-but-not-available-in-QML stuff that could go in there too
[21:37] <qt> exit
[21:37] <qt> quit
[21:45] <mcphail> I think just about all file access needs c++, but that stuff is easy anyway
[21:46] <mhall119> mcphail: it does, but a generic plugin that exports that to QML could be written
[21:47] <mhall119> really it would need to list directories and files in them, and allow simple operations like creating, copying, moving and deleting them
[21:47] <mhall119> it wouldn't even need to support read/write
[21:48] <mhall119> though that might be nice to have too (not sure how much effort it would be to manipulate raw file data in javascript)
[21:50] <mcphail> Yes, I haven't done much manipulation of char streams in javascript, for the really dirty stuff
[22:07] <ahayzen> IIRC in the super early days of music we used the nemo file model plugin or something which could list directories and files
[22:09] <ahayzen> ah .. import org.nemomobile.folderlistmodel 1.0
[22:18] <mhall119> ahayzen: is that system-installed?
[22:18] <mhall119> or does it have to be included in each app?
[22:18] <ahayzen> mhall119, no don't think its seeded anymore, as it was for us
[22:19] <ahayzen> it'd have to be bundled i guess
[22:19] <mhall119> yeah, I think that was just a temporary hack to unblock you guys though
[22:19] <ahayzen> we moved from org.nemomobile.folderlistmodel to  org.nemomobile.grilo after that  then you mediascanner
[22:19] <ahayzen> yeah it was
[22:19] <ahayzen> mhall119, interestingly though there is this package now qml-module-qt-labs-folderlistmodel
[22:20] <ahayzen> so maybe it is something that will appear in the future
[22:20] <ahayzen> note it was qtdeclarative5-nemo-qml-plugin-folderlistmodel before.. so maybe it is something being endorsed by Qt ?
[22:21] <mhall119> I think the qt labs one has been around for a while, but I don't think it's seeded
[22:21] <ahayzen> yeah i wouldn't expect it to be seeded
[22:22] <ahayzen> mhall119, http://doc.qt.io/qt-5/qml-qt-labs-folderlistmodel-folderlistmodel.html
[22:22] <mhall119> yeah, it's in the same docs packages as things that are seeded
[22:22] <mhall119> even if it is included, it looks to only be a ListModel implementation
[22:22] <ahayzen> its enough just to tell what in a directory though :-)
[22:26] <ahayzen> mhall119, probably best to ask the SDK guys :-)


[01:48] <MeatsackApogee> Hello
[01:49] <MeatsackApogee> Anyone know how to turn off bluetooth and keep it of?  everytime i restart its on again.  Lubuntu 18.4.2
[01:51] <MeatsackApogee> also the task bar volume changer wont work. as soon at it pops up and i move out of the taskbar area to change it - it closes
[02:20] <jasmuz> Good evening all.
[03:08] <guiverc> MeatsackApogee, if you remove the 'minimize' condition on your panel, you should be able to access the slider correctly (as I recall).
[16:41] <AlterEdo> Hi I'm having trouble installing lubuntu 19, can someone help me please?
 not without details on the issues you're facing
[17:57] <wxl> Edoardo: did you check the hashes of the ISO and check the disc for defects at boot?
[18:21] <kc2bez> It also isn't clear which option was chosen or how the partitioning was broken up. I notice a swap partition, if you want to erase and install, it is necessary to turn swap off before starting the installer.
[22:21] <Krennic> 11