[00:09] <JontheEchidna> Lex79: oh, I was waiting for akonadi to testbuild it. I'll finish it by tomorrow
[00:21] <Lex79> JontheEchidna: ok, I'm looking kdebindings but seems really messed IoI, delta is very big, and debian testing has 4.2.2, unstable has 4.3.2, which version should I merge?  always testing or is it too old?Anyway I'm just trying, dunno if I can... :)
[00:55] <JontheEchidna> Lex79: You should probably do unstable
[00:58] <Lex79> ok I'll try
[01:36] <rgreening> where is everyone? :)
[01:36] <jjesse> hding
[01:36] <rgreening> ha
[01:54] <ScottK> Lex79: kdebindings has never had a successful merge.
[01:55] <ScottK> Lex79: I talked to Riddell about it and he thinks Debian's package now supports all the same bindings ours does, so instead a pure merge we should prefer the Debian approach and only change stuff we really have to.
[01:57] <JontheEchidna> My thoughts regarding our kdebindings package in song form: http://www.youtube.com/watch?v=e4EqjvnWfRM
[01:59] <JontheEchidna> the lyrics, when they arrive, are rather fitting
[01:59] <Lex79> ScottK: ok, It's better if I leave it to you then because you know what to do :)
[02:00] <ScottK> Lex79: Even better we'll leave it to Riddell
[02:00] <Lex79> right
[02:00] <Lex79> JontheEchidna: kdebindings in song form lol
[04:25] <Riddell> rgreening: got smb sharing done yet? :)
[04:28] <ScottK> Just a few bugs to fix yet
[04:31] <rgreening> a few... hah! I wish
[04:31] <rgreening> Riddell: I have a basic framework Im debugging... then it needs fleshing out...
[04:32] <rgreening> Riddell: get your a$$ to the bar (shtylman__ says)
[04:33] <rgreening> and its time to install cromium.. \
[04:33] <Riddell> but I'm tired!
[04:33] <rgreening> Riddell
[04:33] <rgreening> Riddell:
[04:33] <rgreening> Riddell:
[04:33] <rgreening> no your not Riddell
[04:33] <rgreening> :)
[04:34] <rgreening> I have a beer waitng for you
[04:35] <Riddell> oh well, why didn't you say so
[07:08] <Tm_T> Riddell: just noticed comments in your last blogpost, erp
[09:03] <fale> Someone is willing to test rekonq 0.3.0 on karmic? You can find it here: https://launchpad.net/~f4l3/+archive/ppa
[11:00] <apachelogger_> Sime: can one use KNotificationItem in pykde4.3?
[11:34] <dantti> apachelogger_: hey :) is do-release-upgrade a *buntu application?
[11:40] <apachelogger_> dantti: aye
[11:41] <dantti> apachelogger_: aye means yes? :P
[11:41] <apachelogger_> dantti: aye :P
[11:42] <dantti> k... :P
[11:43] <dantti> apachelogger_: so the DESKTOP env var will be set in new a kpk release so you can easly check..
[12:00] <ryanakca> .. errr... everything in X is fuzzy (hard to describe) this morning. I know it's not my monitor / video card because the problem doesn't exist in VT[1-7]... however, I haven't touched it since last night... any ideas where I should start looking?
[13:49] <JontheEchidna> Riddell, Lex: kdepim-runtime merge in bzr
[14:04] <amichair> there are some basic translations missing in some languages ("Close", "Reset", "Remove") - what to do about it?
[14:07] <amichair> (referring to software-properties, if it matters)
[14:08] <fale> Someone is willing to test rekonq 0.3.0 on karmic? You can find it here: https://launchpad.net/~f4l3/+archive/ppa
[14:11] <apachelogger_> dantti: cool, thx :)
[14:13] <ghostcube> isnt do -release-upgrade in debian too ?
[14:13] <ghostcube> if not good tool :D
[14:33] <apachelogger> ghostcube: doesnt quite matter, it certainly is unique to close-relation-debian-distros :P
[14:52] <ghostcube> apachelogger: ah ok :)
[15:17]  * ryanakca grins after loosing his wisdom teeth :D
[15:20] <ryanakca> Apart from Ayatana this afternoon, are there any Kubuntu related sessions today?
[15:25] <nixternal> ryanakca: seems one with Ayatana at the end of today
[15:57] <rgreening> Riddell: ping
[16:07] <Riddell> hi rgreening
[16:08] <rgreening> where you hiding
[16:09] <rgreening> Riddell: ^
[16:09] <rgreening> I neddz da help
[16:09] <rgreening> :)
[16:09] <rgreening> oh Mr. KDE Compiliation God
[16:10] <Riddell> rgreening: 4th floor alamo 2
[16:10] <Riddell> rgreening: I can come to you if you wish
[16:10] <rgreening> nah... I'll pop over in about 5 min or so
[16:11] <rgreening> is there a session in there now?
[16:11] <Riddell> yes but it's not terribly relevant
[16:11] <rgreening> lol
[16:12] <rgreening> ok, then if you want to ditch, I'm in the bar/lounge
[16:12] <rgreening> Riddell: ^
[16:13] <Riddell> coming
[16:14] <rgreening> ok.. I may be out front for a minute....
[16:21] <JontheEchidna> rgreening: btw, I uploaded kcm-touchpad last night. Just needs to go through the archive admin runaround now
[16:30] <ryanakca> Any merges other than https://wiki.ubuntu.com/Kubuntu/LucidKDEMerges that need doing?
[16:41] <fale> Someone is willing to test rekonq 0.3.0 on karmic? You can find it here: https://launchpad.net/~f4l3/+archive/ppa
[16:46] <ryanakca> Can someone sponsor my meta-kde merge please, dget http://packages.ryanak.ca/ubuntu/pool/main/m/meta-kde/meta-kde_55ubuntu1.dsc
[16:58] <ryanakca> fale: What should I look for?
[16:59] <fale> ryanakca: in the rekonq package?
[17:01] <ryanakca> fale: Yes, any particular spots I should test?
[17:01] <fale> ryanakca: nothing particular, only if it could go into backports ;)
[17:06] <mcas> hi
[17:19] <fale> ryanakca: have you seen it?
[17:21] <yuriy_> fale: working nicely here. never tried rekonq before, but looks like it could easily become my web browser
[17:21] <fale> yuriy_: awesome :)
[17:21] <yuriy_> as soon as they fix QtWebKit not to use 106MB (top says 23 is shared) out of the box
[17:22] <fale> yuriy_: guess that will be in qt 4.6
[17:23] <yuriy_> there is a sort of statusbar that appears in the bottom left when hovering over links but isn't there most of the time, looks kind of strange -- is that normal?
[17:25] <fale> yuriy_: say it's ''normal'' I guess is too much... but is in the official 0.3.0 too ;)
[17:26] <yuriy_> not having the statusbar all the time is kind of nice, but makes that look weird
[17:26] <yuriy_> maybe they'll come up with something
[17:27] <fale> yuriy_: I hope it too
[17:29] <cragdor> Hi All,
[17:29] <markey> with dpkg-buildpackage, how can you create an installable .deb package?
[17:29] <markey> it created an executable for me
[17:30] <markey> (sorry for noob question:)
[17:30] <cragdor> Tell me is there anyone taking the UbuntuOneMusic store forward from the kubuntu side. I have concerns that they are looking at building functionality directly into  Banshee or Rythmbox, and not looking into the bigger picture!
[17:31] <fale> markey: if you use debuild without parameters it will creates a .deb fils
[17:31] <fale> *file
[17:31] <markey> nvm, just saw it in ../
[17:31] <markey> :)
[17:31] <fale> markey: ;)
[17:31] <fale> cragdor: I guess someone will bring it to amarok, at least
[17:33] <markey> send patches :) or even better: a Merge Request
[17:33] <markey> we amarok devs love Merge Requests
[17:33] <cragdor> Well i think theres a better method since i develop middle where solutions, this should have a client that manages the local copies of music, and media players hook into it. Cutting the dependancy on a specific media player
[17:38] <\sh> markey, at least you love merge requests ;)
[17:39] <markey> oh yes, I sometimes dream about them at night
[17:40] <\sh> markey, "merging merging merging oh yeah give me the merge"? ;)
[17:40] <\sh> hach...time to go home
[17:41] <ryanakca> Also, is it worth keeping a delta for a "debian-watch-file-is-missing" lintian override? Or should I have it synced? debdiff between Debian and us: http://ryanak.ca/~ryan/kcometen4_1.0.5-1_1.0.5-1ubuntu1.debdiff
[17:47] <markey> no, more like: "Suck my Git, baby!"
[17:58] <markey> man, something is really borked with udev or so. kubuntu randomly doesn't detect my hardware
[17:58] <markey> be it USB, MTP...
[17:58] <markey> absolutely not cool
[17:59] <markey> latest Karmic with all updates
[17:59] <markey> no weird customizations, all nice and shiny
[17:59] <markey> have similar issues been reported before?
[18:15] <ryanakca> markey: I noticed that Kubuntu wasn't noticing USB thumbdrives / cds / etc when I plugged / put them in (in the recently plugged in devices plasmoid), but I think it was because either hal or dbus had died... Restarting them fixed it.
[18:15] <markey> ryanakca: what's the best way to restart them?
[18:16] <ryanakca> markey: sudo service hal restart && sudo service dbus restart
[18:16] <markey> thanks
[18:16] <markey> trying now
[18:21] <markey> hum, no dice
[18:21] <markey> that didn't do anything
[18:21] <markey> (except restarting d-bus crashed konvi
[18:35] <ryanakca> markey: Hmm... I'd file a bug against konvi in that case... Not sure what the issue might be in that case...
[18:37] <nixternal> karmic sucks!
[18:38] <nixternal> only takes me 5 to 10 times to finally log in to encrypted drives
[18:38] <nixternal> err, encrypted /home
[18:39] <markey> ryanakca: just talked to a konvi dev, it's probably because konvi listens to a screensaver thingie d-bus message
[18:39] <markey> or because it's a KUniqueApplication
[18:39] <markey> both makes sense
[18:39] <markey> anyway, this still doesn't fix my issues :)
[18:39] <markey> I'm kinda getting fed up with it
[18:39] <nixternal> you mean you just talked to Sho_ :)
[18:39] <markey> yep :)
[18:39] <tsimpson> I don't think dbus like being restarted anyway
[18:40] <markey> probably not, no
[18:40] <nixternal> dbus is a muck in karmic no matter which flavor you are using I see
[18:40] <markey> because of the whole session-ID stuff
[18:40] <tsimpson> all the "services" that were registered have no way to re-register
[18:40] <markey> anyway, restartin HAL also did nothign
[18:40] <markey> so I'm still wondering
[18:41] <markey> this whole mess started around the time the KDE 4.3.3. update came in
[18:41] <markey> before that, I never had issues with HAL
[18:41] <nixternal> ya, but there is no telling what the whole switch to upstart may have mucked up
[18:44] <Quintasan> http://imagebin.ca/view/1XjGWSnv.html <-- new amarok rocks!
[18:45] <ryanakca> markey: Does rebooting fix it?
[18:46] <markey> does it now, or are you being ironic? I've seen both ;)
[18:46] <markey> ryanakca: yeah, but then, sometimes after reboot my keyboard doesn't work. plugging it out and in again usually fixes it (but not always)
[18:46]  * ryanakca scratches his head. If that was meant for me, I don't know if it would fix it, but if it bothers you, might be worth trying out.
[18:47] <ryanakca> markey: Oh. Wierd
[18:47] <markey> it was meant for Quintasan
[18:47] <ryanakca> Ah
[18:48] <ryanakca> markey: Keyboard doesn't work... does it work in VT[1-7] and not X, or does it not work in anything (as in, Alt-Sysrq-K won't restart X when you're at the KDM screen and your keyboard isn't working...)... I'd file a bug :)
[18:48] <markey> nope
[18:48] <markey> can't even switch to VT then
[18:49] <ryanakca> Hmmm... wierd. And Alt-SysRq-K doesn't do anything either?
[18:50] <markey> no, basically the keyboard is not there (not seen as a device)
[18:55] <ScottK> Alt-SysRq-K is very hit or miss in my experiece (even if the keyboard works)
[18:56] <ryanakca> ScottK: Ah. Strange. Do you or any of the people at UDS have time to look at two merges (one of which I think can be a sync, the only interesting difference is a lintian override for a missing watch file) ?
[18:57] <ScottK> I'm not with the other Kubuntu people right now (in a session on server stuff)
[18:58] <ryanakca> ScottK: OK
[19:00] <Riddell> ryanakca: poke me in half an hour (after lunch) if you want
[19:00] <ryanakca> Riddell: OK, thanks
[19:40] <Riddell> ryanakca: what needs done?
[19:46] <Riddell> ryanakca: meta-kde uploaded
[19:55] <ryanakca> Riddell: back, sorry.
[19:56] <ryanakca> Riddell: Is it worth keeping a delta for a "debian-watch-file-is-missing" lintian override? Or should I have it synced? debdiff between Debian and us: http://ryanak.ca/~ryan/kcometen4_1.0.5-1_1.0.5-1ubuntu1.debdiff
[19:56] <ryanakca> Thanks for uploading meta-kde by the way :)
[19:56] <JontheEchidna> Riddell: while you're at it, could you look at the kdepim-runtime merge in bzr?
[19:57] <Riddell> ryanakca: I wouldn't bother
[19:58] <ryanakca> Riddell: OK, I'll request a sync
[19:58] <Riddell> JontheEchidna: k
[20:03] <JontheEchidna> thx
[20:04] <ryanakca> Could someone ack bug 485469 please
[20:07] <Riddell> JontheEchidna: can you rack down the origin of the patch in pim-runtime and update https://wiki.kubuntu.org/Kubuntu/LucidPatchReview ?
[20:07] <Riddell> s/rack/track/
[20:08] <Riddell> uploaded
[20:11] <JontheEchidna> Originated to get it out of the Settings submenu so that there wouldn't be a Settings submenu for netbook
[20:12] <JontheEchidna> I think apachelogger talked to upstream about moving it, but they were disinterested or something so we patched it
[20:18]  * ulysses__ had just seen an episode from Doctor WHo
[20:22] <fale> JontheEchidna: I have a positive review... how many ele I have to look for?
[20:22] <JontheEchidna> did they comment on the bug in karmic-backports?
[20:23] <fale> JontheEchidna: which bug?
[20:24] <JontheEchidna> presumably you filed a bug against the karmic-backports project where people can give feedback on the packages
[20:25] <fale> ehm
[20:25] <fale> ok, I'm going to filed the bug
[20:28] <fale> yuriy_: can I ask you a favor?
[20:32] <ryanakca> fale: Just ask him :)
[20:33] <fale> ryanakca: that's a good point ;)
[20:33] <fale> yuriy_: can you write, please, a couple of lines here? https://bugs.launchpad.net/karmic-backports/+bug/485479
[20:55] <debfx> bbigras: I've fixed the file selection bug in firefox-kde, package is in the build queue
[21:09] <Mamarok> Riddell: hi, you got a minute?
[21:11] <Mamarok> or whoever has an idea why Chromium doesn't use Javascript and Flash anymore, both work fine in Firefox on the same installation
[21:12] <Mamarok> strangely it works well for markey, but not for me, and I can't remember having changed any settings
[21:21] <fale> thank you yuriy :)
[21:39] <Riddell> Mamarok: I've never used chromium in my life.  shtylman__ is the chromium fanboy
[21:48] <Mamarok> ok, thanks :)
[21:52] <jussi01> Mamarok: did you change your shortcut at all? it needs the flag to enable plugins, doesnt it?
[21:53] <tsimpson> it needs a flag to _enable_ plugins o_0
[22:02] <ryanakca> I have a feeling I'll have to write a pam_time frontend for my mum (she used Vista's time control module of the parental controls quite a bit to control the amount of time my sister spent on the computer)... If I manage to write it, I wouldn't mind getting it into Kubuntu... should I write it stand alone, or should I figure out how to get it to plug into systemsettings?
[22:04] <tsimpson> all systemsettings needs to know is how to change the config, so you shouldn't have to worry about that now
[22:05] <tsimpson> once you have a settings file, then worry about it ;)
[22:06] <ryanakca> tsimpson: A settings file, as in, other than /etc/security/time.conf ?
[22:07] <tsimpson> whatever it uses
[22:07]  * tsimpson steers clear of pam at all costs
[22:07] <ryanakca> tsimpson: It already exists on a standard install I believe. I don't remember installing any pam stuff anyways.
[22:08] <Riddell> ryanakca: a kcontrol module would be better I'd say
[22:10] <ryanakca> Riddell: I'm guessing that http://developer.kde.org/documentation/other/kcm_howto.html is quite out of date (2004) ?
[22:11] <ryanakca> ... it's for C++ anyways, not what I want.
[22:13] <ryanakca> Riddell: Also, I'm guessing kcontrol modules plug into systemsettings? kcontrol doesn't appear to exist in Karmic, http://packages.ubuntu.com/search?searchon=contents&keywords=kcontrol&mode=&suite=karmic&arch=any
[22:14] <Riddell> ryanakca: anything on developer.kde.org is out of date, techbase is the replacement
[22:14] <Riddell> there's not much docs for pykde kcontrol modules, you just need to start with the template in kdebindings and use the API docs
[22:15] <Riddell> system settings replaced kcontrol
[22:15] <ryanakca> Riddell: OK
[22:15] <Riddell> but the modules are still called kcontrol modules
[22:17] <fale> what the hell happened? they putted in backports an old and uncompilable version? :S
[22:18] <fale> Riddell: I think that is you
[22:18] <fale> Riddell: was karmic3 not karmic1 to be imported
[22:18] <ryanakca> Riddell: Thanks
[22:20] <Riddell> fale: the backport is made from the latest version in lucid
[22:20] <fale> Riddell: yes, but it will never compile if you don't change what I did in karmic2 and karmic3
[22:20] <Riddell> fale: what did you change?
[22:21] <fale> the rules file and the dependences
[22:21] <Riddell> fale: can these changes go into lucid?
[22:21] <fale> Riddell: why don't streight import my version?
[22:21] <Riddell> because backports are done from the development version
[22:22] <fale> Riddell: I think thay can, but this will mean not using debhelper 7
[22:23] <ryanakca> Riddell: Are there any existing python kcontrol module I can look at?
[22:24] <Riddell> ryanakca: system-config-printer-kde
[22:24] <ryanakca> Riddell: Thanks
[22:24] <Riddell> ryanakca: also userconfig which runs as root
[22:24] <Riddell> ryanakca: running stuff as root is an extra hassle for kcontrol modules
[22:25] <Riddell> ryanakca: so it might be easier to just do it as a standalone app fir a first version
[22:25] <Riddell> fale: hmm right, it's the pesky --with kde stuff which isn't in karmic
[22:25] <ryanakca> Riddell: OK
[22:25] <fale> Riddell: pesky?
[22:26] <neversfelde> is there a freeze for merges? I am nearly finished with amarok, but I will be away for the next three weeks, so koffice still needs some time.
[22:26] <Riddell> fale: annoying.  because it means we can't just backport straight from lucid
[22:26] <Riddell> neversfelde: when is koffice 2.1 out?
[22:26] <fale> Riddell: is impossible to import from a ppa?
[22:26] <neversfelde> Riddell: the schedule says 3 weeks after rc1
[22:27] <Riddell> fale: I can do a manual upload and a manual approval, it's all possible but the assumption with backports is that it's done from the development version
[22:27] <Riddell> fale: so I'll do that
[22:27] <fale> Riddell: or, could I change the code into the bazar code?
[22:27] <fale> if yes, we can use the old system
[22:27] <fale> JontheEchidna told that was fine to use the old system in lucid
[22:28] <Riddell> fale: no let's keep lucid as it is, that's in line with debian
[22:28] <neversfelde> Riddell: correction, tagging is tomorrow
[22:28] <fale> Riddell: ok ;)
[22:28] <neversfelde> so I can do the packaging, before I have to leave
[22:29] <neversfelde> probably I can do the merge on my vacation, but I am not sure
[22:29] <Riddell> neversfelde: naw if it's out while you're away someone else can do it
[22:30] <neversfelde> Riddell: I meant the packaging for karmic, I can do it tomorrow
[22:30] <neversfelde> will upload it to ninja ppa
[22:31] <neversfelde> have to leave on sundy, so that should be enough time, but I doubt that debian will have packages ready before
[22:32] <neversfelde> s/sundy/sunday
[22:34] <neversfelde> simple lucid update should be no problem, too. The merge would have to wait until I am back, or someone else has to do it
[22:39] <fale> Riddell: do you plan to do it today?
[22:41] <Riddell> fale: uploaded, waiting for launchpad to do its thing so I can approve
[22:41] <fale> Riddell: I see ;)
[22:41] <fale> Riddell: to approve the backports you have to be motu?
[22:43] <Riddell> fale: backport requests are approved by the backports team
[22:43] <Riddell> manual uploads are approved by an archive admin
[22:43] <fale> I see
[22:46] <apachelogger> JontheEchidna: patch?
[22:46] <JontheEchidna> apachelogger: move akonadiconsole out of the Settings subfolder
[22:46] <JontheEchidna> or to the settings folder, something like that
[22:47] <apachelogger> right
[22:47] <apachelogger> JontheEchidna: for the time being upstream thinks it is sensible to have that beast installed, considering the unmature nature of akonadi at this point
[22:48] <apachelogger> it was discussed on the debian list for reference
[22:48] <JontheEchidna> anything we can do in the way of upstreaming?
[22:50] <Riddell> fale: approved, hopfully it'll compile soon, thanks for the backport, I know it's hassle but it'll be less hassle next time :)
[22:51] <fale> Riddell: cool :)
[22:51] <fale> Riddell: I think is normal that the first time is like that... I used ~1 month to understand a little bit more how to make packages ;)
[23:07] <fale> Riddell: news?
[23:09] <Riddell> fale: hmm?
[23:09] <fale> Riddell: about the packages ;)
[23:10] <ryanakca> Hehe, my dad likes Kubuntu so much that he's converted a coworker after two weeks of using it :)
[23:11] <fale> ryanakca: that's cool :)
[23:15] <dpm> nixternal: hi, we've got a section on improving documentation translation at #ubuntu-uds-alamo1, if you've got some minutes
[23:20] <maco> hey wanna do a kubuntu dinner tonight?
[23:21] <maco> im running to Best Buy with jussi01 to pick up a DVD but we'll be back by 7. wanna go somewhere after that?
[23:21] <maco> (and then watch the DVD, because a lot of us <3 Doctor Who and this will be Whovian)
[23:21] <maco> Riddell, rgreening, agateau, shtylman__, ScottK ^
[23:24] <agateau> maco: count me in
[23:25] <agateau> maco: Actually I could use a trip to Best Buy, if they sell cellphone batteries
[23:25] <maco> agateau: probably depends on the phone model, but worth a try
[23:26] <maco> they often have a verizon or at&t or whatever store inside
[23:32] <neversfelde> Riddell: is there an overview about all the new specs you wrote?
[23:37] <rgreening> maco: sounds interesting... Torchwood?
[23:37] <maco> aye
[23:37] <rgreening> wiked
[23:37] <maco> Children of Earth mini-series
[23:38] <rgreening> that was da bomb
[23:38] <Riddell> neversfelde: linked from my blog
[23:38] <maco> i was gonna bring dtchen's copy but forgot it. i figure i need a copy of my own anyway
[23:38] <txwikinger> agateau: Radio Shack is probably a good place
[23:38] <rgreening> tru dat
[23:40] <neversfelde> Riddell: thx
[23:41] <neversfelde> Service Temporarily Unavailable
[23:41] <neversfelde> hehe
[23:42] <neversfelde> guess taht needs to wait till tomorrow


[00:18] <sgclark> Riddell: nasty message on our facebook page, no clue what they are talking about. Unless it is the systray stuff.
[00:20] <sgclark> Or actually this is probably a case for council members to deal with.
[00:23] <valorie> ewww
[00:23] <valorie> although I dunno if I'm an admin
[00:25] <valorie> I don't see anything nasty, sgclark
[00:25] <valorie> can you give me a link?
[00:27] <valorie> off to dinner for now
[00:35] <sgclark> valorie: it is in the messages. Not public. Have to be a pages admin I think.
[00:35] <sgclark> which council outta be if not already
[01:52] <valorie> ok
[03:25] <valorie> thanks for telling me about that, Scarlett. I've replied
[06:29] <soee> good morning
[07:28] <lordievader> Good morning.
[07:32] <sitter> Riddell: kdepim-runtime was built against kdepimlibs .0 and possibly because of that fails a test
[07:33] <sitter> same for kdepim. kdepim also needs its symbols refreshed with armhf
[07:40]  * yofel wonders what happened to our versioned build-deps
[07:54] <Riddell> sitter: hmm ok, I'll reupload those
[07:55] <Riddell> sitter: what's wrong with mgmt_tools that kubuntu-ci keeps nudging me about? http://kci.pangea.pub/job/mgmt_tooling/765/console
[07:55] <sitter> shadeslayer needs to fix a test
[09:13] <Riddell> sitter: kubuntu-notification-helper  kubuntu-driver-manager kubuntu-debug-installer are still not compiled, are you looking into that?
[09:16] <sitter> wut
[09:17] <sitter> oh ffs
[09:17] <sitter> I HATE MAKE SO MUCH
[09:25] <pursuivant> kubuntu-notification-helper (master) b76f921 * Harald Sitter: debian (2 files)
[09:25] <pursuivant> Fix rules. "Make - Like Perl, but Worse"
[09:25] <pursuivant> http://commits.kde.org/kubuntu-notification-helper/b76f92121ecd9eae5e1bd20418fe96187ad5ba9e
[09:26] <pursuivant> kubuntu-driver-kcm (master) 15.04ubuntu3-10-gcda4cdc * Harald Sitter: debian (2 files)
[09:26] <pursuivant> Fix rules. "Make - Like Perl, but Worse"
[09:26] <pursuivant> http://commits.kde.org/kubuntu-driver-kcm/cda4cdca93cf2655ee449223ede201b4d3508f75
[09:27] <pursuivant> kubuntu-debug-installer (master) 24f4430 * Harald Sitter: debian (2 files)
[09:27] <pursuivant> Fix rules.  I care about the blockage
[09:32] <Riddell> sitter: why does to cause blocking?
[09:33] <sitter> Riddell: because jobs depend on one another and you cannot build one while one of its dependecies is building as then it would install a -data from the new version because amd64 is already done but then fail becuase i386 is not done building and so the -data is in fact not instalalble making the build fail
[09:35] <Riddell> sitter: I get that but I think I don't get what the mgmt_docker one is
[09:36] <sitter> Riddell: the job underneath all other jobs updating the docker containers
[09:39] <Riddell> it's where the magic happens!
[09:39] <Riddell> ok sorry for the no nocis
[10:14] <clivejo> does anyone know how to fix cant find FindICU.cmake error message?
[11:05] <BluesKaj> 'Morning folks
[11:31] <sitter> Riddell: do you have a vivid ISO lying around and can test something?
[11:31] <Riddell> sitter: aye, what's up?
[11:32] <sitter> start iso. go to live. start installer. switch to german. screenshot of that please
[11:32] <sitter> the entire spacing in ubiquity is a joke
[11:33] <sitter> http://i.imgur.com/wVGdUnU.jpg that's the best worst case I can get at without too much change
[11:34] <sitter> that's still pretty shit as the items are stuck together with multiline and too close too border for long words
[11:34] <sitter> ARGH. actually that is also still broken for some languages
[11:51]  * Riddell starts VM
[11:54] <Riddell> sitter: http://embra.edinburghlinux.co.uk/~jr/tmp/ubiquity.png
[11:54] <Riddell> all looks good there
[11:55] <Riddell> I'm not convinced of the lighter grey in the new colour scheme, lacks contrast
[11:56] <sitter> Riddell: second to last entry has an n at the end
[11:56] <sitter> that n is partially cut off
[11:57] <sitter> Riddell: can you shrink the size of that window?
[11:57] <Riddell> sitter: http://embra.edinburghlinux.co.uk/~jr/tmp/ubiquity1.png  as small as it goes
[11:57] <sitter> the weird thing is I can shrink mine lower at which point the wordwrap breaks on the 4th entry in the list
[11:58] <sitter> Riddell: ok thanks
[11:59] <sitter> http://i.imgur.com/U0S2hnr.jpg
[12:00] <sitter> which is still less heigh than what I have
[12:02] <sitter> the weird thing about this is that there were no spacing changes
[12:02] <sitter> only thing that changed is quit moved
[12:03] <sitter> oh and the logo
[12:03] <sitter> but the logo is minimum so that shouldn't shrink the steps layout
[12:03] <sitter> it's all so very terrible
[12:03] <sitter> Riddell: I take it rewriting the thing in qml before release is not a desired solution? :P
[12:04] <Riddell> sitter: I fear this might break some freeze or other
[12:04] <sitter> mh
[12:04] <sitter> so
[12:05] <sitter> it's the logo that breaks it!
[12:05] <Riddell> nasty branding, there's a reason we didn't put any in ubiquity
[12:05] <Riddell> although the reason probably wasn't to do with layout breaking
[12:05] <sitter> but... there either is a hardcoded height somewhere or it is incidentially large enough because the highest height of the wizard pages is just heigh enough to not let me shrink so it breaks
[12:06] <sitter> so that likely is also broken with hidpi, good thing qt4 doesn't support hidpi xD
[12:31] <sitter> barely not too big on 1024x768 with some languages
[12:50] <sitter> Riddell: https://code.launchpad.net/~apachelogger/ubiquity/fix-squished-text/+merge/272738
[12:58] <Riddell> sitter: ❤
[13:25] <sitter> im-config (I think) is weirdly intercepting keyboard control btw
[13:25] <sitter> not sure I like that
[13:25] <sitter> incredibly hard to switch from de_DE keyboard to en_US
[13:25] <sitter> or maybe I am too stupid
[13:27] <Riddell> it does seem to have reappeared on images recently
[13:28] <sitter> it's on the CI iso for some reason
[13:28] <sitter> at least I think that is im-config
[13:38] <Riddell> yes I noticed it on the beta, panel applet
[14:46] <clivejo> Riddell: do you know how to fix a cant find FindICU.cmake error message?
[14:46] <clivejo> Im trying to package kdb, it build locally but wont build in pbuilder
[14:47] <clivejo> when I do a dpkg -S FindICU.cmake it doesnt find anything on the local system
[14:51] <Riddell> installing libicu-dev at a guess
[14:51] <Riddell> if it can't find FindICU I think cmake falls back to general ways of looking for a library
[14:53] <clivejo> and whats the traditional way?
[14:54] <Riddell> well that might be deliberate, have you tried it?
[14:54] <clivejo> trying it now
[14:54] <Riddell> having said that FindICU.cmake does exist in calligra source code
[14:55] <Riddell> so maybe it just wasn't copied to whatever you're compiling now
[14:55] <clivejo> kdb
[14:55] <TJ-> If it were shipped in the distro it'd likely be in 'extra-cmake-modules' - but it isn't there
[14:56] <clivejo> I wonder is it now a separate package too
[14:56] <clivejo> like kdb, kreport and kproperty
[15:26] <Riddell> clivejo: you're probably the first person to try to package it from any distro, you may well find bugs like that, patches can be made for upstream
[15:31] <clivejo> :(
[15:31] <clivejo> and havent a clue how to fix them
[15:33] <Riddell> clivejo: add that  FindICU.cmake into it :)
[15:34] <clivejo> easy for you to say!
[15:34] <TJ-> clivejo: are those all packages that need to build-depend on FindICU.cmake? If so it might be useful to add FindICU.cmake to extra-cmake-modules, then on the packages that require it, in debian/control, add a Build-Depends: extra-cmake-modules (>= X.Y.Z) where X.Y.Z is the package version containing FinICU.cmake
[15:35] <clivejo> TJ-: those are the deps for calligra
[15:35] <clivejo> Im trying to package kdb, but its failing in pbuilder
[15:36] <TJ-> clivejo: So, calligra would need a Build-Depends that pulls in the package containing FindICU.cmake
[15:36] <clivejo> yet it works when building on local machine
[15:36] <TJ-> clivejo: probably because you have the additional build-dependency available on the host. That's why we use pbuilder, to catch missing build-depends
[15:37] <yofel> clivejo: did you at least add libicu-dev to the build-deps?
[15:38] <clivejo> yofel: yes, its just errored out, but Im a little further now
[15:39] <clivejo> wants db files
[15:39] <yofel> ok, so if it doesn't fail on the same thing, we probably don't need FindICU
[15:42] <clivejo> it passed FindICU this time
[15:42] <clivejo> failing on MSQL, xbase etc dev files
[15:45] <clivejo> Riddell: did you test kamoso?
[15:49] <clivejo> anyone know off hand what the postgres dev package is called?
[15:50] <clivejo> postgresql-server-dev-all ?
[15:50] <TJ-> clivejo: looks like it: "apt-cache showsrc postgresql-common | grep '^Binary:' "
[15:53] <clivejo> I generated a package called kreport, but when I use it as a build dep the package installed is saying its a virtual package and wont install it?
[15:53] <clivejo> its in my PPA
[15:55] <yofel> well, kreport FTBFS
[15:59] <clivejo> good lord
[15:59] <clivejo> it built in pbuilder
[15:59] <yofel> does the PPA config match your pbuilder config?
[16:00] <clivejo> what is it even failing over?
[16:00] <yofel> that's a good question actually o.O
[16:01] <clivejo> LOL
[16:01] <clivejo> now kdb is doing the same
[16:01] <clivejo> Could not find   "/tmp/buildd/kdb-2.96.0+git20150928/obj-x86_64-linux-gnu/src/KDbResult.h"
[16:02] <yofel> bbl
[16:03] <clivejo> I think Im going to give up on this, I have no idea what the error message means!
[16:04] <clivejo> and I should be sawing sticks
[16:09] <TJ-> I only see a "src/KDbResult.shared.h"
[17:35] <sgclark> oh. looks like rsibreak used to reside in svn. I presume we want that in git? I need a refresher on the new app in git process.
[17:35] <sgclark> Riddell: ^
[17:45] <sgclark> nm sorted
[18:20] <soee> krunner works for you ?
[18:29] <sgclark> for who?
[18:29] <sgclark> works for me
[19:18] <Riddell> clivejo: yep kamoso worked good for me
[19:18] <Riddell> sgclark: did you work it out?
[19:18] <sgclark> yep. just need to bug sitter for ci
[19:18] <sgclark> putting it in staging
[19:19] <sgclark> as we speak
[19:20] <Riddell> sgclark: anything we want to FFe into wily?
[19:20] <sgclark> um no clue, it is an app that tells you to stop working. Not sure who that is important to lol
[19:22] <clivejo> Riddell sgclark would you have a wee look at this, give me a clue as to why its failing? https://launchpadlibrarian.net/218985877/buildlog_ubuntu-wily-amd64.kreport_2.96.1%2Bgit20150927-0ubuntu1~ubuntu15.10~ppa1_BUILDING.txt.gz
[19:24] <Riddell> KDbGenerateHeaders.cmake wants obj-x86_64-linux-gnu/src/KReportLineStyle.h I think it says
[19:24] <Riddell> so it's probably a bug in a cmake file somewhere
[19:25] <Riddell> "Creating shared data class in KReportLineStyle.h from common/KReportLineStyle.shared.h" it says a few lines above
[19:25] <Riddell> so that file is made, where is it made?
[19:25] <Riddell> presumably not where cmake is looking for it
[19:25] <clivejo> a header file?
[19:25] <Riddell> so tell whoever wrote KDbGenerateHeaders.cmake to fix it to look in the right place
[19:25] <Riddell> yes
[19:26] <sgclark> Riddell: anything else that still needs work?
[19:29] <clivejo> Riddell: but why is it build on my system?
[19:30] <sgclark> https://launchpad.net/%7Ekubuntu-ppa/+archive/ubuntu/staging-kdeapplications/+sourcepub/5442588/+listing-archive-extra
[19:30] <sgclark> please test rsibreak !testers
[19:30] <sgclark> !tester
[19:30] <sgclark> boo
[19:30] <sgclark> !testers
[19:30] <sgclark> ^^
[19:31] <sgclark> works for me.
[19:32] <Riddell> clivejo: dunno do you have KReportLineStyle.h somewhere?
[19:32] <Riddell> sgclark: the whole world could do with being backported to vivid
[19:32] <clivejo> Riddell: yup - /home/clivejo/project/kreport/kreport/obj-x86_64-linux-gnu/src
[19:33] <clivejo> ahhh
[19:33] <clivejo> path
[19:33] <clivejo> its looking in kreport-2.96.1+git20150927
[19:34] <sgclark> world eh? that it? Hmm.
[19:41] <Riddell> sgclark: I expect kci has stuff that needs symbols updated, I know kdepim* did earlier today
[19:41] <ahoneybun> damn clivejo your on fire, https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-kdeapplications/
[19:42] <Riddell> sgclark: this could do with a review to see if any of it is still relevant https://lists.ubuntu.com/archives/kubuntu-devel/2015-August/009849.html
[19:42] <Riddell> sgclark: and of course trello always has ideas
[19:42] <sgclark> I will do backports
[19:43] <clivejo> ahoneybun: I just staged and uploaded them
[19:43] <ahoneybun> right
[19:51] <clivejo> Riddell: LP is rejecting my upload now, saying "File kreport_2.96.1+git20150927.orig.tar.gz already exists in Wily, but uploaded version has different contents."
[19:57] <BluesKaj> added the staging ppa , installing 43 upgrades ... will report back later
[20:00] <soee> sgclark, Riddell: rsibreak install fine, runs fine, configuration fors fine :)
[20:00] <soee> *installs
[20:00] <sgclark> ty
[20:00] <Riddell> clivejo: well does it?
[20:01] <clivejo> Ive had to rename it
[20:01] <clivejo> kreport_2.96.1+git20150928
[20:01] <clivejo> instead of 27
[20:01]  * soee would liek to chabe some nice breeze style icon in ysstray for rsibreak
[20:01] <sgclark> hmm yeah.
[20:02] <sgclark> guess vdg needs bugging
[20:02] <clivejo> Riddell: nope, wont build on LP
[20:02] <soee> sgclark: i'll post an issue for breeze theme @github
[20:03] <sgclark> soee: ty
[20:03] <clivejo> Riddell: but still builds fine locally
[20:04] <soee> sgclark: it has been ported to QT5 right ?
[20:04] <sgclark> soee: yep this was the initial port
[20:04] <clivejo> I dunno, this is driving me crazy
[20:06] <Riddell> clivejo: what's up now?
[20:06] <clivejo> still cant find that file
[20:07] <soee> sgclark: https://github.com/NitruxSA/breeze-icon-theme/issues/285
[20:08] <BluesKaj> ok I've upgraded the packages that were in the staging ppa , should I comment the debs now?
[20:08] <sgclark> comment the debs?
[20:09] <soee> Riddell: are there any chances to have Rsibreak as a part of apps ?
[20:11] <BluesKaj> sgclark,  yes
[20:11] <sgclark> sorry I dont know what you mean
[20:12] <BluesKaj> the staging ppa debs
[20:12] <Riddell> soee: hmm? that's a decison of KDE and the maintainer.  currently it's in extragear
[20:12] <BluesKaj> in the sources list
[20:12] <sgclark> oh yes BluesKaj
[20:12] <BluesKaj> ok thanks sgclark
[20:13] <sgclark> Riddell: oh I thought it was an application. may need moved in debian git
[20:16] <Riddell> sgclark: a simple mv command should work fine
[20:17] <sgclark> where would extragear go?
[20:23] <valorie> sgclark: thanks for packaging rsibreak!
[20:23] <sgclark> np
[20:24] <valorie> Albert brought it back from life-support
[21:34] <pursuivant> muon (master) v5.4.0-39-ga820e58 * andreas kainz: notifier/plasmoid/metadata.desktop
[21:34] <pursuivant> Applet: Add breeze icon for muon applet icon
[21:34] <pursuivant> http://commits.kde.org/muon/a820e58aad2b54a865e87e7a5fa5bdcafabd5c7d
[21:59] <sgclark> ugh
[22:41] <Riddell> uh oh, what's up kubuntu-ci?
[22:42] <sgclark> this is a nightnare. not sure backports is something I can fight with
[22:43] <sgclark> well I can, but time is an issue
[22:43] <shadeslayer> there be conflict
[22:43] <sgclark> yah think?
[22:43] <shadeslayer> look it's fixed
[22:43] <sgclark> pft yeah attica is now
[22:43] <shadeslayer> :)
[22:43]  * shadeslayer has a headache, heading to bed
[22:43] <shadeslayer> night
[22:44] <sgclark> ecm is next. then I am shoving backports back into a corner to be ignored. don't have time for this.
[22:44] <Riddell> oh is it not liking merging from the vivid branches?
[22:45] <sgclark> conflict every one, it is completely magling the changlogs and I don't know how to stop that
[22:45] <sgclark> mangling
[23:13] <sgclark> ahh nm, forgot about harolds script. That really needs to be with the automation tools


[10:54] <wyoung> .o/
[10:54] <wyoung> I would like to join ubuntu but it looks like I am still banned
[13:11] <wyoung> .o/
[13:11] <wyoung> I'll try again tomorrow then, good night all!
[16:41] <hggdh> wyoung: yes, you are still banned. We will need to chat for us to lift this ban. You will have to give us *very* good reasoning for that to happen, given the amount of times we have already done this.
[16:42] <hggdh> wyoung: a priori, I am against...
[16:42] <hggdh> wyoung: and you know you should not idle here


[01:07] <bluesabre> ochosi: yes, pretty sure xfpm 1.6 is going to be included
[01:07] <bluesabre> I think Unit193's concerns have been resolved
[05:29] <flocculant> ochosi: ack
[05:31] <flocculant> ochosi: while I am more than happy to test it doesn't explode - nothing here to be able to test lid closes etc
[08:03] <ochosi> flocculant: yeah sure, just basic testing is ok too
[08:46] <ochosi> wb Unit193
[10:38] <bluesabre> Unit193: any more concerns with xfpm 1.6.x?
[16:52] <Unit193> Thanks.
[16:53] <Unit193> bluesabre: Not really used it since, certainly not the new one.
[19:18] <flocculant> ochosi: you know tooltip on power plugin says Computer on a dekstop?
[19:24] <flocculant> ochosi: also not sure when this occurred but whisker plugin icon appears to have shrunk
[20:55] <ochosi> flocculant: it always said "Computer" afaik. also doesn't seem wrong ;)
[20:56] <ochosi> it should say something else if the display device (aka the device shown in the panel) is e.g. a bluetooth mouse
[20:57] <ochosi> indeed, surprising (whiskermenu)
[20:57] <ochosi> i can check, i see the same here now, seems to have happened in a recent release
[20:59] <ochosi> seems whiskermenu changed something, would have to check the code though
[20:59] <ochosi> so not greybird's fault as far as i can tell


[02:11] <mhall119> munz:
[02:21] <munz_> hey mhall119 , i read in 11.10 no more "classic mode"
[02:21] <munz_> is this for sure?
[02:22] <munz_> i know you still could install gnome but just was a little shocked
[02:22] <munz_> how do you feel?
[02:52] <mhall119> munz: by 11.10, Ubuntu will likely be using Gnome 3, which I believe will also be dropping "classic mode"
[02:53] <munz_> oh, ok..guess i should look at gnome3
[02:55] <munz_> thx :)
[03:12] <mhall119> Gnome 3 has Gnome SHell
[03:12] <mhall119> if you want the "classic' 2 panel desktop, you might look into Xfce
[03:41] <munz_> cool, thx
[03:42] <munz_> my biggest thing is the ability to configure the layout, i like to have all my panels autohide and use cairo dock etc
[03:44] <munz_> im giving unity a fair shot now
[03:45] <munz_> just curious as to where everything is going
[03:45] <crashsystems> munz_: check out http://www.ubuntugeek.com/list-of-ubuntu-unity-keyboard-shortcuts.html
[03:46] <crashsystems> also, a fully transparent top panel with a dark background is great.
[03:46] <munz_> cool, been using the shortcuts, has actually helped me to like it
[03:47] <munz_> the transparent top panel sounds cool
[03:47] <crashsystems> this is what my desktop currently looks like: http://i.imgur.com/o3DRo.jpg
[03:48] <munz_> that looks nice :
[03:48] <munz_> :)
[03:49] <crashsystems> I'll probably replace the background with some of my own photography once I get my new camera.
[03:49]  * crashsystems eagerly awaits his tax return
[03:49] <munz_> :)
[03:50] <munz_> where is the panel config?
[03:50] <crashsystems> look up the unity compiz plugin in ccsm
[03:50] <crashsystems> or if you have ccsm installed, hit alt-f2 then type about:config
[03:51] <munz_> ok
[12:25] <mhall119> oh sweet, unity alt-f2 has an about:config?
[12:27] <munz_> yes :)
[13:02] <mhall119> nice
[13:16] <munz_werk__> yea, i like to change stuff
[14:56] <zoopster> munz_werk, itnet7 we're ramping up for a balloon launch the afternoon of 29 April for the launch...we'll have more info later next week.
[15:14] <DammitJim> man lirc and xbmc was kicking my butt over the weekend!
[16:49] <mhall119> 11:47 < dholbach> https://wiki.ubuntu.com/UbuntuAppDeveloperWeek starting in 15 minutes  in #ubuntu-classroom
[18:10] <munz_werk> zoopster, cool, looking foward to it :)
[21:49] <dorgan> so is gnome 3 in ubuntu 11.04?
[21:50] <dorgan> I've had my head in the sand(work) since the new year now and havent been following it
[22:10] <mhall119> dorgan: it'll be in a PPA for 11.04
[22:10] <dorgan> oh did they decide not to add it at all..because of unity?
[22:17] <crashsystems> it was released a few days ago. thats a bit too late for it to make it into a release that is coming out in less than two weeks.
[22:35] <dorgan> ahh ok...
[22:35] <dorgan> time to go home


[01:54] <bigjools_> it's so much quieter here without thumper around
[01:55] <davecheney> too quiet ...
[03:36] <bigjools> davecheney: I am putting some logger.Infof() calls to debug stuff but they are not appearing, do I need to initialise anything first?
[03:41] <davecheney> bigjools: shouldn't
[03:41] <bigjools> oh ffs
[03:42] <davecheney> but from memory unless you pass -v, then you get nothing
[03:42] <bigjools> I just saw that I need a -v
[03:42] <davecheney> axw will know
[03:42] <bigjools> works with -v
[03:42] <davecheney> yeah, this is fucked
[03:42] <davecheney> he's fixing it
[03:42] <bigjools> good man
[03:42] <davecheney> in our defense, we inhertied this madness from pyjuju
[03:42] <davecheney> i don't know if that is the kind of defence that will stand up in court
[03:43] <axw> yeah just waiting for thumper to ready his changes
[03:43] <axw> it's a bit messy
[03:43] <davecheney> 'yes your honor, I saw someone else brutally murdered, so I figured it was ok '
[03:45] <bigjools> one day, juju will evolve the perfect provider interface
[05:48]  * bigjools juju bootstraps an azure environment and deploys juju-gui on it
[06:21] <axw> bigjools: I'm looking into adding instance-specific state to juju status. Do you know if MAAS provides a way of getting the current state of a machine?
[06:22] <bigjools> axw: one  sec
[06:26] <bigjools> axw: the nearest thing is that api lets you query all allocated nodes which returns quite detailed info for each node.
[06:26] <bigjools> so depends on what state you want?
[06:26] <axw> I don't know :)  I guess I'd like to see what's available and work from there
[06:26] <axw> can you point me to some docs/code?
[06:29] <axw> bigjools: I'm after something comparable to gwacl.HostedServiceDescriptor.Status for Azure
[06:30] <bigjools> jtv1: can you remember if the maas api will return json for a single node if we GET its URL?
[06:31] <jtv1> bigjools: IIRC it does.
[06:32] <bigjools> axw: ok so there's a status on the json that gets returned
[06:32] <bigjools> if you look in the maas source tree at the file src/maasserver/enum.py check out the NODE_STATUS enum
[06:32] <axw> bigjools: cool, thanks
[06:33] <bigjools> axw: if juju knows about it, it'll never see anything other than "reserved" though
[06:33] <axw> ah
[06:33] <bigjools> errr allocated I mean
[06:34] <bigjools> maas does not track the status of anything after the node gets given to a user
[06:34] <axw> bigjools: okey dokey. sounds like it mightn't be useful to add at all then
[06:34] <bigjools> so there's no way of knowing whether it's installing, powering up etc
[06:35] <bigjools> yeah
[07:39] <rogpeppe> mornin' all
[07:43] <axw> rogpeppe: morning
[07:43] <rogpeppe> axw: hiya
[07:54]  * axw wonders how much lxc testing his laptop can take before carking it
[08:55] <dimitern> rogpeppe: ping
[08:55] <rogpeppe> dimitern: pong
[08:56] <dimitern> rogpeppe: hey, morning!
[08:56] <dimitern> rogpeppe: did you merge the agent entity stuff already?
[08:56] <rogpeppe> dimitern: yeah
[08:56] <dimitern> rogpeppe: cool, i'll take a look then
[08:59] <dimitern> rogpeppe: so AgentEntity will now need StatusSetter and Watcher(?)
[09:00] <rogpeppe> dimitern: seems reasonable
[09:00] <dimitern> rogpeppe: how should I call the interface that has Entiy.Watch() ?
[09:01] <dimitern> rogpeppe: and I also need EnsureDeader
[09:03] <rogpeppe> dimitern: ha, you can't have EntityWatcher.
[09:04] <dimitern> rogpeppe: exactly
[09:04] <dimitern> rogpeppe: Watchable?
[09:04]  * rogpeppe thinks
[09:05] <dimitern> rogpeppe: WatchEntiter ?:)
[09:06] <rogpeppe> dimitern: i've already mentally rejected that :-)
[09:06] <dimitern> rogpeppe: yeah
[09:07] <rogpeppe> dimitern: EWatcher?
[09:07] <rogpeppe> dimitern: EntityWatcherInterface?
[09:08] <dimitern> rogpeppe: AgentEntityWatcher ?
[09:08] <rogpeppe> dimitern: thing is, it's not specific to agent entities
[09:08] <dimitern> rogpeppe: why? i think it is
[09:08] <rogpeppe> dimitern: it applies to anything that has Watch() *NotifyWatcher
[09:08] <rogpeppe> dimitern: e.g. Service
[09:09] <rogpeppe> dimitern: but... maybe that's ok
[09:09] <dimitern> rogpeppe: but a service is also managed by some agent after all
[09:10] <rogpeppe> dimitern: really? i don't think so.
[09:10] <dimitern> rogpeppe: well the uniter for example manages services inside the unit agent
[09:10] <rogpeppe> dimitern: it manages units *of* a service
[09:10] <rogpeppe> dimitern: well, one unit of a service
[09:11] <rogpeppe> dimitern: the service itself has no agent
[09:11] <dimitern> rogpeppe: yeah, true
[09:11] <dimitern> rogpeppe: but I don't think we'll need an interface for that
[09:11] <dimitern> rogpeppe: it's about reusing common code for agents
[09:11] <rogpeppe> dimitern: but still, the reason we're defining the interface is for AgentEntity, so i'm ok with calling it AgentEntityWatcher
[09:12] <dimitern> rogpeppe: there'll be a WatchService API call in the uniter
[09:12] <dimitern> rogpeppe: ok, AgentEntityWatcher then
[09:12] <rogpeppe> dimitern: +
[09:12] <rogpeppe> 1
[09:27] <sidnei> here's my attempt at fixing https://bugs.launchpad.net/juju-core/+bug/1203816 https://codereview.appspot.com/12143043
[09:27] <_mup_> Bug #1203816: local provider should support use of local proxy <juju-core:Triaged> <https://launchpad.net/bugs/1203816>
[09:40] <dimitern> rogpeppe: you haven't changed getAuthFuncs to use method expressions yet?
[09:41] <rogpeppe> dimitern: no, i still need another LGTM on that CL
[09:41] <dimitern> rogpeppe: ah, ok
[09:42] <rogpeppe> dimitern: i'm also looking for reviews of https://codereview.appspot.com/12361043/ (mgz?) and https://codereview.appspot.com/12352044/
[09:45] <dimitern> rogpeppe: will take a look in a bit
[10:03]  * thumper waves from the IOM
[10:04] <jamespage> davecheney, which release of juju-core should I be uploading to saucy?
[10:05] <dimitern> thumper: hey, how is it going there?
[10:06] <thumper> good so far, going through everyone's demos
[10:06] <thumper> also, raining
[10:06] <dimitern> :) cool
[10:08] <mgz> jamespage: 1.12 I believe
[10:08] <jamespage> mgz, ack - thats what I thought
[10:15] <davecheney> jamespage: correct
[10:32] <jamespage> davecheney, great -thanks for confirming - working that now
[10:32] <davecheney> jamespage: thanks mate
[10:32] <davecheney> this is the version we talked about in Oakland
[10:32] <davecheney> ie, the one we're hoping to feed into backports
[10:34] <dimitern> rogpeppe: one review done, i'm on your second CL now
[10:34] <dimitern> rogpeppe: can you take a look at https://codereview.appspot.com/12443044/ in the mean time?
[10:35] <rogpeppe> davecheney: i'd be interested in your input on  https://codereview.appspot.com/12361043/ too, please
[10:36] <rogpeppe> dimitern: looking
[10:36] <dimitern> rogpeppe: second review done as well
[10:37] <rogpeppe> dimitern: i don't know if it's a nice catch until we get a lack of intermittent test failures for that test :-)
[10:37] <rogpeppe> dimitern: do you know if it had a bug report, BTW? i couldn't find one
[10:41] <dimitern> rogpeppe: which test failed?
[10:41] <davecheney> rogpeppe: i saw that
[10:41] <rogpeppe> dimitern: MachineSuite.TestWatchMachine
[10:41] <davecheney> where is the change to the README to explain how to use it ?
[10:41] <dimitern> rogpeppe: no, I don't think there's a bug for it
[10:41] <dimitern> rogpeppe: just checked
[10:42] <rogpeppe> davecheney: currently we're just putting it into the tree. mgz is going to change the bot to use it; then i plan to change godeps so it can use it
[10:43] <davecheney> rogpeppe: where is godeps ?
[10:43] <rogpeppe> davecheney: go get launchpad.net/godeps
[10:46] <dimitern> sidnei: you've got a review
[10:47] <sidnei> dimitern: lovely. i might be doing a few more changes, during testing i noticed the proxy is set up too late, talking with smoser about a proper fix
[10:47] <jamespage> davecheney, do you happen to know what happening re upgrade from pyjuju->juju-core
[10:47] <jamespage> first upgrade break:
[10:47] <jamespage> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1200878
[10:47] <_mup_> Bug #1200878: Upgrade breaks existing pyjuju deployment <apport-collected> <regression-release> <saucy> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1200878>
[10:47] <dimitern> sidnei: I see, ok
[10:52] <dimitern> oh boy.. EnsureDeaderer
[10:53] <dimitern> or maybe DeathEnsurerer :)
[10:55] <rogpeppe> dimitern: DeadEnsurer?
[10:56] <dimitern> rogpeppe: that's for state?
[10:56] <rogpeppe> dimitern: is there a problem with changing the Machines field to Entities in the Machine.SetStatus call, BTW? i'm concerned about backward incompatibility.
[10:56] <rogpeppe> dimitern: yeah
[10:57] <dimitern> rogpeppe: that's why I added DEPRECATE(v1.14) to it
[10:57] <dimitern> rogpeppe: to the older struct
[10:57] <rogpeppe> dimitern: ah, ok
[10:57] <rogpeppe> dimitern: cool
[10:58] <dimitern> rogpeppe: ok i'll go with DeadEnsurer
[11:00] <sidnei> dimitern: indeed, the AddScripts was supposed to be a pre-req, wasn't merged yet. i'll submit it.
[11:01] <jam> just saying a quick hello to everyone. In a meeting, but back at work after vacation.
[11:01] <dimitern> sidnei: ok; you might run into conflicts with this CL afte the prereq lands
[11:01] <dimitern> jam: heyhey
[11:01] <sidnei> dimitern: in codereview? because bzr should handle it fine.
[11:03] <rogpeppe> dimitern: i'm not sure how your changes preserve API backward compatibility
[11:03] <dimitern> sidnei: ah, ok then; no, codereview doesn't matter - it's a bzr matter anyway
[11:04] <dimitern> rogpeppe: do you propose to have handling for both MachineSetStatus and SetStatus for compatibility?
[11:05] <rogpeppe> dimitern: how would that help?
[11:06] <dimitern> rogpeppe: it'll take both types of args
[11:06] <dimitern> rogpeppe: (machiner.SetStatus)
[11:07]  * dimitern fwiw i think even considering backwards compatibility with the API at this point is ridiculous
[11:08] <rogpeppe> dimitern: it's something that we need to consider
[11:08] <rogpeppe> dimitern: if something updates the API server but not one of the clients, then this change will break the installation
[11:08] <jam> dimitern: my personal feeling, you don't have to preserve compat with 1.13, but we should preserve with things in 1.12. (At least, we need to start getting comfortable with how we are going to do these things going forward.)
[11:09] <rogpeppe> jam: hiya
[11:09] <rogpeppe> jam: i think i agree with that
[11:09] <dimitern> rogpeppe: so how about my proposal?
[11:09] <rogpeppe> dimitern: and i *think* 1.12 used the API machiner, didn't it?
[11:09] <dimitern> rogpeppe: handle both the old and new args types in SetStatus?
[11:10] <rogpeppe> dimitern: that seems reasonable. just add a Machines field in params.SetStatus, marked deprecated.
[11:11] <dimitern> rogpeppe: and read both?
[11:12] <rogpeppe> dimitern: if len(p.Entities) == 0 { p.Entities = p.Machines }
[11:12] <dimitern> rogpeppe: ok
[11:13] <rogpeppe> dimitern: i'm particularly +1 on jam's remark "we need to start getting comfortable with how we are going to do these things going forward"
[11:14] <rogpeppe> dimitern: it's important that we get experience maintaining API compatibility, see what works, what doesn't.
[11:15] <dimitern> rogpeppe: ok, I can agree with that
[11:26] <dimitern> rogpeppe: how can I get 1.12 tools to test the upgrade?
[11:26] <rogpeppe> dimitern: i should hope they'd be in the tools bucket
[11:27] <rogpeppe> dimitern: if not, you'll have to fetch the tgz and compile them yourself
[11:27] <dimitern> rogpeppe: I might need to have a quick chat with you about that, after the standup
[11:27] <rogpeppe> dimitern: ok
[11:31] <dimitern> mgz: standup?
[11:32] <dimitern> jam, thumper: I suppose you won't be joining as well
[11:33] <mgz> ta dimitern
[11:37] <jam> we will not
[11:37] <jam> lunch time for us
[11:37] <wallyworld> rogpeppe: https://codereview.appspot.com/12308044/ :-)
[11:38] <rogpeppe> wallyworld: ta!
[11:49] <sidnei> dimitern: cl updated
[12:02] <natefinch> rogpeppe: https://codereview.appspot.com/12347044/    It still needs tests, but I wanted a check to make sure the approach was ok, since it's a bit above and beyond what the bug calls for.   It's a very small number of lines changed, however.
[12:03] <dimitern> sidnei: thanks, still LGTM
[12:04] <rogpeppe> natefinch: ah yes, i started looking at that and wasn't entirely sure, but got distracted while trying to think of a better alternative...
[12:04] <rogpeppe> natefinch: one question: why does ReadEnvirons return a no-env error only if path=="" ?
[12:06] <natefinch> rogpeppe: I went back and forth on that.  The idea was that it only gives the error message if you're using the default environment... because otherwise it means you explicitly gave it a file you were expecting to exist, and the error message talks about using init, which won't help make your existing configuration work
[12:08] <rogpeppe> natefinch: hmm, that sounds like something that should be triggered at a different level (for example at the command level, where you know if you've been passed an environment or not)
[12:08] <rogpeppe> natefinch: i have an idea - i'll just check to see if it's viable, one mo
[12:08] <natefinch> rogpeppe: cool, thanks for the help.
[12:18] <rogpeppe> natefinch: i wonder if a better place to return the NoEnv error would be from juju.NewConnFromName
[12:19] <dimitern> natefinch: reviewed
[12:19] <rogpeppe> natefinch: and i'm not sure if we should pollute cmd/cmd.go with juju-command specific stuff (it's also used by jujud)
[12:19] <dimitern> rogpeppe: that's where the supercommand lives, no?
[12:20] <rogpeppe> dimitern: yes, but i don't thing the supercommand wants to know about stuff that cmd/juju is doing. it seems like mixing responsibilities
[12:21] <rogpeppe> natefinch: so i'd be tempted to do something like this, in each juju command that calls NewConnFromName:
[12:21] <rogpeppe> 	conn, err := juju.NewConnFromName(c.EnvName)
[12:21] <rogpeppe> 	if err != nil {
[12:21] <rogpeppe> 		return envOpenFailure(err)
[12:21] <rogpeppe> 	}
[12:21] <dimitern> rogpeppe: if it's already reading the env.yaml file there, the responsibility is there
[12:21] <rogpeppe> dimitern: it's not, is it?
[12:21] <natefinch> rogpeppe: yeah, I was trying to avoid changing every single command, but if cmd.go isn't juju specific, then yeah, we don't want to pollute that
[12:22] <rogpeppe> natefinch: and define envOpenFailure as: func envOpenFailure(err error) error {if err == juju.ErrNoEnvironmentFile {print message; return cmd.ErrSilent}; return err}
[12:24] <dimitern> rogpeppe: i'll not restrict EnsureDead to not alive entities then
[12:24] <natefinch> rogpeppe: Yeah, I guess I was ok letting the error go back up the stack,  mostly so it still gets printed out, but I guess we can just print it out there, too.
[12:24] <natefinch> rogpeppe: (the file not found error)
[12:25] <rogpeppe> natefinch: i think there's no need to embed the original file-not-found error - we already know it's os.IsNotExist
[12:26] <natefinch> rogpeppe: I think it's helpful to know what file the system was trying to open and couldn't find.  It helps if you typo the path of the file somewhere
[12:29] <rogpeppe> natefinch: fair enough
[12:30] <rogpeppe> natefinch: oh yes, you'll probably want envOpenFailure(err error, envName string) so that you can print the "Please create a configuration" message only if it's empty.
[12:30] <rogpeppe> natefinch: or you could even implement it as a method on EnvCommandBase
[12:31] <natefinch> rogpeppe: yep, sounds good
[12:36] <dimitern> mgz: https://codereview.appspot.com/12443044/ this is the first CL
[12:37] <dimitern> mgz: and this is the follow-up https://codereview.appspot.com/12461043
[12:37] <dimitern> rogpeppe: ^^
[12:37] <dimitern> rogpeppe: enter the DeadEnsurer :)
[12:38]  * rogpeppe feels uncomfortable about the spelling, but DeathEnsurer seems wrong too
[12:38] <dimitern> rogpeppe: I'm open to suggestions
[12:39] <rogpeppe> dimitern: i have none.
[12:40] <natefinch> dimitern: If we have the opportunity to put a DeathEnsurer in the product, I think we should take it :)
[12:41] <natefinch> dimitern: Reaper?  With a Reap() function?
[12:41] <dimitern> natefinch: :) alas we need to adhere to the predefined state interface
[12:41] <dimitern> natefinch: I proposed DeathEnsurer, but it's equally bad
[12:42] <natefinch> dimitern: Ahh, too bad.
[13:02] <dimitern> rogpeppe: 1.12 is reallt 1.11.something, right?
[13:02] <dimitern> really*
[13:02] <rogpeppe> dimitern: yeah
[13:02] <dimitern> rogpeppe: do you know which one exactly?
[13:02] <rogpeppe> dimitern: no. why do you want to know?
[13:03] <dimitern> rogpeppe: so I can wget it and test the upgrade
[13:03] <rogpeppe> dimitern: https://launchpad.net/juju-core/1.12/1.12.0/+download/juju-core_1.12.0-1.tar.gz
[13:03] <dimitern> rogpeppe: ah, ok, 10x
[13:07]  * rogpeppe goes for lunch
[13:07] <dimitern> mgz: ping
[13:07] <mgz> hey dimitern
[13:07] <dimitern> mgz: hey, any chance to look at my CLs?
[13:08] <mgz> 088 and 089?
[13:08] <dimitern> mgz: yep
[13:08] <mgz> doing so now
[13:08] <dimitern> cheers!
[13:12] <mgz> I find "NewStatusSetter returns a new StatusSetter" a little funny as the first sentence of a doc comment
[13:12] <mgz> but can't really suggest an improvement....
[13:12] <dimitern> that's what it does :)
[13:16] <mgz> dimitern: one down, will just grab some food them look at the other
[13:16] <dimitern> ok, thanks
[13:26] <dimitern> mgz: about the deprecation stuff - aiui we need to make sure the api params/calls are backwards compatible between versions, rather than removing them straight away - it'll make certain version-to-version upgrades problematic
[13:28] <dimitern> hence the deprecation - we guarantee at least the upgrade is possible from the previous release, but deprecated stuff will go away in the next
[13:40] <dimitern> and now.. AgentEntityWatcherer..
[13:40] <dimitern> we defined a whole dictionary
[13:50] <natefinch> dimitern: I usually take the "add -er to an interface name" as a guideline, not a hard and fast rule, for exactly these problems
[13:50] <dimitern> natefinch: tell that to rogpeppe :)
[13:51] <rogpeppe> dimitern: i agree with natefinch
[13:51] <rogpeppe> dimitern: i hate the *erer names
[13:51] <dimitern> rogpeppe: you're the one who usually insists on using -er everywhere
[13:52] <dimitern> rogpeppe: I can remember at least 3 cases where I choose something else :)
[13:52] <rogpeppe> dimitern: only when reasonable. i would never have suggested Removerer (the first such name)
[13:52] <dimitern> rogpeppe: let me find the CL
[13:52] <natefinch> at some point it just looks ridiculous (pretty much any -erer)
[13:53] <rogpeppe> dimitern: i don't know who did Removerer - i laughed out loud when i saw it
[13:54] <rogpeppe> dimitern: looks like you and jam were responsible... https://codereview.appspot.com/11125043/diff/1/state/apiserver/common/remove.go#newcode17state/apiserver/common/remove.go:17
[13:54] <dimitern> rogpeppe: ok, sorry it wasn't you - it was jam, sorry
[13:55] <rogpeppe> dimitern: you will be :-) :-)
[13:56] <dimitern> well, strictly speaking English is not my native language, so none of these names look especially funny or wrong to me :)
[13:56] <dimitern> it's just convention
[13:56] <fwereade> rogpeppe, dimitern: so, SetStatus change
[13:56] <fwereade> rogpeppe, dimitern: what's the deal?
[13:56] <dimitern> fwereade: it landed
[13:57] <dimitern> fwereade: oh? what
[13:57] <fwereade> dimitern, Machines vs Agents/Entities/whatever
[13:57] <rogpeppe> fwereade: i suggested that it was worth maintaining 1.12 compat
[13:57] <dimitern> fwereade: yes, and I did that
[13:58] <dimitern> fwereade: it's deprecated
[13:58] <fwereade> rogpeppe, for values of "worth" equal to "necessary"
[13:58] <rogpeppe> fwereade: which means that SetStatus needs to recognise the Machines argument, until we can deprecate iyt
[13:58] <fwereade> rogpeppe, dimitern: perfect
[13:58] <fwereade> rogpeppe, dimitern: just checking, there was uncertainty here
[13:58] <dimitern> fwereade: I even added a test for 1.12 compat and live tested an upgrade 1.12 -> tip
[13:59] <fwereade> dimitern, rogpeppe: lovely
[13:59] <rogpeppe> fwereade: in practice, i don't *think* it would be a problem if we didn't recognise the Machines argument, because environments tend to upgrade all at the same time
[13:59] <fwereade> rogpeppe, disagree
[14:00] <fwereade> rogpeppe, dimitern: please confirm which workers are currently using the api
[14:00] <rogpeppe> fwereade: in 1.12, i think it's the machiner
[14:00] <fwereade> rogpeppe, in trunk
[14:00] <dimitern> fwereade: upgrader, deployer and machiner
[14:00] <dimitern> rogpeppe: upgrader as well, right?
[14:00] <rogpeppe> dimitern: yup
[14:02] <rogpeppe> fwereade: i *think* this particular incompatibility is only a problem if there's an agent that's persistently using an earlier version.
[14:02] <fwereade> rogpeppe, I would prefer us not to half-ass compatibility even if we can get away with it today
[14:02] <rogpeppe> fwereade: i agree entirely, which was why i suggested the change
[14:03] <rogpeppe> fwereade: but it's interesting to consider what the actual ramifications of the incompatibility might be in *practice*
[14:16] <fwereade> rogpeppe, gtg, but I note in APIWorker
[14:16] <fwereade>     runner := worker.NewRunner(allFatal, moreImportant)
[14:16] <rogpeppe> fwereade: yes, that will change very soon
[14:16] <fwereade> rogpeppe, cool, so long as we're aligned on it being important
[14:16] <rogpeppe> fwereade: indeed
[14:33] <dimitern> mgz: ping
[14:33] <mgz> dimitern: second branch? :)
[14:33] <dimitern> mgz: yep :)
[14:33] <dimitern> rogpeppe: can you take a look as well? https://codereview.appspot.com/12461043/
[14:34] <mgz> DeadEnsurer really is funny
[14:34] <rogpeppe> dimitern: looking
[14:34] <dimitern> it might as well be GrimReaper
[14:36] <rogpeppe> dimitern: i wonder if we might want to consider combining LifeGetter, StatusGetter, DeadEnsurer etc into a single type
[14:37] <rogpeppe> dimitern: i dunno actually, just a passing thought
[14:37] <dimitern> rogpeppe: I'll actually do something like this in the final CL
[14:37] <dimitern> rogpeppe: but they are good on their own, at least for now
[14:38] <dimitern> sweet.. now with the last CL the machiner API is reduced to a single constructor
[14:58] <dimitern> rogpeppe: thanks!
[14:59] <dimitern> rogpeppe, mgz: last one (for now) https://codereview.appspot.com/12464043
[14:59] <mgz> dimitern: ta
[15:18] <sidnei> can i get one more review on https://codereview.appspot.com/12143043/ ?
[15:19] <dimitern> rogpeppe: now that we have a separate apiserver/agent, we'll get rid of apiserver/machine/agent.go and rename the path to apiserver/machiner, right (well, pending deprecation in 1.14). For the uniter, I'll create it in apiserver/uniter directly
[15:20] <rogpeppe> dimitern: i don't quite understand. rename which path? create what in apiserver/uniter?
[15:21] <dimitern> rogpeppe: rename apiserver/machine to apiserver/machiner, remove agent.go from apiserver/machine; create apiserver/uniter/uniter.go
[15:22] <rogpeppe> dimitern: sgtm
[15:24] <dimitern> rogpeppe: but the renaming and removing agent.go only in 1.14, right?
[15:24] <rogpeppe> dimitern: yeah
[15:28] <natefinch> dimitern, rogpeppe, whoever else: what's the best way to get bazaar to show diffs in an external diff tool? I'm a big fan of Beyond Compare, but a quick google gives me like 6 different ways to hook up external diff/conflict resolution... and none of them look particularly good.
[15:28] <rogpeppe> natefinch: i use qbzr
[15:29] <rogpeppe> natefinch: so there is some way of doing it, but i don't know more than that
[15:29] <natefinch> rogpeppe: thanks, that's a good place to start
[15:29] <dimitern> natefinch: +10 to qbzr
[15:29] <rogpeppe> natefinch: mgz is good on bzr
[15:29] <rogpeppe> dimitern: do you use any other qbzr feature than qdiff?
[15:30] <mgz> you can also just alias something with the --using flag
[15:30] <dimitern> rogpeppe: I use a few - qlog, qannotate, qdiff, q
[15:30] <dimitern> not just q :)
[15:30] <mgz> the reson the docs aren't completely clear on this is there are two scenarious you might want to use beyond compare
[15:30] <mgz> just looking at the current state of the tree, a la `bzr diff`, and resolving merges
[15:31] <mgz> and there's not unified config for the two
[15:31] <natefinch> mgz: pretty much any time I *can* use Beyond Compare, I do :)
[15:32] <dimitern> sidnei: ping rogpeppe and mgz directly :)
[15:32] <rogpeppe> dimitern: good point.
[15:32] <rogpeppe> sidnei: looking :-)
[15:33] <dimitern> rogpeppe: and then maybe look my third? :)
[15:38] <mgz> natefinch: so, for starts you just want somethig like `bzr alias bc="diff --using=/path/to/bc"`
[15:43] <natefinch> mgz: thanks
[15:47] <dimitern> mgz: I feel bad to bug you again..
[15:48] <mgz> dimitern: it's okay, I keep wombling off onto other code
[15:48] <mgz> poking is justified
[15:48] <dimitern> :) ok, noted
[15:58] <mgz> dimitern: why have you moved away from table-ish tests to a similar style but with five or so seperate condidiotns in one test case?
[15:58] <dimitern> mgz: which one are you refering to?
[15:59] <mgz> having the inputs x0..x5 at the top, then the expected results at the bottom of a long-ish test not obviously connected seems more confusing to me
[16:00] <mgz> TestEnsureDead and TestSetStatus in the previous mp
[16:05] <dimitern> mgz: what do you suggest?
[16:05] <rogpeppe> sidnei: reviewed
[16:05] <mgz> I'm just curious, those tests aren't so huge, but I thought it was the kind of thing you favoured the table driven style for
[16:06] <dimitern> mgz: well, imo table-driven tests are good for a lot of similar cases, which only slightly differ in their setup; this is a single test with multiple arguments
[16:10] <sidnei> rogpeppe: thanks!
[16:19] <sidnei> rogpeppe: http://paste.ubuntu.com/5951789/
[16:19] <sidnei> or dimitern ^
[16:19] <rogpeppe> sidnei: sorry, use DeepEquals
[16:20] <dimitern> sidnei: yeah
[16:20] <sidnei> that works, thanks!
[16:23] <sidnei> rogpeppe: next: ./apt.go:24: invalid method expression exec.Cmd.Output (needs pointer receiver: (*exec.Cmd).Output)
[16:24] <sidnei> oh, just did as the error message, works.
[16:25] <dimitern> niemeyer: ping
[16:25] <niemeyer> dimitern: Yo
[16:25] <dimitern> niemeyer: hey
[16:25] <dimitern> niemeyer: so no rpc/jsoncodec lines at all in all-machines.log?
[16:26] <niemeyer> dimitern: Yeah
[16:26] <dimitern> niemeyer: any DEBUG stuff at all?
[16:26] <niemeyer> dimitern: Yeah
[16:27] <dimitern> niemeyer: that's really strange.. can you check machine-1.log or some other machine log?
[16:27] <niemeyer> dimitern: The file is also very messy
[16:27] <niemeyer> dimitern: It's missing line breaks
[16:27] <niemeyer> dimitern: It has about 3 messages about rpc, all of them of the style:
[16:27] <niemeyer> INFO JUJU:jujud:machine rpc: discarding obtainer method reflect.Method{Name:"Kill"
[16:27] <dimitern> niemeyer: anything with "juju.worker.machiner" in there? (not "juju/worker/machiner")
[16:28] <dimitern> niemeyer: ah, should be printed once per method in the beginning - it's messy, yes
[16:29] <niemeyer> dimitern: Nothing at all
[16:29] <dimitern> niemeyer: can you paste the log somehow? it shouldn't be that huge
[16:30] <niemeyer> dimitern: Definitely.. just a sec
[16:31] <niemeyer> dimitern: Btw, I wouldn't be surprised if I have an out-of-date dependency.. but it's not clear which. I'd expect the agent stuff to be all within juju-core itself
[16:31] <dimitern> niemeyer: it is, yes
[16:32] <sidnei> rogpeppe: did you meant to suggest CombinedOutput? the comment is a bit unclear
[16:33] <rogpeppe> sidnei: ah, sorry missed your earlier remark
[16:33] <rogpeppe> sidnei: (*exec.Cmd).Output
[16:33] <niemeyer> % juju ssh 0 cat /var/log/juju/all-machines.log | pastebinit
[16:33] <niemeyer> http://paste.ubuntu.com/5951849/
[16:33] <sidnei> rogpeppe: yes, past that now, onto the next comment about capturing stderr
[16:33] <niemeyer> dimitern: ^^^
[16:34] <niemeyer> Hmm
[16:34] <niemeyer> Didn't quite work
[16:34] <rogpeppe> sidnei: it depends where the apt- command prints its error message to
[16:34] <rogpeppe> sidnei: perhaps it's safer to use CombinedOutput, unless it's cluttered with stdout stuff
[16:34] <dimitern> niemeyer: maybe it's a depedency actually
[16:34] <niemeyer> Weird.. piping isn't working
[16:35] <sidnei> rogpeppe: seems to be stderr: https://pastebin.canonical.com/95449/
[16:35] <dimitern> niemeyer: you can try comparing the godeps generated dependencies.tsv file from here https://codereview.appspot.com/12361043/ to a run of godeps -t `{go list ./...}` in juju-core/ (get it from launchpad.net/godeps/
[16:35]  * rogpeppe goes to look for his keyring for 2-factor auth
[16:35] <sidnei> rogpeppe: sorry, pasting to public
[16:36] <niemeyer> dimitern: Holy crap.. it's one gigantic line!
[16:36] <dimitern> niemeyer: the log?
[16:36] <sidnei> rogpeppe: http://paste.ubuntu.com/5951862/
[16:36] <rogpeppe> sidnei: thanks
[16:37] <rogpeppe> sidnei: it looks as if the error lines have a leading "E:"
[16:37] <niemeyer> dimitern: Yeah
[16:37] <rogpeppe> sidnei: if that's standard, perhaps we should use those for the error message. i wonder if we can have several.
[16:37] <sidnei> indeed. conversely it doesn't print any error on missing config, it just produces no output.
[16:37] <niemeyer> dimitern: It's breaking the editor as well
[16:38] <rogpeppe> sidnei: i guess we could split them and join them with semicolons or something
[16:38] <dimitern> niemeyer: hmm.. maybe take a look for anything suspicious in cloud-init-output.log ?
[16:38] <sidnei> rogpeppe: http://paste.ubuntu.com/5951872/
[16:38] <niemeyer> dimitern: Please note that the system is actually working
[16:39] <dimitern> niemeyer: hmm.. perhaps try zipping the logs and passing it over U1 or something?
[16:39] <rogpeppe> sidnei: i imagine there are other possible failure modes
[16:41] <dimitern> mgz, rogpeppe: poke https://codereview.appspot.com/12464043/
[16:41] <sidnei> rogpeppe: i'll make it like the cmd() in git.go then.
[16:42] <rogpeppe> sidnei: yeah, that seems reasonable
[16:43] <rogpeppe> sidnei: thanks
[16:49] <natefinch> mgz: bzr diff --using seems to only show diffs serially, which is kind of annoying. Is there a way to just have it show them all in parallel?  I don't see anything obvious in the man pages
[16:52] <mgz> not for diff I think, the equivalent for merge can be smarter
[16:53] <mgz> ...though that probably wants you to resolve everything sequentially
[16:54] <mgz> ah, maybe qbzr has better handling for this?
[16:55] <natefinch> qbzr looks like it should work... evidently some kinks to work out
[16:56] <natefinch> it's not opening the external diff I specified in the config by default, and if I switch to bcompare from the qdiff window, the command line seems not to expand environment variables
[16:56] <mgz> have to tried just running `bzr qdiff` with args?
[16:57] <mgz> modifying your alias to be qdiff rather than diff may be all you need
[16:57] <natefinch> qdiff doesn't seem to have using
[16:58] <mgz> hm, no, the flags are different
[16:59] <mgz> so, is through config only
[17:01] <natefinch> yeah, I can get qdiff to pop up the default diff, and then choose beyond compare from the list of external diffs... but it doesn't seem to want to pop up beyond compare by default
[17:02] <dimitern> rogpeppe: are you seious about the tests?
[17:02] <dimitern> serious
[17:03] <rogpeppe> dimitern: only if we're serious about the tests for any of the other of those methods. as they are all going away very soon (assuming my proposal is accepted), i have difficulty in suggesting seriously that you write the tests
[17:03] <dimitern> rogpeppe: yep
[17:03] <mgz> natefinch: as you may have gathered, I don't use external diff toos so am not clear on all the details... possibly qbzr doesn't support going straight to a subprocess for this
[17:04] <dimitern> rogpeppe: I'll shovel up most of these ifaces soon
[17:04] <mgz> looks like what we really want is the better qbzr code in bzr core anyway
[17:04] <rogpeppe> dimitern: that's what i'm doing now
[17:04] <natefinch> mgz: no problem, thanks for the help anyway
[17:04] <dimitern> rogpeppe: ah, even better then :)
[17:04] <rogpeppe> dimitern: i'm also making some changes to the names package that i hope you'll like
[17:05] <dimitern> rogpeppe: nice, can't wait to see them
[17:07] <dimitern> mgz: well, as we discovered with rogpeppe, Setterer is actually a word for some bizare profession, but Watcherer is just a proper name in some parts :)
[17:08] <natefinch> dimitern: have you gotten qdiff to work with external diff by default?
[17:11] <dimitern> natefinch: since I couldn't use my favorite meld, I didn't bother trying to setup external diff with bzr; qdiff seems fine for my uses
[17:12] <natefinch> dimitern: dang
[17:19]  * dimitern signs off for today
[17:20] <dimitern> g'night all!
[17:20] <rogpeppe> dimitern: g'night
[17:21] <sidnei> rogpeppe: fixed 'em all
[17:21] <rogpeppe> sidnei: brilliant, thanks
[17:21] <sidnei> rogpeppe: should i poke someone else re: apt-config, or you're comfortable with approving?
[17:22] <rogpeppe> sidnei: it would be really good to get at least one person who knows about that stuff to have a sanity check
[17:22] <rogpeppe> sidnei: i don't really feel comfortable approving something that i don't know anything about
[17:23] <sidnei> there's not really much to know about it other than 'man apt-config' afaict
[17:23] <sidnei> rogpeppe: i've validated the approach with smoser fwiw
[17:24] <rogpeppe> sidnei: it would be nice if he could have a look at the code, but if it's not possible, then i guess it'll be ok
[17:30] <sidnei> rogpeppe: +1'd in private
[17:30] <rogpeppe> sidnei: cool
[17:31] <sidnei> rogpeppe: there will be a new feature in cloud-init itself so that apt_https_proxy is a valid config option, then we can remove the 99proxy-extra hack when that's out there.
[17:31] <rogpeppe> sidnei: cool
[17:31] <rogpeppe> sidnei: just doing a last once-over
[17:32] <mattyw> I seem to get permission denied when sshing to a unit and cd'ing to /var/lib/juju/agents/<unit-name>/charm, anyone else seen this? < - juju 1.13.0
[17:33] <rogpeppe> sidnei: i hope that apt doesn't sometimes print warnings to stderr :-)
[17:33] <sidnei> i could look at the source, but meh. it's generally not very verbose.
[17:35] <rogpeppe> sidnei: reviewed
[17:37] <sidnei> rogpeppe: when putting }) in the newline, should i end the last line with ',' as well?
[17:37] <rogpeppe> sidnei: yes
[17:37] <rogpeppe> sidnei: (you need to)
[17:39] <sidnei> do i need to lbox propose again or just rv-submit?
[17:42] <sidnei> oh, apt-config output is case sensitive
[17:42]  * sidnei looks for case-insensitive flags on go regex
[17:46] <sidnei> cool fixed.
[17:57] <sidnei> rogpeppe: sent for landing
[18:20]  * rogpeppe smells the sweet smell of frying onions and garlic from downstairs
[18:20] <rogpeppe> time to stop for the day :-)
[18:20] <mgz> how very british :)
[18:21] <rogpeppe> mgz: pea risotto. lots of peas from the garden, mmm.
[18:21] <mgz> sounds great
[18:21] <rogpeppe> mgz: smells great :-)
[18:22] <rogpeppe> g'night all
[18:22] <mgz> later rog
[23:35] <davecheney> jamespage: no, sorry, i do not know about pyjuju -> go juju upgrades
[23:35] <davecheney> at one level, we always said there is no upgrade path for pyjuju-> go juju environments
[23:35] <davecheney> i am not sure if that was your question


[00:55] <highvoltage> what should the incoming directory in dput be for uploading to Ubuntu?
[00:55] <highvoltage> (I'm uploading from a Debian machine so if I just use dput it would upload to debian)
[00:56] <lifeless> I'm moderately sure dput knows about ubuntu upstream
[00:58] <highvoltage> lifeless: heh, indeed!
[06:02] <c2tarun> yesterday i was talking with an admin of bug-squad. he told me that, for fixing errors developers use the triage information and release patch, then review team verifies the patch and send it to upstream if its correct. What i m not getting is what is the role of MOTU in this whole process??
[06:02] <c2tarun> sorry if my english is bit rude :(
[06:04] <micahg> c2tarun: MOTU is supposed to take care of the universe subset of packages at the moment which includes, syncs, merges, security fixes, and bug fixes
[07:59] <MTecknology> hm.. How can I find out what package provides ndk.h?
[08:00] <micahg> MTecknology: apt-file search?
[08:01] <Rhonda> MTecknology: http://packages.ubuntu.com/ and the "Search the contents of packages" form
[08:01]  * Rhonda . o O ( doesn't seem to be part of maverick )
[08:02] <Flannel> If it's in your filesystem already, dpkg -S /path/to/file
[08:03] <MTecknology> it's not on the system and I'm not finding it on packages.ubuntu.com
[08:03] <ebroder> Are you sure it exists? :)
[08:03] <MTecknology> ya, but I'm not so sure any package provides it..
[08:04] <micahg> not in maverick
[08:06] <Rhonda> Neither in natty
[08:08] <Flannel> I don't see it on the internet, what's it for?
[08:09] <MTecknology> an nginx module
[08:10] <micahg> not in any suite
[08:10] <micahg> *series
[08:10] <MTecknology> I see where it is.....
[08:10] <MTecknology> https://github.com/simpl-it/ngx_devel_kit
[08:10] <Flannel> https://github.com/simpl-it/ngx_devel_kit
[08:10] <Flannel> yeah
[08:10] <MTecknology> Flannel: you found it the same time? :P
[08:11] <Flannel> I also found a networking one on SF, but it seemed extremely immature
[08:31] <dholbach> good morning!
[08:34] <MTecknology> Rejected: Unhandled exception processing upload: 'NoneType' object has no attribute 'md5'   .... :S
[08:34] <MTecknology> dholbach: howdy
[08:35] <dholbach> hi MTecknology
[08:35] <MTecknology> I've never seen a package rejected from LP for that reason.
[09:59] <geser> MTecknology: bug 687662
[12:55]  * ari-tczew noticed a trend to applying for core-dev team.
[15:37] <kim0> Hi folks ... why is the --debug option refused in:  pbuilder --debug --build --basetgz natty-base.tgz bacula*.dsc
[15:52] <ScottK> kim0: Did you try it --build --debug?
[15:53] <kim0> ScottK: I'm very new to all of this
[15:53] <kim0> ScottK: I tried  pbuilder --build --basetgz natty-base.tgz --debug  bacula*.dsc
[15:53] <kim0> ScottK: and it finished compiling
[15:54] <ScottK> IIRC the build option has to come first.
[15:54] <kim0> ScottK: I want to find the boken build dir
[15:54] <kim0> so I can fix it .. and try building again
[15:55] <kim0> I guess that's gonna be hard .. since i'm on maverick and building for natty .. which is failing
[16:00] <ScottK> Probably the shortest path to what you want ( --debug isn't it) is do pbuilder --login and then do your build in the chroot directly.
[16:06] <tumbleweed> or use the C10shell example hookscript
[16:10] <kim0> ScottK: I love --login .. didn't know I could do that
[16:10] <kim0> ScottK: I'm in the chrooot ... how do I start the build process ?
[16:11] <ScottK> kim0: dpkg-buildpackage -us -uc
[16:11] <ScottK> (from in the package directory
[16:11] <ScottK> )
[16:11] <ScottK> kim0: Also be sure to copy anything you need to save out of the chroot before exiting because it will be deleted.
[16:12] <kim0> ScottK: can I use pbuilder inside the chroot too ?
[16:12] <ScottK> (the pbuilder chroots live in /var/cache/pbuilder/build)
[16:12] <ScottK> Not reallyl.
[16:12] <kim0> I mean .. how will it get build time deps
[16:12] <ScottK> apt-get build-dep packagename
[16:12] <ScottK> or apt-get install ....
[16:14]  * Rhonda usually does "cowbuilder --login --basepath ./$dist --bindmounts `pwd`/subdir"
[16:14] <Rhonda> and even then in there do a "useradd $LOGIN; chown $LOGIN /home/$LOGIN; su - $LOGIN; cd …; debuild" :)
[16:15] <ScottK> That too
[16:17] <Rhonda> That way I don't have to copy anything away because the source is not directly extracted in subdir but in subdir/$package-$version
[16:18] <Rhonda> And when something breaks I don't have to totally start from scratch. ;)
[16:18] <Rhonda> … and can use the tools from outside still because of the bindmount
[16:37] <artfwo> hello! would anyone like to review/sponsor a debdiff for bug 688096?
[16:38] <artfwo> uh, looks like coolbhavi have noticed it just before I announced :)
[16:39] <coolbhavi> artfwo, yes
[16:39] <coolbhavi> :)
[16:47] <ari-tczew> what a quick response! don't you think?
[16:48] <artfwo> i'm still thinking how he managed to respond before I asked :)
[16:49] <artfwo> I used to ask for a patch review and wait for a couple of days or so...
[16:49] <coolbhavi> artfwo, maybe i saw the request as you typed here :)
[16:49] <artfwo> :)
[16:50] <artfwo> do you keep a hidden camera in my house then?
[16:51] <coolbhavi> artfwo, nopes
[16:51] <artfwo> then I give up
[16:52] <Laney> DktrKranz: can you please process mono in NEW? thanks
[16:54] <ScottK> kklimonda: Thanks again for all your work leading up to being able to rebuild python-visual.  You made Bug #688142 possible.
[17:04] <kklimonda> ScottK: great :)
[17:09] <DktrKranz> Laney: is there an ACK from Release Team?
[17:09] <Laney> DktrKranz: afaik yes, I think from aba
[17:10] <Laney> you might want to confirm with him
[17:10] <DktrKranz> ok, looking into RT mailbox
[17:10] <kklimonda> Laney: you are working (or planning to work) on glom and goocanvasmm?
[17:10] <kklimonda> are you*
[17:10] <Laney> pochu asked me about that today
[17:10] <Laney> yes
[17:10] <Laney> but you can if you want, don't block on me
[17:11] <kklimonda> Laney: I was planning on taking a look at it this weekend
[17:11] <DktrKranz> mh, can't find anything, I'll ask on IRC
[18:00] <kim0> Hi .. I need some help please
[18:01] <kim0> I'm trying to fix a FTBFS with bacula .. I know I need to put -lssl in the Makefile
[18:01] <kim0> in LDFLAGS .. problem is .. I only find Makefile.in and not sure where exactly to use those flags (-lssl)
[18:07] <ScottK> kim0: What I normally do for this is find anyother library it links to already and then grep for where that one gets set.
[18:07] <ScottK> There isn't a one size fits all solution since packages ~all do it differently.
[18:08] <kim0> ScottK: hmm .. what files do I grep :)
[18:08] <ScottK> Any that are involved in the build system.
[18:09] <ScottK> As long as your target is suitably rare it doesn't matter so much not to search overly broadly.
[18:10] <geser> kim0: LDFLAGS won't anymore with ld --as-needed
[18:20] <RoAkSoAx> kim0: /win 15
[18:20] <RoAkSoAx> lol
[18:20] <RoAkSoAx> sorry
[18:21] <kim0> :)
[18:21] <kim0> I'm not your irssi
[18:21] <kim0> heheee
[18:41] <kim0> ScottK: I think I fixed the bug .. I want to test with pbuilder
[18:41] <kim0> ScottK: it ignore the untarred dir .. and seems to re-untar fresh
[18:41] <ScottK> It does
[18:42] <kim0> how do I inject my patch
[18:44] <kim0> ScottK: ^ :)
[18:44] <ScottK> kim0: Sorry, I'm a bit tied up with some other things right now.  Hopefully someone else can help.
[18:45] <kim0> ScottK: thanks a lot for all the help
[18:45] <ScottK> You're welcome and good luck
[18:49] <RoAkSoAx> kim0: first, if the package already has a patchsystem in use, use it to apply your patch. Otherwise, patch the source directly
[18:54] <kim0> RoAkSoAx: the package has a .diff.gz file with it
[18:55] <RoAkSoAx> kim0: take a look at: https://wiki.ubuntu.com/PackagingGuide/PatchSystems :) It explains how to use the patchsystems, it is very helpul :)
[18:59] <kim0> RoAkSoAx: it says "unknown patch system"
[19:00] <RoAkSoAx> kim0: bacula right?
[19:00] <kim0> yes
[19:01] <kim0> RoAkSoAx: do I bzr branch it ?
[19:03] <RoAkSoAx> kim0: take a look in debian/rules, and go to patch-stamp... apparently they are patching the source directly when building the package right there. so might gonna have to do something similar.
[19:04] <RoAkSoAx> kim0: you can either branch it, apply your patch and ask for a merge. Or grab the source, patch it, provide a debdiff
[19:04] <kim0> RoAkSoAx: I'd rather branch it, coz I know more about that
[19:04] <kim0> RoAkSoAx: BUT .. I wanna test it with  my patch
[19:05] <kim0> RoAkSoAx: I don't know how to tell pbuilder to use my modified copy
[19:09] <kim0> nvm .. I'm gonna branch/ask-for-merge
[19:09] <ari-tczew> I have to filter one http link, but it's not related to packaging. how can I use "uscan" to get output from http/ftp link?
[19:11] <RoAkSoAx> kim0: In your branch, do 'bzr bd -S' and it should create an *.dsc file, which you should use to build in pbuilder
[19:12] <kim0> trying that


[14:20] <diwic> hi,
[14:21] <diwic> I posted a comment on fridge.ubuntu.com that I should not have posted there.
[14:21] <diwic> It's currently awaiting moderation, I think. I was wondering if you could delete it.
[14:22] <diwic> It's a comment to http://fridge.ubuntu.com/2015/01/06/community-donations-report-q2-2014/