[00:00] <seb128> hum, I'm wondering why it's working before your change and not after though
[00:00] <seb128> does it fallback to something else when it doesn't find gnome-wm to use?
[00:01] <chrisccoulson> it probably started because it because it was in the autostart folder before
[00:02] <chrisccoulson> this change moves it away from the autostart folder, as gnome-session doesn't look there for the required services
[00:02] <seb128> ah right
[00:02] <chrisccoulson> the launchers for the panel and nautilus, which are required, are all in /usr/share/applications
[00:02] <seb128> right
[00:03] <seb128> what is weird is that setting this key to compiz doesn't work
[00:03] <seb128> but that's probably a compiz bug
[00:03] <chrisccoulson> compiz needs to ship a launcher with X-GNOME-Provides=windowmanager for it to work
[00:03] <seb128> it does
[00:03] <seb128> there is a /usr/share/applications/compiz.desktop
[00:04] <seb128> and it was working when I switched my config to use compiz
[00:04] <chrisccoulson> hmmm, not sure why that doesn't work
[00:04] <seb128> which was before gnome-wm.desktop in the intrepid cycle
[00:04] <seb128> there might be something in the .desktop that confuses gnome-session
[00:05] <chrisccoulson> possibly. setting that key to compiz on my intrepid machine seems to work ok
[00:05] <chrisccoulson> the problem is with that configuration is that both gnome-wm and compiz will be executed at some point
[00:05] <seb128> why?
[00:06] <seb128> it should run only what is in the required_component key no?
[00:06] <chrisccoulson> with the current setup, gnome-wm will always run as it ships in the autostart folder
[00:06] <seb128> ie, gnome-wm on a default install
[00:06] <seb128> but compiz if you change the key
[00:06] <seb128> right, I was speaking about your version
[00:06] <chrisccoulson> it runs regardless of the gconf key at the moment. or at least it should do i think
[00:06] <chrisccoulson> ah yeah, it shouldn't do that in the new version
[00:07] <seb128> I guess I'm one of the only one who changed that key
[00:07] <seb128> anyway it's getting late
[00:07] <seb128> I'll reset the key, restart my session and upload your revision if that works correctly
[00:07] <seb128> we can sort the buggy compiz case later
[00:07] <seb128> thanks for the work on that!
[00:07] <chrisccoulson> thanks. i'll try it again here as well just for sanity
[00:14] <seb128> chrisccoulson: ok, the desktop entries lacks a type= line
[00:14] <seb128> which breaks the compiz start
[00:15] <chrisccoulson> ah, that makes sense
[00:15] <seb128> that's a compiz bug, not a gnome-session one, I'll upload your change and enough work for today ;-)
[00:15] <seb128> and I'll get mvo to fix the compiz issue tomorrow
[00:15] <chrisccoulson> thanks for that:)
[00:15] <chrisccoulson> i've got something i need mvo to do tomorrow too
[00:19] <seb128> ok, uploaded and enough work for today, bye
[05:40] <cearle> After completing an upgrade from hardy to intrepid, the gnome Applications main menu is empty.  Suggestions welcome.
[05:56] <bluesmoke> cearle: rm ~/.config/menus/applications.menu
[06:08] <cearle> thx bluesmoke. will a restart of gnome recreate the file?
[06:09] <bluesmoke> no, running alacarte again will
[06:13] <cearle> aha, alacarte had errors, because there were two "</Menu> <!-- End Applications -->" tags.  Fixed. thx again bluesmoke
[06:14] <cearle> sorry, more specifically, in /etc/xdg/menues/applications.menu
[08:25] <slomo> seb128: please sync gstreamer0.10, gst-plugins-base0.10, gst0.10-python and gst-plugins-bad0.10 from debian/experimental later :)
[08:26] <seb128> slomo: ok
[08:40] <slomo> seb128: thanks for syncing vala :)
[08:40] <seb128> thank you for doing the update ;-)
[09:03] <huats> morning everyone
[09:03] <didrocks> monring huats, seb128 & slomo :)
[09:03] <seb128> lut huats didrocks
[09:03] <huats> morning seb128 and didrocks
[09:03] <didrocks> seb128: ok, will do the "new new" update tomorrow :)
[09:03] <seb128> huats: sorry about yesterday evening but my box crashed on vt switch
[09:04] <seb128> didrocks: you seem to be busy, you still want to do it or should I try to find something easier for you and give that one to somebody else?
[09:04] <huats> seb128: sorry for what ?
[09:05] <seb128> huats: dunno if you talked to me on IRC, we were speaking about updates and my box crashed and when I came back you had left, so in case you asked something and I didn't reply
[09:05] <huats> oh
[09:05] <huats> not a pb
[09:05] <huats> I think I just told you that I will do the gnome-system-monitor + deskbar-applet today
[09:06] <huats> (and I'll add the gnome-keyring too since there is a new available...)
[09:06] <seb128> ok
[09:06] <seb128> yes you can
[09:06] <huats> and that's all :)
[09:06] <huats> ;)
[09:07] <huats> seb128: may be I have added something like : and later on I'll tackle the anjuta update (but first the main things)
[09:08] <huats> and then I think I said good night :)
[09:08] <huats> so you haven't missed anything important :)
[09:08] <seb128> ok
[09:08] <didrocks> seb128: no no. I can handle it now that we discussed yesterday :)
[09:08] <seb128> I knew there was nothing important, I just didn't want to be rude ;-)
[09:08] <didrocks> seb128: that's just I have another dinner with framasoft tonight :)
[09:08] <seb128> didrocks: ok, just ask if you need help updating the lpi change, I'm not sure what I said yesterday was clear
[09:09] <didrocks> seb128: sorry for the delay :)
[09:09] <huats> seb128: don't start to be like didrocks please... One to stand if more than enough :)
[09:09] <seb128> didrocks: that's alright
[09:09] <didrocks> seb128: it was clear :)
[09:09] <seb128> huats: being what? slacking?
[09:09] <seb128> ;-)
[09:09]  * seb128 runs
[09:09] <didrocks> :p
[09:09] <huats> sarcastic :)
[09:15] <seb128> mvo: hey, your compiz.desktop is not correct, gnome-session refuses to use it because it has no type= key
[09:16] <mvo> seb128: oh? is that a regression in the jaunty version? or is gnome-session stricter about it now?
[09:17] <seb128> mvo: not sure, in intrepid gnome-wm.desktop was installed in the autostart directory and always used in fact and I doubt many users change their gconf key to use compiz rather than gnome-wm by default
[09:18] <seb128> mvo: we did fix this bug yesterday and now the gconf key is respect, and I had compiz set there for some reason (I think I changed it early in intrepid when we didn't have gnome-wm.desktop yet)
[09:18] <seb128> mvo: anyway setting compiz doesn't work, it complains about the desktop files not being correct due to the lack of type key
[09:19] <seb128> mvo: I'm too lazy to boot an intrepid box to check if that's gnome-session stricter or if we just didn't notice the bug before ;-)
[09:19] <vuntz> desktop-file-validate!
[09:19] <vuntz> (sorry for the interruption :-))
[09:20] <seb128> vuntz: indeed ;-)
[09:20] <crevette> hey vuntz
[09:20] <crevette> hello seb128  didrocks huats  pitti and slomo
[09:21] <pitti> hey crevette
[09:21] <huats> hey crevette and vuntz
[09:21] <seb128> lut crevette
[09:29]  * seb128 kicks xorg
[09:29] <seb128> jaunty crashes on user switching, really annoying
[09:33] <seb128> crevette: btw do you plan to update your nautilus-sendto upgrade to not use universe?
[09:43] <crevette> seb128, oh yeah I will, sorry, I totally forgot
[09:44] <seb128> hate hate hate
[09:44] <seb128> mvo: there? I need your bzr clues ;-)
[09:45] <mvo> seb128: yes
[09:46] <mvo> seb128: sorry, I was distracted a bit
[09:46] <seb128> mvo: $ bzr push
[09:46] <seb128> bzr: ERROR: No push location known or specified.
[09:46] <seb128> I did bzr get using the command apt-get source suggested
[09:46] <seb128> did bzr commit
[09:46] <seb128> and now try to push the change
[09:46] <seb128> what is the magic url to get that working again? ;-)
[09:47] <seb128> couldn't we try to get that working out of the box? ;-)
[09:47] <crevette> lp:~seb128/yourpackage/ubuntu ?
[09:47]  * crevette does fumb guess
[09:47] <mvo> seb128: best is "bzr bind lp:~seb127/../.."
[09:47] <crevette> dumb
[09:47] <seb128> crevette: no, I don't own this packaging so it's not on my username space
[09:47] <seb128> hum
[09:47] <mvo> (or put it under any ~ you like
[09:48] <seb128> mvo: that's gnome-desktop that you put under bzr
[09:48] <mvo> the bzr bind will make it behave like a checkout
[09:48] <seb128> $ bzr push lp:~ubuntu-core-dev/gnome-desktop/ubuntu
[09:48] <seb128> Pushed up to revision 7.
[09:49] <seb128> ok, that apparently worked
[09:49] <seb128> mvo: can you verify you get that commit on your side?
[09:50] <mvo> seb128: sure, give me sec
[09:50] <mvo> $ bzr log|head
[09:50] <mvo> ------------------------------------------------------------
[09:50] <mvo> revno: 7
[09:50] <mvo> committer: seb128 <seb128@seb128-laptop>
[09:50] <mvo> yeah!
[09:50] <seb128> mvo: ok thanks
[09:50]  * mvo hugs seb128
[09:51] <seb128> would be nice to be able to bzr get and bzr commit and bzr push without having to figure what url to use though
[09:51]  * seb128 hugs mvo
[09:51] <seb128> any idea how we could fix that?
[09:52] <seb128> mvo: ok, next I need to cdbs-edit-patch a patch in this directory, any magic command to do that?
[09:52] <seb128> or do I need to unpack the source somewhere, work there and copy the patch back?
[09:54] <mvo> there is now "bzr bd-do"
[09:54] <mvo> so you run "bzr bd-do 'cdbs-edit-patch patchname'"
[09:54] <mvo> and it will do all the magic for you
[09:54] <mvo> you just need to remember when it created a new patch to bzr add it when you are finished
[09:55] <mvo> seb128: about the url figuring etc> yeah - if we have a standard for this (we are close I think) we can make use of it
[09:55] <huats> pitti: hello
[09:55] <huats> thanks for your comment on the gcalctool SRU I asked
[09:56] <seb128> mvo: ok
[09:56] <huats> but your last comment isn't very clear to me :( can you explain it to me ?
[10:16] <pitti> huats: are any/all of the fixed bugs regressions in intrepid, compared to hardy?
[10:18] <huats> oh, you mean if the bug fixed there were regression from hardy.
[10:18] <huats> honneslty I don't know now... I can try to investigate...
[10:20] <huats> pitti: I'll let you know...
[10:27] <mvo> seb128: compiz fixed
[10:27] <seb128> mvo: danke
[10:28] <seb128> mvo: ok, I updated gnome-desktop using bzr, that works but disturbe my workflow a lot, it cleans the build directory which breaks my check abi change thing, I've to untar the source somewhere to read the NEWS and diff the configure to see depends change before starting, etc
[10:29] <seb128> I'll try to think about how make those tasks easier
[10:30] <mvo> bzr bd-do (without further arguments) give you a shell
[10:30] <seb128> lool: is there several xorg locations in debian? wouldn't it be easier to just patch to use the xorg server location in debian rather than build-depending on xorg only for that?
[10:30] <mvo> in the unpacked tree
[10:30] <seb128> oh!
[10:30] <lool> seb128: This is what I noted in the changelog
[10:30] <lool> seb128: We should patch it to take an AC_ARG_WITH
[10:30] <mvo> you don't even need to download the tarfile manually, it gets it from the watch file (I love this feature :)
[10:30] <lool> But I'd rather do this after the move to newer gdm
[10:31] <seb128> lool: ah, ok, right
[10:31] <seb128> lool: for ubuntu I just tweaked the configure
[10:32] <mvo> seb128: it does support hooks too, so you could make the abi checker part of the regular build
[10:32] <seb128> mvo: right, I noticed, the bd-do trick is a good one ;-)
[10:32] <mvo> seb128: i.e. you run bzr-builddeb and it does the check automatically
[10:33] <lool> mvo: What about git?
[10:33] <mvo> *cough*
[10:33] <lool> Sorry just kidding
[10:33] <mvo> g-what?
[10:34] <mvo> seb128: [HOOKS]
[10:34] <mvo> pre-build = ./pre-build.sh
[10:34] <seb128> btw if some people want to give an hand on desktop sponsoring today feel free to grab items on the sponsoring page, I did a bunch but there is still some there
[10:34] <seb128> mvo: ok, thanks
[10:34] <seb128> mvo: I'll try to come with an optimized workflow for desktop packages so it's easier to work on those
[10:35] <mvo> (that can be any command, it supports pre-build, post-build and pre-export hooks
[10:35] <seb128> mvo: it's not too difficult right now but having to figure what url to use to push changes, how to edit patches, etc is a bit annoying, we should have a clear wiki page about that
[10:35] <mvo> agreed
[10:36] <mvo> the nice thing about the hook and integrating stuff like the abi checker into them is that this way they would be run by anyone messing around^W^Wupdating the package
[10:37] <mvo> but its true, its another tool on top of "debhelper, cdbs, quilt, dpatch" that makes packaging more complex :/
[10:38] <seb128> having bd-do is a good thing
[10:38] <seb128> I was copying directories around before
[10:41] <mvo> seb128: yep, give jame_w a hug if you see him, I love it too
[10:41] <Tm_T> I think James_w is still sleeping after yesterday
[10:42] <seb128> what happened yesterday?
[10:43] <Tm_T> developerweek opening day
[11:47] <ember> hey
[11:53] <pochu> hi ember
[11:53] <pochu> ember: did you read my review?
[11:54] <ember> yes i did, thanks
[12:01] <huats> pochu: so that you know, I'll take care of the anjuta update
[12:01] <huats> I am just doing before some main stuffs (as recommended by seb)
[12:01] <pochu> huats: alright, let me know if you need anything
[12:01] <huats> pochu: sure :)
[12:01] <pochu> (including sponsorship) ;)
[12:01] <huats> thanks
[12:02] <huats> ;)
[12:02] <pochu> yw :)
[13:11] <huats> seb128: I just gave a look at the libgda update (needed for the anjuta one...), and it requires sqlite >= 3.6.0 (the last stable availble upstream is 3.6.10), while on ubuntu/debian we are stuck no 3.5.9... do you know if it will be updated ?
[13:12] <seb128> no idea about that one
[13:12] <seb128> I think fta was looking at that too some time ago maybe try asking him about the update
[13:12] <huats> because I fear that it is blocking...
[13:12] <huats> fta: hey :)
[13:13] <huats> fta: any idea of the status of the sqlite3 toward the 3.6 branch ?
[13:50] <kagou> Hi, I'm testing beta of bibble5. Bibble5 is not compiled for 64bits, so I'v installed ia32 and bibble5 is ok. In the last beta libuuid1 is needed, but libuuid1 installed is for x86-64 architecture.
[13:51] <kagou> I can not find an elegant way to install the 32bit version of this lib
[13:51] <kagou> I'v manually downloaded and manually extracted lib in /lib32 but it's dirty
[13:51] <kagou> is there a way to simplify this ?
[13:52] <seb128> kagou: hi, wrong channel, you want #ubuntu-devel
[13:52] <kagou> seb128, oh
[13:52] <seb128> kagou: the desktop team doesn't work on this package and ia32 and libuuid1 are not desktop things either
[13:52] <kagou> ok
[13:52] <seb128> ie, I've no clue about all that and you will probably get better reply on #ubuntu-devel
[15:17] <didrocks> seb128: I set up a pbuilder and devtools on my server and worked on gnome-games. It builds successfully now :)
[15:18] <seb128> didrocks: excellent ;-)
[15:18] <didrocks> (what a mess to update a configure script in a pbuilder chroot using quilt)
[15:18] <didrocks> I think I will wrote a little thing about it
[15:18] <didrocks> seb128: I will report the changes on my bzr branches, look for correct bugs and then test it on my vm
[15:18] <seb128> ok
[15:19] <didrocks> (but not sure to have the time tonight)
[15:19] <didrocks> and also, I will update the desktop team wiki for using bzr (when working on this packaging, I wrote a step by step how-to)
[15:19] <didrocks> package*
[15:20] <didrocks> have a good evening, I have to go to work for... ubuntu-fr now :p
[15:22] <seb128> didrocks: you too, thanks!
[15:23] <didrocks> lastlog gtk
[15:23] <didrocks> oupss :)
[15:32] <tedg> Has anyone packaged up parasite for Ubuntu?  The screencast looks pretty sweet.
[15:36] <ember> parasite looks cool, but they still haven't release a tarball
[15:39] <tedg> ember: tarballs are for wimps ;)  Hopefully shortly then.
[16:15] <fta> huats, no progress i'm afraid. didn't have time to track all the rdeps so i'm using in-source sqlite in all mozilla products, which happens to be what upstream recommends.
[16:15] <huats> fta: ok
[16:16] <huats> fta: if you want we can work together on the rdeps...
[16:16] <huats> it might be a great thing...
[16:16] <huats> and I am sure we can find some people to help out...
[16:20] <rickspencer3> Desktop team meeting in 10 minutes
[16:21] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-01-20
[16:25] <fta> huats, i was secretly expecting debian to work on this, as we alway get the package from them
[16:25] <fta> +s
[16:26] <huats> fta: I see your point :)
[16:26] <huats> but I think we can wait long for that...
[16:27] <huats> may be we can work with them together... to fasten a bit the process
[16:28] <Ng> tedg: thanks for the pointers yesterday, turned out to be less than three dozen lines of python to listen to NM state changes :)
[16:28] <Ng> tedg: now I just need to tackle python threading horror to make it do something useful ;)
[16:28] <tedg> Ng, heh cool.  I wouldn't use python threading though.  Just use async stuff in Glib.  It'll make your life easier and most users won't notice.
[16:29] <Ng> tedg: the idea is that you run this in a terminal and when NM is connected, it runs ssh for you, so I kinda need to spawn stuff and keep track of NM state. I wouldn't have thought I could do that with glib async stuff
[16:30] <asac> hi
[16:30] <ArneGoetje> hi
[16:30] <rickspencer3> hi all
[16:30] <rickspencer3> ready to meet?
[16:31] <tkamppeter> hi
[16:31] <pitti> hi all
[16:31] <rickspencer3> here's the link again
[16:31] <rickspencer3> bryce sends apologies
[16:31] <seb128> hey rickspencer3
[16:32] <calc> hi
[16:32] <tedg> Ng: You can :)  The GIO async stuff is magic :)
[16:32] <rickspencer3> I guess we're all accounted for
[16:32] <Ng> orly
[16:33] <rickspencer3> first up is outstanding actions from last meeting
[16:33] <rickspencer3> asac to clean up jaunty-desktop-network-changing wiki; draft expected behavior and test cases
[16:33] <tedg> Ng: We actualy use the GIO async stuff for spawning external processes in Inkscape. :)
[16:33] <asac> i did most parts. left out KDE and waiting for more details from mvo on the update- manager things
[16:33]  * tedg 'll be quiet for the meeting, sorry.
[16:33] <asac> now i am going through the apps and file bugs for those that misbehave
[16:33] <mvo> asac: uh, sorry. I was not aware that the deadline for this was today
[16:34] <rickspencer3> asac: great
[16:34] <asac> mvo: no problem ;)
[16:34] <rickspencer3> we might want to discuss more when we get to the sprint topic
[16:34] <Ng> tedg: thanks for the hint, I'll check it out :)
[16:34] <rickspencer3> next item: everyone tag 10 pet bugs by Friday
[16:34] <pitti> I checked specs this morning, and there were no "pending approval" or "review" ones, just lots of "drafting"; this becomes a bit urgent no
[16:34] <rickspencer3> pitti: yes
[16:34] <rickspencer3> I understood that everyone was ready to get them approved now
[16:35] <rickspencer3> ArneGoetje: are you still blocking on anything?
[16:35] <rickspencer3> in terms of spec approval?
[16:35] <ArneGoetje> just had some last minute discussion with mvo about the implementation of language selector improvements
[16:36] <pitti> @all: if you have your spec ready, please set it to "pending approval"
[16:36] <pitti> (sorry, got disconnected
[16:36] <pitti> I WON'T look at specs which are "drafting"
[16:36] <rickspencer3> in a similar vein, has everyone tagged 10 pet bugs?
[16:37] <pitti> http://qa.ubuntu.com/reports/ogasawara/pet-buglist.html
[16:37] <ArneGoetje> rickspencer3: will need to make some small changes to the spec. BUt then it's ready.
[16:38] <rickspencer3> ArneGoetje: okay, please set to pending approval asap
[16:38] <calc> looks like bryce needs to mark his still but the rest are done?
[16:38] <ArneGoetje> rickspencer3: will do
[16:38] <rickspencer3> bryce is out for a few days
[16:38] <pitti> now let the games begin :)
[16:38] <rickspencer3> heh
[16:38] <calc> rickspencer3: ok
[16:38] <rickspencer3> next topic
[16:39] <seb128> I think I'm still one or two bug short, there is some thousand desktop bugs and I still have to pick some in the list ;-)
[16:39] <pitti> as said, those should be the ones which would be intersting for you to work on
[16:39] <pitti> which aren't urgent, require some work, but will do lots of good
[16:39] <rickspencer3> rickspencer3 to follow up with Maria regarding info for presenters
[16:40] <rickspencer3> Mark would like to encourage us to speak and contribute at conferences and such
[16:40] <rickspencer3> so please be thinking if there is something like this that you want to do
[16:40] <rickspencer3> we can discuss 1-1 in our phone calls
[16:40] <rickspencer3> ready to move on to the agenda?
[16:41] <pitti> wrt conferences
[16:41] <pitti> I think we collected the "want to go to" list a while ago
[16:41] <rickspencer3> pitti: understood
[16:41] <pitti> I'm not sure whether we need ack from Matt or anyone else for this
[16:41] <rickspencer3> hmmm
[16:41] <rickspencer3> good point
[16:41] <rickspencer3> I'll follow up on that
[16:42] <Riddell> we should get acks on gran canaria summit soon, air fairs will go up in peak tourist season
[16:42] <pitti> the ConferenceAttendance wiki page looks fairly filled
[16:42] <pitti> Riddell: :-)
[16:43] <pitti> I'll give a speech at the beach cocktail bar
[16:43] <rickspencer3> pitti: could you please paste link
[16:43] <pitti> rickspencer3: /msged
[16:43] <rickspencer3> tx
[16:43] <rickspencer3> moving on ...
[16:43] <rickspencer3> Changing the Add/Remove ...
[16:44] <rickspencer3> this was brought up by Jane and Chris originally, then discussed on the desktop list
[16:44] <rickspencer3> any other thoughts?
[16:44] <pitti> interestingly, the tooltip says "install or remove applications"
[16:44] <seele> was there a conclusion?
[16:45] <pitti> which explains it pretty well IMHO
[16:45] <rickspencer3> seele: no conclusion, this is still in discussion phase
[16:45] <rickspencer3> pitti: yeah, there is a "sizzle" and "steak" question ehre
[16:45] <pitti> maybe it should just say "Install/Remove", to unconfuse it with a menu editor?
[16:45] <seb128> I've no real opinion about that, let the design team decide?
[16:45] <rickspencer3> I think the feeling is that the usable labels aren't very buzz worthy, and we are not getting credit for a great function because of hte naming
[16:46] <pitti> personally I like the location of the menu item, it's exactly where it should be
[16:46] <pitti> it just has always looked a bit like menu editor to me
[16:46] <rickspencer3> I'm neutral to the whole question, if the design/marketing team comes up with something with some sizzle that makes sense to users, I would support it
[16:46]  * seele mumbles something about a lot of people don't realise how important labels are and think they are "preference"...
[16:46] <rickspencer3> I think we need some usability data, we should watch some actual users
[16:47] <asac> buzz worthy? so they dont want a functional name, but something like "software center"?
[16:47] <seb128> seele: do you think add,remove is a good label? and softwares library? and why? ;-)
[16:47] <rickspencer3> asac: that's one of the better suggestions I've heard so far ;)
[16:47] <seb128> asac: "Software Library" what the one suggest on the list which is similar to yours
[16:48] <seele> seb128: rickspencer3 had a point that it didnt follow with the other types of "places" available in that menu
[16:48] <asac> yeah. but Center sounds more complete ;)
[16:48] <seele> how well does something like "Center" translate?
[16:49]  * pitti would favor "Add remove software" or "Install/remove"
[16:49] <asac> seele: in german it would be "Software Center" ;)
[16:49] <||sico||> no problem for spanish...
[16:49] <davidbarth> according to google (if that's an indicator of how people could name such a thing), "software catalog" gets the highest number of results
[16:49] <rickspencer3> pitti: I think they want something that says: there is a world of cool apps here
[16:49] <seb128> pitti: "add remove software" is a no go, too long in some locale (german probably being one of those), the menu becomes quickly ugly because it scales to the label
[16:50] <rickspencer3> so it seems to me that we are generally supportive of the change *if* they can come up with a name that is:
[16:50] <rickspencer3> 1. understandible
[16:50] <rickspencer3> 2. translatable
[16:50] <rickspencer3> 3. cooler than what we already have
[16:50] <rickspencer3> sound about right?
[16:50] <rickspencer3> "they" being design and or marketing
[16:50] <asac> davidbarth: software catalog doesnt really imply that you go there to get something :) ... only that you go there to look stuff up.
[16:50] <seb128> and short enough to not make the menu look ugly because it will scale to the label
[16:51] <asac> rickspencer3: ack
[16:51] <rickspencer3> 4. doesn't make the label look ugly due to length or other issues
[16:51] <pitti> rickspencer3: I wouldn't exactly measure "coolness", but the percentage of users who understand what this menu item means
[16:51] <davidbarth> davidbarth: sorry, that's software *library*, then *catalog* then software center (using double quotes in the queries)
[16:51] <rickspencer3> pitti: yeah, that's the "steak" part of the equation, it has to be usable
[16:51] <seb128> "you should try that, really"
[16:52] <seb128> what about that? ;-)
[16:52] <rickspencer3> so we don't want to sacrifice the steak for the sizzle
[16:52] <rickspencer3> seb128: perfect
[16:52] <pitti> "Get more stuff"
[16:52] <davidbarth> asac: i'm providing some cheap to collect user data
[16:52] <rickspencer3> I still think we should test any changes empirically, and Berlin may be a good opportunity for that
[16:52] <rickspencer3> move on?
[16:52] <asac> "Extend Ubuntu ..." ;)
[16:52] <asac> yes lets move on
[16:53] <seb128> rickspencer3: no need to wait the sprint, if you want to try a change let me know and I'll do the upload
[16:53] <rickspencer3> seb128: will do
[16:53] <rickspencer3> thanks
[16:53] <rickspencer3> there is a section for sponsoring on the agenda template
[16:53] <pitti> so on whose plate is that now?
[16:53] <seb128> it'll take time before we get translations back though since it'll require translator work and language pack updates
[16:54] <rickspencer3> pitti: I'll feedback to Jane and Chris this discussion, and then work with Julian to see if we want to move any ideas forward
[16:54] <asac> seb128: maybe inject all suggestions to some po template so we get all translations and can more easily switch to what we want
[16:54] <rickspencer3> so, sponsoring?
[16:55] <asac> i did a bunch this week
[16:55] <asac> more to come ;)
[16:55] <seb128> I did a bunch too ;-)
[16:55] <pitti> still have to do some, was on vac; on this week's TODO, though
[16:55] <seb128> rickspencer3: anything specific to discuss about sponsoring?
[16:56] <rickspencer3> seb128: no, it looks like it's part of the template for the meeting, and I didn't know what it was for
[16:56] <seb128> or that's just a reminder that everybody should be doing some?
[16:56] <asac> lets whip those that didnt include any in their activity ;)
[16:57] <rickspencer3> I'll follow up with someone after the meeting about the agenda item in general
[16:57] <seb128> rickspencer3: scott used to review during the meeting desktop sponsor request which were waiting for a while
[16:57] <rickspencer3> seb128: thanks, I'll do that next time
[16:58] <rickspencer3> let's move on to release status ... I'd like to briefly discuss status on a few items
[16:58] <rickspencer3> first, Dx Support
[16:58] <rickspencer3> davidbarth: anything to add here?
[16:58] <davidbarth> rickspencer3: sure
[16:59] <davidbarth> so first we're getting great support from mozilla, thanks to asac
[16:59] <rickspencer3> yeah
[16:59] <davidbarth> then, we're reviewing all apps from main *and* universe
[16:59] <davidbarth> i've made a big list with mpt for patches we need to provide
[17:00] <pitti> do we have some public packages for testing in a PPA?
[17:00] <davidbarth> including an initial recommendations for the infamous actions
[17:00] <davidbarth> pitti: not yet, that will be for our code drop
[17:00] <davidbarth> we're progressing with the implementation
[17:01] <davidbarth> we should have something nice by the time of the sprint when entering the beta cycle
[17:01] <asac> davidbarth: maybe you can drop the apps one by one (when done) instead of one huge code drop?
[17:01] <asac> or is that the plan?
[17:01] <davidbarth> asac: yes, that's the plan
[17:02] <davidbarth> asac: the patches may land even before the daemon is there, but that should not be a problem
[17:03] <rickspencer3> thanks davidbarth
[17:03] <davidbarth> i hope to provide more on the message indicator next week btw, ted has made great progresses
[17:04] <davidbarth> he should blog to present his thoughts about the API sometime this week
[17:04] <davidbarth> and i think that's it
[17:04] <rickspencer3> thanks
[17:04] <rickspencer3> next item, which is related ..
[17:04] <rickspencer3> New GDM (PPA and Migration)
[17:04] <pitti> thanks for the update
[17:04] <rickspencer3> seb128: is the PPA ready?
[17:05] <seb128> rickspencer3: ppa? I've started looking at the update again, I plan to get it uploaded to universe this week rather than using a ppa though
[17:05] <rickspencer3> seb128: right
[17:05] <seb128> not yet but will be uploaded during the week
[17:06] <rickspencer3> thanks
[17:06] <rickspencer3> next, Device kit?
[17:07] <pitti> so first packaging it, and then work on the migration code?
[17:07] <asac> migration code?
[17:07]  * asac scared that NM breaks
[17:07] <rickspencer3> pitti: yes
[17:07] <pitti> asac: to carry over old gdm's autologin settings into new gdm's gconf
[17:07] <asac> pitti: oh. thought that was on devicekit ;)
[17:07] <pitti> rickspencer3: latest DK and DK-power are in universe
[17:07] <asac> nevermind then
[17:07] <rickspencer3> pitti: so done?
[17:07] <rickspencer3> sweet
[17:07] <pitti> rickspencer3: well, the spec is about that plus packaging the new gpm in a PPA
[17:08] <pitti> but AFAIK tedg wanted to do that?
[17:08] <pitti> tedg: if not, shall one of us do it?
[17:08] <davidbarth> rickspencer3: is device kit in the scope of 9.04?
[17:08] <rickspencer3> davidbarth: no
[17:08] <davidbarth> ok
[17:08] <pitti> davidbarth: no, just for playing with it
[17:08] <pitti> 9.04 -> universe
[17:08] <pitti> and using current gpm
[17:08] <pitti> 9.10 -> probably switch to new gpm and DK
[17:08] <davidbarth> ok, same as gdm
[17:09] <tedg> pitti: I can do it, I just really messed up my GPM packaging branch :(  I just need to fix it.
[17:09] <pitti> tedg: ok, please let me know if you need help with it
[17:09] <pitti> I guess it depends on how many patches to old gpm we have to port to the new one
[17:09] <tedg> pitti: I just need to figure out what revisions to un-merge.  Not help, just a lot of stupid mistake work.
[17:09] <pitti> I wouldn't dare to touch fusa, but if gpm just has a couple which went upstream, I can probably do it as well
[17:10] <seb128> tedg: speaking about that, you are going to do the 2.25 update in jaunty?
[17:10] <tedg> Many of the GPM patches are for LTSP, which should be handled by DKp, so they shouldn't be GPM patches anymore.
[17:11] <tedg> seb128: No.  We're not going to do 25 in Jaunty as it requires DKp.
[17:11] <seb128> tedg: 2.24.3 then?
[17:11] <tedg> seb128: yes.
[17:11] <seb128> ok good
[17:11] <pitti> 2.25 was for a PPA, depending on dk-p?
[17:11] <seb128> are you sure that 2.25 requires that new thing?
[17:11] <tedg> pitti: ys.
[17:11] <tedg> yes.
[17:11] <seb128> vuntz: ^ do you know about that? is that a GNOME requirement now?
[17:12] <tedg> seb128: I'm pretty sure that's what hughsie's e-mail to GNOME-devel said.
[17:12] <pitti> seb128: AFAIK Richard explicitly sanctioned distros using 2.24 for the moment, for that very reason
[17:12] <seb128> tedg: that's weird that GNOME accepted a 2.26 requirement on that
[17:13] <rickspencer3> ready to move on?
[17:13] <seb128> yes
[17:13] <rickspencer3> we should discuss the Berlin sprint
[17:13] <rickspencer3> it starts in less than two weeks
[17:13] <pitti> my ideas which would greatly benefit from being together: fix (1) hotkey, (2) beamer, (3) suspend/resume for everyone's laptop
[17:13] <tkamppeter> Yes, I live in Berlin and it would be nice if the sprint really takes place there.
[17:14] <pitti> tkamppeter: that's settled already :)
[17:14] <tkamppeter> Is there any Wiki page about the Sprint?
[17:14] <asac> hehe
[17:14] <rickspencer3> tkamppeter: let's talk seperately, I'll bring you up to speed
[17:15] <rickspencer3> pitti: good ideas
[17:15] <rickspencer3> others?
[17:15] <ArneGoetje> pitti: fix the intel driver in xorg for i855, 915 and 945 first
[17:15] <vuntz> seb128: we're discussing the dk-p dep on the r-t mailing list right now, but it'll likely be accepted, yes
[17:15] <pitti> ArneGoetje: outside my competency, so I can't judge whether that's feasible :)
[17:15] <seb128> I should try to get somebody to fix my machine crashing on user switching ;-)
[17:15] <asac> pitti: those three sound more like foundation topics ;)
[17:15] <pitti> asac: true that, but that's quite inherent to hardware specific problems :)
[17:16] <seb128> vuntz: GNOME starts being disappointing on the crack level ;-)
[17:16] <pitti> well, it's not crack, it's just kind of a nuisance to have to support both hal and dk at the same time
[17:16] <rickspencer3> pitti: seb128: I'd like to propose a session on efficient bug management
[17:16] <seb128> pitti: they are hurrying too fast on rewrites recently and that leads to the recent issue we had for gdm, gnome-session, etc
[17:17] <seb128> rickspencer3: good idea yes
[17:17] <pitti> rickspencer3: sounds very similar to my UDS talk?
[17:17] <davidbarth> rickspencer3: +1
[17:17] <rickspencer3> pitti: yes, but more and hands on
[17:17] <pitti> or do you mean something else?
[17:17] <asac> maybe we should do a one day trip to hamburg and visit the pulseaudio lennart
[17:17] <asac> ;)
[17:17] <asac> just kiddin
[17:17] <rickspencer3> :)
[17:17] <pitti> asac: -ECITY, he lives in Boston now?
[17:17] <asac> pitti: shit ;)
[17:18] <rickspencer3> how about some time with the Dx team making sure their new stuff works on all of our laptops?
[17:18] <asac> rickspencer3: efficient bug management -> only thing that can help me is the launcpad plugin getting deployed in bugzillas.
[17:18] <pitti> I think at the sprint we should focus on squashing hardware related bugs and working with the Dx team
[17:18] <rickspencer3> asac: yes, not necessarily useful for everyone, but very useful for some
[17:18] <pitti> and otherwise just continue fixing bugs, picking the ones where we need to pick the brains from colleagues
[17:18] <rickspencer3> pitti: += design team
[17:18] <seb128> asac: what would that change? I'm not convinced about that
[17:18] <asac> rickspencer3: i think its useful for all software that has a bugzilla tracker
[17:19] <asac> seb128: it will resolve the "proxy" problem. e.g. at the moment you file bug upstreawm
[17:19] <asac> and from then on have to proxy discussion for launchpad reporter
[17:19]  * pitti never found that to be a major blocker
[17:19] <rickspencer3> ArneGoetje: what would you like to get out of the sprint?
[17:20] <asac> with plugin you just file upstream against proper component and then monitor and help out when necessary
[17:20] <davidbarth> rickspencer3: we've added that as part of our sprint, on Monday, Wednesday and Friday; the rest of the time is for coding
[17:20] <pitti> the time I need to create an fd.o bug is insignificant compared to the time it takes me to write an upstream-ish bug description
[17:20] <seb128> asac: the proxy thing is a feature, without that we would send crack bugs upstream and they would start ignoring those
[17:20] <asac> seb128: well. we do the initial forwarding. so we still filter
[17:20] <ArneGoetje> rickspencer3: finish a great deal of language selector
[17:20] <rickspencer3> ArneGoetje: is that something that will benefit from being together with everyone?
[17:20] <seb128> asac: well, what does that would change then? You need to clean the bug description before sending the bug anyway
[17:20] <seb128> not really a meeting topic though
[17:21] <seb128> let's discuss that later ;-)
[17:21] <ArneGoetje> rickspencer3: mostly with mvo
[17:21] <vuntz> seb128: well, you can stay with gpm 2.24
[17:21] <vuntz> seb128: that's hughsie's plan, and he's maintaining 2.24 for people who wants to stay with hal
[17:21] <pitti> vuntz: do you happen to know when GNOME will switch everything to DK away from hal?
[17:21] <vuntz> pitti: I asked a few weeks ago. It won't happen for 2.26
[17:22] <rickspencer3> ok, no other ideas regarding the sprint?
[17:22] <pitti> vuntz: no, didn't expect that :)
[17:22] <vuntz> pitti: maybe 2.28. I don't think we have that many things directly using hal, actually
[17:22] <asac> rickspencer3: fixing bugs in apps that dont behave properly on network changes
[17:22] <rickspencer3> Riddell: any thoughts regarding the sprint?
[17:22] <pitti> vuntz: primarily gvfs and nautilus, I guess
[17:22] <rickspencer3> asac: yes, good one
[17:22] <Riddell> rickspencer3: making sure our mysql changes get agreed and in
[17:22] <seb128> vuntz: right, we will do that
[17:23] <vuntz> pitti: nautilus doesn't depend on hal at all. It's pure gio love :-)
[17:23] <Riddell> need to talk to server team people for that
[17:23] <rickspencer3> Riddell: sounds good
[17:23] <rickspencer3> all: I'll put together a list of topics and send out for review
[17:24] <rickspencer3> I have some details from some other teams that I can include
[17:24] <pitti> vuntz: indeed :) so gpm (done), gvfs, network-manager, and system-config-printer primarily
[17:24] <asac> network-manager will go for devicekit for 0.8
[17:24] <asac> but that will take a bit
[17:24] <rickspencer3> moving on in the agenda
[17:24] <rickspencer3> Activity Reports: all done and on the wiki, so thanks for that
[17:25] <pitti> asac: (just would be nice to have the migration for next LTS)
[17:25] <rickspencer3> any other business?
[17:25] <asac> pitti: i hope we can get a quicker release cycle from now on
[17:25]  * rickspencer3 tries desperately to stick to agenda
[17:25]  * rickspencer3 but has already lost control
[17:25] <pitti> rickspencer3: well done
[17:25] <seb128> one thing
[17:25] <pitti> sorry for the side discussions
[17:25] <vuntz> pitti: system-config-printer doesn't depend on hal either, I think :-) But there's a hal backend for cups
[17:26] <seb128> slangasek was needing cd space for the alpha some days ago, I told him to move nautilus-cd-burner deskbar-applet tracker to supported
[17:26] <pitti> vuntz: yes, I mean that hal-cups-utils, it calls s-c-p for autoconfig love
[17:26] <seb128> just to let know everybody if somebody has comments on the change
[17:26] <rickspencer3> seb128: tracker makes sense, but CD burner?
[17:26] <pitti> brasero?
[17:26] <seb128> brasero implements the nautilus-cd-burner features now
[17:27] <seb128> ie, burn: location in nautilus, libraries to be used by rhythmbox, etc
[17:27] <rickspencer3> I guess it makes sense, I'll check it out
[17:27] <pitti> oh, it indeed looks quite nice
[17:27] <seb128> deskbar-applet and tracker where not used in the default configuration, they are not that useful and quite buggy
[17:28] <pitti> burnign an iso has a nice and small UI now, not the full brasero one
[17:28] <rickspencer3> seb128: thanks for the update
[17:28] <rickspencer3> any other business?
[17:28] <asac> i didnt find brasero in accessories ;) ... then found it in sound & video ... hmmm
[17:28] <seb128> one other small thing
[17:28] <pitti> rickspencer3: oh, sprint idea: measure everyone's desktop startup speed and work on making them faster
[17:28] <seb128> somebody raised a question about the dpi setting we use some time ago on the channel
[17:29] <seele> rickspencer3: unrelated but i am still waiting for MPT to get me the bib for Ubuntu's notification design
[17:29]  * calc notes jaunty a3 takes ~ 18s on his desktop
[17:29] <asac> seb128: font dpi?
[17:29] <seb128> gnome-settings-daemon still force the value to 96 dpi rather than using the xorg value
[17:29] <asac> yeah
[17:29] <seb128> we did that because we had too many buggy cases when we trying to not force the value in gutsy
[17:29] <asac> i think bryce has to comment on that .... afaik it was because of a X bug or something
[17:29] <pitti> calc: 62 seconds for me :(
[17:29] <seb128> this user was arguing that nowadays that break many setups though
[17:29] <seb128> and that we should drop the forced value
[17:29] <rickspencer3> seele: have you been in contact with MPT directly regarding this?
[17:29] <calc> pitti: on a fresh install? i didn't have anything else loaded on mine
[17:29] <pitti> seb128: another good sprint material, I think
[17:30] <seb128> does anybody has an opinion about that?
[17:30] <seele> rickspencer3: yep, no rely though
[17:30] <davidbarth> seele: i'm seeing him tomorrow, i'll pass on the message
[17:30] <calc> pitti: and that was from grub to gdm login prompt for me
[17:30] <seele> *reply
[17:30] <seele> davidbarth: ok thanks
[17:30] <asac> seb128: many setups?
[17:30] <seb128> should we try not forcing the value for a while and get user feedback during this cycle?
[17:30] <pitti> calc: ah, I mean gdm until the desktop is ready to use
[17:30] <calc> pitti: ah ok
[17:30] <pitti> seb128: *nod*
[17:30] <pitti> seb128: and on the sprint we have plenty of people and hardware to try it out on
[17:30] <asac> seb128: i think we should try
[17:31] <seb128> asac: lot of screen have higher dpi resolutions now and 96 makes those look really wrong where letting xorg get the value would work better
[17:31] <seb128> asac, pitti: ok
[17:31] <bluesmoke> mvo: Do you have any idea what http://bazaar.launchpad.net/~compiz/compiz/ubuntu/annotate/head%3A/debian/patches/010-disable-child-window-clipping.patch is even for?
[17:31] <rickspencer3> meeting adjourned?
[17:31] <mpt> rickspencer3, yes she has
[17:31] <seb128> thanks rickspencer3
[17:31] <asac> thanks
[17:31] <pitti> rickspencer3: I think we should start adding those to the sprint wiki page
[17:31] <ArneGoetje> thanks
[17:31] <bluesmoke> mvo: I think it's for that hack to enable XaaNoOffscreenPixmaps on the fly? Do we need that?
[17:31] <pitti> thanks everyone
[17:31] <rickspencer3> pitti: agreed
[17:32] <mpt> but I'm still ~1 month behind on non-urgent stuff
[17:32]  * calc wonders if displays should be a focus for 9.10 wrt dpi, working better on netbooks, etc
[17:32] <tkamppeter> I have something, WDYT about a foomatic-filters SRU: bug 318816, bug 318818, bug 299918, bug 303691
[17:32] <pitti> tkamppeter: we can discuss that in #u-devel IMHO
[17:32] <tkamppeter> pitti, OK
[17:33] <tkamppeter> Yes, this is the server side of the printing stack and not desktop.
[17:33] <seb128> is launchpad not working today?
[17:33] <calc> seb128: works for me
[17:33]  * seb128 got almost no bug mail this afternoon, that's weird
[17:33] <Amaranth> mvo: Other than that we have 4 patches that aren't for settings or from upstream and I think we should be able to get at least 2 of them upstream
[17:34] <seb128> pedro_: did you triage bug this afternoon? I don't get my usual bug mail flood today ;-)
[17:34] <pedro_> seb128: it's being slow here but it's working
[17:35] <pedro_> seb128: just returning from lunch :-P
[17:35] <calc> seb128: i'm getting email from LP
[17:35] <seb128> ok, must just be a calm day for desktop bugs
[17:35] <calc> seb128: i think it might be delayed a bit (< 1hr though)
[17:36] <calc> oh hmm i just an email for a change 7m ago so maybe not delayed so much
[17:38] <seele> rickspencer3: davidbarth: mpt: i'm going to write up my notes on notifications so we can begin discussing them in terms of KDE.
[17:38] <rickspencer3> seele: thank you
[17:40] <pedro_> is anybody having cracking sounds with pulseaudio?
[17:40] <davidbarth> seele: yes, thanks, you'd better start, i'm still paddling in gnome code, that will help me switch to kde
[17:40] <asac> pedro_: cracking?
[17:41] <calc> pedro_: i hear that on my laptop but no sound other than the cracking
[17:41] <asac> for me pulse is definitly on crack ;) ... but indeed
[17:41] <asac> if i go to gstreamer-properties and run the test sound i get a crack shortly after it starts
[17:41] <pedro_> asac: well, like.. not being so good, you know little jumps between music
[17:41] <asac> but otherwise no
[17:41] <asac> hmm
[17:41] <calc> PA is known to have issues with among other things all hda-intel realtek codecs :-\
[17:42] <asac> pedro_: for me it happened when my ati graphics driver was running EXA
[17:42] <calc> not sure what kind of issues those happen to be
[17:42] <asac> which slowed down things to death
[17:42] <asac> pedro_: i forced Xaa and all is fine now ... so wasnt a pulse issue ... more a general system load thing caused by buggy exa accell method
[17:43] <pedro_> I have an intel card but i'm having issues with xorg being slow at the beginning of the session
[17:43] <asac> my line in isnt working on hda-intel realtek  though :(
[17:43] <asac> pedro_: also EXA?
[17:43] <pedro_> asac: yeah
[17:43] <asac> i think intel uses exa for quite some time
[17:44] <asac> but still worth a try ... if xaa works at all
[17:44] <asac> on intel
[17:45] <pedro_> yup will try that otherwise will fill a bug
[17:46] <crevette> hey
[17:46] <crevette> seb128: I updated nautilus-sendto
[17:46] <seb128> crevette: good, I'll review that later
[18:21] <mvo> Amaranth: no idea about 010_ - its there since the dawn of time (i.e. nice before I merged it into bzr)
[18:22] <Amaranth> mvo: Yeah, it's been there since 0.3.6
[18:22] <Amaranth> I remember mjg59 added it
[18:22] <Amaranth> All it does is create that atom, I'm pretty sure it's for the XAA workaround
[18:23] <mvo> Amaranth: ok
[18:24] <Amaranth> also, it's kind of neat running compiz without LIBGL_ALWAYS_INDIRECT now :)
[18:24] <Amaranth> and seeing compiz-manager handle that correctly
[18:32] <chrisccoulson> hi seb128 - i notice gnome-session didn't build on 1 arch
[18:50] <chrisccoulson> hi mvo - i did the work on bug 302326 that we spoke about last week. the change is in bzr. would you mind taking a look at it?
[18:51] <mvo> chrisccoulson: sure, I misread the last comment when I looked at it the other day, I missed the bit that the patch is already commited :)
[18:51] <mvo> chrisccoulson: what is the bzr lp url?
[18:52] <chrisccoulson> 1 second
[18:52] <chrisccoulson> it is lp:~chrisccoulson/update-notifier/bug302326
[18:54] <chrisccoulson> i had to bring the branch in sync with what was in the archive, which just involved moving a changelog entry (for a change that went in after the last release)
[18:58] <mvo> thanks chrisccoulson
[18:58] <chrisccoulson> you're welcome
[20:25] <seb128> re
[20:25] <seb128> chrisccoulson: sorry I was just running for dinner when you ask your question
[20:26] <seb128> chrisccoulson: the build was on ia64? that seems to be a buildd issue
[20:45] <jlamsens> Anyone already has Compiz 0.7.8 running on Ubuntu 8.04 ? I have the problem: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/242735
[20:46] <jlamsens> Apparently, compiz 0.7.8 is only available for Intrepid, not for hardy. No backuport exists. Latest Compiz version for hardy: 0.7.6
[20:47] <jlamsens> Anyone ?
[21:07] <chrisccoulson> hi seb128, sorry i had to disappear as well. yeah, i was referring to the ia64 build of gnome-session. i wasn't sure what the problem was with it
[21:07] <chrisccoulson> it's just a transient error is it?
[21:08] <seb128> chrisccoulson: it seems, let me build retry this one
[21:08] <chrisccoulson> thanks
[21:08] <seb128> chrisccoulson: you're welcome, thank you for the work you are doing
[21:09] <chrisccoulson> you're welcome too:)
[21:09] <seb128> chrisccoulson: not sure if you are interested by doing some other GNOME updates but let me know if you are there is still some tarballs to update ;-)
[21:10] <chrisccoulson> no problem. i can't do any this evening as i've got some other stuff to do, but just give me a shout if you see me on here
[21:10] <chrisccoulson> i'm around most evenings
[21:10] <seb128> ok
[21:10] <seb128> we really should update the workflow this cycle, there was some work started on that
[21:11] <seb128> having a public system listing updates that are waiting and letting anybody claim any of those
[21:12] <chrisccoulson> that would be quite useful
[21:39] <asomething> seb128: http://norsetto.890m.com/desktop_packages.php is nice but it doesn't seem to look for 2.25.* packages
[21:47] <seb128> asomething: right, it needs to be updated
[21:48] <asomething> seb128: tools like that are important, they show people (like me) good places to jump in
[21:49] <seb128> asomething: right, we need some server to run the tools and some organisation though
[21:50] <seb128> asomething: the "whoever is the fast to grab an upgrade" system is not the best one
[21:50] <seb128> some people are working on a regular base on the same components and should be prefered upgrader if they are around
[21:50] <seb128> and we try to balance the tasks between contributors
[21:50] <seb128> we tend to attribute work on IRC right now but that has limitation
[21:51] <seb128> we could use a summary and a list of tasks though
[21:51] <asomething> seb128: exactly, if a page like that were kept up to date, it would make things easier to know
[21:52] <seb128> if you are looking for something to do just ask there though ;-)
[21:52] <seb128> do you have some special interest in some component?
[21:53] <asomething> seb128: i often have a hard time figuring where my efforts are best needed
[21:53] <seb128> the question should rather be what is interesting you the most because that's where you should start
[21:53] <asomething> seb128: nothing too specific, I mostly keep to working on gnome/gtk desktop stuff
[21:54] <seb128> you can do bug triage, bug fixing, updates
[21:54] <seb128> is there any GNOME component you already worked on? or that you use often and have special interest in?
[21:56] <asomething> seb128: i've done a few uploads of cheese and (not gnome but ubuntu-desktop) transmission
[21:58] <asomething> i maintain file-browser-applet and parcellite in debian
[22:01] <dobey> file-browser-applet?
[22:01] <dobey> like the thing that shows a menu of the file system in the gnome panel?
[22:01] <asomething> dobey: it's a gnome panel applet, in universe for Ubuntu
[22:02] <asomething> upstrea home: http://code.google.com/p/gnome-menu-file-browser-applet/
[22:03] <dobey> interesting
[22:03] <asomething> though, the upstream dev is probably moving to LP soon, with my help
[22:09] <seb128> asomething: nobody seems to be actively working on cheese, you are welcome to do the updates when they are available if you want
[22:09] <seb128> asomething: just ask on the channel if you are not sure or have any question
[22:10] <asomething> seb128: if there are any other gnome 2.25.* packages that still need to be done, feel free to delegate something to me, i'd love to help more
[22:13]  * dobey still needs to make 2.25.x releases of a few things
[22:15] <didrocks> seb128: you are working late these days
[22:15] <didrocks> :)
[22:16] <seb128> didrocks: no
[22:16] <seb128> didrocks: I stop early and sometime come back later
[22:17] <seb128> "early", ie at a reasonable work hour ;-)
[22:17] <didrocks> seb128: oki :-) I am building my changes again (on my laptop this time) and test on my vm
[22:17] <seb128> didrocks: time to update your laptop to jaunty!
[22:18] <didrocks> seb128: indeed :-)
[22:18] <didrocks> hum, taking a tour on LP to see which bugs can be closed with this release
[22:20] <seb128> asomething: there is not too many updates to do right now in fact but when one tarball is available I will let you know
[22:20] <seb128> didrocks: good
[22:20] <asomething> =)
[22:21] <seb128> asomething: not sure how much you know about packaging, evolution-mapi is a new thing to package but that's not really a beginner task though
[22:24] <asomething> seb128: not a beginner but not exactly a vet yet either. but i wouldn't really be able to test it. it's for interacting with an exchange server right?
[22:32] <seb128> asomething: the server team can do the testing
[22:36] <seb128> asomething: they don't seem to be that interested in packaging it and technically that's a GNOME component so we sort of agreed on having the desktop team doing the packaging and they will do the testing
[22:36] <asomething> seb128: i can take a crack at it, is there already a needs-packaging bug?
[22:38] <ember> btw seb128 is there any update free?
[22:38] <seb128> asomething: not that I know
[22:38] <seb128> ember: no, that's what I was saying to asomething just before
[22:38] <ember> pochu reminder, take a another look at gtk-css sitting on revu when you have time
[22:39] <ember> ok i didn't read the backlog i was just asking
[22:39] <seb128> ember: it would be nice if you could stop doing updates without asking there before, some of those you did are not useful they only have translation updates and since jaunty language packs are not updated yet they just give extra sponsoring work for nothing
[22:39] <seb128> ember: you also did some which were assigned to other people who asked on the channel
[22:40] <ember> oh sorry didn't know about the translations, were just trivial ones
[22:41] <ember> which one? i can invalid it
[22:41] <seb128> ember: that's ok, better to ask on the channel until there is a better way to list updates to do though
[22:42] <seb128> ember: don't bother now that they are done, they are quick to sponsor too, but there is no real need to do those
[22:43] <seb128> gnome-menus and libwnck were not really required, there is some minor changes there and version will be uptodate this way
[22:44] <asomething> seb128: I'll get a package on REVU in the next couple days, bug 319400
[23:17] <seb128> ok, enough work for today now


[03:21] <len-dt> New ISO has landed... Thanks all who helped.
[04:48] <len-live> 12.10 ISO boots.
[04:51] <len-live> 12.10 ISO settings menu is changed, has a lot more menu entries.
[04:52] <len-live> I think the names have changed.
[05:05] <len-live> Nautilus is wonky. it does not show mass storage devices as it used to. The menu background colour is wrong and it calls itself "files", but ps x still shows nautilus.
[05:10] <len-live> In fact removable devices don't show anywhere... desktop or thunar either
[05:20] <len-live> Installer knows I am PST again :)
[05:23] <len-live> Installer screen is still too tall for a netbook. scroll bars still show up too.
[07:32] <astraljava> len-dt: I don't suppose we'll partake on Alpha-2 milestone, still? ;)
[15:10] <len-1210> I was able to install the 1210 ISO without glitch.
[15:18] <len-1210> The big problem for me is the missing gui stuff in files/nautilus/thunar/desktop to mount unmount other storage devices.
[15:22] <len-dt> astraljava, we haven't done anything yet. It also looks like we have to go back and make things that worked before work again.
[15:25] <len-dt> I don't see anything really new happening this cycle. Add some new apps that are missing, fix up the menu some more, get permissions right so that the stuff we added to the kernel is available to the software that needs it.
[16:01] <astraljava> len-dt: That sort of was my drift. :)
[16:05] <len-dt> astraljava, I guess web page and docs could be really big though.
[16:05] <len-dt> That was the one thing missing 12.04
[16:05] <astraljava> Sure. Oh well, there's still about four months left of this cycle. We could technically still kick arse.
[16:06] <len-dt> I am just looking at the software-center man page. It looks like it is possible to start it with a selection of software.
[16:07] <len-dt> So we could have it start with an audio selection of stuff we don't ship for example.
[16:10] <len-dt> astraljava, instead of the software center menu item it could be a submenu with audio/photography/graphics/video/all software selectors in it.
[16:13] <len-dt> I get the idea there are a lot more ways of starting this software, but the man page is pretty bleak.
[16:14] <len-dt> astraljava, so far as kicking arse.... a leader would really help.
[16:16] <astraljava> len-dt: I'm pretty lost on software center, it'd rock if someone could look into that, as it seems to be the only real GUI in the future for package management, I heard synaptic is going away.
[16:17] <len-dt> Life happens though, my activity has been pretty low too.
[16:17] <astraljava> len-dt: As for leader, I don't know what's going on and going to happen. Let's give it (him) some time.
[16:18] <astraljava> len-dt: Yeah, mine too. And it looks like I'm going to be more active on Xubuntu side this cycle, but let's still try not to let this flavor die, anyway. :)
[16:18] <len-dt> astraljava, Ya it would be nice to be able to give S.C. a file with a list of apps to show. Or a type of sw to show
[16:18] <len-dt> astraljava, do you know what part of xfce gives us the storage device icons?
[16:19] <len-dt> Is xubuntu missing them as well?
[16:21] <astraljava> len-dt: Yes, they are.
[16:21] <astraljava> Or it is*
[16:21] <astraljava> Whichever is the correct form. :)
[16:21] <len-dt> both are close enough..
[16:22] <len-dt> Those of us born speaking english spend our whole life mucking it up :)
[16:23] <len-dt> astraljava, So is this something that will come back? Is it something to do with xfce 4.10?
[16:24] <len-dt> Was xfce4-util pulling in something that is not there anymore?
[16:36] <len-dt> astraljava, we seem to be missing gvfsd-dnssd, gvfsd-http, gvfsd-network, gvfsd-smb-browse
[16:39] <len-dt> astraljava, gvfs-gdu-volume-monitor seems to be replaced by gvfs-udisks2-volume-monitor.
[16:41] <len-dt> I am not sure if this is xfce related or if all of ubuntu has this problem
[16:42] <astraljava> I'm not really sure, to be honest. I haven't investigated the issue at all, yet, but one tester reported this and I doubt it's fixed so far.
[16:42] <astraljava> I'd lean towards it being the removable drives mounting over at xfce's side, though.
[16:43] <len-dt> It doesn't work for nautilus either.
[16:43] <len-dt> I think I will download vanilla and see if it is there.
[16:51] <len-dt> A mass storage device is not auto mounted either.
[16:53] <astraljava> On vanilla?
[16:54] <len-dt> I am not sure, there is a bug report #1010523, but it says 11.10, however it is recent enough it might be a typeo
[16:55] <len-dt> Bug #1010523
[16:55] <len-dt> The kernels mentioned look to new to be 11.10
[16:56] <astraljava> Yeah but it's from apport, isn't it?
[16:56] <len-dt> Scratch that...
[16:56] <len-dt> Kernel is old enough.
[16:59] <len-dt> astraljava, I guess I will have to DL vanilla...
[17:00] <len-dt> I am not good at searching bugs... picking out good search strings
[17:04] <len-dt> astraljava, this looks related...Bug #1011257
[17:06] <len-dt> And this bug #1012081
[17:06] <astraljava> Right, but that's with the old kernel, still.
[17:07] <len-dt> No its 12.10
[17:07] <len-dt> kernel 3.4.0-5.11-generic 3.4.0
[17:08] <len-dt> Thats ahead of ours.
[17:08] <len-dt> US 12.10 kernel is still <IP_ADDRESS>
[17:09] <len-dt> astraljava, this may also be related: Bug #1015854
[17:12] <len-dt> astraljava, it looks like a vanilla gvfs (or supporting SW) problem
[17:13] <len-dt> I will DL vanilla and see if my problem is there and do another bug report, but include at least one of these bugs as ref.
[17:13] <astraljava> Oh, well it's possible the -lowlatency hasn't been updated recently.
[17:13] <astraljava> I think the vanilla goes in 3.5 already.
[17:14] <len-dt> astraljava, we need to do two updates, one for 12.04 and one for 12.10
[17:15] <astraljava> What has precise got?
[17:29] <len-dt> astraljava, precise is one version back from vanilla. My Yf's netbook is one more.<IP_ADDRESS> or something.
[17:29] <len-dt> same kernel but updated.
[17:30] <astraljava> Alright, one more thing to the TODO list... *sigh*
[17:44] <len-dt> astraljava, BTW, synaptic is faster and more flexable than software centre, I hope it remains available on some PPA.
[17:44] <astraljava> Could be, but it's unlikely that we can keep it on the images, though.
[17:45] <len-dt> astraljava, it is nice for checking depends etc.
[17:45] <astraljava> bah... that's what terminal is for. *smirk*
[17:45] <len-dt> Ya, aptitude has all that. I imagine it will stay around for server
[17:46] <len-dt> astraljava, I'v been spoiled....
[21:17] <len-1210> Bug #1016978
[21:19] <len-1210> astraljava, ^^ if the xubuntu tester who had the same problem filed a bug, I can mark this a dup, or if not they can confirm and add any info to this one.
[21:20] <astraljava> Yeah, we just need to figure out the root cause first.
[21:20] <len-1210> vanilla seems to be ok
[21:21] <len-1210> They have a section called "devices" at the top of the side bar. That seems to be missing on our version. I would guess xubuntu is using thunar, but I had the same problem there too.


[10:13] <mpt> xnox, cool. How can I test the case of the menu from the command line? When I do "pkexec gcalctool" the prompt contains just a text field.


[08:29] <zerwas> Hi
[09:26] <zerwas> i've just bought a masterkeyboard. can anybody tell me what the best application to test it with jack would be?
[09:29] <AutoStatic> Hello zerwas, I'd say a softsynth like Yoshimi, amSynth or PHASEX
[10:57] <zerwas> sorry, i'm back
[10:59] <zerwas> ok, how do i connect the USB-MIDI cable? i put USB in the computer and on the other side there is a MIDI IN and MIDI OUT cable …
[10:59] <zerwas> does the MIDI OUT cable need to be plugged in to the keyboard?
[10:59] <AutoStatic> MIDI OUT of master keyboard into MIDI IN of cable
[11:00] <zerwas> aaah, ok
[11:00] <AutoStatic> Then start JACK and the softwaynth you want to try and connect it together
[11:00] <AutoStatic> softsynth
[11:01] <AutoStatic> In the ALSA tab of QjackCtl your USB-MIDI cable should be there
[11:02] <AutoStatic> Connect the one in the Readbale Clients/Output Ports pane to the softsynth port in the Writable Clients/Input Ports pane
[11:02] <AutoStatic> Readable
[11:02] <zerwas> okay
[11:03] <zerwas> Done.
[11:03] <AutoStatic> Which softsynth are you using?
[11:03] <zerwas> amsynth
[11:03] <AutoStatic> Ok, cool
[11:03] <zerwas> just like you suggested
[11:03] <zerwas> but it stays silent when i press a key.
[11:03] <AutoStatic> Make sure amSynth's auio outputs are connected too in the Audio tab
[11:04] <zerwas> okay, done
[11:04] <zerwas> still just silence :o
[11:05] <AutoStatic> :( gotta go unfortunately
[11:05] <zerwas> but when i press a key on the keyboard, the "IN" LED on the USB-MIDI-adapter blinks
[11:05] <zerwas> oh noez ☹
[11:05] <zerwas> will you be back today?
[11:05] <AutoStatic> No don't think so
[11:06] <zerwas> too bad. but thank you VERY much for your help so far
[11:06] <AutoStatic> Maybe this might help: http://www.youtube.com/watch?v=kBEzMC35gt8
[11:06] <AutoStatic> NP
[11:07] <zerwas> Thanks, i wil have a look at your video ☻
[12:09] <torpor> hello ubuntustudio'ers.
[12:10] <torpor> i just upgraded my old ubuntu studio machine from 9.04 to 10.04.  now i don't have a realtime kernel.  how do i get it back?
[12:12] <torpor> never mind i'll use abogani's ppa .. ;)


[00:38] <skaet> ubuntu desktop (20110831) and kubuntu alternate(20110830.1) posted
[01:19] <skaet> kubuntu desktop (20110831) and kubuntu dvd (20110831) posted
[01:19] <skaet> urk,  earlier post saying ubuntu desktop should have been kubuntu;   still about to build ubuntu desktop. :/
[02:23] <skaet> have gone into iso tracker and marked the builder with the images currently being rebuilt to pick up the firefox changes.
[03:45] <skaet> ubuntu desktop, alternate 20110831 posted
[03:45] <skaet> xubuntu alternate 20110831 posted
[03:45] <skaet> ubuntustudio 20110831 posted
[03:45] <skaet> yup lots of things nicely ready when I came back from dinner ;)
[04:10] <skaet> ubuntu dvd 20110831 posted
[07:30] <jibel> good morning
[07:35] <xdatap1> morning jibel
[07:35] <jibel> Hey xdatap1
[10:29] <zeedune> I get a crash after installing i386 Kubuntu. I'm trying to create a crash report, but I'm missing the debug symbols for kde-window-manager. Where can I find those?
[11:02] <zeedune> Never mind. Found the repository with dbgsyms
[11:04] <zeedune> Should I cross reference to a KDE bug when reporting the result of the Kubuntu ISO test? If yes, how would I do that?
[13:30] <hggdh> good morning jibel charlie-tca gema pedro_ bdmurray skaet
[13:31] <pedro_> good morning!
[13:31] <charlie-tca> Good morning
[14:01] <jibel> morning hggdh
[14:12] <jibel> Could anyone test the new Ubuntu DVD from a USB and tell if persistent mode works ?
[14:12] <jibel> it's only 1.5GB
[14:13] <xdatap1> jibel, ok I can do that
[14:14] <xdatap1> jibel, i386 or amd64?
[14:15] <jibel> xdatap1, great thanks, the arch you like.
[14:16] <xdatap1> jibel, ok, starting the download right now
[14:16] <xdatap1> jibel, are you using startup disc creator with persistence option, right?
[14:17] <jibel> xdatap1, right.
[14:22] <xdatap1> jibel, is this image new?
[14:22] <xdatap1> jibel, I don't remember a live test with the DVD image
[14:25] <jibel> xdatap1, Yes, it's new. It is a USB form factor image like a desktop + langpacks and additional packages.
[14:26] <xdatap1> jibel, I'll talk with our testing team then, It makes sense to be added to the adoption since there's the live testcase
[14:29] <zeedune> Should I cross reference to a KDE bug when reporting the result of the Kubuntu ISO test? If yes, how would I do that?
[14:32] <charlie-tca> Xubuntu encrypted lvm just failed to install:
[14:33] <charlie-tca> broken dependencies for abiword, system-tools-backend, xubuntu-desktop
[14:34] <charlie-tca> will run 64bit to verify
[14:38] <fader> charlie-tca: I just ran xubuntu amd64 alt
[14:38] <fader> Same thing
[14:38] <fader> bug 838136
[14:38] <charlie-tca> Thanks
[14:39] <fader> I'm guessing since you saw the same thing in another test run that it's not worth it for me to try it on i386 ;)
[15:05] <xdatap1> jibel, rebooting right now for testing the dvd, see you later
[15:07] <charlie-tca> fader: correct; word from pitti and cjwatson is it will fail all the Xubuntu alternate tests
[15:07] <charlie-tca> They are kicking a resping
[15:07] <charlie-tca> s/ resping/respin
[15:20] <primes2h> Hi jibel! How are you? xdatap pinged me, I've just added DVD live as a new adoption in our Testing Team, asking people to test them ASAP.
[15:21] <charlie-tca> new xubuntu alternate images posted
[15:27] <xdatap1> jibel, persistence works in the DVD image i386
[15:42] <jibel> xdatap1, Yay, thanks for confirming \o/
[15:43] <jibel> primes2h, thanks, I hope we'll have a lot of feeback from your testing team as usual :)
[15:44] <primes2h> jibel: we'll do our best ;-)
[16:58] <pedro_> QA Meeting at #ubuntu-meeting in ~2 mins
[20:52] <jibel> Could anyone try to reproduce https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/838273 on Kubuntu ?
[20:55] <charlie-tca> I have a hardware system I can it on
[20:58] <charlie-tca> burning the kubuntu desktop cd now
[21:12] <charlie-tca> jibel: reproduced it
[21:12] <charlie-tca> happens only when there is more than two partitions on the drive and you attempt to change one
[21:13] <jibel> charlie-tca, thanks. I'll try on Ubuntu or is xubuntu affected ?
[21:14] <charlie-tca> I had no problem with xubuntu, even with the same number of partitions
[21:14] <jibel> charlie-tca, ok so only kubuntu seems affected
[22:45] <cjwatson> chadadavis1: thanks for finding bug 837681, and sorry for the badness.  will you be able to retest in time for the beta release?  I think you can probably make those partitions readable again by using gptsync from a live CD
[22:47] <chadadavis1> cjwatson, I'm in the process of reproducing again, to get you some more logs (from the second OS install). Assuming it fails to boot, I will try gptsync. Have you managed to reproduce it?
[22:47] <cjwatson> chadadavis1: no need for more logs, I've just uploaded a fix
[22:47] <cjwatson> I think
[22:47] <cjwatson> I managed to fake up a VM just about enough to see what was going on
[22:47] <chadadavis1> OK, so will ISOs be respun for amd64+mac then?
[22:48] <cjwatson> yep, and i386
[22:48] <cjwatson> actually I think just everything, we were due a respin for some ubiquity bugs in any case
[22:49] <chadadavis1> OK, great, I'll keep an eye out. What's the deadline for beta1 then, for having the ISOs tested, that is?
[22:49] <cjwatson> skaet is better placed to tell you that
[22:52] <cjwatson> chadadavis1: your latest comments are consistent with what I found.  Note that fdisk/sfdisk are showing you the legacy MBR rather than the real partition structure
[22:52] <cjwatson> (but in this case it's the legacy MBR that's broken)
[22:54] <skaet> chadadavis1, would like to know the results tomorrow morning (US time), if at all possible.   Image won't be coming off the builders until fairly late tonight.  I'll ping you directly when its available.
[22:55] <cjwatson> I think current best guesstimate would have an image in maybe 1.5-2 hours
[22:55] <cjwatson> best case
[22:55] <chadadavis1> cjwatson, good to hear. Kinda makes sense.
[22:55] <cjwatson> chadadavis1: insofar as anything about legacy MBRs makes sense, yes ...
[22:56] <chadadavis1> skaet, thank you. Quitting for today then, I'm CEST so that should be enough time to get you results by morning Eastern time.
[22:56] <cjwatson> I know of at least two other bugs in that code but I'm too scared to fix them at short notice; they can wait until after beta-1
[22:56] <cjwatson> (hopefully)
[23:00] <skaet> chadadavis1, great.   Thanks for your help with this one.  :)   Will post in this channel when the images are ready.   Have a good evening.
[23:02] <charlie-tca> Will take a short (couple of hours) break, then test what I can that isn't done yet
[23:05] <skaet> Thanks charlie-tca!   Will post here when the new ones come off.


[01:00] <SpamapS> hazmat: pong (but not sure how long I'll be online ;)
[01:07] <SpamapS> hazmat: and with that, I disappear
[02:44] <hazmat> SpamapS, maybe tomorrow then
[03:37] <hazmat> SpamapS, negronjl http://jujucharms.com/tools/store-missing
[04:05] <negronjl> hazmat: nice ... thx for the tool
[04:49] <SpamapS> hazmat: cool :)
[04:49] <SpamapS> another queue for charmers to work on really
[04:50] <SpamapS> but sort of pointless without the import logs for the charm store
[08:43] <lynxman> SpamapS: did that, I've been having some problems promulgating as well :(
[08:43] <lynxman> SpamapS: tried to fix them with m_3, maybe I can grab ahold of you later
[15:07] <m_3> quiet friday
[15:11] <imbrandon> m_3: heh yea, /me has been fighting with RPM's and charm-tools-that-should-be-called-i-hate-the-osx-bsd-tools
[15:12]  * m_3 grin
[15:13] <imbrandon> took me an hour to figure out bsd getopt != gnu-getopt
[15:13] <imbrandon> heh
[15:14] <SpamapS> imbrandon: hah! perhaps we should rewrite all those in python
[15:14] <imbrandon> btw i came accross a very slick way to install juju on OSX now without the need for brew at all , gonna script it up and it can live in the official juju branch then ( that assumes it would be approved for such but i dont see why not )
[15:15] <imbrandon> SpamapS: i thought seriously about it, i got a few patches in either case :)
[15:16] <imbrandon> added some error checking too and checking of exit codes from the commands / scripts
[15:17] <imbrandon> and normalized the help where it called them commands and scripts interchangeably
[15:17] <imbrandon> but its all like one big commit right now, gonna split it out here in a few in case you dont like all the changes its easier to cherry pick
[15:18]  * imbrandon gets back at it before i get destracted too much
[15:20] <imbrandon> oh and got a 3-month free window azure thing too today so thought about trying to make a provider , but likely will fail if/when i get to that part
[15:25] <imbrandon> SpamapS, m_3, jcastro: if i did the leg work and got a Proof-of-concept OS X jenkins deploying code then running unit/regression testing for juju and charm-tools what do you think the chances of getting a VM running in canonical's to do that would be ?
[15:26] <imbrandon> canonical's datacenter*
[15:29] <shazzner> imbrandon: you're working on juju for osx right?
[15:29] <imbrandon> yup
[15:30] <shazzner> cool, as someone who has unfortunately been forced to use it. I sincerely applaude your effort :)
[15:30] <imbrandon> doing some touchups today matter fact, some things still not 100% right but its getting there :)
[15:30] <shazzner> sweet
[15:31] <shazzner> I wonder if juju can deploy to rackspace's managed cloud, probably not I assume
[15:31] <imbrandon> fixed up bash completion and got most of the charm tools runnning , most importantly charm proof
[15:31] <imbrandon> it can
[15:31] <shazzner> interesting...
[15:31] <imbrandon> i use rackspace a little
[15:31] <shazzner> I figured it would be one layer abstracted too much
[15:32] <imbrandon> nah, they have pure openstack
[15:32] <imbrandon> e.g. it was them and nasa that started that show anyhow :)
[15:32] <shazzner> yeah, I'm familar with it all
[15:33] <shazzner> I'm wondering if a managed cloud user can get openstack creditials to deploy services to
[15:33] <imbrandon> but yea, you can, you neeed to use SpamapS's external s3 patch or the OSAPI provider thats on LP for testing only yet
[15:33] <imbrandon> but it works
[15:33] <shazzner> huh, awesome
[15:33] <imbrandon> shazzner: i'm not sure 100% i just asked support and now they are in my cpl
[15:34] <imbrandon> few weeks ago
[15:34] <shazzner> cool, let me know what they say :)
[15:34] <imbrandon> no thats what i mean, i asked them , and they gave em to me
[15:34] <shazzner> oh I see what you mean
[15:34] <imbrandon> and put them in my cpl alogn with the API key :)
[15:34] <shazzner> damn that rules
[15:34] <m_3> imbrandon: there's really nowhere to run such a VM afaik, but get me a VM and I'll see what I can do
[15:35] <imbrandon> m_3: ok, i'll see if i cant have it sometime next week
[15:35] <imbrandon> :)
[15:35] <m_3> imbrandon: the qa lab hardware is up/down all the time with openstack and maas testing... but I'll ask around
[15:35] <imbrandon> if not cool i understand, more convience for others than me
[15:35] <imbrandon> kk
[15:37] <hazmat> m_3, there's one more charm which still showing some ill effects from the distro branches
[15:37] <hazmat> m_3, cs:oneiric/hadoop-master
[15:37] <hazmat> ie. can't be checked out, as it references a precise branch
[15:38] <hazmat> its at this unreachable branch lp:~charmers/charms/oneiric/hadoop-master/trunk
[15:40] <m_3> hazmat: that's a strange one... b/c it shouldn't be in precise
[15:41] <m_3> in oneiric, the charms are hadoop-master, hadoop-slave, hadoop-mapreduce
[15:41] <m_3> in precise, it's just hadoop
[15:41] <hazmat> m_3, right.. perhaps because it got yanked?
[15:41] <m_3> no clue... lemme look at the branches
[15:41] <hazmat> m_3, its the only charm branch thats inaccessible
[15:49] <m_3> hazmat: man that's just hosed... bzr info's not showing that oneiric/hadoop-master/trunk's stacked on anything but it's referencing the precise/hadoop-master/precise branch
[15:54] <m_3> oh, I see what's going on here... lp's trying to be smart.. the branch has no reference to series... bzr+ssh://bazaar.launchpad.net/+branch/charms/hadoop-master/... and it gets filled in magically
[15:55] <m_3> makes sense that we can't manually manage series then
[16:07] <gmb> SpamapS: around?
[16:34] <negronjl> 'morning all
[16:35] <m_3> hazmat: ok, try it now
[16:35] <hazmat> negronjl, g'morning
[16:35] <negronjl> hi hazmat
[16:35] <m_3> hazmat: actually retry all hadoop-{master,slave,mapreduce}
[16:35] <hazmat> m_3, in progress
[16:36] <hazmat> negronjl, how'd it go?
[16:37] <negronjl> hazmat: It went very well... I never expected so many people to be so interested in Ubuntu in Azure
[16:37] <m_3> negronjl: yeah, it's totally cool imo
[16:37] <negronjl> M$ is about 60-70% to where Amazon is in features
[16:38] <negronjl> and they are giving away a lot of very interesting features ( metrics and such ) for free
[16:40] <hazmat> negronjl,  i'm curious to try out their prod platform to see what the i/o is like
[16:41] <hazmat> negronjl, if they can just make the config stuff work it would go alot nicer
[16:41] <negronjl> hazmat: Prod IO is about 30M/s
[16:41] <hazmat> negronjl, nice.. that's roughly 6x dev
[16:41] <negronjl> hazmat: yup
[16:41] <SpamapS> gmb: I'm off this week, but peeking in here and there
[16:41] <negronjl> hazmat: They were telling me that their dev/beta env was pretty much worthless
[16:41] <hazmat> negronjl, did you do a juju demo?
[16:41] <gmb> SpamapS: Okay. I'm about to EoD, so I'll drop you an email instead and we can talk when you're back.
[16:42] <negronjl> hazmat: No ... I just had the presentation in a loop on my laptop and had people ask about it and such after looking at it
[16:42] <m_3> negronjl: cool
[16:43] <SpamapS> gmb: I do plan to get your python modules into Debian/quantal *soon*
[16:43] <SpamapS> gmb: you're just suffering from an unfortunate series of events of very high priority ;)
[16:43] <hazmat> SpamapS, i think i'm going to need to rewrite charm-tools check to be more amenable for library usag
[16:44] <gmb> SpamapS: Okay; is there anything at all we can do to help? Should we rope someone else with packaging experience to help out rather than just loading you up with more work?
[16:46] <SpamapS> hazmat: library?
[16:46] <SpamapS> hazmat: its pretty easy to parse....
[16:46] <hazmat> hmm
[16:46] <m_3> yeah, I was just trying to fiure out what hazmat was talking about
[16:46] <SpamapS> why not speak the international language of shell love... exec()
[16:47] <hazmat> because its nice to avoid fork bombs on small instances ;-)
[16:47] <hazmat> but fair enough
[16:47] <hazmat> i'll give that a short first
[16:47] <SpamapS> Even if there are 10,000 charms... thats not too many forks if you wait() on them :)
[16:48] <hazmat> SpamapS, there's also some thing this would pick up better if it used the juju.charm class
[16:49] <hazmat> there's a couple of invalid things it misses
[16:49] <SpamapS> No
[16:49] <SpamapS> it must not share code w/ juju
[16:50] <SpamapS> the whole point is that it is an independent static analysis tool
[16:51] <hazmat> SpamapS, what value does that provide, other than inconsistency?
[16:51] <hazmat> it can do additional checks and policies
[16:51] <SpamapS> its an air gap to protect against bugs in the juju implementation
[16:52] <SpamapS> charm proof is meant to assert the way the spec says charms are composed
[16:52] <SpamapS> If it throws errors where juju does not, then *one* of them has a bug.
[16:52] <hazmat> the juju analysis is static, bugs should be fixed there, we already have multiple implementations of that..
[16:53] <hazmat> SpamapS, the problem is that its not throwing errors, where juju does
[16:53] <hazmat> and rather than copy the implementation, why not just use it..
[16:53] <SpamapS> then thats a bug in one of them too
[16:53] <SpamapS> (unless its a runtime error, not a static format error)
[16:55] <SpamapS> hazmat: I'm fine with charm proof *calling* juju's version of "is this formatted correctly" after it has found that it thinks the charm is formatted correctly. But I don't want them sharing code.
[16:56] <imbrandon> we could do the charm-tools in ruby then it would not be an issue ... just teasin before someone takes me serious :)
[17:10] <gmb> SpamapS: I'm eod'
[17:10] <gmb>
[17:10] <gmb> arg
[17:11] <gmb> 'ing now, so please email me if there's anything that we (~Yellow, ~launchpad or others) can do to help you with the packaging of our charm-tools additions and python-shelltoolbox. We're happy to try and find someone else to do the packaging if you've got too much on your plate.
[17:12] <imbrandon> gmb: are they on LP branch somewhere ?
[17:12] <SpamapS> gmb: given that buildbot is being abandoned, is anything else going to use these python charm helpers?
[17:13] <imbrandon> wait should they be charm-helpers or charm-tools
[17:13] <SpamapS> imbrandon: they exist.. just simple python modules that I want to have packaged before we start relying on them.
[17:13] <SpamapS> imbrandon: definitely charm helpers
[17:14] <SpamapS> which is a part of charmt-tools
[17:14] <imbrandon> SpamapS: i will likely have time over this weekend assuming this rpm stuff falls in line, if that will help
[17:16] <SpamapS> imbrandon: sure if you can dig them out
[17:16] <imbrandon> k
[17:26] <m_3> SpamapS: so python-shelltoolbox needs to be built as a package and marked as a dep of charm-tools? re: https://code.launchpad.net/~yellow/charm-tools/trunk/+merge/101554 or is there something more going on here?
[17:27] <SpamapS> m_3: right, well ,a dep of the python bit
[17:27] <SpamapS> anyway, I'm out again
[17:28] <SpamapS> be back to work on Monday
[17:28] <m_3> SpamapS: great weekend!
[17:30] <hazmat> SpamapS, have a good one
[17:30]  * hazmat gathers a list of all the charms proof has a runtime error on
[17:36] <m_3> hazmat: did hadoop-xxx work now?
[17:36] <m_3> (oneiric and precise)
[17:37] <hazmat> m_3, yup
[17:37] <hazmat> m_3, thanks
[17:38] <hazmat> that's not bad... charm proof only barfs completely on two charms (out of 360).
[17:38] <hazmat> http://paste.ubuntu.com/1030745/
[17:38] <hazmat> the terracota one though juju is fine with in practice, has an odd definition of its peer interface though
[18:51] <adam_g> is there some backdoor way to go about clearing the charm cache from an existing juju environment, so that juju deploy will always use the local:charm regardless of revision?
[18:54] <benji> adam_g: I think you want "juju deploy --upgrade"
[18:58] <adam_g> benji: will that work for a local charm that has an earlier revision # than whats currently cached/was last deployed?
[18:59] <m_3> adam_g: http://bazaar.launchpad.net/~juju-jitsu/charmrunner/trunk/view/head:/charmrunner/snapshot.py clean_juju_state does some of this... it was written against the local provider though
[18:59] <imbrandon> adam_g: or set a cron to rm it from /usr/lib/juju/* on the bootstrap node
[19:00] <imbrandon> kinda hackish tho
[19:00] <imbrandon> phh m_3 idea much better
[19:00] <imbrandon> :)
[19:01] <imbrandon> adam_g: iirc juju upgrade-charm --repository /usr/local/lib/charms/ local:mycharm
[19:01] <imbrandon> will make the version auto inc
[19:01] <imbrandon> err revision
[19:02] <adam_g> hmm. thanks, ill mess around with all of the above
[19:02] <imbrandon> actually tho you would need to drop the local: from that it wants the service name, but it should still get it from local if it was deployed from there
[19:03] <hazmat> adam_g, --upgrade should do the trick
[19:03] <hazmat> adam_g, it will increment the revision
[19:03] <hazmat> if not snapshot script should do it
[19:03] <hazmat> adam_g, actually one more way...
[19:04] <hazmat> adam_g, upgrade --force
[19:04] <adam_g> hazmat: it will increment the revision where? in the ./precise/foo/revision, or in the juju environment?
[19:04] <hazmat> foo/revision afaicr
[19:04] <adam_g> hmm
[19:04] <hazmat> adam_g, what's the issue again?
[19:05] <adam_g> i basically just need juju to ignore the local revision if at all possible, or reset it in its state
[19:05] <hazmat> you have a rev 5 in the env, and rev 3 on disk?
[19:05] <adam_g> hazmat: potentially, yeah
[19:05] <hazmat> adam_g, whats the scenario that arises in?
[19:06] <hazmat> adam_g, and why couldn't you just increment the revision?
[19:06] <adam_g> currently MAAS only supports precise, i need to deploy and test services on both precise quantal and precise. to do this, i need to switch the installation between releases in cobbler. from juju's POV, everything is being deployed to precise.  i have two charm branches for each service (one for precise, one for quantal). when i deploy, i branch them into ./precise and 'juju deploy --repository=. local:foo'.  i'd like to not have to re-bootstrap every deploy
[19:07] <hazmat> adam_g, there different charms
[19:07] <adam_g> hazmat: yeah
[19:07] <hazmat> adam_g, the series is part of the charm name
[19:07] <hazmat> oh..
[19:07] <hazmat> gotchqa
[19:07] <adam_g> hazmat: in this case, both charms look the same
[19:07] <adam_g> precise/nova-compute
[19:08] <hazmat> adam_g, why not tell juju quantal/nova-compute ?
[19:08] <adam_g> between deploys, i replace that charm with the quantal version
[19:08] <hazmat> ie. why try to make two separate charms both pretend to be the precise?
[19:08] <adam_g> hazmat: does 'deploy local:quantal/nova-compute' work? i thoguht it resolved the directory based on the series specified in environemnets.yaml
[19:08] <hazmat> adam_g, it resolves the *default* series
[19:08] <hazmat> adam_g, but you can specify any series when deploying
[19:09] <hazmat> in the absence of one specified, it uses the default
[19:10] <adam_g> hazmat: specify the series how? as an argument to deploy? either way, i think MAAS provider will refuse anything other than precise ATM?
[19:10] <adam_g> unless specifying it at deploy time is independent of the provider
[19:11] <bkerensa> =o
[19:11] <hazmat> adam_g, its specified as part of the charm name so local:quantal/nova-compute should do it
[19:11] <adam_g> hazmat: er, yea
[19:11] <adam_g> Bad 'ubuntu-series' constraint 'quantal': MAAS currently only provisions machines running precise
[19:11] <hazmat> adam_g, it needs provider support though
[19:12] <hazmat> lame
[19:12] <adam_g> so im back at square one. :)
[19:12] <hazmat> yup
[19:12] <hazmat> but with context its so much better ;-)
[19:12]  * m_3 grimace
[19:12] <hazmat> adam_g, so the snapshot script is what you want
[19:12] <adam_g> hazmat: great. ill take a look after lunch
[19:13] <gary_poster> hey SpamapS gmb mentioned you were wondering whether the python charm helpers would be helpful.  I'm hoping they still are.  I'm proposing that we write a Launchpad dev charm, so I'm selfishly interested, but also I thought we were all pleased that they were good tools for charmers in the future.
[19:13] <gary_poster> maybe I misunderstood though
[19:13] <hazmat> adam_g, its in pypi.. so its an easy_install charmrunner away..
[19:13] <hazmat> also in lp:charmrunner
[19:13] <adam_g> sweet, thanks kapil
[19:14] <m_3> gary_poster: think they'll be generally useful... peeps were just balking at deps that weren't packaged
[19:15] <gary_poster> m_3, cool thanks
[19:15] <hazmat> hmm.. it does look like snapshot has some local provider specifivity..
[19:15] <m_3> gary_poster: so I think we'll package python-shelltoolbox or something like that and mark it a dep of charmhelpers-py
[19:15] <hazmat> we don't abstract out removing files from storage...
[19:15] <hazmat> :-(
[19:16] <m_3> hazmat: shouldn't be too hard to extend it... it takes care of the zk part
[19:16] <gary_poster> cood, m_3, yeah that's what I was hoping
[19:16] <hazmat> i don't think that should be a problem since its killing the zk state for the charm
[19:16] <gary_poster> thank you
[19:16] <m_3> gary_poster: np... sorry it sat in the queue for so long!
[19:17] <gary_poster> :-) will be very happy when it is all set up
[21:25] <jimbaker> m_3, SpamapS, i just proposed lp:~jimbaker/juju-jitsu/watch-subcommand which adds a jitsu watch subcommand
[21:27] <jimbaker> it's a superset of what can be done with polling juju status and parsing; in particular, one can wait for relation settings to be set (or unset). so that should be useful for testing. also it uses the Juju API where possible, otherwise ZK, so it's much lighter weight/instaneous
[21:29] <m_3> jimbaker: cool... thanks!
[21:33] <jimbaker> m_3, one other cool thing is that multiple conditions can be specified, with all or any waiting. also being able to wait for --num-units of a service to be in a state, along with some set of relation settings, should hopefully prove useful
[22:10] <hazmat> negronjl, cassandra charm exposes jmx as a 'cassandra' interface ? that's not right
[22:10] <negronjl> hazmat: I'll look into it ... would you open a bug and assign it to me?  I'm swamped at the moment and don't want to forget about it.
[22:11] <hazmat> negronjl, np
[22:11] <negronjl> hazmat: thx