[01:55] <schmichael> can someone point me to good docs on how to integrate with the main appindicator icon?
[01:55] <schmichael> preferably in python
[01:55] <schmichael> this seems too high level: https://wiki.ubuntu.com/MessagingMenu/
[01:55] <schmichael> this isn't exactly comprehensive: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Python
[01:56] <schmichael> and this is for C and doesn't really tell what I should do: http://people.canonical.com/~ted/libappindicator/current/AppIndicator.html
[01:56] <schmichael> 6pm Pacific timezone is probably the wrong time to ask
[02:05] <RAOF> schmichael: This isn't really the correct channel.  You probably want #ubuntu-app-devel or #ayatana.  That said, there are multiple things you could mean here: do you want to integrate with the messaging menu?  With the Me menu?  With the sound menu?  Or just use the replacement notifiation-area-like appindicator?
[02:07] <schmichael> holy shit that's a lot of menus
[02:07] <schmichael> um
[02:07] <schmichael> I think the messaging menu
[02:08] <schmichael> where Mail, Compose, and Broadcast live
[02:08] <schmichael> I've never even heard of ayatana
[02:08] <schmichael> Sorry for posting in the wrong channel, I think one of the pages I cited says to drop by here
[02:10] <RAOF> That's ok.
[02:14] <RAOF> Right; so you're looking for information about the messaging menu.  I think python-indicate is the package you'll be needing, and gwibber-service is an example of a python app using it.
[02:14] <schmichael> I think I'll just use libnotify and figure out what I want to do about an icon later
[02:14] <schmichael> ah
[02:14] <schmichael> hm
[02:15] <schmichael> looking
[02:15] <RAOF> Your app is something that presents messages, right?
[02:15] <schmichael> yes
[02:16] <RAOF> Yeah, python-indicate will be what you're after then.
[02:16] <schmichael> hm, can't find that in pypi
[02:16] <schmichael> ah but there's a deb
[02:17] <RAOF> “apt-get source gwibber-service” might help you work out how to use it if you can't find better documentation.
[02:17] <schmichael> how is python-indicate different from python-appindicator?
[02:17] <schmichael> I've been toying with the latter and it seems to create a new icon entirely
[02:18] <RAOF> App indicators are the replacement for the notification area.  They're for generic apps which want some form of notification-area like control system - see for example Banshee, gtg, the power manager & bluetooth thingies.
[02:19] <schmichael> gotcha
[02:19] <schmichael> python-indicate seems to offer the same api though
[02:19] <schmichael> er, similar
[02:19] <RAOF> The API should be substantially the same, they're both based on dmusmenu.
[02:19] <RAOF> Ahem. dbusmenu.
[02:19] <schmichael> any idea where docs might live?
[02:20] <schmichael> I'll look at gwibber
[02:20] <RAOF> Yeah.
[02:20] <RAOF> I wouldn't be surprised if the pydocs weren't bad; we often have good docstrings in my experience.
[02:22] <schmichael> Thanks for the help. I'm a web/server python developer trying to take a stab at a desktop client
[02:22] <schmichael> Very difficult to figure out where to start
[02:22] <schmichael> Also, I'm at a pub. Which may be the wrong place to be hacking
[02:24] <RAOF> Nonsense!
[02:25] <schmichael> :)
[02:26] <schmichael> Pint #2 in progress
[02:26] <schmichael> First one might have been 8% ABV, a poor choice
[02:26] <schmichael> This one is 5.4% though, so I should be able to recover
[02:35] <schmichael> RAOF: so gwibber appears to try to load a desktop file from the directory it's launched from...
[02:35] <schmichael> ...do you know if this is important?
[02:36] <schmichael> And if so, why from the dir it's launched from, shouldn't desktop files be in HOME directories?
[02:36] <schmichael> or at least not by executables
[02:37] <RAOF> As I understand it you need to stick a .desktop file somewhere that the Messaging menu checks in order to register yourself.  After all, you can _start_ apps from the messaging menu.
[02:40] <schmichael> I have so much to learn
[02:40] <schmichael> I barely know what a .desktop file is...
[02:40] <schmichael> ...just that it describes desktop applications
[02:40] <schmichael> and associated resources (icons, translated names, etc)
[02:40] <schmichael> Web development is so much easier
[02:41] <schmichael> You have GET variables, request data (POST/PUT variables), and each request/response cycle is completely independent
[07:10] <pitti> Good morning
[07:15] <robert_ancell> james_w, do you have an updated empathy indicator patch?
[07:31] <didrocks> good morning
[07:40] <pitti> hey robert_ancell, bonjour didrocks
[07:40] <didrocks> guten morgen pitti
[07:41] <robert_ancell> pitti, hello
[08:36] <seb128> hey there
[08:37] <pitti> it's a Seb!
[08:37] <baptistemm> hello
[08:38] <didrocks> salut seb128
[08:38] <didrocks> hello baptistemm
[08:38] <baptistemm> salut didrocks
[08:38] <seb128> hey pitti
[08:38] <seb128> lut baptistemm didrocks
[08:40] <robert_ancell> seb128, hey, I have empathy updated ready for maverick.  This will be the first package to have a definite dependency on GSettings.  Any final words?
[08:42] <baptistemm> salut seb128 didrocks pitti and robert_ancell
[08:42] <robert_ancell> baptistemm, hey
[08:42] <pitti> hello baptistemm
[08:42] <pitti> robert_ancell: wohoo!
[08:42] <seb128> robert_ancell, hey, I've been trying to figure from empathy guys if they will depends on gtk3 for a week now
[08:43] <didrocks> robert_ancell: they have a shared gconf key, we should maybe look at that
[08:43] <seb128> robert_ancell, I'm fine with gsettings, not with gtk3
[08:43] <seb128> robert_ancell, I guess we can go for it but we will need to distro patch to build with gtk2 if required
[08:43] <robert_ancell> seb128, so what do you think?  Shall we leave it in bzr/a ppa wait and see what they do, or roll back if there is a problem
[08:43] <seb128> robert_ancell, what is your take on updates? did you pick that one for a reason or do you plan to start doing GNOME 2.31 updates?
[08:44] <seb128> robert_ancell, btw I was wrong about new poppler it doesn't require new cairo
[08:44] <robert_ancell> seb128, picked that one because you mentioned it, debian already has it in experimental, there's lots of stability updates and the geolocation is a nice new feature
[08:44] <seb128> robert_ancell, got the new cairo in the ubuntu-desktop ppa as well
[08:44] <baptistemm> anyone to review lp:~bluetooth/ubuntu/maverick/bluez/main and lp:~bluetooth/ubuntu/maverick/obexd/main?
[08:44] <seb128> robert_ancell, did you enable geolocation?
[08:44] <robert_ancell> seb128, sweet, is that in bzr too?
[08:45] <robert_ancell> seb128, yes, I figure we'll disable at a later date if it causes problems
[08:45] <seb128> robert_ancell, no, Sarvatt did the update I just sponsored to get some testing there
[08:45] <seb128> robert_ancell, the issue is that it will need mir for the libchamplain etc
[08:45] <seb128> robert_ancell, it can't build until then
[08:45] <seb128> robert_ancell, otherwise back to the topic I think empathy is fine to update, limited risk, easy to downgrade and nice changes
[08:46] <seb128> robert_ancell, do you want me to upload it with the geoclue stack for now?
[08:46] <robert_ancell> seb128, why can't it build?  what happens in maverick if you depend on a universe package?
[08:46] <seb128> robert_ancell, it depwaits
[08:46] <robert_ancell> Ah ok
[08:46] <seb128> robert_ancell, the main builders don't know about universe
[08:46] <seb128> so they will not find the binaries
[08:47] <robert_ancell> seb128, but they can have universe build-eeps right?
[08:47] <robert_ancell> deps
[08:47] <seb128> no
[08:47] <seb128> they don't know about universe
[08:47] <seb128> ie universe is not in their sources.list
[08:47] <robert_ancell> ok
[08:48] <seb128> I will sponsor that
[08:48] <robert_ancell> ok, it's in bzr
[08:48] <seb128> sorry I didn't follow up on other things you mentioned
[08:48] <robert_ancell> np
[08:48] <seb128> where are the compiz updates?
[08:48] <robert_ancell> in bzr (~compiz_)
[08:48] <seb128> I'm also not sure if you let the gnome-menus merge etc for me to finish or still planned to do it
[08:48] <seb128> I got busy with other changes
[08:48] <seb128> but I can catch up today
[08:49] <robert_ancell> yeah, I've just left that one for now, it had changes I didn't understand
[08:49] <seb128> just apply those ;-)
[08:49] <seb128> which ones? want to discuss those now?
[08:49] <robert_ancell> nah, I don't let it through unless I can put a changelog entry and a patch header :)
[08:49] <robert_ancell> ok
[08:50] <seb128> robert_ancell, btw you still have one work item for alpha2 to write a mir for d-conf
[08:50] <seb128> robert_ancell, do we need to get d-conf installed for the new empathy yet?
[08:51] <robert_ancell> seb128, no, but the next release requires it
[08:51] <seb128> ok, so will do
[08:51] <seb128> I will do the libglib update today
[08:52] <seb128> robert_ancell, sorry lot of context switch and catchup, we have low overlap recently and I feel you will call it a week rsn ;-)
[08:52] <robert_ancell> you got 10 minutes :)
[08:52] <seb128> robert_ancell, what are the gnome-menus changes you didn't understand? the ones with "??" in the changelog?
[08:54] <seb128> robert_ancell, so 06_menus_rename.patch and 08_menus_prefix.patch is a debian change
[08:54] <seb128> they prefixed the names on their menus to not conflict with kde
[08:54] <seb128> it did create extra work and some issues though and is not required since the kde ones are already prefixed in ubuntu
[08:55] <seb128> so we don't use those debian changes
[08:55] <robert_ancell> seb128, yeah, looking over it now.  Nothing stands out.  I think it was just a combination of the prerm/postinst changes, the cache and just not being familiar with the pacakge
[08:55] <robert_ancell> compared to compiz it looks simple :)
[08:55] <seb128> the admin one is to hide things which require sudo if you are not in the admin group to use those
[08:56] <seb128> no point to lists entries you can't use
[08:56] <seb128> robert_ancell, great work on the merges btw
[08:56] <seb128> robert_ancell, you did some I wouldn't have started on seing the number of changes, it sometime seems lot of work for low benefit...
[08:57] <seb128> but I guess it's still nice to do those if we can once a cycle to see our changes and reduce delta where we can
[08:57] <robert_ancell> I think if we're going to merge we have to do them all otherwise they'll just get harder and harder to merge in the future
[08:58] <seb128> right
[08:58] <seb128> sometime it's easy the other way around
[08:58] <seb128> diff what debian changed since we merges and apply those changes to what we have
[08:58] <robert_ancell> sure
[08:59] <robert_ancell> seb128, hey, do you know about the latest webkit - 1.3?  Is that going to be released in time for Maverick?
[09:00] <robert_ancell> (and where are their releases?)
[09:00] <didrocks> (2nd warning try) there is a shared gconf key for the used font with empathy, not sure how that can be handled with gsettings
[09:01] <robert_ancell> didrocks, shared between what?
[09:01] <didrocks> robert_ancell: that was what Zdra told me, I can ask him what else uses it
[09:02] <seb128> didrocks, we will get this gconf, gsettings sync issue for some things anyway
[09:02] <seb128> we will need to sort it
[09:03] <didrocks> seb128: yeah, but didn't we tell at UDS "we won't update apps using shared keys?"
[09:03] <seb128> robert_ancell, I guess empathy uses the desktop font settings
[09:03] <robert_ancell> has anyone got any ideas about the gconf->dconf migration?  It requires you to restart your sessing for your keys to be migrated (if the package has a migration script).  If you upgrade and restart your app it will use blank keys until the session is restarted and the migration occurs.  I assume this then overwrites the keys you might have just set
[09:03] <robert_ancell> session
[09:03] <seb128> didrocks, we don't want to step in tricky situations like breaking mimetype handles or automounting or that sort of things
[09:03] <robert_ancell> man my spelling is awful at the moment
[09:04] <didrocks> seb128: ok, for a font settings, it seems not to be so much a big deal
[09:04] <seb128> didrocks, I think if empathy users have to change fonts in empathy that's a fair trading for the new version
[09:04] <didrocks> just wanting to point that :)
[09:04] <seb128> didrocks, thanks
[09:04] <didrocks> robert_ancell: maybe we can drop the magic file to say "restart required"
[09:04] <seb128> robert_ancell, well after distro versions change we highly encourage users to restart
[09:05] <robert_ancell> didrocks, yeah, that was the best I could come up with
[09:05] <robert_ancell> seb128, so can we accept "strange behaviour" if they don't?
[09:05] <didrocks> in any case, with lucid -> maverick upgrades, people will have a new kernel, so it's highely possible they will restart :)
[09:05] <seb128> robert_ancell, yes
[09:05] <robert_ancell> ok
[09:05] <seb128> robert_ancell, we will always have some anyway
[09:07] <robert_ancell> so if empathy is upgraded and uses gsettings (successfully), we should upload any GNOME apps we want as long as they don't use GTK3 and we have the time to support them?
[09:08] <seb128> right and we don't get tricky gconf, dconf shared key issues
[09:08] <seb128> we should review the dg,conf keys used
[09:08] <seb128> I'm a bit concerned for things like proxy to use
[09:09] <robert_ancell> yeah
[09:09] <robert_ancell> anything that is set by gnome-control-center is vulnerable
[09:09] <seb128> but seems GNOME will mostly depends on gtk3
[09:09] <huats> morning
[09:09] <robert_ancell> seb128, what parts of GTK3?
[09:09] <seb128> robert_ancell, gtkapplication
[09:09] <seb128> they will also change their configure to use the new pkgconfig files
[09:10] <seb128> ie gtk+-3.0
[09:10] <robert_ancell> meh, is anyone using that?  (is it required for gnome shell?)
[09:10] <seb128> robert_ancell, it's the libunique replacement for GNOME3
[09:10] <robert_ancell> seb128, it doesn't sound too complex then, a candidate to port to GTK2?
[09:10] <seb128> we might want try to convince upstream to backport gtkapplication to 2.22
[09:10] <seb128> that would make our job easier
[09:11] <seb128> robert_ancell, well I'm a bit careful about what might land in gtk3 and requirements that might be created on the road
[09:11] <seb128> robert_ancell, let's not upgrade everything we can think of but only what we think would be really valuable
[09:12] <seb128> if the new version is mainly a gsettings gtk3 port without nice changes there is no point to take the extra work and risk now
[09:12] <robert_ancell> seb128, I'm thinking it wont be anything too invasive that many apps will pick up, not without more warning than this
[09:12] <seb128> we can have a better overview around 2.31.9x
[09:12] <robert_ancell> yeah
[09:12] <didrocks> urgh, I forgot the "halsectomy" of banshee for UNE
[09:12] <seb128> then decide easily on what we will take
[09:12] <seb128> robert_ancell, but I'm fine doing a GNOME3 ppa if you want
[09:12] <didrocks> pitti: do you think you will have some time to play with removing hal from banshee or do you have a guide so that I can see what I can do?
[09:13] <seb128> robert_ancell, we should just maybe keep focussing a bit on maverick and the platform for now and don't track every 2.31 versions
[09:13] <seb128> robert_ancell, seems we can avoid some work and start getting those updates later in the cycle
[09:14] <pitti> didrocks: that sounds like nontrivial upstream work; you'd need to switch to using media-player-info and add the parser to it which was added to rhythmbox
[09:14] <pitti> to be able to parse music player capabilities, formats, etc.
[09:14] <pitti> it's not just an 1:1 API conversion from libhal to gudev
[09:15] <robert_ancell> seb128, I think we have most of the Maverick platform in place now.  There is some optional/universe stuff like GTK3 but the core platform is ther
[09:15] <didrocks> pitti: urgh, maybe I should talk with upstream about that, that's clearly a showstopper for banshee by default on UNE
[09:15] <pitti> !
[09:15] <seb128> robert_ancell, right, next real task will be to get gtk3 packaged and gtk3 versions of libraries
[09:15] <pitti> didrocks: why do we switch now?
[09:15] <seb128> real -> requiring work
[09:16] <seb128> didrocks, pitti: I though banshee switched to udev etc previous cycle?
[09:16] <pitti> didrocks: it's much slower and memory hungry and uses hal/hal-info; also, does it have u1 music store?
[09:16] <robert_ancell> oh, what do you guys think about putting the latest sane-backends in Lucid?
[09:16] <didrocks> pitti: we talked about that in the UNE session, and there is a better netbook interface that I've hacked on the last few days
[09:16] <seb128> robert_ancell, what does it change?
[09:16] <didrocks> pitti: yes, it has u1 music store plugin
[09:17] <robert_ancell> seb128, lots of bug fixes, I have it in Maverick now, and a Lucid PPA.  It would help a lot of users.  Don't know the best way to test it
[09:17] <robert_ancell> they took ages to make a release
[09:17] <seb128> robert_ancell, do a sru bug, hard to say without saying the diff
[09:17] <seb128> seeing
[09:18] <robert_ancell> that's the issue, the diff will be huge, and there's no way to test any significant proportion of the drivers
[09:18] <seb128> robert_ancell, but seems it something that should be doable, maybe let sit in the candidate update for a while
[09:18] <seb128> to make sure it gets testing
[09:18] <robert_ancell> perhaps the PPA will be good enough, and users will find out about it on the forums
[09:18] <pitti> seb128: I don't know, I'm not following banshee development
[09:18] <pitti> I'm currently dealing with u{dev,disks}-ifying xfce :)
[09:19] <seb128> pitti, ^ do you have an opinion about the sane sru?
[09:19] <pitti> unless it changed ABI, sounds ok; it's by and large adding support for new hw?
[09:19] <RAOF> didrocks: There's a gudev backend in development, Alex Launi has done the initial work.
[09:19] <robert_ancell> pitti, and fixing bugs in existing drivers.  There were some specific models that people were having problems with and used to work in Jaunty
[09:20] <pitti> robert_ancell: diff is still interesting to see what kind of changes it has
[09:20] <robert_ancell> ok, I'll SRU it up next week
[09:20] <didrocks> RAOF: do you think it will be finished before our feature freeze?
[09:20] <pitti> robert_ancell: I can test it on a Canoni LiDE 40, but that has worked for ages
[09:20] <pitti> "Canon"
[09:21] <robert_ancell> without a hardware lab we can't be sure it won't cause regressions.  and it's too much work I think to take individual patches
[09:22] <robert_ancell> beer o'clock!  See you guys later
[09:23] <RAOF> didrocks: Not unless someone steps up and finishes it.
[09:23] <didrocks> enjoy your week-end robert_ancell
[09:23] <didrocks> RAOF: ok, I'll see with jcastro if we can leverage some community help there
[09:24] <RAOF> Dinner making time!
[09:27] <didrocks> RAOF: enjoy :)
[09:58] <didrocks> seb128: if you have some time today, I sponsored kenvandine package for indicator-network yesterday evening. It should be waiting in NEW
[10:01] <seb128> didrocks, ?
[10:01] <seb128> didrocks, I newed it yesterday evening I think
[10:02] <seb128> didrocks, or did that didn't work?
[10:02] <didrocks> seb128: oh sweet, I didn't check TBH, I wasn't thinking you connected back
[10:02] <seb128> I did
[10:02] <didrocks> right, it's done, you are so quick :)
[10:02] <seb128> there is usually quite some sponsoring required on thursday
[10:02]  * didrocks hugs seb128
[10:02] <seb128> kenvandine desktop set upload right don't work for quite some dx sources
[10:02] <seb128> so I usually try to come back to sponsor things he can't upload
[10:03]  * seb128 hugs didrocks back
[10:03] <didrocks> oh ok, it's the "late Thursday tasks" so? :)
[10:03] <seb128> yeah
[10:22] <seb128> pitti, we stopped assigning bugs to desktop-bugs now btw
[10:23] <pitti> seb128: oh, good to know
[10:23] <seb128> pitti, just fyi since I noticed you reassigned one to it
[10:23] <pitti> yes, I'm afraid I have no time for that one, and it didn't seem that urgent
[10:25] <seb128> pitti, yeah, no discussion about the bug itself ;-)
[10:25] <pitti> seb128: is there a replacement for desktop-bugs, or we just stop caring?
[10:26] <seb128> "stop caring" for whatever that means to you ;-)
[10:26] <seb128> we still care about the bug but we have tools to build buglists nowadays without having to assign those to a team in launchpad
[10:26] <pitti> ah, right
[10:27] <seb128> we can do json queries for those now
[10:27] <seb128> ie do "bugs reported on all components this team is subscribed to"
[10:54] <kamstrup> Is it me or are the icons and tiles and the launcher (trunk) a bit blurry?
[10:59] <chrisccoulson> is it possible to do a dist-upgrade between releases with PPA sources? i tested a hardy -> lucid upgrade last night before realising that firefox hadn't been updated because the new version is still only staged in a PPA
[11:00] <chrisccoulson> i suppose that's a mvo question, but he's not around
[11:01] <seb128> chrisccoulson, what do you mean exactly?
[11:01] <seb128> it's always possible to run dist-upgrade, it will just grab newest versions and install those
[11:02] <seb128> or do you mean "does the dist-upgrade tweak ppa source lines as well as normal distro ones"
[11:02] <chrisccoulson> seb128 - i want to do an upgrade from hardy -> lucid, but keeping the u-m-s PPA as a source
[11:02] <seb128> dist-upgrader
[11:02] <seb128> using the graphical dist-upgrader you mean?
[11:02] <chrisccoulson> yeah
[11:02] <seb128> I'm not sure
[11:03] <chrisccoulson> i wanted to make sure the upgrade still works, but i forgot that it disables the PPA sources before the upgrade
[11:03] <seb128> I would add the hardy and lucid ppa lines to the source before running it
[11:03] <seb128> oh
[11:03] <seb128> I guess it's a mvo question then yes
[11:03] <seb128> he will be back on monday
[11:03] <chrisccoulson> thanks, i can wait until then. i've got lots of karmic bugs to fix already ;)
[11:06] <seb128> ok
[11:06] <seb128> didrocks, can you check bug #595867
[11:06] <ubot2> Launchpad bug 595867 in evolution (Ubuntu) "recipient address with german umlauts gets broken on new/reply .. mail (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/595867
[11:07] <seb128> didrocks, the descriptions says it's happening after the recent update
[11:08] <didrocks> seb128: do you think it's the mailing list encoding in e-d-s?
[11:08] <seb128> didrocks, I guess it would be the e-d-s change
[11:08] <seb128> well, I'm not sure
[11:08] <didrocks> hum, not sure I have the time right now, will try to reproduce and revert this change…
[11:09]  * didrocks will never ever have serious time to work on banshee anyway :/
[11:09] <seb128> I can't confirm though
[11:09] <seb128> I've tried to reply to emails from macslow and it works
[11:10] <seb128> didrocks, try maybe just asking questions about since when he's having the issue and how to trigger it easily for now
[11:10] <didrocks> oh really?
[11:10] <didrocks> seb128: sure I will thanks
[11:10] <MacSlow> seb128, cover-display in notificatiosn again?
[11:11] <seb128> MacSlow, no sorry, an evolution bug with names with umlauts, I was taking you as an example to test it
[11:11] <MacSlow> seb128, ah ok
[11:12] <seb128> MacSlow, sorry for the highlight ;-)
[11:12] <MacSlow> didrocks, ok... bring on the german umlauts then :)
[11:14] <didrocks> MacSlow: heh, you have an uptodate lucid too? can you try to hit reply on an email from an expeditor having an umlaut in the name, please?
[11:15] <MacSlow> didrocks, pulled lucid updates yesterday... recent enough?
[11:15] <seb128> yes
[11:15] <didrocks> MacSlow: should be :)
[11:18] <MacSlow> didrocks, ok did that... everything looks ok in the email-reply window
[11:18] <seb128> MacSlow, thanks
[11:18] <didrocks> MacSlow: sweet, thanks a lot :)
[11:18] <MacSlow> seb128, didrocks: np yw
[11:18] <seb128> didrocks, let's start by asking if the issue is in the composer or in the email sent and if that happens with any names with an umlaut
[11:20] <didrocks> seb128: done, thanks
[11:24] <seb128> didrocks, thank you
[13:34] <didrocks> bug #525807 is really embarrassing when you are giving an ubuntu presentation
[13:34] <ubot2> Launchpad bug 525807 in openoffice.org (Ubuntu) (and 2 other projects) "[upstream] [3.2.1] OOo Slide Show and Fullscreen modes - not full screen under compiz (affects: 86) (dups: 6) (heat: 462)" [Medium,Triaged] https://launchpad.net/bugs/525807
[13:35] <seb128> didrocks, did you get hit by this?
[13:35] <didrocks> yeah, during the ubuntu party :)
[13:35] <didrocks> and I'm still hit by this
[13:35] <didrocks> (I'll give an ubuntu presentation in Paris this evening)
[13:35] <didrocks> just tested again and yeah, still there :/
[13:38] <seb128> we should make sure it gets fixed for .1
[13:38] <seb128> ccheney should be back to work so I guess he can work on this one
[13:38] <didrocks> right, this one should be high IMHO to not get dropped for .1
[13:39]  * didrocks tries in metacity as it seems to happen only with compiz from the report
[13:39] <seb128> you should use your netbook and unity for presentations I guess ;-)
[13:40] <didrocks> seb128: heh, unity had some issues with OOo fullscreen too during the party :-)
[13:40] <didrocks> ok, works with metacity, I can workaround with that
[13:41] <didrocks> I put that in autohide but when you show what's new, it wasn't really convenient
[13:42] <seb128> lol
[13:46] <seb128> it's not germany's day
[13:55] <didrocks> why?
[13:56] <ccheney> the fix that went into 3.2.1 should make it into our .1
[13:56] <didrocks> ccheney: apparently, the last person told that the fix in 3.2.1 doesn't work
[13:56] <didrocks> hey btw :)
[13:56] <ccheney> didrocks: hi :)
[13:57] <ccheney> didrocks: hmm, will have to look at the report again, to fix it properly required a pretty invasive change upstream, from what i recall so they were trying to first just fix it for gnome (iirc)
[13:58] <ccheney> but it has been a while since i last read the status for the bug
[13:58] <didrocks> ccheney: ok, if you need testing, do not hesitate
[13:58] <ccheney> didrocks: ok
[13:58] <didrocks> thanks ccheney :)
[14:01] <seb128> ccheney, hey
[14:01] <seb128> ccheney, how are you?
[14:01] <ccheney> seb128, doing pretty well :)
[14:02]  * ccheney brb, have to run to restroom before his daily mumble meeting
[14:04] <didrocks> 14:46:22        seb128 | it's not germany's day
[14:04] <didrocks> seb128: what happened to those poor germans? :)
[14:04] <seb128> didrocks, yeah, serbia scored one, germany got one player out due to a fault and they didn't score the penalty they had
[14:05] <didrocks> ok, it was football, not something broken on ubuntu :)
[14:06] <seb128> didrocks, no ;-)
[14:06] <seb128> right, it's football
[14:07] <didrocks> :-)
[14:07] <seb128> ccheney, didrocks: the slideshow bug is correctly lucid tasked with milestone for lucid .1 now
[14:08] <didrocks> seb128: thanks a lot
[14:08] <seb128> np, thank you for pointing it
[14:12]  * ccheney back
[14:59] <rickspencer3> good morning everyone
[15:06] <seb128> rickspencer3, hello! how are you?
[15:11] <didrocks> good morning rickspencer3
[15:12] <rickspencer3> hi seb128 and didrocks
[15:12] <rickspencer3> I
[15:12] <didrocks> reboot, bbiab
[15:12] <rickspencer3> m good, otp with stormy talking about guadec
[15:54] <seb128> kenvandine, Riddell: could you update https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus if you have anything to set there?
[15:54] <seb128> I will update the list of specs for the cycle in a bit
[15:55] <kenvandine> seb128, sure
[15:56] <seb128> kenvandine, thanks
[15:57] <kenvandine> seb128, the heat for the twitter change in gwibber is off, for now
[15:57] <kenvandine> seb128, they have postponed the change... but no new target date
[15:58] <kenvandine> seb128, they haven't even turned on the new service yet...
[15:58] <seb128> ok
[15:58] <seb128> kenvandine, let's move it to alpha3 then?
[15:58] <kenvandine> hopefully we'll hear when the new date is soon, hopefully it isn't too soon
[15:58] <kenvandine> ok
[16:02] <davidbarth> seb128, kenvandine: will update that now too; ping hard when it's my turn
[16:04] <seb128> davidbarth, ok
[16:39] <rodrigo_> is libappindicator0.1-cil broken in maverick? tomboy doesn't start for one user, while it works for another one
[16:39] <rodrigo_> and can't build a tomboy packae, it complaiuns:
[16:39] <rodrigo_> error CS0006: cannot find metadata file `/usr/lib/cli/appindicator-sharp-0.1/appindicator-sharp.dll'
[16:40] <seb128> rodrigo_, yes, tedg is working on it right now
[16:40] <rodrigo_> ah, ok
[16:40] <seb128> or I think he is
[16:41] <seb128> check with him
[16:46] <rodrigo_> tedg, ^^
[16:51] <tedg> rodrigo_, Sorry, right now learning to hate mono's al >:-(  Should hopefully be fixed in a bit.
[16:52] <rodrigo_> tedg, ok, let me know if you want me to test, I'm waiting on having it fixed for building a tomboy package
[17:32] <didrocks> ok, let's call it a week, going to Paris to give a conference on Ubuntu now :)
[17:34] <didrocks> enjoy your week-end everyone o/
[17:40] <seb128> didrocks, thanks, have fun today and a nice weekend ;-)
[17:45] <schmichael> Is there a simpler example than gwibber on using appindicator from python?
[17:45] <seb128> schmichael, jockey
[17:45] <schmichael> seb128: thanks
[17:45] <seb128> yw
[17:46] <seb128> schmichael, https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
[17:46] <seb128> schmichael, there is a small code example there as well
[17:46] <schmichael> seb128: yeah, I've done that, but it's a little too simple to be very useful
[17:47] <schmichael> and it uses appindicator when evidently using indicate is preferred
[17:47] <schmichael> and I'd like to integrate with the existing messaging appindicator
[17:49] <schmichael> "NOTICE: 'jockey' packaging is maintained in the 'Bzr' version control system at:"
[17:49] <schmichael> that's pretty cool!
[17:54] <schmichael> seb128: I'm not understanding how jockey uses appindicator. It appears to me to just be a gtk app that uses notify
[17:54] <schmichael> Considering I'm building a messaging related app, I think gwibber is probably what I should be looking at :(
[17:56] <seb128> schmichael, well appindicator does basically what the example on the wiki or jockey are doing...
[17:56] <seb128> ie adding a menu to an icon
[17:57] <seb128> it's what you get for ie the bluetooth icon in lucid
[17:57] <seb128> seems you want to integrate with the messaging menu though rather than using appindicator
[17:57] <seb128> you can ask questions about that on #ayatana
[17:58] <schmichael> hm
[17:58] <schmichael> I have a messaging application which will pop-up notifications that need to fire an event (eg launch an app)
[17:59] <schmichael> Since Ubuntu removed the ability for notifications to do anything, I figured appindicator was the route to go...
[17:59] <schmichael> is that correct? should I take these questions to #ayatana?
[17:59] <schmichael> (and wth is ayatana? I've been an Ubuntu user for years and never heard of that...)
[18:04] <schmichael> "The Ayatana Project is the collective project that houses user interface, design and interaction projects started by Canonical." hm
[18:10] <seb128> schmichael, the indicator work is ayatana work
[18:10] <seb128> as is notify-osd
[18:11] <seb128> schmichael, well, there is a specification about user interactions on the wiki
[18:11] <seb128> schmichael, incoming messages should be queued in the message indicator
[18:12] <seb128> schmichael, things which require user to know about and act with should probably be opened in a dialog
[18:12] <schmichael> hm, interesting. reading the full MessagingMenu wiki now
[18:12] <seb128> ok
[22:04] <Rebus> Perhaps i dropped the question of starting XFCE-desktop in the wrong room (#xubuntu)?
[22:59] <nessita> hello all
[22:59] <nessita> didrocks: you around? I managed to break python-mkdebian ;-)
[23:10] <arand> Is this a place to discuss potential papercuts? I that case I would like to point at Bug #479489 as a good candidate, I've even prepared to report a new bug before i found that, and did a writeup (use case abd all..): http://pastebin.org/340224
[23:10] <ubot2> Launchpad bug 479489 in compiz (Ubuntu) "disable Super+MiddleClick by default (affects: 1) (heat: 15)" [Medium,Triaged] https://launchpad.net/bugs/479489


[05:07] <didrocks> morning
[05:27] <TheMuso> Morning didrocks, I can only assume jetlag is involved here. :)
[05:27] <didrocks> TheMuso: hey! a little, bit not that much, it's only 30 minutes earlier than usual :)
[05:31] <TheMuso> Oh ok.
[07:30] <seb128> good morning desktopers
[07:31] <didrocks> salut seb128!
[07:31] <seb128> lut didrocks ;-)
[07:31]  * didrocks felt lonely on this channel :)
[07:31] <seb128> hehe, no pitti this week, so nobody early!
[07:31] <didrocks> yep ;)
[07:33] <willcooke> greets
[07:33] <didrocks> morning willcooke
[07:34] <willcooke> o/
[07:35] <seb128> hey willcooke
[07:35] <willcooke> mornin'
[07:47] <willcooke> ha - typical.  Running chromium from gdb, and it doesn't crash when I download something anymore
[07:48] <seb128> when it did, have you got a file in /var/crash?
[07:50] <willcooke> didn't look tbh - quengo hooked me up with the debug build of Chromium so hopefully it will happen again soon
[07:50] <seb128> you can still look, if you didn't empty the dir
[07:50] <willcooke> ah yes
[07:51] <willcooke> there is it
[07:51] <willcooke> it is
[07:51] <seb128> you can apport-unpack .crash <somedir> it and use gdb on the CoreDump
[07:54] <willcooke> I'll have a go
[07:57] <seb128> let me know if you need help on getting that to work
[07:58] <seb128> but it's basically "apport-unpack .crash dir; cd dir; gdb /usr/bin/<binary> CoreDump"
[09:47] <seb128> bah, since today chromium on utopic seems to give only error pages here :/
[09:48] <seb128> qengho, is there a known issue (using i386 if that makes a difference)
[09:54] <didrocks> going for a run
[09:56] <seb128> didrocks, enjoy!
[11:43] <qengho> seb128: I'm looking into Cr broken pages. I don't see it on my amd64.
[11:45] <qengho> seb128: is there anything in "dmesg" about it?
[11:46] <seb128> qengho,
[11:46] <seb128> [ 8715.000510] chromium-browse[19778]: segfault at 0 ip   (null) sp bff504cc error 14 in card0[a9712000+40000]
[11:47] <qengho> "card0".  /me boggles.
[11:47] <qengho> seb128: thanks
[11:47] <seb128> qengho, errors in libv8.so as well
[12:11] <qengho> seb128: reproduced. Thanks.
[12:11] <seb128> qengho, yw! thanks for looking at it, let me know how it goes
[13:01] <seb128> gatox, hey, do you think you are going to have some cycles to look at the update panel? You still have some work you started that didn't landed, and a stack of bugs assigned to you
[13:02] <gatox> seb128, i know... i need to land a couple of branches of pay-ui that are almost ready, and after that i'll be working on system settings
[13:02] <seb128> gatox, ok, thanks
[13:34] <seb128> kenvandine, when you comment approve and don't change the status, that's usually because you wait for CI?
[13:35] <kenvandine> yes
[13:35] <kenvandine> but your's doesn't really need CI :)
[13:35] <seb128> kenvandine, e.g https://code.launchpad.net/~seb128/ubuntu-system-settings/update-label-tweaks/+merge/230264 can be toggled to accepted then?
[13:35] <seb128> kenvandine, can you review that one liner as well?
[13:35] <seb128> https://code.launchpad.net/~seb128/ubuntu-system-settings/update-ubuntushaped-icons/+merge/230285
[13:36] <kenvandine> done
[13:36] <seb128> kenvandine, thanks
[13:36] <seb128> kenvandine, I guess we have enough to do another landing ;-)
[13:38] <kenvandine> seb128, not yet :)
[13:38] <kenvandine> i have 2 more branches i want to land this morning :)
[13:38] <kenvandine> reviewing now
[13:39] <kenvandine> more dual sim related branches, nice to finally have passing CI :)
[13:40] <kenvandine> just takes a little more time for manual testing
[13:42] <seb128> kenvandine, I'm wondering if I'm having another toolkit issue :-(
[13:42] <kenvandine> uh oh
[13:42] <kenvandine> what's that?
[13:42] <seb128> in the updates panel, the list of updates is not correctly aligned on the "install <n> updates" button
[13:43] <seb128> the list has a "anchors.top: installAllButton.visible ? installAllButton.bottom : parent.top"
[13:43] <seb128> if I change that to be ""anchors.top: installAllButton.bottom"
[13:43] <seb128> which should be the same when installAllButton.visible = true
[13:43] <seb128> there is no gap!
[13:44] <seb128> it's like the listview content was not properly starting at the top for some reason when there is a change
[13:45] <kenvandine> is the listview contentHeight set?
[13:45] <seb128> yes
[13:45] <seb128>         contentHeight: contentItem.childrenRect.height
[13:48] <rickspencer3> willcooke, seb128 anything interesting happening with Unity 8 desktop image yet?
[13:48] <rickspencer3> can sabdfl launch apps and stuff like that yet?
[13:48] <seb128> rickspencer3, define "interesting"
[13:49] <willcooke> :)
[13:49] <rickspencer3> seb128, interesting == I can run some apps
[13:49] <seb128> rickspencer3, it has daily builds
[13:49] <willcooke> rickspencer3, you can launch, e.g., gedit
[13:49] <rickspencer3> what about Touch apps?
[13:49] <seb128> willcooke, you need manual tweaks for that
[13:49] <rickspencer3> seb128, what could one do if they installed the daily image?
[13:49] <seb128> rickspencer3, you can run/install it, run our core apps (like webbrowser, gallery, phone apps in the sidebar)
[13:50] <seb128> rickspencer3, you can add an u1 account and install clicks from the store and run those
[13:50] <seb128> well
[13:50] <seb128> need to apt-get install qt5-defaults for that to work
[13:50] <seb128> I emailed ubuntu-devel@ about the qt4 being default issue, but didn't get any traction from our qt guys
[13:50] <seb128> not sure how to get things moving there :/
[13:50] <rickspencer3> seb128, well, I suppose focus on the phone customer right now is probably pretty distracting for them :/
[13:51] <seb128> yes
[13:51] <seb128> just saying, the desktop image is not very "interesting" because focus is on rtm
[13:51] <seb128> and we don't get much traction to have people looking at our issues
[13:51] <rickspencer3> seb128, maybe try pinging pmcgowan_ again, I think things may be loosening up
[13:51] <seb128> k
[13:51] <rickspencer3> willcooke, ^
[13:51] <willcooke> ack
[13:52] <rickspencer3> seb128, does anything run in the main stage yet?
[13:52] <rickspencer3> and do other Qt and Gtk apps run at all?
[13:53] <seb128> rickspencer3, the apps I listed before run in the main view
[13:53] <seb128> webbrowser
[13:53] <seb128> gallery
[13:53] <seb128> camera IIRC
[13:53] <seb128> Qt5 apps should run just fine
[13:53] <seb128> Gtk apps, we landed the Mir backend in utopic
[13:53] <seb128> you need to tweak the .desktop to have them listed in the dash though
[13:54] <seb128> I can run gedit from stock utopic with a .desktop hack
[13:54] <seb128> but input is not working
[13:54] <seb128> nor are menus and other stuff
[13:54] <seb128> mir is limited
[13:56] <rickspencer3> willcooke, seb128 can you guys paste me a link to the image that I can pass on to sabdfl
[13:56] <rickspencer3> and if there is a wiki, etc... for pointers to get rocking, that would be nice too
[13:56] <seb128> rickspencer3, http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/
[13:56] <seb128> rickspencer3, https://wiki.ubuntu.com/Unity8DesktopIso
[13:57] <seb128> rickspencer3, https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session
[13:57] <seb128> (the blueprint is referenced from the wiki as well)
[14:40] <willcooke> hey seb128 - whats the model number of that touch screen HP laptop?
[14:40] <willcooke> think I should get me some new hardware
[14:41] <seb128> willcooke, hp?
[14:41] <seb128> willcooke, the one I had in China was a Dell
[14:41] <willcooke> Dell, HP - whatevs ;)
[14:41] <seb128> inspiron 11 3000 serie
[14:41] <seb128> http://www.dell.com/us/p/inspiron-11-3137/pd
[14:42] <seb128> or http://www.dell.com/us/p/inspiron-11-3147-laptop/pd
[14:42] <seb128> seems to be the new serie
[14:43] <seb128> the one I have is a 3137
[14:49] <willcooke> ordered, thx seb128
[14:49] <seb128> willcooke, yw!
[14:49] <willcooke> seb128, do you know if it's a standard laptop hdd?
[14:49] <willcooke> like, I dont have to order a "slim" replacement or anything
[14:50] <willcooke> going to order a cheapo sdd
[14:50] <seb128> I don't know, sorry
[14:50] <willcooke> I'll take a punt on it, I reckon it will be
[14:50] <willcooke> actually - google
[14:52] <seb128> seems to be "9.5MM, 2.5""
[14:52] <willcooke> perfect, thanks seb128
[14:52] <seb128> yw!
[14:53] <seb128> willcooke, http://www.myfixguide.com/manual/dell-inspiron-11-3147-disassembly/
[14:54] <seb128> has a guide on how to get to the disk with a photo of it
[15:08] <jdstrand> bregma: hi! are there known bugs on multimonitor with unity7 on utopic?
[15:12] <willcooke> thx seb128
[15:12] <seb128> yw!
[15:16] <ChrisTownsend> jdstrand: There are some issues, yes.  Do you have a specific issue in mind?
[15:19] <jdstrand> ChrisTownsend: today I hotplugged my external monitor into my vga port on my thinkpad x201s (intel). I have it setup to turn off the laptop display and use the external. the external came up, but unity did not adjust the size and was frozen
[15:19] <jdstrand> ChrisTownsend: I had to stop lightdm. I then tried to login and when I did, all I had was the launcher and an empty panel. nautilus did not even come up
[15:20] <jdstrand> ChrisTownsend: I'm happy to file a bug or add info to an existing one
[15:20] <ChrisTownsend> jdstrand: Hmm, nothing we've touched in that area recently.
[15:21] <jdstrand> ChrisTownsend: I haven't plugged into this monitor much since upgrading to utopic a couple of weeks ago
[15:21] <jdstrand> when I upgraded to utopic, I has plugged into it
[15:22] <jdstrand> then I hot unplugged and it crashed with similar symptoms
[15:22] <ChrisTownsend> jdstrand: Hmm, sounds like some config got screwed up, but not sure what.  Please file a bug and I'll give it some attention.
[15:22] <jdstrand> ChrisTownsend: ack, thanks. against 'unity'?
[15:23] <ChrisTownsend> jdstrand: Could also be a graphics driver issue that is freaking out Unity.
[15:23] <ChrisTownsend> jdstrand: Yeah, unity is fine.  I'll change it if necessary.
[15:23] <jdstrand> ok, thanks
[15:23] <jdstrand> it'll be a bit, I need to step into a meeting
[15:23] <ChrisTownsend> jdstrand: I've been noticing some other weirdness wrt to drivers, so maybe related.
[15:23] <ChrisTownsend> jdstrand: No worries, I'll look for it.
[15:30] <seb128> hum, meeting it is!
[15:30] <willcooke> seb128, didrocks, attente_ qengho - it's meeting time in 5....4.....3.....2......1..... now!   Who'd I miss?
[15:30] <willcooke> curse you seb128
[15:30] <seb128> lol
[15:30] <willcooke> you beat me
[15:30] <didrocks> ahah
[15:30] <seb128> the indicator popped up a notification ;-)
[15:30] <willcooke> :)
[15:31] <seb128> willcooke, is tkamppeter off this week?
[15:31] <brookswarner> morning guys
[15:31] <seb128> not sure if you missed him in the list or if he's on vac
[15:31] <willcooke> seb128, kinda - he's a the Open Printing summit
[15:31] <seb128> k
[15:31] <seb128> so list looks good to me
[15:31] <didrocks> waow, short list, will be a short meeting :)
[15:31] <seb128> FJKong might still be around/wanting to should
[15:31] <seb128> to join
[15:31] <willcooke> and happyaron
[15:31] <FJKong> seb128: here
[15:31] <seb128> happyaron stops earlier than that
[15:32] <seb128> it's 11pm for them
[15:32] <willcooke> hey FJKong
[15:32] <FJKong> hey willcooke
[15:32] <seb128> hey FJKong ;-)
[15:32] <willcooke> FJKong is a night owl :D
[15:32] <willcooke> hey brookswarner
[15:32] <didrocks> FJKong: young coders :p
[15:32] <brookswarner> welcome back willcooke
[15:32] <FJKong> lol, I am a night bird
[15:32] <willcooke> folks, brookswarner is the EM for Sustaining Engineering
[15:33] <brookswarner> glad to hear you had a successful trip
[15:33] <dgadomski> hello everyone
[15:33] <willcooke> hey dgadomski
[15:33] <seb128> hey dgadomski
[15:33] <willcooke> welcome aboard
[15:33] <brookswarner> thanks willcooke
[15:33] <dgadomski> thanks! :)
[15:33] <brookswarner> i been lurking for months but don't say much
[15:33] <willcooke> Right - let's get this show on the road....
[15:33] <seb128> dgadomski, is Daruisz I guess?
[15:33] <didrocks> hey dgadomski
[15:33] <brookswarner> seb128, correct
[15:33] <willcooke> oh
[15:33] <seb128> dgadomski, welcome on board!
[15:33] <dgadomski> yes, it's Dariusz
[15:33] <willcooke> before we syaty
[15:34] <willcooke> start
[15:34] <FJKong> hey dgadomski
[15:34] <willcooke> didrocks and I were just on the Community Team hangout
[15:34] <seb128> willcooke, you might want to add him to the roundtable list then
[15:34] <seb128> willcooke, didrocks: how did it go?
[15:35] <willcooke> it was good.  We talked about the work that didrocks is doing on the dev desktop
[15:35] <didrocks> seb128: was fun, as usual. It seems the dev desktop has quite a bit of traction/interests
[15:35] <willcooke> it was a very quick intro, once didrocks is back from hols we'll publish it more
[15:35] <willcooke> right - let's get started then
[15:35] <willcooke> seb128 you first?
[15:35] <seb128> didrocks, nice ;-)
[15:35] <seb128> k
[15:35] <seb128> was in China for a week, back since yesterday. Quite some good discussions with the people working on Kylin, also about input methods in Ubuntu (using fcitx for Chinese)
[15:35] <seb128> • ubuntu-system-settings bugsfixing, worked on
[15:35] <seb128> ∘ text not smooth on the charge graph
[15:35] <seb128> ∘ rotation not being handled correctly on the same widget
[15:35] <seb128> ∘ error labels not wrapping as they should
[15:35] <seb128> ∘ the apps list using rectangle icon rather than ubuntushaped ones
[15:36] <seb128> • review u-s-s changes for others
[15:36] <seb128> • some bugs triaging
[15:36] <seb128> • reviewed a SRU change for precise
[15:36] <seb128> • reviewed and approved didrock's udtc

[15:36] <seb128> (the first item is missing its dot, copy error)
[15:36] <willcooke> seb128, do we want to talk more about fcitx now, or will we wait until next UOS?
[15:37] <seb128> willcooke, next UOS is not good for this cycle, we are going to use mailing lists rather
[15:37] <willcooke> ok, great
[15:37] <seb128> I plan to email ubuntu-devel@ once the support for it lands
[15:37] <seb128> call for testing, etc
[15:37] <willcooke> that will be an interesting discussion
[15:37] <seb128> yeah
[15:37] <seb128> well, we add support for it
[15:37] <seb128> and plan to make it default only for Chinese this cycle
[15:37] <seb128> assuming the feedback is good
[15:37] <seb128> if not we can revert to ibus for Chinese as well
[15:38] <willcooke> cool, seb128 are you blocked on anything/anyone?
[15:38] <seb128> that's a question for attente, he's doing the work
[15:38] <willcooke> I mean in general
[15:38] <seb128> he still had a few bugs he wanted to sort out before landing
[15:38]  * happyaron arrives...
[15:38] <seb128> hey happyaron
[15:38] <willcooke> happyaron, \o/
[15:38] <attente_> happyaron, hey
[15:39] <happyaron> hey everyone, :)
[15:39] <seb128> happyaron, 你好
[15:39] <seb128> ;-)
[15:39] <didrocks> evening happyaron :)
[15:39] <happyaron> great
[15:39] <FJKong> happyaron: hello qin
[15:39] <willcooke> ok, then let's move on to attente_ then since we're sorta talking about him - how was your week?
[15:39] <happyaron> FJKong: ...
[15:39] <willcooke> attente_, find your wallet yet?  ;)
[15:40] <attente_> bah, who needs it :)
[15:40] <seb128> that's an under the belt one!
[15:40] <attente_> lol
[15:40] <willcooke> \o/
[15:40]  * seb128 gives a yellow card to willcooke
[15:40] <seb128> ;-)
[15:40] <willcooke> XD
[15:40] <attente_> not much to report, i was trying last week to do the alternate fcitx transition work, but we decided to move forward on the approach in the ppa
[15:41] <attente_> and some small tweaks to system settings language panel, thanks seb128 for review
[15:41] <seb128> attente_, thanks for the changes!
[15:41] <willcooke> ok, attente_ you need anything from anyone?
[15:42] <attente_> nah, not at the moment
[15:42] <willcooke> cool
[15:42] <willcooke> didrocks, your go...
[15:42] <didrocks>  /!\ long report (covering last couple of weeks as no meeting)
[15:42] <didrocks> * Travelling to Guadec and China, lot of good discussions with people working on Kylin and GNOME ones. But that didn't stop to cover the following during those 2 weeks:
[15:42] <didrocks> * Ubuntu Developer Tools Center itself is now in utopic \o/ Support android-studio for now.
[15:42] <didrocks> * Updated ubuntu developer tools center dependencies in utopic, adding python3 flavors for argcomplete, packaged and uploaded nose-cov.
[15:42] <didrocks> * Packaging, integrate git buildpackage and shell completion support.
[15:42] <didrocks> * For trusty, created ubuntu-developer-tools-center ppa with all required dependencies that aren't high enough/doesn't meet python3 requirements (https://launchpad.net/~didrocks/+archive/ubuntu/ubuntu-developer-tools-center).
[15:43] <didrocks> * Hooked up pep8 and small tests to autopkgtests. Will need pitti's expertise to add network-linked tests as autopkgtests (medium and large tests).
[15:43] <didrocks> * pep8 and small tests running automatically on each commit to master.
[15:43] <didrocks> * Setup translations and import in launchpad. Completely translated to French (random pick ;))
[15:43] <didrocks> * Run all integration tests in a docker container now as medium tests + add some additional tests like wrong md5sum and certificates. There is no difference in term of code in large and medium tests: the only difference is medium tests are using a fake network, fake local packages, and a base docker container (isolated from the hosts system).
[15:43] <didrocks> * More tweaks on the docker ubuntu image and fighting in setup to have tests passing in this fake desktop env (a lot of wrapper and grumbling may have happened).
[15:43] <didrocks> * Rename binary itself to udtc and adapt tests + local provider to it. We can now run any tests against the local binary and library or the installed system ones, and with or without any virtualenv environment.
[15:43] <didrocks> * Machine with a daily trusty setup, need to run the tests against a real system daily from it and report results.
[15:43] <didrocks> * Add more tests, code cleanup, test speed optimization (14 medium tests were taking 464s and they are now at 109s) and misc bug fixes (md5sum, certificates support, download races, launcher in non existing xdg dir, apt cache refresh, switch as root…). We are now at 279 tests in total!
[15:43] <didrocks> EOW(s)
[15:43] <willcooke> blimes!
[15:43] <willcooke> just that?
[15:43] <didrocks> tried to DDOS your connection :p
[15:44] <didrocks> you know… because of fiber here ;)
[15:44]  * seb128 points didrocks to pastebin
[15:44] <willcooke> surely thats a yellow card referee?
[15:44] <seb128> indeed is
[15:44] <didrocks> seb128 likes giving points :p
[15:45] <willcooke> didrocks, you need anything from anyone before your holiday?
[15:45] <didrocks> train on time from the SNCF
[15:45] <didrocks> but that's it :)
[15:45] <seb128> didrocks, when are you off? tomorrow evening or thursday?
[15:45] <didrocks> thursday evening
[15:45] <seb128> k
[15:45] <didrocks> will be back on the 27th
[15:45] <willcooke> happy trails didrocks
[15:45] <seb128> do you have some free slots before that?
[15:45] <didrocks> thanks ;)
[15:46] <didrocks> seb128: I can postpone what I want to do if needed
[15:46] <didrocks> why? anything I can help with?
[15:46] <seb128> happyaron is opening MIRs for fcitx, it would be nice if you could maybe look at some before your holidays
[15:46] <didrocks> sure
[15:46] <didrocks> will it be opened before our tomorrow?
[15:46] <seb128> because that needs to land for FF and you know how it is to find reviewers
[15:46] <seb128> happyaron ^?
[15:46] <didrocks> so that we can get some cycle back-and-force if needed
[15:46] <didrocks> yeah, I know ;)
[15:46] <seb128> didrocks, thanks
[15:46] <didrocks> yw!
[15:46] <happyaron> didrocks: after my getting up again, :)
[15:47] <didrocks> happyaron: as long as it's ready before my getting up, that's awesome
[15:47] <didrocks> happyaron: I'll ping you directly on IRC to speed up the process, just assign it to me
[15:47] <didrocks> (the bug)
[15:47] <happyaron> ok
[15:47] <didrocks> thx!
[15:48] <willcooke> ok, qengho - you around?  Anything to report?
[15:48] <qengho> Hey hey.
[15:48] <qengho> * in-progress: x86-utopic crasher.
[15:48] <qengho> * in-progress: mir support for chromium-browser/ozone.
[15:48] <qengho> * in-progress: Fl*sh plugin for partners repo.
[15:48] <qengho> willcooke: I don't know if that's the problem you saw.
[15:48] <qengho> #1
[15:49] <willcooke> could be, have you got a bug number handy?  I've been running via gdb all day, not crashes so far
[15:49] <willcooke> oh wait
[15:49] <willcooke> I'm not running U :/
[15:49] <willcooke> meh
[15:49] <qengho> I haven't filed a bug report yet.
[15:50] <willcooke> I'll see if I can get it to crash and let you know
[15:50] <willcooke> any progress with v36?
[15:50] <qengho> willcooke: v36 is uploaded.
[15:51] <willcooke> woot!
[15:51] <willcooke> sorry, I must have missed that
[15:51] <seb128> \o/
[15:51] <didrocks> sweet
[15:51] <willcooke> congrats qengho
[15:51] <willcooke> and thanks
[15:51] <seb128> qengho, is the x86 "not working" specific to utopic?
[15:51] <qengho> I should have lead with that.
[15:51] <seb128> or does it happen in all series?
[15:52] <qengho> seb128: I have only heard of problems in U. T and earlier had the update last week, so I think I would have heard.
[15:52] <seb128> k
[15:52] <seb128> good
[15:53] <willcooke> qengho, need anything from anyone?  Blocked on anything?
[15:54] <qengho> Nope. I'm blocked on understanding mir, but I can fix that.
[15:54] <willcooke> :D
[15:54] <willcooke> ok, let's go to happyaron and FJKong so they can get to bed :)  happyaron how was your week?
[15:56] <willcooke> or maybe FJKong ?
[15:56] <FJKong> fix bugs of sogou input method, prepare to release 1.1 version
[15:56] <FJKong> meeting with NUDT at ChangSha
[15:56] <FJKong> that's all maybe
[15:56] <willcooke> FJKong, cool - do you need anything from anyone?
[15:57] <FJKong> not yet now, maybe some days later
[15:57] <willcooke> ok, let me know and we'll get you sorted out
[15:57] <FJKong> after new version release
[15:57] <happyaron> line dropped..
[15:57] <willcooke> :)
[15:57] <willcooke> happyaron, how was your week?
[15:59] <happyaron> willcooke: a tiring week, mostly spent on talking to people everywhere, and merged ibus for two upstream releases, plan with attente_ on the fcitx transition
[15:59] <willcooke> :)
[16:00] <willcooke> happyaron, are you blocked on anything (not including the fcitx work which is on going)
[16:00] <happyaron> think no
[16:00] <willcooke> kk
[16:00] <attente_> happyaron, about the patch you made to fcitx, we might have to revert it...
[16:01] <happyaron> attente_: you have changed the plan, right? :)
[16:01] <attente_> happyaron, lol, don't worry :P
[16:02] <attente_> happyaron, it removes the /keyboard object path from the fcitx dbus service, is that what we wanted?
[16:03] <happyaron> attente_: so it does not handle keyboard anymore
[16:03] <attente_> happyaron, this is fine, it's just that we wanted to disable the fcitx switching shortcut
[16:04] <attente_> in the ppa is a unity-control-center that filters out the keyboard layout engines that fcitx provides, so we don't have to worry about that problem
[16:04] <happyaron> ok
[16:05] <attente_> i hope i'm not misunderstanding what the patch is meant to do happyaron
[16:05] <attente_> if i'm wrong please correct me
[16:07] <happyaron> it just disables whatever related to xkb handling in fcitx, so that if we switched keyboard layout in u-s-d, it won't be reset by fcitx
[16:08] <willcooke> let's take this to the side once the meeting is over.
[16:08] <willcooke> ok, so brookswarner or dgadomski - you guys have anything for us?  Questions etc?
[16:08] <dgadomski> no questions yet from me, I just wanted to thank you for welcoming me and I look forward to working with you!
[16:08] <brookswarner> i dont today willcooke
[16:08] <brookswarner> thank you
[16:08] <willcooke> coolio
[16:08] <attente_> happyaron, oh, i guess i did misunderstand after all
[16:08] <willcooke> any other business?
[16:08] <seb128> not from me at least
[16:08] <attente_> happyaron, ok, don't revert it
[16:09] <seb128> we can continue the fcitx discussion off meeting
[16:09] <didrocks> nothing from me as well
[16:09] <attente_> i have a swap day today, so i might take some time off in the afternoon to get my wallet stuff resolved
[16:09] <willcooke> day off fail attente_
[16:09] <seb128> attente_, good luck with that
[16:10] <seb128> attente_, btw let me know when you think the ppa is ready for optin for xkb users
[16:10] <willcooke> ok - that's a wrap.  Thanks all - until next week....
[16:10] <attente_> it shouldn't affect xkb users in the slightest
[16:10] <happyaron> attente_: k
[16:10] <attente_> it's literally the bare minimum we need to get fcitx integration in the stack
[16:11] <seb128> willcooke, thanks
[16:11] <didrocks> thanks!
[16:11] <seb128> attente_, k, said differently ... tell me when you can user testers, or/and if you need sponsoring
[16:12] <attente_> seb128, thanks, could use some reviews for https://code.launchpad.net/~attente/indicator-keyboard/fcitx-transition/+merge/229737 and https://code.launchpad.net/~attente/unity-settings-daemon/fcitx-transition
[16:13] <attente_> er, second one is https://code.launchpad.net/~attente/unity-settings-daemon/fcitx-transition/+merge/230289
[16:13] <seb128> attente_, k, on my list for tomorrow
[16:14] <attente_> seb128, thanks
[16:16] <seb128> yw!
[16:27] <kenvandine> attente_, i ran into merge conflicts when adding your 2 settings branches to a silo
[16:27] <kenvandine> attente_, can you make sure they merge with trunk cleanly?
[16:35] <attente_> kenvandine, sure
[16:36] <kenvandine> attente_, thx... the both had conflicts, even separately in the silo
[16:36] <kenvandine> i removed them for now, but can add them again in a bit
[16:37] <attente_> kenvandine, this is kind of strange, i'm not seeing the conflicts
[16:37] <kenvandine> hummm
[16:37] <attente_> they're the u-s-s branches called language-use-gsettings-qt and 1352398
[16:37] <attente_> ?
[16:39] <attente_> 1352398 depends on language-use-gsettings-qt if that might have some affect
[16:39] <attente_> *effect
[16:43] <seb128> kenvandine, weird, we didn't change that panel for a while afaik
[16:43] <kenvandine> yeah... weird
[16:43] <seb128> kenvandine, in what file do you get conflicts?
[16:44] <kenvandine> Text conflict in plugins/language/language-plugin.h
[16:44] <kenvandine> oh
[16:44] <kenvandine> lp:~jpakkane/ubuntu-system-settings/cleanups
[16:44] <kenvandine> that caused the conflict
[16:44] <seb128> oh, right
[16:44] <seb128> can you rather drop that one?
[16:44] <kenvandine> ok... let me get this built first
[16:44] <seb128> the other ones are missing features/fixes that need to land
[16:45] <kenvandine> will do
[16:45] <seb128> thanks
[16:45] <seb128> attente_, ^ no need to do anything from your side
[16:45] <seb128> we can ask Jussi to rebase once the other ones land
[16:47] <attente_> cool thanks!
[17:12] <willcooke> ZOMG!
[17:12] <willcooke> Check it:
[17:12] <willcooke> Copy some text to your clipboard
[17:12] <willcooke> in Chromium middle click on the new new tab icon
[17:23] <sarnold> neat
[17:23] <seb128> indeed
[17:37] <willcooke> hrm
[17:37] <willcooke> seb128, do we make .torrents available for iso downloads any more?
[17:37] <willcooke> more specifically, the Desktop next image
[22:49] <mikeg3> Hi I am having a very difficult time getting Ubuntu installed and just working right.  Is this the place to get help?


[12:51] <Pip__> hi, I can't open alsamixer without doing 'sudo alsamixer'.  What am I missing?  Usually there's no problem with just 'alsamixer'.  This is a fresh mini-iso install
[14:19] <ciccio> Hi, I'm updating mu xubunt 12.04 and the installation got stuck for about an hour at zz.update.grub-generic etc. then it moved on to generating grub.cfg and it's been stuck there for an hour now. what shall I do?
[14:24] <cortman> it can take a good while
[14:24] <cortman> just let it for another bit
[14:32] <ciccio> thanx. now it moved on to 'found initrd image'. I keep faith and when I 'll have to leave the office I'll let the pc on. I'm scared that interrupting the update process may compromise the system's integrity.
[15:48] <ciccio> quit
[15:49] <smartboyhw> ciccio: Use "/quit"


[14:24] <alex_mayorga> timeless: ping
[15:40] <cousin_luigi> Hello.
[15:45] <cousin_luigi> micahg: Tell me, how safe is to use the ubuntu-mozilla-security repository? In what way do packages in it differ from ubuntu security?
[15:45] <cousin_luigi> Qualitatively, that is.
[16:01] <alex_mayorga> Hello! Can anyone here do something about "Failed to build" at https://launchpad.net/~ubuntu-mozilla-daily ?
[17:15] <micahg> cousin_luigi: ubuntu-mozilla-security is where we stage Mozilla security updates and is possible to use to pretest the updates, stable updates usually go there a few days before release, you'd basically be using RC quality stuff, there might be stuff warranting a respin in there, but relatively believed to be stable
[17:20] <Omega> even nightly has been stable from my experience
[17:34] <cousin_luigi> micahg: Okay.
[17:34] <cousin_luigi> micahg: Thanks.
[18:52] <FernandoMiguel> evening
[21:49] <cousin_luigi> bbl
[21:54] <alex_mayorga> timeless: I tried to complete what you requested at http://piratepad.net/c3berohKLm
[22:10] <chrisccoulson> right, thunderbird-stable and firefox-stable PPA's are on again :)
[22:11] <Omega> :)
[22:11] <Omega> great job my friends
[22:23] <alex_mayorga> chrisccoulson: how about daily builds?
[22:24] <chrisccoulson> alex_mayorga, the daily builds are all broken atm
[22:24] <chrisccoulson> i'll try and fix them in a bit, but i'm meant to be on vacation :)
[22:24] <chrisccoulson> they always break when i go on vacation
[22:30] <alex_mayorga> chrisccoulson: I see
[22:30] <alex_mayorga> chrisccoulson: hope it'd be an easy fix, if not, enjoy your vacation


[02:59] <wallyworld__> thumper: yo
[03:12] <thumper> wallyworld__: hey
[03:12] <thumper> wallyworld__: how's it going today?
[03:12] <wallyworld__> thumper: notice how i didn't ping :-)
[03:12] <wallyworld__> going ok, deep into some refactoring
[03:12] <thumper> wallyworld__: as you may have seen, I've put the kvm broker review up
[03:12] <thumper> wallyworld__: yeah...
[03:12] <wallyworld__> thumper: funny that, i have a question
[03:12] <thumper> wallyworld__: I'm now getting containers to return hardware characteristics
[03:13] <wallyworld__> quick hangout?
[03:13] <wallyworld__> https://plus.google.com/hangouts/_/76cpj9mtcok4cua6di82i0o3ms?hl=en
[03:14]  * thumper joins
[04:39] <thumper> wallyworld__: https://codereview.appspot.com/36980043/
[04:40] <wallyworld__> \o/
[04:41] <thumper> wallyworld__: it's a start
[04:41] <wallyworld__> yes
[04:45] <thumper> thanks for the review
[04:45] <thumper> I'll tweak and land tomorrow morning
[04:45] <thumper> night all
[05:28] <axw> gtg to my daughter's school orientation, bbl
[06:43] <axw> back
[08:14] <rogpeppe> mornin' all
[08:16] <axw> morning
[08:24] <jam> smoser: there was a discussion about allowing charms to add constraints (like mem, etc), I could see that being extended to support stuff like "!lxc". However, that probably isn't on the roadmap for this cycle.
[09:18] <axw> jam: I forget, do we need to support old CLI with new server?
[09:18] <axw> jam: just wondering if I can remove secrets pushing API
[09:19] <axw> server-side
[09:19] <jam> axw: the old CLI didn't push secrets via PI
[09:19] <jam> API
[09:19] <jam> so yes, but we don't have to keep that bit
[09:19] <jam> axw: we have to allow the old CLI direct DB access
[09:19] <axw> jam: ah, it's only on trunk isn't it?
[09:19] <axw> no.. I broke the last release
[09:20] <jam> axw: ? you broke the new CLI connecting to the old server
[09:20] <jam> IIRC
[09:20] <jam> but we can drop that bit
[09:20] <jam> right now we are trying and if it fails just continuing
[09:20] <axw> ok
[09:20] <jam> with synchronous bootstrap, we don't even have to try anymore :)
[09:20] <axw> jam: well, we should still push secrets for old servers, right?
[09:21] <axw> or do we not care?
[09:21] <axw> assume they're already set up?
[09:21] <jam> axw: even if there was a 1.17.0 that had async bootstrap and we were pushing via the API as a dev release wedon't have to push secrets to it in 1.17.1
[09:21] <jam> axw: we don't care if it is only a dev release
[09:21] <jam> thats why we call them *dev*
[09:21] <axw> jam: sorry, I mean, can we drop the code that pushes secrets to existing installations
[09:21] <jam> it is our way of "lets get this out there, without committing to supporting migration to/from it"
[09:21] <axw> of non-dev
[09:22] <jam> axw: so for pushing secrets directly to the DB, I'm not sure if we can drop it.
[09:22] <jam> "maybe"
[09:22] <jam> we had talked about "if you bootstrap with 1.16 and then *never do anything with it* and then try to connect with 1.17" that might be broken, but we're not sure we care
[09:22] <axw> I really don't think we should
[09:23] <jam> (you can destroy-env & rebotstrap because you have nothing in your env, or you can connect with the 1.16 that you bootstrapped, etc)
[09:23] <axw> indeed
[09:23] <jam> axw: so *I* wouldn't immediately say "when connecting via direct DB access don't pass secrets"
[09:23] <jam> axw: it isn't worth poking that code just to remove it if we don't have to touch it at all
[09:23] <jam> axw: I'd much rather focus on "we never connect to the DB for a 1.18 client and server"
[09:23] <jam> so that instead of having a "and now we don't push secrets" we end up with a "and now we never connect to the DB"
[09:24] <jam> axw: so *probably* we could drop it, but I'd rather get to the point where we can drop NewConnFromName completely
[09:24] <axw> understood
[09:24] <axw> hmm
[09:25] <axw> jam: the reason why I'd like to remove it altogether, is then we can get rid of the idea of secrets
[09:25] <axw> but I can leave it for now I guess
[09:27] <jam> axw: we can't. we still have to not put the secrets into cloud-init, and only pass them once we connect to the bootstrap node
[09:27] <jam> axw: the reason we have them today is to not put them into cloud-init
[09:27] <axw> jam: that bit's irrelevant, we never put any config into cloud-init anymore
[09:27] <axw> (with synchronous bootstrap)
[09:28] <axw> cloud-init now does ssh keys, and that's it
[09:29] <jam> axw: so IMO, changing that isn't our first priority right now. I do like that, but I'd be fine if getting rid of the notion of secrets was in 1.20
[09:29] <axw> mmkay
[09:29] <jam> axw: vs, we actually have to finish stuff like upgrade-charm and status or we can't remove direct DB access in 1.20
[09:31] <jam> axw: and, of course, time spent with sinzui to make sure CI is happy is time very well spent.
[09:31] <axw> jam: indeed. not sure what's going on there :/
[09:31] <axw> I can't reproduce the issues on either canonistack or ec2
[09:32] <jam> axw: I haven't been able to either. there was a comment about connection flakiness for them. Certainly how did we get a machine up and running and then not have SSH configured.
[09:32] <jam> axw: one thing I was wondering
[09:32] <jam> how do we pick the ssh private key to connect with?
[09:32] <jam> If I set "authorized-keys: foobar" in my environments.yaml how do you match that with eg ~/.ssh/id_rsa_ec2key
[09:33] <axw> jam: by default I think it takes id_dsa.pub, id_rsa.pub and identity.pub from ~/.ssh
[09:34] <axw> jam: now sure what you mean by "how do you match that"
[09:34] <axw> I think ssh will just cycle through all the possible private keys on ~/.ssh?
[09:35] <jam> axw: no
[09:35] <jam> it cycles through everything in your ssh-agent
[09:35] <jam> I think
[09:36] <jam> but for direct keys you can configure it in ~/.ssh/config or supply it as "ssh -i PATHTOKEY" or a couple of other ways.
[09:36] <jam> but I'm pretty sure it doesn't just try keys on disk
[09:36] <jam> I could be wrong, and I've overspecified my ssh config
[09:36] <axw> no actually I think you're right
[09:36] <jam> but I was wondering if what sinzui and aaron were seeing was because of keys not getting picked up correctly.
[09:36] <axw> it'll also try those defaults I mentioned
[09:37] <axw> jam: well, that bit hasn't changed at all, so I don't understand how that'd be the case
[09:37] <jam> axw: right, the specific 2/3 private bits
[09:37] <jam> axw: they weren't having Juju drive SSH before
[09:37] <jam> axw: in the test suite
[09:37] <axw> ah, true.
[09:37] <axw> :)
[09:37] <jam> they were copying logs of via scp at one point
[09:37] <jam> but that command *might* be configured specially
[09:38] <jam> the fact that they get "Permission denied (publickey)" sometimes hints that *something* is doing tat.
[09:38] <jam> axw: for Canonistack, I've heard another wrinkel
[09:38] <jam> if you give a Canonistack instance a floating IP
[09:38] <jam> that becomes a world-routable IP, but it is *not* routable within the cloud
[09:38] <jam> so machine A on canonistack has to talk to machine B in canonistack via the private address, and *not* the floating ip
[09:39] <jam> axw: so you might try "use-floating-ip: true" in your canonistack config and see if that breaks bootstrap for you
[09:39] <axw> hurngh
[09:39] <jam> it shouldn't from local
[09:39] <jam> but it might from cstack => cstack
[09:39] <axw> no, but maybe from jenkins
[09:39] <jam> axw: ah, also
[09:40] <jam> you can't directly connect to CStack machines
[09:40]  * jam => lightbulb
[09:40] <axw> yeah, gotta sshuttle
[09:40] <rogpeppe> anyone know anything about amazon request limits?
[09:40] <jam> axw: actually most people configure their SSH to bounce via chinstrap
[09:40] <jam> axw: ProxyCommand ssh chinstrap.canonical.com nc -q0 %h %p
[09:40] <rogpeppe> i'm still trying to get this guy's environment up, and we're seeing "Request limit exceeded" errors
[09:41] <jam> axw: so for CStack abentley and sinzui both probably have that, which would let them SSH to a machine, but would *not* let them Dial a machine
[09:41] <axw> jam: doesn't explain the permission denied error tho
[09:41] <jam> rogpeppe: more that 100/5s is going to trigger their limits, but I don't know what the actual values are (xplod charm was causing amazon request limit exceeded problems before we fixed it)
[09:42] <jam> axw: It would explain not being able to connect, but yes, doesn't explain perm denied
[09:42] <axw> I think you're probably onto something with the private keys/them not using ssh before
[09:42] <jam> axw: connect as "ubuntu" user?
[09:42] <axw> jam: yep
[09:42] <rogpeppe> jam: we're still seeing this error after a night of inactivity
[09:42] <jam> axw: I *think* user@host:port is openssh specific
[09:43] <jam> rogpeppe: whose inactivity :)
[09:43] <jam> rogpeppe: everything shut down?
[09:43] <rogpeppe> jam: well, we stopped jujud-machine-0
[09:43] <jam> rogpeppe: i
[09:43] <rogpeppe> jam: i wonder if the other instances are making ec2 requests
[09:44] <jam> if this was 1.13.2 the User and Machine agents had provider creds, IIRC
[09:44] <rogpeppe> jam: everything is on 1.16.3 AFAIK
[09:44] <jam> so they could have been doing it
[09:44] <jam> rogpeppe: did you actually get it all moved over?
[09:44] <rogpeppe> jam: yes
[09:44] <rogpeppe> jam: but now we're getting this problem
[09:44] <rogpeppe> jam: one issue after another :-(
[09:53] <axw> wow, that ping thread is getting on a bit
[09:54] <rogpeppe> axw: which ping thread?
[09:55] <axw> rogpeppe: warthogs
[09:56] <rogpeppe> axw: ha fun
[09:56] <rogpeppe> axw: i don't look at warthogs much
[09:58] <TheMue> rogpeppe: any chance to take a look at my CL today?
[09:59] <TheMue> rogpeppe: oh, and hello btw
[09:59] <rogpeppe> TheMue: i started on it yesterday, will continue today
[09:59] <TheMue> rogpeppe: ah, looking forward, thx
[09:59] <rogpeppe> TheMue: the main issue i have with it so far is that it always reads from the very start of the file
[10:00] <rogpeppe> TheMue: and for very big files (and log files can be very big) that's a significant waste of resources
[10:01] <TheMue> rogpeppe: I have to admit I stole an algo of you of the newsgroup :)
[10:01] <rogpeppe> TheMue: ha ha
[10:02] <TheMue> rogpeppe: but doing the initial reading from the end indeed seems better
[10:02] <rogpeppe> TheMue: when was that from?
[10:02] <TheMue> rogpeppe: oh, pretty old, would have to look again
[10:02] <TheMue> rogpeppe: but I liked the clean approach
[10:02] <jam> TheMue, rogpeppe: one thought would be that the api could pass in a possible "bytes from start" to give some context as to where it was looking, which might be a negative number to mean from the end of the file ?
[10:03] <rogpeppe> jam: i think it would be more intuitive if the api passed in number of lines of context
[10:03] <jam> rogpeppe: it would, but it is also *very* hard to do efficiently, vs if you had a byte offset hint
[10:03] <jam> it could even just be a hint
[10:03] <rogpeppe> jam: or even a start date
[10:03] <rogpeppe> jam: it's not too hard
[10:04] <rogpeppe> jam: i've done it before, and tail(1) does it without too much difficulty
[10:04] <TheMue> rogpeppe: but even then you would have to find it in the file first. ok, a binary search could hel.
[10:04] <rogpeppe> TheMue: you can't do binary search
[10:04] <rogpeppe> TheMue: but you can read backwards
[10:05] <rogpeppe> TheMue: actually, you could binary search if you're looking for a start date
[10:05] <TheMue> rogpeppe: that's what I meant
[10:05] <rogpeppe> the difficulty with a start date is clock skew
[10:06] <rogpeppe> log lines won't necessarily be in strict date order
[10:06] <rogpeppe> but that might not be too much of a problem in practice
[10:07] <TheMue> rogpeppe: will talk to frankban if that inaccuracy would be ok there
[10:07] <dimitern> rogpeppe, fwereade_, mgz, jam, others interested: PutCharm proposal document for comments https://docs.google.com/a/canonical.com/document/d/1TxnOCLPDqG6y3kCzmUGIkDr0tywXk1XQnHx7G6gO5tI/edit#
[10:07] <rogpeppe> and as for client vs server clocks, you could probably ask for a given duration before the last log message
[10:08] <TheMue> rogpeppe: hey, that's a nice approach, like it
[10:08] <TheMue> rogpeppe: with different operating modes I still can keep the full scan if wanted
[10:09] <rogpeppe> dimitern: looking
[10:11] <jam> TheMue: I think the GUI probably wants "as many old lines as is comfortable to put into the UI" so strictly restricting by date might be unwanted
[10:11] <jam> consider "it failed 2 days ago"
[10:11] <jam> or "it looks failed, when did it fail" ?
[10:11] <jam> So *hinting* to make finding the right value sounds good, but assuming it is just a hint is probably worthwhile
[10:12] <rogpeppe> jam: i think that's probably more of an argument for being able to move back in time
[10:12] <jam> I guess you could just seed "estimated size of line" in the code, and then update that estimation for a given request as you read through stuff and filter it
[10:12] <jam> rogpeppe: sure, but what estimate is 'good' for 100 lines
[10:12] <rogpeppe> jam: i don't think we need to estimate in bytes
[10:13] <jam> rogpeppe: I mean we don't have the API hint, but we use an internal hint
[10:13] <jam> given that you might have a really noisy machine that *isn't* in the filter
[10:13] <jam> or the machine you are reading is noisy itself
[10:14] <rogpeppe> jam: are you suggesting this as an optimisation?
[10:14] <jam> rogpeppe: right
[10:14] <jam> I think we don't need to expose it to the UI, and we do already have "num lines" in both the CLI and in what the GUI would like
[10:14] <jam> that said
[10:14] <rogpeppe> jam: i'm not entirely sure i see how it helps
[10:15] <jam> rogpeppe: I think we can land an unoptimized version as long as we can think of a way to make it better when we need to.
[10:15] <rogpeppe> jam: could you explain?
[10:15] <TheMue> jam: yep, wanted is number of lines
[10:16] <jam> rogpeppe: so we want to get (eg) 100 lines of filtered context for the UI. We start at some place near the end, read and determine how many filtered lines are in that space, and then jump back an estimate based on the number of lines we've found so far.
[10:16] <jam> you could make the default start 1MB from the end of the file, which might catch 90% of the actual cases
[10:16] <jam> but the specific tweaks would all be things that we'd actually need real world testing to fine tune
[10:16] <jam> so lets not optimize too much until we have evidence that it is a problem
[10:16] <rogpeppe> jam: so you're suggesting that we might or might not return the number of lines requested by the user?
[10:17] <rogpeppe> jam: personally i prefer to avoid heuristics when we can
[10:17] <jam> rogpeppe: I'm saying we start with an estimate of where those lines might be, and keep looking until we find them, potentially hitting the beginning of the file
[10:17] <jam> rogpeppe: seeking from the end ==> heuristic about how much you should read in one chunk, etc
[10:18] <rogpeppe> one mo, am just going to check if this guy's environment is actually working
[10:18] <jam> if we do "something" that is ~ reasonable, we get most of the benefit and can drive the rest of the work by actual content
[10:19] <jam> TheMue: so I guess my point is, we know the log file can get to multiple GB, so a small amount of "try to get the answer near the end of the file" is worth implementing. But don't do a lot of work to optimize the code until we actually know it is a problem
[10:19] <TheMue> jam: btw, how often do we log rotate?
[10:20] <jam> TheMue: we don't yet
[10:20] <jam> IIRC natefinch started on something, but he wasn't able to get all files so stopped trying
[10:20] <TheMue> jam: ouch
[10:21] <jam> (he could get all-machines.log to be better, but juju itself kept the log file handle open, so it just kept writing to the rotated place)
[10:21] <jam> TheMue: bug #1191651
[10:21] <_mup_> Bug #1191651: Juju logs don't rotate. <canonical-webops> <canonistack> <logging> <pyjuju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1191651>
[10:22] <jam> or bug #1078213
[10:22] <_mup_> Bug #1078213: juju-machine-agent.log/logs are not logrotated <amd64> <apport-bug> <canonical-webops> <canonistack> <logging> <precise> <juju-core:Triaged> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1078213>
[10:22] <TheMue> jam: ic, and needs indeed a solution, especially for larger environments
[10:23] <jam> TheMue: sure, and it will probably also end up interfering with debug-log, which we'll want to sort out, but it can be an exercise in the future for now
[10:23] <jam> though I think just rotating all-machine.log would be a big win today
[10:23] <TheMue> jam: yep
[10:23] <jam> even if we aren't rotating everything
[10:24] <jam> all-machines.log is something we can do 'easily' because rsyslog already has hooks for rotating its log files
[10:24] <jam> vs jujud that would need a SIGHUP or something to be added
[10:27] <TheMue> jam: btw, did you looked at the CL so far?
[10:28] <jam> TheMue: only in brief, I didn't review it.
[10:31] <TheMue> jam: ah, ok
[10:31] <rogpeppe> oh darn, another problem encountered.
[10:31] <rogpeppe> 2013-12-04 10:19:20 ERROR juju.provisioner provisioner_task.go:342 cannot start instance for machine "77": cannot set up groups: cannot authorize securityGroup: The permission '36226792-3--1--1' has already been authorized on the specified group (InvalidPermission.Duplicate)
[10:31] <rogpeppe> anyone seen the above error before?
[10:32] <jam> rogpeppe: I saw it once. After I had a permission group and I added ICMP to it. Then destroyed and rebootstrapped
[10:32] <jam> because destroy doesn't delete perm groups
[10:32] <jam> it saw a group that already existed and tried to reconfigure it
[10:32] <jam> apparently in a duplicate fashion
[10:32]  * rogpeppe goes to look at that logic
[10:33] <jam> rogpeppe: I *fixed* it by deleting all the low-numbered juju-ENV-0,1,2 etc groups
[10:33] <rogpeppe> these guys are really seeing the worst of juju
[10:33] <jam> in this case, you'd want to delete juju-ENV-77
[10:33] <jam> juju-ENV-machine-77, I think
[10:36] <rogpeppe> jam: hmm, i guess it might just be an eventual consistency issue
[10:37] <rogpeppe> jam: we revoke first, but perhaps the authorize hasn't seen the initial revoke, so it gives the duplicate error
[10:46] <rogpeppe> jam: FYI i just looked at all their security groups and there's no security group for machine 77
[10:46] <jam> mgz: rogpeppe: TheMue: standup ?
[10:46] <rogpeppe> jam: i think it must be the global group
[10:46] <jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[10:47] <jam> could be
[10:48] <mgz> there in a sec
[11:14]  * dimitern gives up on the hangout
[11:24] <jam> mgz: I approved your https://code.launchpad.net/~gz/juju-core/1.16-juju-update-bootstrap-tweak/+merge/196950 but you might want to hold off for a tick
[11:24] <jam> IsStateServer got renamed to IsManager in the old 1.16.4 stuff
[11:24] <jam> so it conflicts there
[11:25] <mgz> wait, we moved the rename back to 1.16 in the end?
[11:25] <jam> mgz: that is part of destroy-machine --force, which is still targetted to the 1.16 series (as in something that customers do need, so we're putting it into the current stable series)
[11:25] <mgz> >_<
[11:26] <mgz> I'll merge and fixup conflicts
[11:26] <jam> mgz: it hasn't landed yet, I accidentally proposed against trukn
[11:28] <mgz> okay, so if I win the race, *you* have to fix it  up? :0
[11:28] <mgz> that was not the correct smilie...
[11:31] <jam> mgz: that is true, but I just marked mine approved
[11:31] <mgz> :D
[11:32] <jam> mgz: well, frank's stuff is in the queue now, so you have a chance
[11:33] <jam> depending on what the bot finds first :)
[11:48] <jam> mgz: mine landed first :)
[11:49] <mgz> I let you win :P
[11:49] <jam> I didn't realize you could do that, what does it look like on your end (Insert horizontal rule)
[11:50] <TheMue> mgz, jam: geeks :D
[12:16]  * TheMue => lunch
[12:52] <axw> hey natefinch. got my xps 15 today - did you have any issues loading 13.10 onto it?
[12:52] <axw> I'm getting weird udev issues at startup :\
[12:52] <axw> about to go back to 12.04 and then upgrade...
[13:00] <natefinch> axw: I just transferred my hard drive from my old machine to this one
[13:01] <natefinch> axw: but that worked fine :D
[13:01] <jam> morning natefinch, I hope you're feeling better
[13:02] <natefinch> jam: got a litle extra sleep, feel like a new man... well, not exactly, but not bad :)
[13:02] <mgz> a new-ish man
[13:03] <natefinch> jam: certainly better than I would have if I'd gotten up at 5:20
[13:05] <axw> natefinch: aha. I was thinking of doing that as a last resort :)
[13:08] <natefinch> axw: sorry, it never occurred to me that installation would be a problem
[13:09] <axw> natefinch: no problems, I'm somewhat used to this :(
[13:09] <axw> sad to say
[13:24] <rogpeppe> lunch
[13:47] <dimitern> rogpeppe, jam, any comments on the PutCharm doc?
[13:48] <dimitern> mgz, if you want to take a look as well?
[13:48] <rogpeppe> dimitern: i will have; juggling a few things currently.
[13:48] <dimitern> rogpeppe, sure, take your time
[13:49] <mgz> dimitern: sure, looking
[13:50] <mgz> geh, google doc links are annoying to transfer across... :)
[14:01] <mgz> dimitern: left a couple of notes
[14:05] <niemeyer> rogpeppe: Any news from that issue?
[14:06] <rogpeppe> niemeyer: we got it all working, but they've decided that juju is not for them in the future, sadly
[14:06] <niemeyer> rogpeppe: Due to that issue, or did they bring up any other reason?
[14:06] <rogpeppe> niemeyer: a number of issues
[14:07] <niemeyer> rogpeppe: Okay, well.. at least we have feedback to work on then
[14:07] <rogpeppe> niemeyer: yes - i am putting together a summary
[14:07] <niemeyer> rogpeppe: Thanks a lot
[14:07] <rogpeppe> niemeyer: i asked if they could summarise their juju experience for us too
[14:07] <rogpeppe> niemeyer: they've put a lot of time into it
[14:12] <dimitern> mgz, cheers
[14:21] <sinzui> jamespage, I think devs are willing to forgo an SRU for saucy for the sake of 1.16.4.
[14:36] <jam> sinzui, jamespage: so 1.16.4 is set in stone (IMO) because it is actually being used in the wild. If we decide we have to revert things/move it to 1.18/whatever we can do so as necessary
[14:36] <jamespage> jam, sinzui: so I guess you would like me to upload it to trusty and do the backports dance right?
[14:37] <jam> jamespage: I think we want to make binaries available, I'm not 100% sure how that has to happen
[14:38] <sinzui> jamespage, yes please :)
[14:40] <jamespage> sinzui, jam: OK _ but as we probably can't sru this point release, it can't go into cloud-tools
[14:49] <jamespage> sinzui, jam: uploaded to trusty and backporting for the stable PPA now
[14:50] <sinzui> Thank you jamespage
[15:08] <abentley> jam: It appears that bug #1257481 applies only when hyphen is used as a separator.  Can you confirm?
[15:08] <_mup_> Bug #1257481: juju destroy-environment destroys other environments <ci> <destroy-environment> <juju-core:In Progress by jameinel> <https://launchpad.net/bugs/1257481>
[15:08] <mgz> abentley: yeah, that seems right
[15:09] <mgz> we match machines on juju-ENVNAME-*
[15:09] <mgz> so, be more creative in your naming :0
[15:09] <jam> abentley: yes
[15:10] <mgz> jam: we can just make the pattern better, right?
[15:10] <mgz> in fact, I think it *was* better in pyjuju
[15:10] <jam> mgz: see the branch associated with the bug
[15:10] <mgz> jam: I see no associated branch
[15:10] <jam> mgz: "juju-ENVNAME-machine-\d*"
[15:11] <jam> mgz: because I fat-fingered it to 1256481
[15:11] <jam> ugh
[15:11] <mgz> jam: you li... right
[15:11] <mgz> reviewing, at any rate :)
[15:12] <jam> mgz: I'm proposing one with the right associated bugs, but the code is the same
[15:12] <jam> then again, it is *one* line :)
[15:12] <mgz> jam: really does seem like we want a test
[15:13] <jam> mgz: how would you write such a test?
[15:13] <jam> mgz: we do still have 1 test that calls AllMachines
[15:13] <jam> and I did manual testing on HP and Canonistack
[15:14] <jam> I can do a whitebox test of what the regex is
[15:14] <jam> but that doesn't really help much
[15:14] <jam> you really need a test in an environment, because the thing interpreting the regex is HP/Canonistack/Havana/etc
[15:14] <jam> mgz: and it doesn't help that our "go test -live" is actually broken right now (something about not having AgentVersion in the config)
[15:15] <mgz> jam: can write a local live test, hook in some extra instances, and assert only sanely named ones are returned by Instances
[15:15] <mgz> doesn't need to be a live live test
[15:16] <mgz> ...but I do see why you want that
[15:16] <jam> mgz: so we can, though it sounds very close to testing that I implemented exactly that, if you have a good way to phrase it that isn't *too* tied to implementaiton, I do think it is good "I didn't screw this up when I refactored code"
[15:17] <mgz> manually nova boot another server with a name that would have matched under the old pattern, but won't under this?
[15:17] <mgz> that way we have a test that fails on the actual bug reported
[15:18] <jam> mgz: reasonable point, please leave it in the review so I remember to do it
[15:19] <mgz> jam: are you putting up a new -cr or should I use that one?
[15:25] <rogpeppe> dimitern, fwereade_: i've added my original thoughts for how we might do charm uploads to the PutCharm proposal.
[15:28] <rogpeppe> dimitern, fwereade_: it seems a bit simpler to me, but there's probably a good reason why it would not work
[15:28] <dimitern> rogpeppe, thanks, i'm reading it now
[15:29] <dimitern> rogpeppe, and commenting
[15:32] <abentley> jam: Thanks for the quick fix.  Looks like it will be really hard to cause a bogus match from here on out.
[15:35] <natefinch> niemeyer: got a second?  Hopefully quick question about replica sets
[15:36] <niemeyer> natefinch: Yo, yep
[15:38] <natefinch> niemeyer: I'm writing tests for my code that configures replica sets, so it brings up some mongo instances with mongod --replset foo etc, but I need a good way to test if they're fully up and ready before adding them to the replica set.  Suggestions?  Would Ping() work?
[15:43] <natefinch> niemeyer: my thought was to put a direct dial and then a ping into a loop, and wait til it succeeds or passes a deadline... but it seems never to succeed
[15:43] <mgz> can I have stamp on codereview.appspot.com/37210044 merge of 1.16 into trunk please?
[15:47] <abentley> jam: It appears that when you create an instance on openstack, you can attach metadata to it.  And when you list instances, you can retrieve that metadata.  This could be a sure-fire way of ensuring you delete only the instances you created, e.g. by storing the env name as metadata.
[15:48] <natefinch> niemeyer: nevermind, I think I just figured it out... forgot to use a monotonic session.
[15:55] <niemeyer> natefinch: Have you seen the LiveServers method?  That's one way too
[15:55] <niemeyer> natefinch: Oh, *before* adding to the RS.. okay, nevermind
[15:56] <natefinch> niemeyer: right, the problem is that I was trying to add them to the replicaset before they were fully up, so mongo would complain that it couldn't add a majority of the servers to the set
[15:56] <rogpeppe> fwereade_, jam, dimitern: any idea how the problem mentioned by iri- in #juju might be happening?
[15:56] <niemeyer> natefinch: Understood
[15:57] <rogpeppe> fwereade_, jam, dimitern: (iri- is peter waller, BTW, the person I've been trying to sort out the environment of)
[16:29] <mgz> rogpeppe: can I have a stamp on the trunk merge of 1.16 please? cr 37210044
[16:29] <rogpeppe> mgz: looking
[16:30] <rogpeppe> mgz: LGTM
[16:30] <mgz> ta!
[16:43] <bac> hi rogpeppe or fwereade_, when bootstrapping juju is there a way to get the same effect of 'default-series' in the environment file via the command-line?  --series does not seem to be it.
[16:44] <rogpeppe> bac:  i think it has to be in the environment config
[16:44] <bac> rogpeppe: that was my conclusion but i'd hoped i'd overlooked something.
[16:48] <fwereade_> bac, it's not ideal, but you can always change default-series with set-env after you've bootstrapped
[16:49] <bac> fwereade_: and that will affect your bootstrap node?
[16:49] <fwereade_> bac, no, it won't
[16:50] <bac> yeah, that would be scary.
[16:50] <fwereade_> bac, it'll affect what charm series is inferred when yu deploy, and what series machines added without --series get, but that should beit
[16:50] <bac> ok, thanks
[16:50] <fwereade_> bac, cheers
[16:52] <jcastro> sinzui, I have a community update on juju to stream today, looking at the milestone for 1.16.5 it's 1 bug away, is it safe for me to say that we'll have .5 out before the holidays?
[16:52] <sinzui> NO way
[16:53] <sinzui> jcastro, I reported that bug weeks ago and no one is working on it. I think 1.16.5 can never happen because it breaks cli compatability
[16:54] <jcastro> ok so I can just reiterate that .4 is where it's at?
[16:55] <sinzui> I think we should hope for 1.17 this month with 1.18 in January
[16:59] <sinzui> damn it. abentley there is an extra leading / in the azure release files that is not in the testing files. All the files were pushed to the wrong location
[16:59]  * sinzui blows a gasket.
[16:59] <abentley> Crap!
[17:11] <sinzui> abentley, I am pushing the files to the correct location. We can talk while everything goes up
[17:14] <TheMue> rogpeppe: you'll get a new push of my CL tomorrow, I'm now changing it to reading from the end first
[17:14] <rogpeppe> TheMue: cool
[17:14] <rogpeppe> TheMue: you got my email?
[17:15] <TheMue> rogpeppe: oh, eh, yes (right now, didn't looked into mail before) :D
[17:16] <abentley> sinzui: relevant? http://<IP_ADDRESS>:8080/job/azure-upgrade-deploy/71/console
[17:16] <rogpeppe> TheMue: quite fun that i was still able to find the code that i remembered...
[17:16] <TheMue> rogpeppe: great, my approach looks initially simpler, but with less error control and less generic
[17:17] <TheMue> rogpeppe: will combine both
[17:17] <TheMue> rogpeppe: but have to step out now, visitors
[17:17] <rogpeppe> TheMue: ok, see ya
[17:18] <sinzui> abentley, yes, in fact, it answers what is in my head,
[17:23] <jamespage> sinzui, all the juju-core 1.16.4 packages are built in the juju-packagers PPA btw
[17:24] <sinzui> jamespage, I saw thanks
[18:44]  * rogpeppe is done for the day
[18:44] <rogpeppe> g'night all
[19:44] <thumper> mramm: you around for a quick hangout?
[19:44] <mramm> yea
[19:45] <mramm> can I have 5 min
[19:54] <thumper> sure
[19:54]  * thumper didn't notice the response
[19:54] <thumper> mramm: if you need a few more minutes, I'll go make a coffee
[19:54] <mramm> yea
[19:55] <mramm> need a few more
[19:55] <thumper> ok
[19:55]  * thumper goes to make coffee
[19:58] <natefinch> plugged in a new USB gigabit ethernet adapter today, and laptop froze up twice today, which it's never done before.  Coincidence?
[20:00] <thumper> natefinch: probably not :-)
[20:01] <natefinch> thumper: I didn't really think so :)   Dang... 'cause it's really much more pleasant on ethernet than wifi where my desk is (there's like 3 walls between me and the router, and my signal blows)
[20:02] <thumper> natefinch: we have brick or plaster interrior walls, and that kills the signal.
[20:02] <thumper> ran a cat 6 cable from the office to the dining room
[20:02] <thumper> and have a second access point there
[20:03] <thumper> mramm: for when you are ready https://plus.google.com/hangouts/_/72cpim91vapctd3ad0g1v02aa0?hl=en
[20:03] <natefinch> I actually am planning to run a cable from the basement under my office... there's a phone jack in this room that is sort of hilariously useless, which I plan to replace with an ethernet jack.  Putting an access point in here is a good idea, though.  hadn' thought of that
[20:44] <natefinch> You know one of the things I like best about Canonical?  Sometimes stuff actually gets addressed when I complain.
[21:13] <natefinch> niemeyer: one (hopefully last) mongo question if you have second?
[21:37] <jcastro> heya thumper
[21:37] <jcastro> what's the TLDR on manual provisioning lately?
[21:37] <thumper> jcastro: mostly working
[21:38] <thumper> jcastro: hazmat is using it quite a lot I think
[21:38] <thumper> jcastro: axw is working on making it destroy itself properly
[21:39] <thumper> which is involving moving destroy environment into the API
[21:39] <thumper> which is mostly done I think
[21:39] <thumper> apart from that, I think it is working
[21:39] <thumper> but not really documented
[21:42] <thumper> o/ waigani
[21:45] <waigani> thumper: hello :)
[21:53] <hazinhell> jcastro, its awesome.. after i get out of hell, i've got a cool plugin that you'll like
[21:53] <hazinhell> is there still on-going work on api
[21:54] <hazinhell> deploy is listed as is progress but dimeter is on holiday for a while
[21:54] <hazinhell> mostly just looking for putcharm in the api
[21:55] <hazinhell> jcastro, manual still has some rough edges, there's the manual-provider tag on the bugs
[21:55] <hazinhell> but it works pretty well outside of the rough edges imo.
[21:55] <jcastro> thumper, it's partially documented: https://juju.ubuntu.com/docs/config-manual.html
[21:56] <jcastro> hazinhell, that's good to hear!
[23:09] <hatch> hey does 1.16.4 have the fix for manual provider?