[00:46] <ytrezq> Hello, any ideas for this : http://stackoverflow.com/q/29357563/2284570#comment46899862_29357563 ?
[10:53] <apw> ytrezq (N,BTFL), if that was doable then the world would be a lovely place
[13:45] <arges> /join #ubuntu-release
[13:51] <apw> arges, having fun ?
[13:56] <arges> apw: : ) maybe its me,but i'm blaming the keyboard
[14:00] <apw> arges, works for me, i tend to blame unity, then the keyboard
[15:08] <jsalisbury> ##
[15:08] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC
[15:08] <jsalisbury> ##
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##


[00:43] <Ampelbein> kenvandine: there? about couchdb, I can't get it to build, see http://paste.ubuntu.com/258999/
[01:22] <Ampelbein> kenvandine: nevermind, figured it out.
[05:38] <bryce> chrisccoulson, sorry, I guess I missed your comment earlier... been a busy day today
[05:49] <bryce> bbl
[06:54] <pitti> Good morning
[06:55] <pitti> didrocks: can't it become a proper conffile instead?
[06:56] <pitti> didrocks: config file handling is okay, but always needs some care
[06:59] <pitti> geser: FYI, I'm using Ctrl+K - > in vim
[06:59] <pitti> see :digraphs
[06:59] <pitti> chrisccoulson: ah, seems it was mis-NEWed
[06:59]  * pitti fixes
[07:46]  * mvo attacks the gnome items in the sponsoring queue
[07:47]  * pitti hugs mvo
[07:49] <TheMuso> Some have already been taken care of.
[07:49] <mvo> TheMuso: woah, dholbach was 20 seconds faster
[07:50] <pitti> hyperair: I'm using Ctrl+K - > in vim, see :digraphs
[07:51] <hyperair> pitti: ooh cool. thanks
[07:51] <pitti> hyperair: I can remember a few unicode numbers, but not that many :) Ctrl-K is much easier, very similar to compose
[07:52] <hyperair> yeah i can imagine
[07:52] <hyperair> digraphs is something i've never tried using before =\
[07:57]  * hyperair wonders if emacs has support for digraphs
[08:11]  * Amaranth points to the branch linked on bug 178953 again
[08:11] <Amaranth> can someone take a look? :)
[08:11] <pitti> I'm off for a bit, doctor appointment
[08:15] <didrocks> pitti: good morning
[08:15] <didrocks> pitti: I was thinking (didn't checked) that distutilsextra would handle it as a conffile
[08:25] <mvo> Amaranth: patch looks good
[08:29] <mvo> Amaranth: will you push that patch upstream too?
[08:29] <Amaranth> mvo: already did, in the linked bug report
[08:32]  * mvo hugs Amaranth
[08:33] <mvo> Amaranth: I will just tag the patch (so that it links to the upstream bug) and then upload
[08:33] <Amaranth> mvo: alright, awesome
[08:34] <Amaranth> mvo: btw, whole load of fixes in the compiz-0.8 branch again today
[08:34] <Amaranth> hope they do a release :/
[08:34] <mvo> Amaranth: yeah, I overheard in the channel that they plan to do one
[08:34] <mvo> Amaranth: cornelius is rocking it seems, he did some nice commits :)
[08:34] <Amaranth> yeah, seems he is out of school now or something :)
[08:35] <mvo> Amaranth: haha :)
[08:35] <mvo> Amaranth: funny how strong free software is influenced by this
[08:35] <mvo> Amaranth: I was preparing a new upload, I want to coordinate with robert_ancell on it
[08:35] <Amaranth> cool
[08:36] <mvo> abi break of course :/ but thats how it is :)
[08:36] <Amaranth> mvo: should have a lot less of those with the C++ stuff
[08:37] <mvo> Amaranth: in my experience its also hard with c++ to keep the abi stable, but I guess they will manage
[08:37] <Amaranth> mvo: I know I added a bunch of stuff to the Screen class and it didn't change the ABI
[08:37] <Amaranth> unlike in the C version where a single change does
[08:38] <robert_ancell> mvo, sorry, have to go so can't talk about compiz.  Feel free to PPA up the new version or something and I will look into it tomorrow
[08:39] <mvo> Amaranth: ok
[08:39] <mvo> robert_ancell: sure, I saw that you were *very* busy with all of the gnome updates, no problem
[08:39] <robert_ancell> later all
[09:00] <lool> pitti: Hmm I'm lost on the indicator-sus/-session changes
[09:00] <lool> Oh the new target to milestone popup of LP is cute
[09:01] <lool> pitti: Hey why dont we just do a MIR status chat?
[09:09] <Amaranth> lool: he had an appointment to go to, probably isn't here
[09:14] <lool> k thanks
[09:33] <maxb> If someone on the desktop team has a moment, could they update lp:~ubuntu-desktop/notification-daemon/ubuntu with the latest upload to the archive, which was done ignoring the branch? Thanks.
[09:35] <maxb> Or, if there is nothing special involved in retroactively adding a version beyond just downloading the source, manually adding the changes, and committing, tell me, and I'll propose a branch for pulling.
[09:40] <didrocks> maxb: there is no more debian/control.in in the new upload and nothing is specified in the changelog. Is it intended?
[09:41] <maxb> Uhm. I had nothing to do with the upload, I just wanted an accurate branch to submit changes against for sponsoring :-/
[09:41] <didrocks> maxb: I will ask Aurélien, before uploading the branch
[09:41] <maxb> ok
[09:44] <didrocks> hey lool, how was your vacations?
[09:47] <didrocks> maxb: ok, it was not intented. I'll upload a package to sync that first
[09:49] <maxb> ok - I have a further fix for breakage introduced in -1ubuntu1 - worth combining, or do you want to keep them separate?
[09:50] <didrocks> maxb: as you whish, I can upload it at the same time if you wish
[09:51] <maxb> lp 418478
[09:51] <didrocks> maxb: hum, it's now in main though, I'll upload it to bzr and ask for sponsoring though
[09:51] <lool> didrocks: Okayish
[09:51] <lool> didrocks: What about yours?   :)
[09:52] <didrocks> lool: great, thanks! It was the good weeks to go on holidays regarding the weather, I guess :)
[09:53] <lool> Oh yeah; I was in Britany and it was really much cooler than in Paris
[09:54] <didrocks> for sure. I was still in Haute Savoie and Annecy's lake was really a relief :)
[10:08] <didrocks> maxb: bug #418478
[10:08] <didrocks> subscribed sponsor and sync to the ~ubuntu-desktop branch
[10:08] <didrocks> synced*
[10:11] <maxb> Thanks   notify-osd just doesn't do it for me :-)
[10:13] <didrocks> I think we should add something to debcheckout if bzr branch and effective package aren't in sync
[10:13]  * didrocks notes on his TODO :)
[10:24] <pitti> didrocks: if you create something in the postinst, it's way out of distutils' reach
[10:24] <pitti> lool: upload coming, I just had to leave for a doctor appointment
[10:24] <pitti> lool: I'll upload indicator-session and then flip the source task
[10:26] <didrocks> pitti: I don't do anything in postinst atm. I just wanted to know what do you think about sourcing in postinst the installed file (by distutils) /etc/bash_completion.d/quickly to have shell-completion directly after installing quickly (and don't have to launch a new bash for that)?
[10:30] <lool> pitti: Ok thanks
[10:30] <lool> pitti: Is indicator-sus being removed then?
[10:30] <lool> pitti: I hope you're doing alright?
[10:30] <pitti> didrocks: why would you source the completion file in the postinst? that's not even an interactive shell
[10:31] <pitti> didrocks: you still have to launch a new bash, there's no way around that
[10:31] <pitti> lool: renamed to -session, yes
[10:31] <pitti> lool: oh yes, I just finally want to tackle my hayfever, which I have had for decades
[10:32] <didrocks> pitti: yes, you're right, postinst is not source and launched from current shell but a real subshell. Ok, no clue for enabling directly shell-completion so... :/
[10:32] <pitti> lool: so I went to a "nature healing center", to try with some alternative medicine
[10:33] <didrocks> pitti: really? long time recovery :/ glad you're alright now.
[10:35] <pitti> didrocks: it's been bothering me for years during summer (when all the grass and tree polls are flying around), but so far I just used the normal symptom medicines; time to get to the root of it :)
[10:35] <pitti> didrocks: you really can't poke it into existing shells, sorry
[10:39] <lool> pitti: Ah would love to hear how that turns out to work then
[10:39] <lool> In a couple of months
[10:39] <pitti> so am I :)
[10:39] <lool> pitti: So on MIRs, everything should pretty much be asssigned
[10:39] <lool> asac is on VAC; he did a good job on euca MIRs but had some backlog on the other ones
[10:39] <pitti> lool: thanks for having taken care of that during my holidays; I didn't really catch up on MIRs yet, I'm afraid
[10:40] <lool> I have some little backlog on the regular MIRs which I'm taking care of as much as possible
[10:40] <lool> The biggest issue is the euca MIRs
[10:40] <lool> We need to process as much as possible this week
[10:40] <pitti> *nod*
[10:40] <lool> I said Thierry we'd promote euca even if we dont complete the MIRs to have euca on the server CD for A5 and then would post process the MIRs
[10:41] <lool> doko/kees are relatively busy; I kept Kees' time for the security related stuff mostly
[10:42] <pitti> lool: I agree to early promotion, also for testing stuff
[10:43]  * pitti goes back to catch up on OMGurgent stuff
[11:06] <pitti> lool: FYI, I'm using https://bugs.edge.launchpad.net/~ubuntu-mir/+subscribedbugs?assignee_option=none&orderby=status for "unassigned MIRs"; seems there's still a bunch of them, I'll go through them
[11:07] <chrisccoulson> good morning everyone
[11:07] <pitti> lool: ah, seems that euca was promoted already? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is full of it
[11:07] <pitti> hey chrisccoulson!
[11:07] <didrocks> hello chrisccoulson
[11:07] <chrisccoulson> hey pitti! enjoying your time back?
[11:08] <chrisccoulson> hi didrocks too:)
[11:08] <lool> pitti: There's an issue, I'm using a similar URL (https://bugs.launchpad.net/~ubuntu-mir/+bugs?assignee_option=none) but it lists bugs which do have an assignee
[11:08] <lool> pitti: I didnt know it had been promoted already
[11:08] <lool> It was slated for happening this week, tomorrow IIRC
[11:09] <pitti> so we should just promote the rest as well, to fix component-mismatches and unbreak server CD builds
[11:10] <lool> pitti: The ruby stuff might not be assigned yet, but I'd like to clarify with Riddell about pulling ruby in the kubuntu CD
[11:10] <pitti> ok, will ignore this for now
[11:10] <lool> pitti: Another LP bug I seem to be a victim of is that I dont get any email when ubuntu-mir is subscribed
[11:10] <lool> I just see comments afterwards, but no NEW anymore
[11:10] <Riddell> we've always had ruby on the Kubuntu CD
[11:10] <pitti> lool: right, I seem to suffer the same
[11:11] <lool> Riddell: I mean the new ruby libs
[11:11] <pitti> lool: I don't rely on that any more, and just use that bug list
[11:11] <Riddell> another library isn't likely to make much difference
[11:11] <lool> pitti: Yeah that's what I did too, but it's painful due to the first bug (list bugs with assignees)!
[11:11] <lool> pitti: Ok I guess that clarifies that the ruby stuff is up for assignment
[11:13] <pitti> lool: maybe it works on +subscribedbugs but not on +bugs for some reason?
[11:15] <pitti> ArneGoetje: should the seeds be changed to ibus now? can you please give a list of all the new necessary packages in the MIR bug? (check the current dependencies of ubuntu-desktop for the current set)
[11:15] <lool> pitti: Oh indeed
[11:15] <lool> Tss
[11:15] <pitti> ArneGoetje: also, did the necessary Xsession.d/ switching magic land?
[11:15] <pitti> (I guess that's a precondition for promoting and seeding it)
[11:18] <lool> pitti: soren apparently just seeded euca which is why it just appeared on components-mismatches
[11:18] <lool> forwarded you an email to that effect
[11:18] <pitti> ah, I see
[11:18] <soren> lool: Err... I didn't.
[11:18] <soren> I was *just* about to.
[11:18] <soren> If it's there now, someone else did it.
[11:19]  * soren wonders
[11:19] <soren> Task: eucalyptus-simple-cluster
[11:19] <soren> That must be Colin.
[11:23] <lool> Oh right he worked on the d-i integration
[11:23] <pitti> eucalyptus | 1.6~bzr452-0ubuntu4 | karmic/universe | source
[11:23] <lool> I approved his MIRs before the euca one
[11:23] <pitti> right, still in universe
[11:24] <pitti> lool: so it's basically just you and me for this week, right? (plus kees who is busy with the more intense security review of already assigned MIRs)
[11:24] <pitti> so I'll distribute the currently outstanding ones between the two of us
[11:25] <lool> pitti: Yeah   :-(
[11:26] <pitti> lool: did you review ruby packages before? I'm inclined to assign all those small ruby libs to the same person, and the rest to the other; do you want to review them?
[11:26] <lool> pitti: I now belive we're understaffed; I focused a lot on MIRs in the last weeks and it's eating a lot of time yet I still have a constant backlog not counting the euca stuff
[11:26] <pitti> (I'm fine, too, just wanting to know your prefs)
[11:26] <lool> pitti: I didnt particularly review ruby packages but should be ok
[11:26] <pitti> lool: understaffed> right, the euca hit plus holiday season doesn't help :/
[11:26] <pitti> but I don't think we can thoroughly review all the euca pacakges anyway
[11:27] <lool> pitti: Perhaps we should add new blood too?  When I started Kees and doko had more time for MIRs
[11:27] <pitti> we shouldn't spend more than 5 mins on the trivial java packages each
[11:27] <pitti> lool: that would be good indeed
[11:27] <chrisccoulson> asac recently updated gnome-python-extras and bumped the version number from 2.25.3-2ubuntu2 to 2.25.3-2ubuntu2.0xul191. i want to do a small change to it now, and wonder what i should make the version number
[11:27] <chrisccoulson> 2.25.3-2ubuntu2.0xul191.1 or 2.25.3-2ubuntu3?
[11:27] <pitti> chrisccoulson: 2ubuntu3 IMHO
[11:27] <chrisccoulson> pitti - thanks
[11:28] <pitti> I guess the xul191* stuff was from a PPA or so
[11:28] <chrisccoulson> possibly
[11:28] <chrisccoulson> would you mind reviewing the change in a bit? it's needed for me to get the new version of glom in before FF tomorrow
[11:28] <chrisccoulson> (i know everyone is really busy today though) ;)
[11:39] <pitti> chrisccoulson: sure, just toss a pastebin url here
[11:41] <pitti> lool: ok, got them all assigned now, I took the majority of them since you still have a large backlog (your new ones should be quick, though)
[11:42] <lool> Thanks!
[12:32] <chrisccoulson> hey pitti - the change i want to make to gnome-python-extras is here: http://paste.ubuntu.com/259246/
[12:32] <chrisccoulson> glom depends on python-gda
[12:33] <Amaranth> rickspencer3-afk, didrocks: You probably don't want to have your developer week session called "squickly fun" considering what "squick" means...
[12:34] <pitti> chrisccoulson: libgda4 is in universe, though
[12:35] <pitti> chrisccoulson: eyeballing the debian/rules change is hard, but I take it you tested it, so it should be okay :)
[12:35] <pitti> chrisccoulson: so this needs a MIR for libgda4?
[12:36] <pitti> chrisccoulson: we have libgda3 in main, smells like duplication
[12:36] <pitti> (unknown what we need it for, or whether rdepends can use gda4)
[12:36] <chrisccoulson> hmmm
[12:36] <chrisccoulson> i'll have a think about that. got to disappear for a bit
[12:56] <mpt> mvo, does <https://wiki.ubuntu.com/SoftwareStore#How%20you%20can%20help> look sane to you?
[12:56] <didrocks> Amaranth: yes, it was a temporary title but I think rickspencer3-afk didn't ask to change it (it was $quickly actually)
[12:58] <mpt> mvo, btw, it looks like MoinMoin doesn't transfer subscriptions when a wiki page is renamed, so you may want to resubscribe
[12:59] <mpt> james_w, is there a simple page somewhere describing how to branch an Ubuntu package?
[13:00] <james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/
[13:01] <Amaranth> didrocks: yeah, but $ is leet for s :P
[13:01] <chrisccoulson> pitti - libgda3 and libgda4 are both from the same upstream project (libgda). we just rename the source tarballs to incorporate the API version so we can ship multiple versions
[13:01] <chrisccoulson> so, libgda4 is the successor to libgda3 really. and glom depends on the later version
[13:02] <Laney> glom's new version ported to the new API
[13:02] <Laney> I think
[13:02] <Laney> oh, feature freeze... I was going to look at that update
[13:02] <mpt> james_w, perfect! thanks
[13:02]  * Laney weeps
[13:02] <mvo> mpt: that looks sane
[13:03] <chrisccoulson> Laney - yeah. i already started looking at the glom update
[13:03] <chrisccoulson> i updated some libraries some weeks ago for it, then got sidetracked
[13:03] <mvo> mpt: how is the virtual machine setup going?
[13:03] <Laney> I did some in the past but kind of lost interest in it
[13:03] <Laney> it's a great idea but still quite buggy
[13:03] <chrisccoulson> and glom needs pygda too, which we currently don't even build
[13:03] <chrisccoulson> and to pygda needs the latest version of libgda, which is currently in universe
[13:04] <mpt> mvo, I installed Karmic yesterday, installed the apt-daemon package, and branched software-center, but got a xapian error ("unknown database type" or something like that)
[13:04] <mpt> mvo, I guessed much later that it was because I should have had the version of apt-daemon from your PPA rather than from Ubuntu. Is that correct?
[13:04] <mpt> s/software-center/software-store/
[13:05] <mvo> mpt: its because of the renaming buisiness, sorry. please install the "software-store" package from the archive
[13:05] <mvo> mpt: that should fix it
[13:05] <mpt> mvo, it's in the archive? sweet
[13:05] <mvo> mpt: yeah, james_w did a superfast NEW review
[13:05]  * mvo hugs james_w for this
[13:05] <mpt> thanks james_w
[13:06] <james_w> I knew it would be an easy one ;-)
[13:06] <mpt> yeah, not likely to get many packaging errors from mvo of all people
[13:06] <mpt> mvo, so would you prefer to track all bugs on the package rather than the project, as with ubiquity for example?
[13:07] <mvo> mpt: I persoally prefer to have a single point to look at, I never really liked that its not possible to say "show me all software-store bugs (no matter if project or distro)
[13:08] <mvo> mpt: this is why I prefer to track them on the package. if LP would offer me a single view for all bugs, I would not mind
[13:08] <Laney> chrisccoulson: I was trying to lay the ground work for glom in Debian too
[13:08] <Laney> dunno if you are interested in doing something there
[13:08] <mpt> mvo, yes, that's bug 76416 (which I reported nearly three years ago now)
[13:08] <chrisccoulson> Laney - possibly. I will take a look at glom again this week, but i don't think it's going to make FF now
[13:08] <mvo> mpt: :)
[13:08] <Laney> nah
[13:09] <mvo> mpt: so for now I would prefer bugreports on packages
[13:09] <mvo> mpt: how does it look so far to you?
[13:09] <mpt> mvo, I'll need to restart into Karmic to find out :-) (I'll do that VM thing later-ish)
[13:10] <mpt> for now I'm filling in a few sections on the spec, and then I'll send you a draft announcement for ubuntu-desktop@
[13:10] <mvo> mpt: ok, no rush, I did not had a chance to work on it this morning, so nothing new since we talked last
[13:10] <mvo> mpt: nice, thanks
[13:11] <mpt> mvo, so maybe we should set the software-store project as *not* using Launchpad for tracking bugs, and instead point people (in the project description) to the package Bugs page. Make sense?
[13:12] <mvo> mpt: yeah, good point
[13:16] <mpt> ok, I'll do that now
[13:17] <mvo> thanks mpt
[13:18] <mpt> mvo, what is the relationship between the summaries/descriptions in the app-install-data(...) packages and the summaries/descriptions in the corresponding packages? Are they automatically synced, or manually synced, or what?
[13:21]  * mpt is confused as to why <https://edge.launchpad.net/ubuntu/+source/app-install-data> lists no versions
[13:22] <mvo> mpt: please try https://edge.launchpad.net/ubuntu/+source/app-install-data-ubuntu
[13:22] <mvo> mpt: the long description is taken from the apt repository (so its what apt-cache show apt) will show
[13:22] <mpt> aha, thanks
[13:22] <mvo> mpt: that is refreshed with every apt-get update run
[13:23] <mvo> mpt: but the app name and the inital line is taken from the desktop file
[13:25]  * mpt slowly realizes that the app-install-data-ubuntu source package provides the app-install-data binary package, and the app-install-data source package does not
[13:26] <mvo> mpt: there is no app-install-data source package (well, there was at some point in the long long ago past)
[13:26] <mvo> LP never forgets ;)
[13:26] <mpt> Apparently it forgets about the long-deceased versions, but not about the name
[13:27]  * mvo nods
[13:29] <mpt> mvo, so is the "initial line" (shall we call it the "summary"?) from the .desktop file often the same as the first line in the Description: field for the package?
[13:34] <mvo> mpt: I stand corrected, currently its using the app name and then the apt description. g-a-i is using "appname, comment, apt description"
[13:34] <mvo> mpt: the summary is almost never the same as the desktop file
[13:35] <mvo> mpt: they are maintained by two different people usually (but not always). desktop-file is upstream, the apt description data is the debian/ubuntu maintainer
[13:35] <chrisccoulson> Ampelbein - your gnome-applets update has an error
[13:35] <mpt> understood
[13:35] <chrisccoulson> the current BZR version has an unreleased change
[13:36] <chrisccoulson> but you didn't account for that in the changelog
[13:36] <chrisccoulson> gnome-applets (2.27.4-0ubuntu2) UNRELEASED; urgency=low
[13:36] <chrisccoulson> should be replaced with "gnome-applets (2.27.91-0ubuntu1) UNRELEASED; urgency=low" rather than added to
[13:37] <mvo> mpt: should I add the comment line (just like with g-a-i) back ?
[13:37] <mvo> mpt: the current view has the advantage that its more polished
[13:37] <mpt> mvo, not sure yet. Where does the Comment come from?
[13:38] <mvo> mpt: from the upstream desktop file. it may not match very well with the apt description (as its two different people writing them)
[13:38] <Ampelbein> chrisccoulson: I thought about that. I thought it would be sufficient to pass -v2.27.4-0ubuntu1 to debuild to pull that in to the changes. But I can merge it with the other changelog entry.
[13:41] <mpt> mvo: So we have available (1) package name [from Debian/Ubuntu packager], (2) application name [.desktop file via app-install-data-ubuntu], (3) Comment [.desktop file via app-install-data-ubuntu], (4) Summary [first line of Description: from Debian/Ubuntu maintainer, treated specially], and (5) Description [the rest of the Description: from Debian/Ubuntu maintainer]. Is that right?
[13:41] <chrisccoulson> Ampelbein - thanks
[13:41] <mvo> mpt: yes, correct
[13:41] <mpt> Egads.
[13:42] <mvo> mpt: and if we expand to non-apps we loose all the info from the desktop files of course
[13:42] <mpt> sure
[13:42] <mvo> mpt: and right now multiple applications can be in a single package
[13:42] <mpt> yes
[13:42] <mvo> mpt: (that is pretty common)
[13:42] <mpt> e.g. gnome-games
[13:42] <mvo> yeah
[13:43] <mvo> its probably worthwhile to have this information somewhere iin the long description, I put them small in the appdetails currently
[13:43] <mvo> (not sure that is the best place)
[13:44] <pitti> chrisccoulson: right; I asked whether we really need to keep both versions in main, perhaps we can transition 3 to 4?
[13:45] <chrisccoulson> pitti - perhaps. i've not looked at the rdepends for libgda3 yet
[13:45] <chrisccoulson> i'm not sure this is going to make FF though - i'm time limited at the moment ;)
[13:53] <pitti> kenvandine: hm, shouldn't indicator-applet-session depend on indicator-session?
[13:53] <kenvandine> pitti, you know... i was just thinking the exact same thing :)
[13:53] <pitti> kenvandine: we need to settle the seeding for this stuff soon; which are the "top level" packages which we want?
[13:53] <kenvandine> i think it should depend on indicator-session
[13:53] <pitti> kenvandine: (I was just apt-get installing i-a-s and wondered why it didn't pull in anything else)
[13:54] <kenvandine> did it get libindicate2?
[13:54] <pitti> kenvandine: darn, I get a pakcage install failure
[13:54] <kenvandine> oh?
[13:54] <pitti>  Versuche, »/usr/lib/bonobo/servers/GNOME_FastUserSwitchApplet.server« zu überschreiben, welches auch in Paket gdm ist
[13:54] <kenvandine> oh
[13:54] <pitti> i-a-s needs to replace gdm
[13:54] <kenvandine> no
[13:54] <pitti> so, that and the new dependency
[13:54] <glatzor_> hello mvo
[13:54] <pitti> kenvandine: yes :)
[13:54] <kenvandine> needs to require newer version of gdm
[13:55] <pitti> kenvandine: insufficient
[13:55] <kenvandine> really?
[13:55] <glatzor_> mvo, could you please upload packagekit_0.4.9+20090825 from https://edge.launchpad.net/~packagekit/+archive/0.4.x
[13:55] <glatzor_> ?
[13:55] <pitti> kenvandine: depends: can be unpacked at random, it just determines the unpack order
[13:55] <kenvandine> oh
[13:55] <kenvandine> ok
[13:55] <glatzor_> mvo, Thanks
[13:55]  * kenvandine will fix that
[13:55] <pitti> kenvandine: it needs to conflicts/replaces gdm (<< version_that_drops_the_file)
[13:55] <kenvandine> pitti, did you do the gdm upload?
[13:55] <pitti> kenvandine: not yet, I was just about to do it
[13:55] <kenvandine> ok
[13:55] <pitti> but I wanted to get all the archive debs for testing first
[13:56] <kenvandine> pitti, so i need a Conflicts and a Replace?
[13:56] <pitti> kenvandine: could you please add the c/r and new dependency, push, and then I'll upload that as well?
[13:56] <pitti> kenvandine: yes, both versioned
[13:56] <kenvandine> ok
[13:56] <kenvandine> the gdm version is 2.27.4-0ubuntu12
[13:56] <kenvandine> right?
[13:57] <mvo> glatzor_: sure
[13:57] <pitti> kenvandine: correct, the one that will drop the file
[13:57] <pitti> kenvandine: with that, apt will ensure to unpack the new gdm first, and then i-a-s
[13:58] <pitti> btw, is xsplash supposed to work in karmic?
[13:58] <pitti> I updated after my holidays, and have it installed, but I never saw it
[13:59] <kenvandine> Conflicts: indicator-applet-sus, gdm (<< 2.27.4-0ubuntu12)
[13:59] <kenvandine> Replaces: indicator-applet-sus, gdm (<< 2.27.4-0ubuntu12)
[13:59] <pitti> kenvandine: ah, robert updated gdm bzr to 2.27.90-0ubuntu1
[13:59] <pitti> kenvandine: so please rather use this version
[13:59] <kenvandine> oh
[13:59] <pitti> (doesn't matter much)
[14:01] <mvo> glatzor_: uploaded
[14:02] <kenvandine> pitti, indicator-applet branch pushed
[14:04] <kenvandine> pitti, lets talk about xsplash in a few
[14:04]  * kenvandine is testing trunk :)
[14:04] <kenvandine> pitti, fyi new xsplash version coming today :)
[14:08] <pitti> kenvandine: i-a uploaded
[14:08] <kenvandine> thx
[14:09] <kenvandine> pitti, the PK deprecation is important right?
[14:10] <kenvandine> as in must be done before feature freeze?
[14:10] <pitti> kenvandine: not necessarily for FF
[14:10] <pitti> but I'd really like it to get done for beta or so
[14:10] <kenvandine> ok, but for karmic :)
[14:10] <kenvandine> tedg, ^^
[14:10] <pitti> it'd be very ugly to ship with two PK stacks
[14:10] <pitti> since it also means two PK UIs, two dialogs, string sets, and configurations
[14:11] <pitti> and I expect this one to be trivial (just rip out all the code)
[14:11] <kenvandine> ewwww
[14:11] <pitti> kenvandine: why does gdm need to depend on i-a-s? shouldn't it be the other way round rather?
[14:11] <pitti> or we should just explicitly seed i-a-s?
[14:12] <tedg> pitti: Yeah, I think so.  But we haven't been able to develop an automatic test suite for all of the login/logout stuff -- especially in the multi user case.  So it's lots of manual testing.
[14:12] <kenvandine> we should see i-a-s
[14:12] <kenvandine> seed
[14:12] <pitti> kenvandine: right
[14:12] <kenvandine> pitti, i assumed that is what we did for fusa
[14:12] <pitti> tedg: sorry, that was a reply to what?
[14:12]  * kenvandine looks at the gdm package
[14:12] <tedg> pitti: The PK stuff in indicator-session.
[14:13] <pitti> tedg: ah
[14:13] <kenvandine> oh it's a recommends
[14:13] <pitti> tedg: that's just client-side code, or does it provide PK-protected services?
[14:13] <kenvandine> pitti, i suspect that was just someone replacing fusa with i-a-s
[14:13] <pitti> tedg: (I suppose the former)
[14:13] <tedg> pitti: Just client side in the case of multi-user logged in and trying to shutdown.
[14:13] <pitti> tedg: right, that's easy then; just rip it all out :)
[14:13] <pitti> and it's even necessary, since gdm itself uses PK-1
[14:14] <pitti> so using the old PK API will break
[14:14] <tedg> pitti: Well, not entirely the case.  As we need to test on whether there are multiple users so we dont' show two dialogs... but yes, it shouldn't be a huge deal.
[14:14] <tedg> pitti: I just have a list of things for Feature Freeze to do, and I'm avoiding putting another on the list :)
[14:14] <pitti> tedg: right, as I said, it's not FF critical
[14:15] <tedg> pitti: Cool, I'll file a bug and tag it.
[14:15] <pitti> I just wanted to know how much effort it is (real porting or just dropping)
[14:15] <pitti> tedg: some details are in the MIR bug, FYI
[14:15] <pitti> I sub'ed you to it
[14:17] <mpt> mvo, is software-store GPLv2-or-later?
[14:19] <rickspencer3> pitti: kenvandine: good morning
[14:19] <kenvandine> hey rickspencer3
[14:19] <kenvandine> Riddell, fyi.... libindicate is uploaded :)
[14:19] <pitti> hey rickspencer3
[14:20] <Amaranth> yay, I got my bug-control membership back
[14:20]  * Amaranth hugs pedro_
[14:21]  * pedro_ hugs Amaranth back
[14:21] <rickspencer3> pitti: thanks for the activity report
[14:21]  * rickspencer3 forgot to send the reminder mail yesterday :(
[14:21] <pedro_> Amaranth, saw your name on the list of applicants, next time give me a ping ;-)
[14:21] <pitti> rickspencer3: some other people sent one as well
[14:22] <rickspencer3> yup
[14:22] <rickspencer3> Riddell , bryce, TheMuso, etc...
[14:24] <Riddell> kenvandine: yay
[14:26]  * pitti tests new gdm with tedg's indicator love
[14:31] <pitti> oh, so xplash does actually run
[14:31] <pitti> it just makes my login experience much uglier than before :(
[14:31] <pitti> tedg, kenvandine: anyway, i-a-s seems to work; it starts as "offline", has a terminal symbol in the panel and no icons in the menu, but otherwise does its job
[14:32] <tedg> pitti: Yes, both of those fixes are waiting on code review :)
[14:32] <pitti> tedg: retroactive bug fixing, you rock!
[14:35] <pitti> bratsche: so, with current xsplash I get a lot of flickering, it times out too early, and it doesn't cope with xrandr resolution changes during login; are any of those known, or shall I file bugs for them?
[14:36] <kenvandine> pitti, the flicker is fixed
[14:36] <kenvandine> file the other issues
[14:37] <pitti> ok, will do
[14:37] <kenvandine> pitti, we really want a release today
[14:37] <pitti> right, not saying that those are blockers
[14:37] <pitti> I just wasn't aware that xplash looks like a background image, I though there was some throbber or so
[14:37] <pitti> so I didn't actually notice it
[14:39] <pitti> kenvandine: ok, so I go ahead and seed indicator-session-applet; anything else?
[14:40] <kenvandine> yes please
[14:40] <kenvandine> well we need to seed evolution-couchdb... but i can't get it to work :/
[14:40] <kenvandine> pitti, oh yeah... one more thing
[14:40] <kenvandine> one sec
[14:41] <pitti> kenvandine: evo-couchdb> wouldn't that require erlang in main first?
[14:41] <kenvandine> yes... bug 401691
[14:41] <kenvandine> so the tests aren't included in the source distribution
[14:42] <kenvandine> only in their vcs
[14:42] <pitti> right, I saw the conversation
[14:42] <kenvandine> so not trivial
[14:42] <pitti> shouldn't block MIR, though
[14:42] <kenvandine> good :)
[14:42] <pitti> ok, so I'll rebuild -meta with i-a-s for now
[14:42] <kenvandine> elliot already contacted the debian maintainer to see what he wants to do
[14:42] <kenvandine> so can you approve that MIR?
[14:43] <kenvandine> pitti, so here is what is in the pipe for today (we hope)
[14:43] <kenvandine> xsplash and desktopcouch releases
[14:43]  * pitti grumbles at CDs being oversized again
[14:43] <pitti> good
[14:44] <kenvandine> and hopefully a fix for  evo couchdb
[14:44] <kenvandine> then add it all to the seed :)
[14:44]  * kenvandine eyes gimp
[14:44] <Amaranth> CD oversized?
[14:44]  * Amaranth eyes evolution
[14:44] <pitti> and they just have three langpacks
[14:44] <kenvandine> no!
[14:44] <Amaranth> everyone uses gmail, doncha know? ;)
[14:44] <bratsche> pitti: xrandr is not a known issue.  The other ones I believe are fixed.
[14:45] <pitti> bratsche: timeout is tricky, I guess; on a cold boot, gnome takes some 40 seconds to start for me, but I have a ridiculously slow hd
[14:45] <pitti> bratsche: and we don't have the gnome-panel and nautilus d-bus sends for proper termination yet, or do we? (the bug is still open)
[14:46] <Amaranth> pitti: I bet a quarter of that is compiz :/
[14:46] <bratsche> pitti: Yes we do.  But the timeout is currently set to like 10 or 15 seconds or something in case something goes wrong.
[14:47] <kenvandine> pitti, so that isn't a bug... more of a design decision :)
[14:47] <kenvandine> 10s is enough time for gnome to load here... not sure if we should bump that up
[14:48] <bratsche> We could bump it to 15s if you think it's necessary, but I would not want to go higher than that I think.
[14:48] <kenvandine> 10s is enough for my laptop, desktop and all my test VMs :)
[14:49] <pitti> kenvandine: right, I just noticed it
[14:49] <pitti> but if we shold get the d-bus commands in the normal case, the timeout shouldn't actually kick in normally, no?
[14:50] <bratsche> pitti: One thing I'm wondering about (and I think seb maybe answered this for me in Dublin and I forgot now).. is why can't we enable metacity compositing for the gdm user's session?
[14:50] <bratsche> pitti: Right, the timeout is only for the fallback in case something with the dbus signals goes wrong.  So it's okay if it's set longer, but 40s sounds longer than I'd want even the fallback.
[14:51] <bratsche> pitti: Because if something goes wrong on a system whose desktop normally loads in 10s.. then that user is sitting on xsplash for 40s.
[14:51] <pitti> bratsche: right, 15 seconds seems appropriate to me as well
[14:52] <pitti> bratsche: we have never had a broad test of metacity compositing, it will cause a whole new flush of hardware specific bugs (similar to compiz) (that was the reason AFAIUI)
[14:52] <bratsche> Oh okay, bummer.
[14:53] <pitti> bratsche: but gdm doesn't actually use/need compositing, or do you plan a new theming for it?
[14:53] <Amaranth> yay buggy drivers
[14:53] <pitti> bratsche: well, not just the drivers, also the WM itself; many bugs are in compiz proper
[14:53] <bratsche> pitti: The original xsplash spec wanted it to fade in both the gdm and user sessions, but right now it can only fade out in the user session.
[14:53] <pitti> and given how excruciatingly bad mutter is at the moment, I wouldn't expect metacity to be so much better :/
[14:53] <bratsche> And right now it looks pretty terrible in the gdm session imo.
[14:54] <pitti> ah, I see
[14:54] <pitti> that's a matter of WM?
[14:54] <pitti> I had expected that xplash itself would need to enable compositing
[14:54] <pitti> but I don't pretend to actually understand compositing that much
[14:54] <bratsche> I just set the window opacity to fade it, but you have to have compositing enabled for that to do anything.
[14:55] <Amaranth> pitti: xsplash could be a compositor but it would have basically a copy of the metacity code
[14:55] <bratsche> Amaranth: Yeah, I thought about that but that's getting way out of scope. ;)
[14:55] <pitti> can we enable metacity compositing in gdm only?
[14:55] <Amaranth> the only other way to do a fade is the way gksu used to before I patched it: take a screenshot and blend the screenshot with your final look over time
[14:55] <pitti> without enabling it for user sessions?
[14:56] <bratsche> pitti: I would assume we could, yes.. it's just a gconf setting for gdm user.
[14:56] <Amaranth> but you can't do that in this case because without a compositor your final screen is blocked from view anyway
[14:56] <Amaranth> metacity compositing is actually pretty stable
[14:57] <Amaranth> The two times it is most likely to break are turning it on and turning it off though
[14:58] <Laney> I found it to be more stable than compiz, fwiw
[14:58] <bratsche> heh
[14:58] <Laney> but bugs are likely to be hardware specific eh
[14:58] <bratsche> I never noticed stability issues with either, but I didn't run metacity compositing for very long.  It's very slow, not suitable for a user session.
[14:59] <Amaranth> bratsche: depends on your video card, drivers are more likely to get OpenGL acceleration right than XRender acceleration
[14:59] <bratsche> Amaranth: Will the XRender fu work correctly if you don't have any special drivers?  That's probably the most important thing in this case.
[14:59] <Amaranth> bratsche: but even running it all in software should be fine for gdm
[15:00] <Amaranth> bratsche: turn it on when using the vesa driver and see :)
[15:00] <bratsche> k
[15:00] <Amaranth> if that is fast enough for xsplash you should be ok
[15:01] <bratsche> I'll try it after my next call.
[15:01] <Amaranth> although you'll have to consider netbooks with GMA500 chips too since that'll probably be all software rendering on the atom
[15:07] <ArneGoetje> pitti: the Xsession.d/ magic has not happend yet... and I would need some help for this to happen, since I'm very busy with the language-selector development in the moment. The changes would need to go into the im-switch package.
[15:32] <mac_v> mvo: how do i install software store?
[15:32] <mac_v> i dont see it in my updates  , ppa?
[15:44] <mac_v> hmm... is installing from the deb the only way?
[15:46] <mac_v> nevermind i found it ;) ,
[16:08] <hggdh> a question: re. bug 418416 -- the impact *may* be severe for Finnish users (with libmalaga and voikko*). Is this enough for a SRU to Jaunty? Patch is already in Karmic
[16:39]  * rickspencer3 is doing a dist-upgrade before team meeting
[16:39] <cassidy> hi guys. Would be cool to fix https://bugs.edge.launchpad.net/ubuntu/+source/gnome-doc-utils/+bug/418702 as this block the next Empathy release
[17:23] <kklimonda> transmission 1.73-5/1.74-1 provides a new QT interface. Does it have to go in before feature freeze?
[17:25] <rickspencer3> desktop team meeting in 5 minutes
[17:25] <rickspencer3> kklimonda: yes, I would think so
[17:25] <rickspencer3> that sounds like a new feature
[17:25] <rickspencer3> kklimonda: is there a QT interface now, and this just tweaks it, or is a QT interface a new feature?
[17:26] <chrisccoulson> pitti - just looking at libgda3 rdepends now
[17:26] <chrisccoulson> they're all in universe
[17:26] <chrisccoulson> so, that can be demoted can't it?
[17:26] <kklimonda> a interface was introduced in 1.70 upstream release but 1.73-5 is the first debian package that has it enabled.
[17:27] <chrisccoulson> kklimonda - the debian package splits the qt interface in to a separate package doesn't it?
[17:27] <kklimonda> yes
[17:30] <bryce> heya
[17:30]  * pedro_ waves
[17:30] <rickspencer3> hiya bryce
[17:30] <rickspencer3> team meeting time
[17:31] <rickspencer3> ArneGoetje: awe: bryce: ccheney: kenvandine: Riddell: pitti: TheMuso: tkamppeter: ready?
[17:31] <pitti> o/
[17:31] <ccheney> hi
[17:31] <Riddell> group hug time?
[17:32] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-08-25
[17:32] <rickspencer3> hehe
[17:32]  * rickspencer3 taps gavel
[17:32] <ArneGoetje> rickspencer3: here
[17:32] <rickspencer3> If you look at the meeting page, you can see that I cut the meeting back to just Feature Freeze topics
[17:32]  * kenvandine is ready
[17:32]  * awe waves
[17:33] <rickspencer3> essentially, I'd like everyone to give pitti a quick status update on your feature areas wrt feature freeze
[17:33] <rickspencer3> and allow questions
[17:33] <rickspencer3> for some, this will be quite quick
[17:33] <pitti> right, I'd like to run over the ones at https://blueprints.edge.launchpad.net/ubuntu/karmic/+specs?searchtext=desktop-karmic- which aren't "beta avail" or "implemented" yet
[17:33] <rickspencer3> pitti: shall we start with those?
[17:33]  * rickspencer3 hand mic to pitti
[17:33] <pitti> sorted by "delivery"
[17:33] <pitti> from the top
[17:34] <pitti>    desktop-karmic-bug-workflow
[17:34] <pitti> that's not really bound to FF, is it?
[17:34] <pitti> it's a separate tool
[17:34] <rickspencer3> pitti: nop
[17:34] <pitti>    desktop-karmic-integrating-with-ubuntu-one (started)
[17:34] <rickspencer3> kenvandine: ^
[17:34] <kenvandine> that should be done tomorrow
[17:34] <pitti> kenvandine: we need to push this by FF, and get some packages on the CDs, I think
[17:35] <kenvandine> yeah
[17:35] <pitti> what are the main blockers here?
[17:35] <kenvandine> desktopcouch release
[17:35] <kenvandine> and evo couch release
[17:35] <pitti> (and I think it's not negotiable for karmic :) )
[17:35] <kenvandine> both due today
[17:35] <pitti> sounds on track then
[17:35] <kenvandine> yup
[17:35] <pitti>    desktop-karmic-quickly (Started)
[17:35] <rickspencer3> pitti: that should be beta available
[17:35] <pitti> my thought
[17:35] <rickspencer3> we will put v 0.2 into universe as soon as desktopcouch is in main
[17:36] <pitti> I'd appreciate if someone else could update spec states accordingly
[17:36] <rickspencer3> we are just waiting to doublecheck that it works with the latest
[17:36] <tkamppeter> hi
[17:36] <rickspencer3> pitti: will do
[17:36] <pitti> web tube is excruciatingly slow for me right now, and it'd take me minutes
[17:36] <pitti> rickspencer3: merci
[17:36] <pitti>    desktop-karmic-gnomescan (started)
[17:36] <pitti> kenvandine: should we postpone that, perhaps?
[17:36] <kenvandine> pitti, did you test that?
[17:36] <kenvandine> it is ready... but you wanted to test it
[17:37] <kenvandine> i am fine with postponing...
[17:37] <pitti> gnomescan? just around UDS, and it was basically unusable
[17:37] <kenvandine> pitti, no... remember you planned on testing after your vacation?
[17:37] <pitti> kenvandine: ah, ok
[17:37] <kenvandine> that was a 2 year old version
[17:37] <pitti> well, don't block that on me
[17:37] <pitti> if you still wnat to land it, fine
[17:37] <kenvandine> i do... :)
[17:38] <kenvandine> it is far simpler to use :)
[17:38] <kenvandine> but you weren't comfortable with it yet...
[17:38] <pitti> anyone else has a scanner, too?
[17:38] <rickspencer3> kenvandine: pitti: I would propose getting it in asap, and then we test it
[17:38] <kenvandine> mine is broken...
[17:38] <pitti> kenvandine: ok, let's discuss this later then; seems implementing this spec is trivial once we decide
[17:38] <rickspencer3> and then we can revert if necessary
[17:38] <kenvandine> yeah
[17:38] <rickspencer3> I have a scanner
[17:39] <kenvandine> install flegita and flegita-gimp
[17:39] <pitti> right, still the old problem; wrong workflow, only png, no brightness/contrast/gamma changing
[17:39] <kenvandine> testing it natively and in gimp
[17:39] <pitti> and no clipping
[17:39] <kenvandine> pitti, yeah... it is simple
[17:39] <kenvandine> xsane is the opposite :)
[17:39] <pitti> ah, clipping works
[17:40] <pitti>    desktop-karmic-wine-integration
[17:40] <pitti> Yokozar is offline right now
[17:40] <pitti> we might need to postpone that
[17:40] <pitti>    desktop-karmic-network-ui (slow progress)
[17:40] <pitti> awe: do you happen to know about this?
[17:40] <awe> yea
[17:41] <awe> i'm working on menu changes this week.  the WEP dialog changes are mostly done as well.
[17:41] <awe> should be in good shape
[17:41] <pitti> so should it actually be better than "slow progress" right now?
[17:41] <pitti> and you plan to land the essential bits in time for UIF? (I guess FF doesn't apply here, UIF is more interesting)
[17:42] <awe> FF is thurs, corrrect?, when is UIF?
[17:42] <pitti> two weeks later
[17:42] <rickspencer3> awe: two weeks later
[17:42] <awe> yea, the features should be landed before UIF
[17:42] <pitti> good; please update the status then, "good progress"
[17:42] <awe> ok, will do
[17:42] <pitti>    desktop-karmic-compiz-bug-management (slow progress)
[17:43] <pitti> not bound by FF, I think
[17:43] <rickspencer3> pitti: right
[17:43] <pitti> desktop-karmic-language-selector (slow progress)
[17:43] <pitti> ArneGoetje ?
[17:43] <ArneGoetje> yeah... probably needs exception
[17:43] <ArneGoetje> I'm halfway through, basically
[17:44] <pitti> much of it is UIF, I take it
[17:44] <ArneGoetje> yes
[17:44] <pitti> but e. g. the language-support reorg and LANG vs. LANGUAGE is FF
[17:44] <ArneGoetje> language-support reorg is done, version is in ppa for testing
[17:44] <ArneGoetje> LANG vs. LANGUAGE not yet
[17:45] <ArneGoetje> currently working on that
[17:45] <pitti> do you think you can upload the lang-support reorg by Thursday?
[17:45] <ArneGoetje> if people help me to test, yes
[17:45] <pitti> please send a CFT to u-devel@ then
[17:46] <ArneGoetje> ok
[17:46] <pitti> and u-translators@
[17:46] <pitti> thanks!
[17:46] <pitti> so we might need to postpone parts of that
[17:46] <pitti>    desktop-karmic-gnome-3 (good progress)
[17:46] <pitti> that's a collection of "target of oppportunity"
[17:46] <rickspencer3> pitti: right
[17:46] <pitti> and fine AFAICS
[17:47] <pitti>    desktop-karmic-evolution-couchdb (good progress)
[17:47] <rickspencer3> the packages are in universe, now it's a matter of how much seb128 can get done
[17:47] <pitti> kenvandine?
[17:47] <kenvandine> that should be beta available or implemented
[17:47] <kenvandine> it is feature complete
[17:47] <pitti> rickspencer3: that one was about old library migration, I think
[17:47]  * kenvandine doesn't have perms to change that
[17:47] <pitti> kenvandine: please change status then (although I guess there should be one work item for gettting it on the CD?)
[17:47] <kenvandine> the work item is on the u1 one
[17:47] <rickspencer3> pitti: gnome3 has three parts: 1. gnome-shell, 2. zeitgeist, 3. library migration
[17:48] <rickspencer3> 1 and 2 are done, and 3. is just keeping working up until the bitter end
[17:48] <pitti> rickspencer3: 1 and 2 are "get the new components in universe: DONE", I think
[17:48] <rickspencer3> right
[17:48] <pitti> kenvandine: ah, I see; so, implemented is fine, please change
[17:48] <rickspencer3> so we could set it to beta available, I think
[17:48] <kenvandine> pitti, i can't
[17:48] <pitti> desktop-karmic-gdmconfig (good progress)
[17:48] <kenvandine> that should be beta available at least
[17:48] <pitti> kenvandine: uh? aren't you assignee?
[17:49] <kenvandine> pitti, no
[17:49] <kenvandine> rodrigo is
[17:49] <rickspencer3> pitti: I changed that to implemented
[17:49] <rickspencer3> gdmconfig
[17:49] <pitti> set to beta
[17:49] <pitti> rickspencer3: oops, mid-air collision then, sorry
[17:49] <pitti> set to implemented
[17:49] <kenvandine> rickspencer3, can you change the evo-couch blueprint to implemented
[17:49] <pitti> kenvandine: already done
[17:49] <kenvandine> thx
[17:49] <pitti> anyway, gdmconfig
[17:50] <pitti> I think that should be at least beta avail, it's in the default install
[17:50] <pitti> ah, rickspencer3 changed it
[17:50] <rickspencer3> sorry
[17:50] <pitti> desktop-karmic-bluetooth-stack (good progress)
[17:50] <rickspencer3> :)
[17:50] <rickspencer3> awe: ^
[17:50] <pitti> rickspencer3: no, that was good :)
[17:50] <rickspencer3> ?
[17:50] <awe> question....
[17:50] <awe> if a MIR has been filed...
[17:50] <awe> can the task be marked DONE?
[17:51] <pitti> no, it needs to be approved
[17:51] <awe> OK
[17:51] <rickspencer3> well ...
[17:51] <pitti> there's often feedback for fixes that need to happen
[17:51] <awe> second question...
[17:51] <awe> how does a package get demoted to universe?
[17:51] <pitti> awe: if that's blocking you for something FFish, please get it to me after the meeting
[17:51] <awe> eg. bluez-gnome
[17:51] <pitti> awe: demoted> officially: report a bug against it, and subscribe ubuntu-archive
[17:51] <awe> ok
[17:52] <rickspencer3> does bluez need to be demoted?
[17:52] <pitti> awe: but in practice, you just get the new package into the seeds, and then it'll automatically fall out of main
[17:52] <awe> bluez-gnome, not bluez
[17:52] <pitti> rickspencer3: no, I think that's the underlying daemon which we keep
[17:52] <awe> pitti, ah ok
[17:52] <rickspencer3> k
[17:52] <pitti> awe: so promoting it to main and getting it into the seeds is the only remaining thing for this spec?
[17:53] <awe> pitti, it's been promoted to main, the mir bug hasn't been closed though...
[17:53] <awe> i'll follow up and make sure to update the spec accordingly
[17:53] <pitti> work items say that it's just MIR, documentatino, and testing what is left, so that looks good
[17:53] <awe> yea
[17:54] <pitti> awe: indeed, it's already the default in ubuntu-desktop
[17:54] <pitti> awe: please set to beta avail then
[17:54] <awe> ok
[17:54] <pitti> and "implemented" once all the remaining work items are done
[17:54] <pitti> desktop-karmic-browsers (good progress)
[17:54] <awe> np
[17:55] <pitti> says "good progress", but all work items are "TODO"
[17:55] <pitti> but at least the ffox 3.5 migration is mostly done, AFAICS, so that might be stale
[17:55] <rickspencer3> pitti: it's odd, as I think it overlaps with mozilla 3.5 spec
[17:55] <rickspencer3> and chromium is outside scope of ff, I think
[17:56] <rickspencer3> I suggest we follow up with asac when he gets back next week
[17:56] <pitti> right, I think for FF this is good enough, and we'll ask asac to update the spec next week
[17:56] <pitti> same for desktop-karmic-firefox-3.5
[17:56] <pitti> 3.5 is the default, so for FF purposes this is beta avail
[17:56] <rickspencer3> yes, I think it should be set to beta avail
[17:57] <pitti> (changed)
[17:57] <pitti>    desktop-karmic-gnome-speech-replacement (good progress)
[17:57] <pitti> I guess TheMuso is tight asleep
[17:57] <rickspencer3> right
[17:57] <rickspencer3> hold on
[17:57] <pitti> rickspencer3: could you perhaps handle that in the eastern edition?
[17:57] <rickspencer3> go ahead, I'll check my notes
[17:57] <pitti> I'm afraid I don't know about this one
[17:57] <rickspencer3> yes, and we will cover tonight/tomrrow
[17:58] <pitti>    desktop-karmic-social-from-the-start (good progress)
[17:58] <pitti> kenvandine?
[17:58] <kenvandine> gwibber feature work is done, being merged back into trunk then will branch for 2.0... shooting to upload a snapshot of 2.0 tomorrow
[17:58] <kenvandine> i need to do the MIR for that (today)
[17:58] <kenvandine> this one will be tight, but should make it
[17:58] <pitti> is it bound to get on the CDs?
[17:58] <kenvandine> yes
[17:58] <kenvandine> afaik
[17:59] <rickspencer3> kenvandine: pitti: I have to ask again
[17:59] <pitti> so, another 2.5 MB to take from the -1 MB of free CD space
[17:59] <pitti> (different topic, though)
[17:59] <rickspencer3> why are we pushing gwibber into main now?
[17:59] <kenvandine> rickspencer3, yeah... please find out asap
[17:59] <kenvandine> rickspencer3, cause i was told it would be on the CD
[18:00] <kenvandine> if not then no need for main
[18:00] <rickspencer3> but that was for dx features that aren't going to be implemented
[18:00] <kenvandine> rickspencer3, i don' tthink that was the driver
[18:00] <kenvandine> that came up after the social from the start stuff started
[18:00] <kenvandine> it wasn't initially dx work
[18:00] <rickspencer3> kenvandine: right, the idea being that all kinds of stuff would use the backend
[18:00] <pitti> isn't empathy enough "social" :-)
[18:00] <kenvandine> hehe
[18:00] <kenvandine> pitti, true!
[18:01]  * ccheney hopes gwibber is somewhat more stable than it was in June
[18:01] <kenvandine> ccheney, should be
[18:01] <rickspencer3> let's take as POR that we don't need Gwibber in main, and I'll follow up asap to make sure that there is buy in
[18:01] <rickspencer3> if there is push back, we'll get an exception
[18:01] <kenvandine> rickspencer3, thx!
[18:01] <rickspencer3> 1. Gwibber 2 is coming in hot
[18:01] <pitti> more seriously, seb128 had some real issues with the code quality and architecture
[18:01] <rickspencer3> 2. We are desperate for room on the CD
[18:01] <kenvandine> rickspencer3, agreed
[18:01] <rickspencer3> pitti: right, that's kind of my #1
[18:02] <pitti> but we traditionally have been moving stuff to main way past FF, as long as the package itself sticks to FF
[18:02] <pitti> but it should happen before beta
[18:02] <kenvandine> ok
[18:02] <pitti> and finally
[18:02] <pitti>    desktop-karmic-input-methods (good progress)
[18:02] <pitti> ArneGoetje?
[18:03] <pitti> kenvandine: oh, if the rest is done, please set to "beta avail"
[18:03] <pitti> kenvandine: (MIR can be "POSTPONED" then)
[18:03] <ArneGoetje> ibus-anthy, -hangul and -chewing need to be synced from debian, then the seeds can be changed
[18:03] <kenvandine> ok
[18:03] <kenvandine> will do
[18:03] <ccheney> pitti: cases where that was caused by OOo shouldn't happen much anymore (if at all)
[18:03] <pitti> ArneGoetje: I saw the bug, will sync as soon as they actually land in sid
[18:03] <ArneGoetje> pitti: ok
[18:03] <pitti> ccheney: "that"?
[18:04] <ccheney> pitti: er the pushing stuff into main from universe past FF
[18:04] <pitti> ArneGoetje: so we're missing the small change to the xsession.d script to select the right method (scim vs. ibus), right?
[18:04] <pitti> chrisccoulson: ah, good to know
[18:04] <ArneGoetje> pitti: then we need to figure out how much space on the cd the scim/ibus shuffle will buy/cost us
[18:04] <ccheney> pitti: we used to put a new OOo in right around final freeze which would pull a lot of things in
[18:04] <pitti> chrisccoulson: now eucalyptus has taken over the role of "need 60 new java libs" :)
[18:04] <ArneGoetje> pitti: yes. that should be done in im-switch, I guess... however, it's not trivial.
[18:04] <ccheney> pitti: for the past release cycle (and hopefully to continue) we will have the final version of OOo in around feature freeze
[18:05] <chrisccoulson> pitti - do i need to do a full MIR for libgda4?
[18:05] <pitti> chrisccoulson: after meeting, please
[18:05] <chrisccoulson> pitti - no problem:)
[18:05] <pitti> chrisccoulson: (not really, but we generally object to library duplication)
[18:06] <ArneGoetje> pitti: if anyone with a better background knowledge of update-alternatives could assist for doing that, I would highly appreciate it.
[18:06] <pitti> ArneGoetje: update-alternatives?
[18:06] <ArneGoetje> pitti: yes, that's what selects which IM is going to be used.
[18:06] <pitti> ArneGoetje: I thought that was an user setting
[18:07] <pitti> ok, then u-a on a system level; in away that should make things easier
[18:07] <ArneGoetje> pitti: if we want to have it automatically, u-a is the current way im-switch uses it
[18:07] <ArneGoetje> pitti: only problem is, im-switch uses it based on the user's locale
[18:08] <pitti> right, that's why I thought it was an user setting
[18:08] <pitti> ok, let's discuss after meeting
[18:08] <ArneGoetje> ok
[18:08] <pitti> actually, that's the end of the list
[18:08] <pitti> the rest is beta avail/implemented
[18:08]  * pitti hands mike back to rickspencer3
[18:08] <pitti> thanks everyone
[18:08]  * rickspencer3 will have lots of summarizing to do
[18:09] <rickspencer3> before we end, I'd like to touch on a couple of hot spots that may not be ff related per se
[18:09] <rickspencer3> bryce: x? seems to be working well ... are we more or less running our final xstack now?
[18:09]  * rickspencer3 asks loaded question
[18:10]  * pitti is particularly interested in ATI/KMS, since that's FFish
[18:10] <bryce> rickspencer3, pretty close
[18:10] <bryce> rickspencer3, still need to get -ati updated, and there was a problem with last week's mesa upload I need to investigate
[18:10] <bryce> rickspencer3, aside from that it's mostly bug fixing here on out
[18:10] <rickspencer3> bryce: so the mesa 7.6 branch did not upload?
[18:10] <bryce> rickspencer3, it uploaded but didn't build on the buildd's
[18:11] <rickspencer3> oops
[18:11] <rickspencer3> ok
[18:11] <bryce> (built fine in ppas, I think it's just a version discrepancy on libdrm)
[18:12] <rickspencer3> so when you get that sorted out, we may see some regressions, but ati kms should work, right?
[18:12] <bryce> once that's sorted, people will be able to test ati kms, but we'll still be running ums at that point
[18:12] <rickspencer3> ok
[18:12] <rickspencer3> thanks
[18:12] <bryce> it'll take a kernel change to switch us to kms officially
[18:12] <bryce> if the testing goes well
[18:12] <rickspencer3> ok
[18:13] <rickspencer3> so this is next weekish?
[18:13] <bryce> yes, the mesa and -ati stuff should be this week by thursday, the kernel change can be whenever, it's minor
[18:13] <bryce> (I think... need to doublecheck with andy)
[18:13] <pitti> bryce: can you test it already with a kernel option in grub?
[18:14] <bryce> pitti, not until the mesa/-ati stuff is sorted
[18:14] <pitti> right, I meant kernel-wise
[18:14] <bryce> pitti, oh I believe so, but that's what I need to doublecheck with andy
[18:15] <rickspencer3> we should track this, as it will be new features after ff ...
[18:15] <rickspencer3> but in general, sounds managable
[18:15] <rickspencer3> bryce: thanks for your very systematic efforts moving x forward this release!
[18:16] <rickspencer3> ccheney: thanks for getting us in good position wrt OOo despite being on your OEM rotation
[18:16] <rickspencer3> finally ... looking at the burndown chart has been giving me some heartburn for the last couple of weeks
[18:16] <Riddell> yay for KDE OOo integration getting in
[18:16] <rickspencer3> though folks assure me that after feature freeze, there should be a dramatic reduction in open items
[18:17] <rickspencer3> so I think we need to go on a postponing binge right after FF, probably monday
[18:17] <kenvandine> rickspencer3, there are a bunch of extra work items on the u1 integration blueprint
[18:17] <rickspencer3> it is better to postpone early
[18:17] <kenvandine> stuff that ended up landing in other things...
[18:17] <kenvandine> noise
[18:17]  * rickspencer3 did not single out kenvandine ;)
[18:18] <kenvandine> just saying that should drop it way down
[18:18] <rickspencer3> kenvandine: ok, would be useful to just delete those lines and remove the noise
[18:18] <kenvandine> like 12 or 15ish
[18:18] <rickspencer3> great
[18:18] <kenvandine> i want to run it by josh
[18:18]  * kenvandine wants rickspencer3 to sleep at night
[18:18] <rickspencer3> hehe
[18:18] <rickspencer3> last thing ..
[18:19] <rickspencer3> we have partners relying on us to help them achieve their goals ...
[18:19] <rickspencer3> and I can see everyone working hard to help them
[18:19] <rickspencer3> that's really great ... and when I look at the release as a whole, I see that we are on a great trajectory for both new features, and good stability
[18:20] <rickspencer3> this includes Ubuntu, Kubuntu, and UNR
[18:20] <rickspencer3> any other business?
[18:21] <bratsche> pitti: btw.. I'm noticing that I'm still having this problem in Karmic that when I switch from Normal effects to None, it works fine.. but going back to Normal effects doesn't work.  Do you know why this may be?  (Intel X3100 video hardware, fwiw)
[18:21] <rickspencer3> pitti: awesome job getting ff together, on your 2nd say back!!
[18:21]  * rickspencer3 taps gavel
[18:21] <pitti> bratsche: it's a bug in the capplet
[18:21] <pitti> :)
[18:21] <bratsche> Okay, cool.
[18:22] <pitti> cheers to the team :)
[18:22] <bryce> thanks
[18:22] <pitti> thanks everyone
[18:22] <pitti> bratsche: ah, actually no; AFAIR it quickly starts compiz, then fails, then starts metacity again, doesn't it? i. e. compiz bug
[18:23] <chrisccoulson> pitti / bratsche - i'd be interested if its a capplet bug just in case it's anything i broke when i ported to gtkbuilder ;)
[18:23] <pitti> chrisccoulson: no, that happened way before, I think
[18:23] <chrisccoulson> pitti - thanks:)
[18:23] <chrisccoulson> so, you free to talk about libgda now? ;)
[18:23] <pitti> and it really doesn't look being related to gtkbuilder
[18:24] <chrisccoulson> i cant test features like that in the capplet as i have no compositing on my setup at the moment ;)
[18:24] <pitti> chrisccoulson: as I said, the main problem is not so much the MIR bureaucracy, as library duplication
[18:25] <chrisccoulson> pitti - right. i think libgda3 can be demoted to universe though. i had a look at the rdepends, and it doesn't look like anything in main uses it anymore
[18:25] <bratsche> pitti: Yeah it pops up a dialog that says "searching for drivers" or something.. then it seems to start compiz, then reverts to metacity.  But if I go into gconf-editor and switch it to compiz manually and then run compiz --replace everything is fine.
[18:25] <pitti> chrisccoulson: checking
[18:26] <kklimonda> chrisccoulson, have you said anything about transmission qt? it looks i got disconnected from bnc and my backlog wasnt long enough.
[18:26] <chrisccoulson> kklimonda - no
[18:26] <pitti> chrisccoulson:
[18:26] <pitti> -- karmic/main build deps on libgda3-dev:
[18:26] <pitti> planner
[18:26] <pitti> that's the only thing
[18:26] <pedro_> pitti, may you have a look to bug 403192 later? we're having ~83 dups
[18:27] <pitti> pedro_: I already had a quick look, but this needs some serious time
[18:27] <chrisccoulson> pitti - doesn't that sound like a rogue dependency?
[18:27] <pitti> pedro_: it's on my radar, but not important enough to be done before FF, I'm afraid
[18:27] <chrisccoulson> (i didn't check libgda3-dev actually, i only looked at libgda3-3)
[18:27] <pedro_> pitti, ok, thanks!
[18:28] <pitti> chrisccoulson: I have no idea about planner, but apparently it uses some DB functionality?
[18:28] <james_w> pedro_: didn't I provide some patch for that already?
[18:28] <chrisccoulson> ah, yes
[18:28] <chrisccoulson> putti - but it's only a suggests
[18:28] <chrisccoulson> s/putti/pitti
[18:28] <chrisccoulson> lol
[18:28] <pitti> chrisccoulson: no, it's a build dep and a binary dep of planner-dev
[18:29] <james_w> yeah, I did, but it's rather a band-aid
[18:29] <james_w> there's a race condition or something at login
[18:29] <chrisccoulson> pitti - yes, you're right. so it's probably possible to port this to libgda4
[18:29] <pitti> right, and David said it "should not" fail
[18:30]  * kenvandine runs out for lunch
[18:30] <kklimonda> chrisccoulson, if everyone are too busy to make an update to 1.74 before deadline there is always my merge of 1.73-5 in LP. As QT is the only new feature we can always merge 1.74 after FF.
[18:30] <chrisccoulson> kklimonda - can you do the merge and the update to 1.74 in one go? :)
[18:31] <pitti> chrisccoulson: if the API isn't too different, perhaps it just works
[18:31] <Amaranth> bratsche: try to make it switch to compiz then look in .xsession-errors
[18:31] <kklimonda> the problem is I can't do it till this sunday as I'm on vacations (damn mobile phones and irc clients ;) )
[18:32] <Amaranth> finally a developer with this problem I can prod at :)
[18:32] <chrisccoulson> pitti - possibly. i will take a look at that and see
[18:32] <chrisccoulson> kklimonda - that's ok. i'm sure someone will pick it up if they have the chance
[18:47] <james_w> ha! https://code.edge.launchpad.net/~james-w/ubuntu/karmic/devicekit-disks/fix-403192/+merge/10675
[18:47] <james_w> take that bug!
[18:47] <bratsche> :)
[19:00] <chrisccoulson> pitti - it looks like some work to port planner from libgda3 -> 4
[19:00] <chrisccoulson> the api looks quite different
[19:03] <ccheney> rickspencer3-afk: i don't recall if i mentioned this earlier but the final OOo 3.1.1 should be out on Thursday so after that goes in only bug fixes from updated using newer ooo-builds will be added
[19:04] <ccheney> rickspencer3-afk: we're in the middle of a time crunch release for oem atm so pretty busy with it, but should be done in time to get OOo 3.1.1 in
[19:05] <rickspencer3-afk> ccheney, great
[19:06] <rickspencer3-afk> please let pitti know if you think there will be a ff related issue .. but I would think it would be fine to do after ff, since it's bug fixes for existing packages
[19:06] <ccheney> so far i don't know of anything except the splash screen which i already emailed kwwii about again
[19:07] <ccheney> but that is under uif instead
[19:33] <pitti> chrisccoulson: ok, don't waste too much work on it
[19:37] <ArneGoetje> pitti: discuss the Xsession.d/ stuff tomorrow?
[19:37] <pitti> chrisccoulson: ooh!
[19:37] <pitti> ArneGoetje: as you wish, now or tomorrow
[19:38] <ArneGoetje> pitti: well, it's 02:37 here
[19:38] <pitti> james_w: good work! btw, davidz is in #udev, if you want to discuss that directly with him
[19:39] <james_w> pitti: thanks. Post FF I think :-)
[19:43] <mclasen> didrocks: hey, I wondered if I could convince you to turn one of your notebook flipping demos into a gtk-demo example ?
[19:46]  * ArneGoetje needs to sleep
[19:47] <pitti> ArneGoetje: ah, tomorrow then; sleep well!
[20:01]  * kenvandine runs out for a bit, be back tonight!
[20:05] <didrocks> mclasen: it would be cool :) but again, the code is quite a hack atm and if we really want to implement such things, we will have to rewrite some part of gtk-clutter at leat (atm, a GtkClutter can only be binded to a GTKContainer which can be parented to a GTK Container itself!) So, we've to fix that first
[20:05] <didrocks> mclasen: also, there is some concerns about not having the tab rotating itself (which can be difficult to achieve with the current GTK Notebook component)
[20:06] <mclasen> didrocks: ah, if this uses clutter, it is not really suitable as drop-in for gtk-demo anyway
[20:06] <mclasen> I thought this was done manually, like alex' rotation example
[20:08] <didrocks> mclasen: alex' rotation was using gtk-clutter too, no? (if you speak about this demo: http://blogs.gnome.org/alexl/2009/06/12/the-return-of-client-side-windows/)
[20:09] <didrocks> "This is using the current client-side-windows branch of Gtk+, plus my own gtk-in-clutter code availible in the client-side-window branch of http://gitorious.org/clutter-gtk-copy."
[20:10] <mclasen> didrocks: theres a testoffscreen in the gtk tree that does not use any clutter
[20:13] <didrocks> mclasen: I'm using his modified gtk-clutter binding so, I guess it can uses offline screen too (I'm not really aware of that part)
[20:13] <mclasen> well, nice demos, anyway...
[20:13] <didrocks> thanks :)
[20:26] <chrisccoulson> hey pitti
[20:26] <chrisccoulson> (19:37:40) pitti: chrisccoulson: ooh!
[20:26] <chrisccoulson> did you mean to say something else, or did i miss something?
[20:26] <chrisccoulson> ;)
[20:26] <pitti> chrisccoulson: that was actually meant to go to james_w, but you deserve a hug as well! :-)
[20:26] <chrisccoulson> heh, thanks:)
[20:26]  * chrisccoulson hugs pitti
[20:29] <didrocks> mclasen: sorry, I didn't understand what you was telling the first time. Yes, it's using Alex' work for GtkClutterEmbeded and so, can use offscreen rendering
[20:49] <fta> who's maintaining liferea now?
[20:50] <fta> with the darkroom theme, links are unreadable (light yellow on white)
[23:55] <TheMuso> /c/c
[23:56] <hggdh> jcastro, ping
[23:59] <rickspencer3> robert_ancell, TheMuso - good morning
[23:59] <robert_ancell> hey rickspencer3


[01:15] <themonk> hi all
[01:16] <themonk> can anyone tell me when i should use peer?
[01:20] <jose> themonk: afaik it's when the service will relate to itself
[01:28] <lazypower> themonk: whenever you ahve scale out situations. as in you go from a single node to 2+
[01:28] <lazypower> those nodes are by defintion peers of one another. this is handy for say exchanging cookie secrets in webapps
[01:31] <themonk> another question if 2 charm require each other, do i use different name for same relation or same name?
[01:31] <themonk> hello lazypower :) how are you?
[01:34] <themonk> hello jose :)
[01:34] <jose> hey themonk!
[01:35] <jose> it's the same relation I think
[01:35]  * jose hasn't looked too much into peer relations
[01:36] <themonk> jose, forgate peer talking about normal relation :)
[01:36] <themonk> jose, forgate peer talking about normal relation  now:)
[01:36] <jose> oh
[01:37] <jose> themonk: what do you specifically mean by relation name?
[01:38] <lazypower> themonk: its all dependent on the interface you use. its dictated by the provides: and requires: directive in your metadata.yaml
[01:38] <lazypower> and i'm doing well, thanks :)
[01:41] <themonk> jose, lazypower, charm1->provides->relname1->interface1 and charm2->requires->relname1->interface1  then charm2->provides->relname2->interface2 and charm1->requires->relname2->interface2
[01:41] <themonk> this is the case
[01:43] <themonk> or will i do it like this: charm1->provides->relname1->interface1 and charm2->requires->_relname1->interface1  then charm2->provides->relname2->interface2 and charm1->requires->_relname2->interface2
[01:44] <jose> yeah, I think that's fine
[01:44] <themonk> jose, which one
[01:45] <jose> both are the same, I don't see any difference
[01:45] <lazypower> you've got a circular reference in relationships
[01:45] <lazypower> unless they need 2 specific defined interfaces
[01:45] <lazypower> you only need the provides/requires one way
[01:45] <lazypower> its a bidi comunication interface
[01:45] <lazypower> as in you can set on both sides, and receive on both sides. so you're good 2 go to exchange whatever data you need to send/receive across teh wire with just the singular interface
[01:46] <lazypower> these aren't governed by RFC's they are loosely coupled/typed relationships. arbitrary variables and values
[01:46] <jose> should we do a charm school about relations?
[01:46] <themonk> lazypower, hmm
[01:47] <lazypower> jose: there are several already
[01:47] <themonk> jose, yes that will be great
[01:47] <lazypower> juju.ubuntu.com/videos
[01:47] <jose> themonk: see ^
[01:47] <themonk> ok thanks man :)
[01:47] <lazypower> ugh
[01:47] <lazypower> its not clearly labeled as "relationships"
[01:48] <jose> who could've done that? *cough* jcas *cough* tro *cough*
[01:48] <lazypower> its in one of the getting started videos
[01:48] <lazypower> so it encompases more than just relationships
[01:48] <lazypower> i'm sorry i dont have a direct video link for you
[01:48] <lazypower> i'll raise the issue at tomorrow's standup that we need to do a video over relationships
[01:49] <lazypower> themonk: there's also an open call to 'what should we do next' on the list - which we'd love to have your feedback if you've got grey areas that a charm school would help with
[01:49] <lazypower> we're always upping our game, one week at a time, on getting new videos out there for our user base to really grokk what we're doing with juju
[01:49] <lazypower> so make sur eyou're subbed to<EMAIL_ADDRESS>to get in on all the community voting action
[01:50] <themonk> hmm ok i will
[01:51] <themonk> AFK 15 min
[03:48] <l1fe> quick question: i've been creating and destroying some juju environments
[03:49] <l1fe> however after destroying an environment, juju-mongodb is leftover
[03:49] <l1fe> when i try to purge/auto-remove it
[03:49] <l1fe> an upstart script somewhere keeps on redownloading the package and reinstalling mongodb
[03:49] <l1fe> how the heck do i stop this?
[03:51] <l1fe> i'm currently on juju 1.19.4 running on maas with trusty nodes all over
[03:58] <l1fe> n/m...had to remove the upstart scripts in /etc/init and then purge
[04:35] <lazypower> l1fe: sounds bugworthy. can you file a bug against juju-local about that?
[08:06] <mwhudson> 237.872  + juju deploy --to 0 nova-compute237.873  ERROR cannot upload charm to provider storage: Head http://<IP_ADDRESS>:8040/: dial tcp <IP_ADDRESS>:8040: connection refused
[08:06] <mwhudson> would this be a race condition?
[08:06] <mwhudson> it's in a script that does more or less "juju bootstrap; juju deploy --to 0 nova-compute"
[08:07] <mwhudson> (manual provider)
[11:33] <schegi> anyone here who could help with a cloud-init-nonet issue during boot??
[13:03] <voidspace> https://github.com/juju/testing/pull/17
[13:27] <l1fe> sorry to be a bother, but i'm trying to deploy juju-gui on my juju environment, it every time i try, my node stays in pending status
[13:27] <l1fe> i'm deploying on a MAAS controlled, 4 node environment
[13:28] <l1fe> bootstrap worked, relatively well, although i had to manually go in an create a /var/lib/juju/nonce.txt in order for it to not timeout
[13:28] <l1fe> when i do a "juju deploy juju-gui" it kicks off the process fine, and in maas it shows the node as going from ready to "allocated to root"
[13:29] <l1fe> but ultimately nothing is ever done on the node
[13:30] <l1fe> also, nothing really shows up in the all-machines.log in /var/log/juju
[16:35] <cory_fu> So, jose commented on my choice of using a juju run script for setting admin passwords in the Apache Allura charm (https://bugs.launchpad.net/charms/+bug/1314699), but I'm still not convinced that having a config option is the right approach for admin passwords.
[16:35] <_mup_> Bug #1314699: New charm - Apache Allura <Juju Charms Collection:Incomplete> <https://launchpad.net/bugs/1314699>
[16:37] <jose> cory_fu: hey, I recommended that because juju set is the default for any options you can configure, I would personally not have it as a run script
[16:38] <lazypower> cory_fu: didn't you email the list about it?
[16:38] <cory_fu> Yes.
[16:38] <lazypower> was there any traction from your list mailing that was pro/against?
[16:38] <jose> hmm, i didn't see that one
[16:39] <lazypower> i think its a unique approach - and it's definately work further investigation / discussion.
[16:39] <cory_fu> It kind of went off on a tangent about password-typed config options
[16:39] <lazypower> s/work/worth/
[16:39] <cory_fu> But I'm not convinced that passwords make sense as options at all, regardless of whether there's a password type
[16:40] <lazypower> if they're a salted hash in the database - whats the argument against that?
[16:40] <cory_fu> For one thing, the passwords can be changed outside of Juju, leading to a mismatch between Juju's idea of the password value and the actual password value
[16:40] <lazypower> sarnold: ping
[16:41] <cory_fu> I think Juju options make sense for things that can't be configured from within the application, but trying to manage application settings from Juju seems incorrect to me.
[16:41] <cory_fu> Honestly, it would be better if the application in question handled the initial admin password itself, on first run.
[16:41] <lazypower> cory_fu: whys that? we have several charms that support application configuration.
[16:42] <cory_fu> lazypower: So how do you handle the possibility of Juju resetting options that were changed from within the application due to Juju having an outdated idea of what the value should be?
[16:43] <lazypower> cory_fu: within the domain of what we're talking about, if juju has an idea of the application configuration, it makes sense to me to change those within juju and not the application.
[16:44] <lazypower> what's being described is very much a smiliar problem that exists with all CM frameworks - if you deploy msyql and tweak your my.cnf by hand - its going to be lost on the next convergence.
[16:44] <cory_fu> And if Juju doesn't cover all of the settings, you end up in a weird place where you should use Juju to set some of the options, and the application others, even if those options are on the same page within the application.
[16:44] <cory_fu> In Allura's case, there are three default users set up.  So you would presumably set the "root" user's password via Juju, but none of the others?
[16:45] <jose> you can have three config options
[16:45] <cory_fu> Though that's not as bad as being in a situation where you have to remember "the 5th option down on the settings page shouldn't be touched, since it's handled by Juju"
[16:46] <lazypower> cory_fu: so a lot of this sounds like it would be well served by juju-actions when they land. Such as setting up username/passwords
[16:46] <cory_fu> jose: That seems like config.yaml bloat.  :)  What about the other users that will later be added?  And what if the admin removes the default users and creates a new admin user?
[16:46] <lazypower> that prevents it from being a configuration option and exposed
[16:46] <cory_fu> lazypower: +1 and that's what I was using the run script as a makeshift version of.  :)
[16:47] <lazypower> and exposes an option for you to add/remove users with juju through an action.
[16:47] <lazypower> cory_fu: oh i'm pretty much for your implementation
[16:47] <lazypower> cory_fu: i'm playing devils advocate here so its being fleshed out in everybody's face so when we start doing more of this, i can point to the irc log and say "we talked about it on the list and here - i like this better +1 for participation"
[16:47] <cory_fu> jose: Just to be clear, I'm not entirely averse to adding a "root-password" option to the Allura charm.  Just raising it for discussion.  :)
[16:48] <cory_fu> lazypower: Good
[16:49] <cory_fu> That's also why I raised it here.  I'm currently adding the option to the charm, anyway, though I'm going to leave the run scripts in (since I basically need them to set the password anyway)
[16:49] <lazypower> cory_fu: nah leave the run script
[16:49] <lazypower> what you've got makes all the sense in terms of domain specific configuration
[16:49] <lazypower> the service doesn't expose a default password that can be hacked
[16:50] <lazypower> i wont nack it for a missing password config value - especially since as you pointed out, there are 3 users with only 1 configuration option.
[16:50] <lazypower> bcsaller: will you have a chance to review allura this week? Cory's got a really interesting implemenation that could set the model for charm security moving forward.
[16:51] <cory_fu> It also uses the services framework (though it's probably not the best poster-child)
[16:51] <lazypower> well - i know that actions are going to land in the not so distant future
[16:51] <lazypower> so this is a really good stop gap / prototype implementation until we get 'juju actions'
[16:52] <lazypower> its the first charm that i'm aware of that will have a juju-run based config step too, which i like. its exposing more usefuleness to juju-run
[16:52] <cory_fu> jose: What was that charm I gave you a +1 on recently?
[16:52] <lazypower> HAHAHA cory_funo retroactive -1's!
[16:52] <lazypower> j/k, nack away ;)
[16:53] <jose> cory_fu: tracks I think?
[16:53] <cory_fu> No, I think it started with a C?
[16:53] <lazypower> chamilio
[16:53] <cory_fu> I wish there was a way to see my past activity on Launchpad
[16:53] <cory_fu> lazypower: That's the one.
[16:53] <jose> I've been working in many charms lately
[16:54] <cory_fu> That would be awesome to convert to the services framework, since it would make all of the effort of having to maintain the dot-files go away
[16:54] <lazypower> cory_fu: services framework?
[16:54] <cory_fu> jose: You're a charming monster.  :)
[16:54] <lazypower> he's Charmbot 5000
[16:54] <jose> BTW, I do like the approach you have and believe it's worth a Discussion
[16:55] <jose> yeah, see my /nickserv info
[16:55] <cory_fu> lazypower: The thing that we have proposed for merging into charmhelpers, and that I use in the Allura charm, that we developed while working on Cloud Foundry
[16:55] <lazypower> Ah, i saw teh inclusion of custom helpers
[16:55] <lazypower> i didnt dive too deep into it, when i reviewed allura it was a pretty fresh cut
[16:55] <lazypower> you'e since remixed the charm haven't you?
[16:56] <cory_fu> lazypower: Yeah, quite a bit
[16:56] <lazypower> that must be a post-review inclusion
[16:56] <lazypower> if bcsaller doesn't ping back about being able to review allura, ping me tomorrow and i'll dive into it
[16:56] <bcsaller> I see the branch, but I don't see it in the review queue
[16:57] <cory_fu> lazypower: The services framework, in a nutshell, is a system to automatically manage the complexity of dealing with figuring out at what point you have all the info you need to actually set up the software, which could come from disparate sources such as config, relation data, etc, and could end up being completed in any of a number of hook invocations
[16:57] <lazypower> bcsaller: the bug is incomplete
[16:57] <lazypower> https://bugs.launchpad.net/charms/+bug/1314699
[16:57] <_mup_> Bug #1314699: New charm - Apache Allura <Juju Charms Collection:Incomplete> <https://launchpad.net/bugs/1314699>
[16:58] <cory_fu> bcsaller: I'm about to update said bug, as I've made some changes
[16:58] <lazypower> cory_fu: whoa. thats awesome
[16:58] <lazypower> so you define the required params, and once everything in this dictionary is complete, we say "Ok return true and configure now"
[16:58] <bcsaller> lazypower: we did try to sell you all on this in Vegas :)
[16:59] <lazypower> bcsaller: i probably said shut up and take my money, then forgot i voted for it.
[16:59] <cory_fu> However, jose, I wasn't able to reproduce that issue with the mongodb hook error, nor even see how it could have occurred, since it could only happen if the pymongo library was broken
[16:59] <bcsaller> ha
[16:59] <cory_fu> As in, not properly installed
[16:59] <lazypower> bcsaller: you guys are like kickstarter - too many good ideas, me with too little money
[17:00] <bcsaller> just waiting for fb to dump 19M on us
[17:00] <lazypower> cory_fu: moving forward, when you want reviews - make sure the bug is "Fix Comitted" or "new"
[17:00] <lazypower> otherwise it gets scrubbed from teh queue
[17:00] <cory_fu> lazypower: Yeah, I know.  I was still in the process of making fixes
[17:00]  * lazypower flips tables
[17:00] <cory_fu> I literally *just* pushed up my last fix.  :)
[17:00]  * lazypower puts it back
[17:01] <lazypower> k
[17:02] <cory_fu> lazypower: Where are the IRC logs posted at?
[17:02] <jose> cory_fu: I'll have to check once I'm back home
[17:02] <jose> irclogs.ubuntu.com
[17:03] <cory_fu> lazypower: http://imgur.com/gallery/5VDqD3L
[17:04] <lazypower> cory_fu: you sir, have taken it to the next level.
[17:08] <sarnold> lazypower: pong :)
[17:09] <lazypower> sarnold: we had abit of a discussion up above between cory, jose and myself. From a Sec Audit perspective, how do you feela bout charms using isolated scripts to perform user/password management in leu of a configuration option on a charm?
[17:12] <sarnold> lazypower: heh, nice can of worms we've got here :)
[17:12] <lazypower> isn't it though?
[17:13] <lazypower> if you've got any input on the matter, i'd love to hear your opinions.
[17:14] <sarnold> ideally we wouldn't even have passwords -- they have to be stored somewhere, whether it is in mongo or a plain text file in ~/.juju/ somewhere. the danger of storing them in ~/.juju is that someone might check them into git as an easy way to 'distribute' juju control amongst a team..
[17:15] <sarnold> so it'd be wonderful if services that support key-based authentication could use keys, instead, but that's unrealistic to hope for that; some services just require passwords.
[17:15] <lazypower> sarnold: this is about a service thats being deployed with juju - in the event of apache allura - it come swith a root, a git, and a reviewer user (paraphrasing) - and we need to set them up in the application. Key based auth is not an option unfortunately - its a webapp.
[17:16] <sarnold> I would much prefer a centralized place to store them all, and using the juju set functionality is easily flexible enough to handle them all, but I further hope admins wouldn't actually need to set (or see) passwords as a regular part of business
[17:17] <sarnold> lazypower: ah; I had expected something more like pgsl accounts for applications, these are users "within" an application.
[17:17] <sarnold> lazypower: you just added some nuts to this can of worms :)
[17:17] <lazypower> correct. the 3 users are required to finalize a core installation.
[17:17] <lazypower> haha, well - i was thinking this was going a bit askew based on your answer
[17:18] <lazypower> and i'm also known as the master of no-context
[17:18] <sarnold> .. and so firing up e.g. juju set just to change the reviewer password seems heavy-handed :)
[17:18] <cory_fu> sarnold: Like I said above, ideally the application itself would manage the admin user / password and juju wouldn't have to get involved, but in this case (and others), the application needs a "bootstrap" user / password that can't be set up properly from within the application
[17:18] <sarnold> lazypower: well, it's certainly my fault for not reading -all- of scrollback, just enough to jump to the wrong conclusion :)
[17:19] <cory_fu> Really, once the admin password is set, it should be managed from within Allura, which is another argument against having it as a config option, IMO
[17:19] <sarnold> yeah, that makes sense
[17:21] <cory_fu> But I can also see having Juju actions for managing admin users as a convenience option.
[17:21] <sarnold> though, if we think about e.g. apache httpd; it has a pluggable authentication and authorization mechanism, different kinds of authetication can be required, and user/passwords can be handled via e.g. htpasswd or ldap or gdbm or any other number of tools; I might expect a "protected filesharing with apache" charm to provide configuration switches for the different mechanisms, and perhaps even a pre-seeding mechanism for the htpasswd method..
[17:23] <cory_fu> Exactly.  And Actions would seem like an ideal candidate for managing that.  Using a config option would seem wrong to me.
[17:23] <sarnold> so I might also expect that an allura charm could provide a way to preseed the values with a plain text file -- when they eventually grow a pluggable auth system to use e.g. github users or something, it might not be necessary..
[17:25] <cory_fu> Yeah.  Allura has some support for LDAP, so that's probably the right direction to go, long-term
[17:25] <lazypower> sarnold: that all feeds into actions being the path forward.
[17:25] <lazypower> do i take that as a vote pro script, nack on config?
[17:33] <marcoceppi> cory_fu: lazypower this sounds like it's best used with juju actions
[17:33] <marcoceppi> the password stuff
[17:33] <marcoceppi> I'd support a juju run to set password
[17:33]  * marcoceppi looks at charm
[17:33] <marcoceppi> It
[17:33] <marcoceppi> 's definitely not a blocker
[17:34] <lazypower> agreed
[17:34] <lazypower> i want to see more traction around this. i'm pretty sad that the conversation got derailed on the mailing list wrt a password field type. I think this warrants a follow up post to the thread
[17:35] <cory_fu> I can make a follow-up post.
[17:35] <cory_fu> And link to this discussion
[17:35] <lazypower> cory_fu: sounds good
[17:36] <cory_fu> Regarding the transient AttributeError, I was completely unable to reproduce it, nor come up with a reason why it might have happened or a way to prevent it in the future.  Would that be a blocker, or can we chalk it up to one of those things?
[17:37] <lazypower> if its missing, it looks like maybe pypi had a hiccup?
[17:37] <cory_fu> But how did the step that actually installed it not fail?  And how did it fix itself magically?
[17:37] <cory_fu> It makes no sense to me
[17:37] <lazypower> if it had a hiccup and pip install didn't exit 1 - it makes sense that retrying ti worked.
[17:38] <lazypower> i dont know if pip exits > 1 if an install fails, do you?
[17:38] <cory_fu> Re-running the relation-changed hook would not have installed pymongo.  That only happens in the install hook
[17:38] <lazypower> hmm
[17:38] <lazypower> well thats weird
[17:38] <cory_fu> Also, pymongo itself imported ok, it was only when accessing the MongoClient attribute that it barfed
[17:39] <cory_fu> I even tried looking at the pymongo source to come with an idea, and see nothing obvious
[17:39] <lazypower> i'm going to have to blame this one on khai
[17:39] <cory_fu> khai?
[17:40] <lazypower> marco wrote an RFC about khai being the root of all problems
[17:40] <cory_fu> What does he have against some random village in Pakistan?
[17:41] <marcoceppi> Khai is a person not a village
[17:41] <marcoceppi> though I feel bad for everyone in that village now
[17:42] <lazypower> marcoceppi: at some point you need to send me that RFC so i can mirror it and point people at it when i make that reference.
[17:43] <marcoceppi> lazypower: https://github.com/marcoceppi/547-khai
[17:43] <lazypower> YES!
[17:44] <marcoceppi> I need to update it, it's expired
[20:32] <tvansteenburgh1> HTTP 547, "Use in an abundantly conservative manor" https://github.com/marcoceppi/547-khai/blob/master/draft-547-http-547.nroff#L66
[20:32]  * tvansteenburgh1 imagines an abundantly conservative large country house, with much surrounding land.
[21:26] <alesage> trying to bootstrap a local env and finding that juju is trying to connect to mongodb at 37017 , my apt-get installed mongodb-server listening on 27017, something I'm doing wrong?
[21:27] <sarnold> alesage: juju supplies its own mongo, no?
[21:29] <alesage> sarnold, so I'm told, but juju bootstrap seems to want me to install one: http://pastebin.ubuntu.com/7738856
[21:30] <sarnold> alesage: ah, then I'll return to the background :) good luck
[21:31] <alesage> sarnold, thanks you gave me hope :P
[21:32] <sarnold> alesage: hooray! :)
[21:56] <lazypower> alesage: did you have the mongodb package instaleld prior to installing juju-local?
[21:57] <lazypower> sinzui: are we still providing support for running mongo in paralell with an existing mongodb install? i know this was a pain point in the past - not sure if it ever got resolved.
[21:57] <alesage> lazypower, don't think so
[21:57] <lazypower> alesage: initctl list | grep juju - can you pastebin the output of that command for me?
[21:58] <alesage> lazypower ok in process on another bootstrap attempt, one min
[21:59] <alesage> lazypower coming up blank fwiw
[21:59] <lazypower> dpkg -l | grep juju-local
[22:00] <alesage> lazypower, blank again, sensing a theme
[22:00] <lazypower> alesage: sudo apt-get install juju-local, then re-try the bootstrap with local provider
[22:01] <alesage> lazypower, attempting thx
[22:02] <alesage> lazypower, no errors thanks
[22:02] <alesage> "Starting Juju machine agent"
[22:02] <lazypower> alesage: np. Glad we got it sorted :)
[22:02] <lazypower> alesage: if you dont mind me asking, were you looking through the juju docs or did you just dive right into using juju?
[22:03] <alesage> lazypower, forgive the noobishness but I also have a 'local' env set up in .juju/environments, is this config 'parallel' to the local provider I've just installed??
[22:03] <alesage> lazypower, dove in with a howto from a colleague
[22:04] <lazypower> alesage: yep. local is an environment that deploys locally using LXC on your workstation. its intended for rapid deployment prototyping / charm development
[22:04] <lazypower> the idea is that you can export a bundle from your local environment, and move that to any public cloud that we support, such as hp-cloud, aws, joyent, etc.
[22:04] <alesage> lazypower, makes sense--just trying to clarify if a 'local' env named in my config would require that juju-local package to be installed?
[22:05] <lazypower> Correct, unless you changed the environment type
[22:05] <alesage> lazypower, ok thanks again
[22:05] <lazypower> as it were, if you feel like beign obscure between names that are meaningful to you - you could change it to type: ec2
[22:05] <lazypower> and plug in some AWS credentials
[22:06] <lazypower> and your 'local' environment is now an AWS provider based environment.
[22:06] <lazypower> which is a good point, i haven't asked about that in the past....
[22:08] <alesage> I see


[00:16] -SwissBot:#ubuntu-news- ::Planet:: Full Circle Magazine: Full Circle Weekly News #228 @ https://fullcirclemagazine.org/podcast/full-circle-weekly-news-228/
[02:14] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Ubuntu 21.10 Beta Released, This is What’s New @ https://www.omgubuntu.co.uk/2021/09/ubuntu-21-10-beta-ready-to-download (by Joey Sneddon)
[02:50] <guiverc> I see https://lists.ubuntu.com/archives/ubuntu-announce/2021-September/000273.html so I'll get it ready shortly
[03:16] <Bashing-om> UWN: ^ Gdoc updated.
[03:16]  * guiverc still *fighting* with wordpress
[03:17]  * guiverc but mostly it's editor
[03:18] <Bashing-om> guiverc: Good that you have the Know-How :D
[03:18]  * guiverc has almost NIL know-how, why I have to fight with it
[03:21] <Bashing-om> guiverc: I fail to be able to put any Know-How in your smart bucket :(
[03:22] <guiverc> 18.04.6 was only VERY RECENT.. so this should be sorta easy (yeah it's larger; no flavors involved in 18.04.6 so a lot less headings etc... but still I forget stuff in mousepad before I pasted to wordpress.. much harder on the stupid-web-editor
[03:26]  * guiverc just wiped it all ... going back to mousepad again   grrr
[03:28] <Bashing-om> Is easier to think from our own desktop :P
[03:30] <guiverc> mousepad doesn't get in the way like wordpress editor; or I use the wrong one to paste into [somewhat likely]   (though I had mousepad space out a lot of lines today; maybe a change has added a new feature to mousepad I gotta turn off)
[03:33]  * guiverc smiles; it's behaving finally (but I have no idea what I did - but editor is different so I've change a setting somewhere)
[03:36] <guiverc> https://fridge.ubuntu.com/?p=9340&preview=true  is ready for review
[03:37] <guiverc> please :)
[03:38] <guiverc> Ubuntu 21.10 (Impish Indri) Final Beta released   (yeah lower case released - using the original case per usual)
[05:41] -SwissBot:#ubuntu-news- ::Security:: Episode 132 @ https://ubuntusecuritypodcast.org/episode-132/
[07:59] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Design and Web team summary – 10 September 2021 @ https://ubuntu.com//blog/design-and-web-team-summary-10-september-2021
[10:58] -SwissBot:#ubuntu-news- ::Planet:: Kubuntu General News: Kubuntu Impish Indri (21.10) Beta Released @ https://kubuntu.org/news/kubuntu-impish-indri-21-10-beta-released/
[11:30] <guiverc> I'm still after approval on 21.10/impish indri beta release for ubuntu fridge
[12:12] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Bare metal cloud support for Ubuntu 14.04 and 16.04 LTS @ https://ubuntu.com//blog/bare-metal-cloud-support-for-ubuntu-14-04-and-16-04-lts
[15:28] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Studio: Ubuntu Studio 21.10 Beta Released @ https://ubuntustudio.org/2021/09/ubuntu-studio-21-10-beta-released/
[15:30] <krytarik> guiverc: You know, if you can expect like half a day for someone (me) to look at the draft, just the heck publish it.. we can always fix it up later if needed.. :P
[15:33] <krytarik> Merely fixed the somewhat spacious footer of it, otherwise looks fine.
[19:57] <guiverc> thanks krytarik
[19:58] <guiverc> https://fridge.ubuntu.com/2021/09/24/ubuntu-21-10-impish-indri-final-beta-released/
[20:16] -SwissBot:#ubuntu-news- ::Planet:: The Fridge: Ubuntu 21.10 (Impish Indri) Final Beta released @ https://fridge.ubuntu.com/2021/09/24/ubuntu-21-10-impish-indri-final-beta-released/
[20:26] <guiverc> tweeted & pushed to fb the 21.10/impish beta (fridge annoucement)
[23:18] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu 21.10 (Impish Indri) Final Beta released @ https://fridge.ubuntu.com/2021/09/24/ubuntu-21-10-impish-indri-final-beta-released/ (by guiverc)