[04:02] <Kilos> o/
[14:13] <Mister_Q> o/
[14:54] <Kilos-> o/
[16:19] <czajkowski> all very quiet with no dholbach these days
[16:19] <czajkowski> no morning
[16:19] <czajkowski> no see you tomrorow
[16:19] <czajkowski> :(
[16:19] <Kilos> yeah sad hey
[16:40] <popey> jose: the uoa bot seems to be tweeting about uoa which we aren't doing anymore (at least until the new year) and mentions dpm and dholbach, which it shouldn't do anymore.
[19:05] <knome> czajkowski, you can be the new dholbach - just start doing it yourself
[19:08] <czajkowski> alright folks.... I'll call it a day see you tomorrow
[19:08] <knome> :)


[00:08] <Linux000> This is my first triage, so could someone make sure bug 534582 is a wishlist item?
[00:08] <ubot4> Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 1)" [Undecided,New] https://launchpad.net/bugs/534582
[00:25] <crimsun> plars: in Lucid, please export LIBASOUND_DEBUG as a non-empty value and try again
[00:26] <crimsun> plars: alternately, ltrace
[00:26] <bdrung_> Linux000: i wouldn't consider it as withlist item. it's a bug and not a feature request.
[00:26] <Linux000> Thanks, so what would it be?
[00:27] <Linux000> Sorry, misread your post
[00:29] <Linux000> Could someone set bug 534582 to Importance low, I can't seem to.
[00:29] <ubot4> Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/534582
[00:29] <plars> crimsun: exporting LIBASOUND_DEBUG=y and playing something doesn't give me anything
[00:29] <plars> crimsun: do you want the ltrace on aplay, or paplay?
[00:31] <crimsun> plars: both, please
[00:31] <Linux000> And set bug 534582 to Triaged? Thanks.
[00:31] <ubot4> Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/534582
[00:31] <crimsun> plars: current board is running 1.0.22-0ubuntu6, correct?
[00:32] <Linux000> Never mind the Triaged status on 534582, new here.
[00:32] <plars> crimsun: of which package?
[00:32] <crimsun> plars: libasound2
[00:33] <plars> crimsun: yes
[00:33] <plars> crimsun: do you think that's where I should file a bug against for now? then attach the logs?
[00:34] <crimsun> plars: please do, yes.
[00:35] <plars> crimsun: will do that shortly, have an interrupt at the moment
[00:36] <crimsun> np. Thanks.
[03:07] <crimsun> plars: note: aplay expects PCM. It won't play vorbis as you intend.
[03:08] <crimsun> plars: specifically, PCM->wav
[03:08] <plars> crimsun: ah, my mistake.  Still, the rest of it holds true.  I'll retry that part with wav files
[03:09] <crimsun> plars: now, the symptom that you describe in bug 534815 typically points to an incorrect resampling rate configured in pulse
[03:09] <ubot4> Launchpad bug 534815 in alsa-lib (Ubuntu) "imx51 some audio files play, others do not (affects: 1)" [Undecided,New] https://launchpad.net/bugs/534815
[03:10] <plars> crimsun: I have a similar, but opposite bug on another SoC
[03:10] <crimsun> plars: to verify, please see default-sample-rate in /etc/pulse/daemon.conf
[03:11] <plars> ; default-sample-rate = 44100
[03:11] <crimsun> plars: in verbose mode, the pulse daemon will use snd_pcm_dump() to print hw config. Please see https://wiki.ubuntu.com/PulseAudio/Log
[03:12] <crimsun> plars: another more apropos environment variable to test is to export PULSE_NO_SIMD to a non-empty value and forcibly restart the pulse daemon
[03:13] <crimsun> plars: finally, try bypassing pulse entirely by using speaker-test -Dplughw:0 [any additional params]
[03:13] <crimsun> plars: (or, pasuspender -- speaker-test -Dplughw:0 [...])
[03:15]  * persia idly notes that it's common for different hardware solutions to need different sorts of quirks.
[03:31] <plars>  crimsun: ah, yes, with -Dplughw:0 speaker-test -c2 -t wav works (without it, it does not)
[04:00] <crimsun> plars: ok, definitely a pulse bug, then.
[04:01] <crimsun> plars: did PULSE_NO_SIMD=1 help?
[04:02] <plars> crimsun: no, I turned that on when I reproduced it for the verbose log
[04:03] <crimsun> ok, I haven't read the log yet
[04:03] <crimsun> still commuting from work
[04:05] <plars> crimsun: np, thanks for all your help.  About to go to sleep myself
[04:47] <dreamer_> has anyone here got jack+pulse working in lucid
[04:47] <dreamer_> everytime I fire up jack with pulse apps won't start and I get Bus error (core dumped) messages from almost all apps I try to run (even ubuntu-bug)
[07:18] <kermiac> vish: ping re last comment in bug 532633. I'll ask as you have been involved in this bug too. Are you happy for me to go ahead & change the description to focus only on the wm controls?
[07:18] <ubot4> Launchpad bug 532633 in light-themes (Ubuntu) "[light-theme] please centre window title and order window controls (affects: 36) (dups: 6)" [Wishlist,Triaged] https://launchpad.net/bugs/532633
[07:19] <kermiac> vish: the wm controls are the main issue in this bug
[07:19] <vish> kermiac: yeah , sure , i wanted to do it either way.. there are many dups , we can use this for the controls..
[07:20] <vish> only the title needs change
[07:20] <vish> kermiac: thanks for following up
[07:20] <kermiac> you don't think i should remove the reference to the window title from the description? If I change one, I think both should be changed
[07:22] <kermiac> vish: ^^
[07:22] <vish> kermiac: hmm , the title and the controls will probably need to be changed at the same time , we can just leave it alone
[07:22] <kermiac> vish: ok, no probs :) I'll update the title
[07:30] <Anzenketh> That is a lot of bugs
[07:45] <Zus> hello guys
[07:45] <Zus> and gals
[08:54] <BUGabundo_remote> \0
[09:25] <ikt> BUGabundo_remote: \o/
[09:31] <BUGabundo_remote>  /8\ ikt
[09:34] <ikt> BUGabundo_remote:  wut is that?
[10:01] <ikt> https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/529378
[10:01] <ubot4> Launchpad bug 529378 in yelp (Ubuntu) "yelp crashed with signal 5 (affects: 2)" [Medium,Incomplete]
[10:12] <ikt> wow @ vish w/57 days in a row
[10:14] <ikt> 57 weeks?
[10:19] <vish> ikt: 57 weeks is 1 yr ;)
[10:19] <vish> more than*
[10:20] <ikt> that would be quite insane
[10:20] <ikt> or not really
[10:21] <ikt> so if you can do 5 a day for 5 days in a 7 day week, that counts if you say miss out on 2 days?
[10:22] <vish> ikt: hm.. i havent done 57 weeks  , but yeah , 5 in 7 days counts
[10:24] <ikt> ah sweet
[12:57] <ttx> pedro_: hey, thanks for the samba bugday announcement. Unfortunately I have an emergency on Wednesday (European) morning so I won't be able to kick off early
[13:00] <pedro_> ttx, hola, no worries!, thanks for let us know ;-)
[13:01] <pedro_> ttx, we can always wait a little bit for the other folks on the server team to ask questions if we have any
[13:01] <ttx> pedro_: ack
[13:02] <chrigi> hi! i'm new here and i've got a question regarding the ubuntu bugfixing process. is this the right place for such a question?
[13:04] <pedro_> chrigi, better to ask at the #ubuntu-motu channel
[13:04] <persia> We can try.
[13:04] <pedro_> oh well persia is here ;-)
[13:04] <persia> pedro_: Why?
[13:05]  * persia thinks bugsquad is probably subscribed to more bugs than MOTU :)
[13:07] <pedro_> cause they might know better about the bug fixing process from the developer point of view ;-)
[13:09] <chrigi> Well some time ago I had this problem that my keyboard went dead after I resumed from suspend. I found several bugreports on launchpad on it. Further I found that the problem was already fixed in the head of the upstream repository. now my question is: how will the bug find it's way from the upstream github to the ubuntu repos? And what to do with the bugreport?
[13:09] <chrigi> Sorry for the n00b question ;)
[13:11] <yofel> waah, there I'm busy for 2 weeks only to come back and find out we have the meeting, kernel bug day and 2 hug days the same week o.O, busy...
[13:12] <yofel> chrigi: usually the bug get's fixed in the development  release once a new upstream release gets into lucid containing the fix
[13:13] <yofel> chrigi: to fix bugs in released versions of ubuntu you have to follow https://wiki.ubuntu.com/StableReleaseUpdates
[13:15] <yofel> chrigi: btw, you mentioned a bug report, which bug?
[13:15] <chrigi> yofel: thanks! well I think it's not major enough for a StableReleaseUpdate, but is there some place I can see what development release of the package will make it into lucid?
[13:16] <chrigi> yofel: it's the following bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/437862
[13:16] <ubot4> Launchpad bug 437862 in xserver-xorg-input-evdev (Ubuntu) "device key_bitmask has changed (affects: 19) (dups: 3)" [Medium,Triaged]
[13:16] <yofel> ah, X...
[13:17] <yofel> !info xserver-xorg-input-evdev lucid
[13:17] <ubot4> yofel: xserver-xorg-input-evdev (source: xserver-xorg-input-evdev): X.Org X server -- evdev input driver. In component main, is optional. Version 1:2.3.2-3ubuntu1 (lucid), package size 80 kB, installed size 204 kB
[13:17] <yofel> chrigi: that's the version we have right now
[13:17] <yofel> chrigi: for more details you'll probably get better help in #ubuntu-x
[13:18] <chrigi> yofel: 2.3.2 is perfect, where did you get this info?
[13:19] <yofel> chrigi: look at the last line I posted before ubot4 posted the information, also you can query the bot in private with '/msg ubot4 info <pkg> lucid'
[13:20] <chrigi> and what to do with the bug report? just leave it as "triaged" or change it to fix released (as it is already fixed in upstream)?
[13:20] <chrigi> yofel: thanks!
[13:21] <yofel> chrigi: also useful is the 'rmadison' command that's part of the devscripts package
[13:21] <yofel> actually  I find most of the 'ubuntu-dev-tools' package useful
[13:24] <chrigi> !info xserver-xorg-input-evdev lucid
[13:24] <ubot4> chrigi: xserver-xorg-input-evdev (source: xserver-xorg-input-evdev): X.Org X server -- evdev input driver. In component main, is optional. Version 1:2.3.2-3ubuntu1 (lucid), package size 80 kB, installed size 204 kB
[14:08] <zeroseven0183> Hi! Am I right in saying that the meeting will start in two hours?
[14:09] <zeroseven0183> I'm living in the Southeast Asia and it's already 10PM in the evening here. I won't be able to attend the meeting if my timing is correct.
[14:14] <yofel> zeroseven0183: yes, in 2 hours
[14:19] <persia> zeroseven0183: I have a similar issue in my timezone.  If I have something I want to raise, I usually ask someone else to raise it for me, and review the logs later.
[14:19] <persia> zeroseven0183: logs can always be found at irclogs.ubuntu.com
[14:20] <persia> (or if they are missing, complain, because they *should* be there)
[14:23] <zeroseven0183> Thanks for the suggestion persia. I guess I have to checkout the logs after
[14:24] <zeroseven0183> I wanted to familiarize myself with the terminologies the BugSquad is using
[14:24] <zeroseven0183> So I can easily triage bugs
[14:24] <zeroseven0183> and better help this team
[14:24] <persia> zeroseven0183: Best way to do that is to check the wiki pages in the /topic
[14:25] <zeroseven0183> Yup. Actually, it helps me a lot.
[14:25] <persia> zeroseven0183: Or just ask: there's lots of us in Asia, and a healthy overlap with early-rising Europeans, and late-sleeping Americans.
[14:26] <persia> (for the purposes of the above, the antipodes are "Asia": apologies for overgeneralisation.  Africans aren't mentioned only because I don't see many early-rising ones around often)
[14:30] <BUGabundo_remote> seb128: I'm experiencing similar lag as the fixed GTK bug we had a few weeks ago :(
[14:31] <seb128> BUGabundo_remote, ok, dunno where from since we dropped this gtk patch a week ago in lucid
[14:32] <BUGabundo_remote> I'll test with gtkperf once I get home
[14:32] <BUGabundo_remote> it just started feeling like that right after this last batch of updates
[14:32] <BUGabundo_remote> The following packages will be upgraded:
[14:32] <BUGabundo_remote>   cheese cheese-common f-spot firefox firefox-branding firefox-gnome-support gdm gnome-settings-daemon gstreamer0.10-plugins-good gstreamer0.10-pulseaudio libcheese-gtk18   libgnomekbd-common libgnomekbd4 libgweather-common libgweather1 linux linux-generic linux-headers-generic linux-image linux-image-generic tomboy xulrunner-1.9.1   xulrunner-1.9.1-gnome-support
[14:33] <BUGabundo_remote> but I don't see anything even closelly related
[15:59] <bdmurray> Today is meeting day right?
[15:59] <yofel> if everybody remembered yes
[15:59] <bdmurray> I remembered ;-)
[15:59] <yofel> me too :P
[16:00] <yofel> hm, hggdh is here, qense and micahg aren't :/
[16:00] <mrand> As usual, I'll be in and out.
[16:01] <pedro_> is there any agenda item?
[16:01] <bdmurray> There are some additional topics we haven't discussed
[16:04] <bdmurray> I guess the only topic with an attendee is hggdh's
[16:04] <bdmurray> hggdh: ?
[16:05] <BUGabundo_remote> foo
[16:08] <hggdh> here, sorry
[16:08] <yofel> maybe we should send out a metting reminder to the ML a day before ^^
[16:08] <bdmurray> no problem
[16:08] <yofel> *meeting
[16:08] <bdmurray> yofel: yeah, that'd be good ;-)
[16:09] <mrand> Should probably be a way to do that automatically so someone doesn't have remember to send it out ;-)
[16:10] <hggdh> so. Are we going to talk about the pending nominations?
[16:10] <bdmurray> hggdh: yes, sounds good
[16:10] <BlackZ> hi all
[16:11] <hggdh> Laibsch started to review pending nominations, and asked what is the procedure there. This is a rather vague process right now
[16:12] <bdmurray> If its vague its because the nomination workflow is incomplete or lacking in Launchpad
[16:13] <bdmurray> One issue is that any bug can be nominated for a release - it doesn't need to be confirmed or triaged or anything
[16:13] <bdmurray> That might be handled socially if we were to educate people about when to nominate
[16:13] <hggdh> yes indeed. I would rather have social controls than programatic ones
[16:14] <bdmurray> However, another issue is that its not possible to renominate a bug for a release so if you decline a nomination people don't have much recourse
[16:14] <hggdh> which, then, makes it difficult to work on them...
[16:15] <hggdh> coiuld we have package owners/bug-control able to re-nominate?
[16:16] <hggdh> (which would mean a LP bug to be opened, of course)
[16:16] <bdmurray> well, package uploaders can target disapproved nominations for release but there is no way for them to get back in the queue
[16:16] <hggdh> but this is an individual action, bypassing the rejected nomination
[16:16] <bdmurray> so let's pretend we have a new / incomplete bug nominated for lucid
[16:17] <bdmurray> it then gets declined / rejected ... how will it be renominated?
[16:17] <bdmurray> should the decliner subscribe to the bug in the off chance it becomes complete?
[16:18] <hggdh> hum
[16:18] <bdmurray> Maybe there is some workaround we could use with tags?
[16:19] <thekorn> sorry, but I'm missing something: how are nominations used in the development comunity? is the current use of nominations described somewhere?
[16:19] <hggdh> perhaps by -- instead of officially declining it -- by tagging "declined"?
[16:19] <bdmurray> hggdh: right and telling people to remove it if the bug is squared away
[16:19] <nigelb> thekorn: nominations are used for SRU I think
[16:20] <hggdh> but the flow is quite undocumented
[16:20] <thekorn> release management is also using it, right?
[16:20] <bdmurray> thekorn: https://wiki.ubuntu.com/RCBugTargetting
[16:21] <bdmurray> 'To indicate that a bug should be fixed prior to the final release, the bug should be nominated using the "nominate for release" option in Launchpad'
[16:21] <hggdh> bdmurray: who has final decision power on nominations?
[16:21] <charlie-tca> Then why can you nominate for any release instead of just the development release?
[16:21] <bdmurray> hggdh: generally uploaders of the packages
[16:21] <pedro_> charlie-tca, because of the SRU
[16:22] <thekorn> ok, cool. Related question: who can set nomination in ubuntu?
[16:22] <bdmurray> thekorn: anybody
[16:22] <charlie-tca> anyone
[16:23] <thekorn> I think I never used it ;)
[16:23] <bdmurray> hggdh: so using tags for declining would allow more people to participate in the workflow
[16:23] <bdmurray> which would be good I think
[16:23] <hggdh> I agree
[16:24] <hggdh> and it is something we can do without changes to LP
[16:25] <hggdh> I guess we could do with just one tag -- to signal it is being declined. Absence of the tag would mean it is game for nominations
[16:26] <bdmurray> hggdh: yes and then query for nominations without the "declined" tag
[16:26] <charlie-tca> The problem is the bug could be nominated for 5 releases, then declined for one only
[16:26] <pedro_> declined-release , right?
[16:26] <bdmurray> pedro_: yep
[16:26] <bdmurray> and maybe even nomination-declined-lucid
[16:27] <pedro_> sounds better to me
[16:27] <bdmurray> to avoid confusion with declining other things that I don't have an example of ;-)
[16:27] <charlie-tca> As in a bug nominated for lucid, karmic, hardy, dapper
[16:29] <bdmurray> charlie-tca: I think that's covered right?
[16:29] <charlie-tca> As long it is a release specific tag
[16:30] <hggdh> and I like the hierarchical naming
[16:30] <charlie-tca> nominating is a favorite for spammers. Once they do it, you have to decline all of them, and the bug can never be nominated again at a later date
[16:31] <hggdh> yes. This is why we are considering tagging instead of officially declining them
[16:31] <thekorn> does anyone know if the procedure described in https://wiki.ubuntu.com/RCBugTargetting "untargeting bugs" ever worked?
[16:32] <bdmurray> thekorn: I think it does
[16:32] <hggdh> but it gets to be more work than tagging, I think
[16:32] <bdmurray> thekorn: they are talking about if a bug is targetted to lucid, then it doesn't have a current release tag if you won't fix the lucid task a "current" one gets added
[16:32] <bdmurray> current release task not tag
[16:33] <thekorn> hmm, maybe I'm just too confused ;)
[16:33] <thekorn> sorry
[16:33] <bdmurray> https://bugs.staging.launchpad.net/ubuntu/+source/debian-installer/+bug/229699
[16:33] <ubot4> Launchpad bug 229699 in debian-installer (Ubuntu) ""setting locale failed" if using other keyboard layout then language (affects: 1) (dups: 1)" [Undecided,Confirmed]
[16:34] <bdmurray> there is an example I just made
[16:34] <bdmurray> on staging
[16:34] <bdmurray> so I think if you won't fix the lucid task a new one will appear
[16:34] <bdmurray> It doesn't really help with the work flow we are discussing as this one's nomination was already approved
[16:35] <bdmurray> hggdh: So I think we should discuss this with the release team / slangasek
[16:35] <hggdh> I agree.
[16:35] <thekorn> no, it did not work, but yeah it's not relevant to our discussion
[16:36] <bdmurray> In the mean time an announcement about when to nominate a bug would still be a good idea though
[16:36] <hggdh> and a wiki update?
[16:37] <bdmurray> thekorn: I think it did work as there is now a confirmed task
[16:37] <bdmurray> hggdh: maybe I was thinking mailing list / blog
[16:38] <thekorn> bdmurray, sorry, you are right
[16:40] <hggdh> bdmurray: probably the wiki should wait for after the discussion with slangasek
[16:40] <bdmurray> hggdh: right, I was just thinking saying don't nominated bugs unless they are confirmed
[16:40] <hggdh> bdmurray: +1
[16:42] <bdmurray> okay anything else about release nominations?
[16:42] <hggdh> not from me
[16:42] <thekorn> no
[16:42] <pedro_> nope
[16:43] <bdmurray> And any other agenda items to discuss?
[16:44] <yofel> how about backporting apport?
[16:44] <yofel> micahg: ping
[16:44] <micahg> yofel: pong
[16:44] <hggdh> micahg: can you expand on backporting apport?
[16:45] <micahg> hggdh: well, where possible add new feature/hooks that are useful in older releases
[16:46] <nigelb> micahg: basically backporting hooks to older releases?
[16:46] <bdmurray> apport depends on python-launchpadlib so that would likely get tricky
[16:46] <hggdh> is it a large dependency tree?
[16:47] <bdmurray> have a package that was a collection of backported package hooks would be neat
[16:47] <bdmurray> however, those might also depend on a newer version of apport if they call a general hook
[16:48] <sbeattie> you'd also want to be sure that the reason the package hook is different in the newer release is not because something in the package configuration (e.g. different logfile layout, etc.)
[16:48] <micahg> bdmurray: how about where possible?
[16:48] <hggdh> which releases would we target (if we get to do it)?
[16:48] <micahg> hggdh: LTSs
[16:48] <micahg> at least
[16:49] <bdmurray> micahg: I think its a neat idea and interesting but not something I'd work on directly.
[16:49] <micahg> one of the big problems in triaging bugs is trying to get info off of a harsystemdy
[16:49] <bdmurray> maybe it is something we could do for Lucid though
[16:49] <micahg> hardy system
[16:49] <bdmurray> so as new hooks come out in M add them to Lucid
[16:49] <nigelb> I can help with that :)
[16:50] <micahg> could package hooks also be allowed in SRUs
[16:50] <bdmurray> I mean really its Hardy and Lucid is almost here
[16:50] <hggdh> another thing to think on -- as bdmurray said, a package with the hooks, as opposed to hooks in each package
[16:50] <bdmurray> micahg: there is some cost to having an SRU just for a package hook - downloading the whole thing etc...
[16:51] <micahg> hggdh: that package would probably get updated frequently
[16:51] <micahg> bdmurray: maybe included with some other fix?
[16:51] <hggdh> yes, it will, but better than -- for example -- rebuild Evolution for a hook
[16:51] <bdmurray> micahg: right better one small package than all of X / firefox
[16:52] <hggdh> and all other large packages...
[16:52] <micahg> bdmurray: k, sounds good, but who maintains it?
[16:52] <bdmurray> ubuntu-bugcontrol in backports?
[16:53] <micahg> bdmurray: well, wouldn
[16:53] <micahg> t' that mean that it can't be shipped with the release?
[16:53] <micahg> and not everyone uses -backports
[16:54] <bdmurray> so an optional package in universe with updated version of the package hooks for apport
[16:54] <micahg> bdmurray: I'd say we need to discuss this on the -devel list
[16:55] <bdmurray> micahg: okay, could you start the discussion?
[16:55] <micahg> bdmurray: sure
[16:56] <micahg> but the problem with bugsquad maintaining the hooks is a lack of the package knowledge
[16:56] <micahg> I think that's one of the reasons there are hooks in the package
[16:57] <hggdh> this would not change
[16:57] <hggdh> it is just the target package that would change
[16:57] <bdmurray> micahg: I'm not following I think it would be as simple as watch the archive for new package hook.  Put package hook in meta-package.
[16:57] <micahg> hggdh: you can;t have two packages offering the same file
[16:58] <hggdh> no, you cannot. This is another thing to discuss with -devel. I frankly do not like having the hooks on each package
[16:58] <bdmurray> hggdh: it makes it so universe devels can add a hook to their one package without waiting on apport
[16:58] <micahg> hggdh: yes, but as I said it's usually the package maintainers that best know what should be in the hook
[16:58] <bdmurray> s/one/own/
[16:59] <hggdh> bdmurray: the universe devels could just forward the branch
[16:59] <hggdh> micahg: so could the maintainers
[16:59] <bdmurray> hggdh: still it becomes a bottleneck
[16:59] <micahg> hggdh: as it is, we;re short on core-devs
[16:59] <hggdh> more than now?
[17:00] <micahg> hggdh: exhibit A is the main sponsors queue :)
[17:00] <hggdh> LOL. The DA rests ;-)
[17:01] <micahg> it would be nice to be able to at least authorize in SRU inclusion an updated hook
[17:01] <micahg> and any apport features that aren't py-lplib specific
[17:01] <hggdh> obviously, this would require a lot of talking. But I still think it simpler to change a small package (with a low cost to build) than a whole complex one
[17:02] <bdmurray> and maybe we could stick them in /usr/share/apport/package-hooks/backported/
[17:02] <micahg> bdmurray: that's an idea...
[17:02] <hggdh> good idea, makes it more resistant to other unintentional consequences
[17:03] <micahg> then those can be in a single package :)
[17:03] <hggdh> defence rests...
[17:03] <hggdh> defense
[17:03] <micahg> still needs to be discussed on -devel list but this has a chance of being awarded by the jury :)
[17:03] <hggdh> yes
[17:04] <hggdh> next one?
[17:04] <bdmurray> I think that's all we have time for
[17:04] <hggdh> CoC signing requirement?
[17:04] <hggdh> oh, OK
[17:05] <nigel_nb> meeting officially over?
[17:06] <hggdh> nigel_nb: yes, I guess so. Left-over for next meeting
[17:06] <nigel_nb> hggdh: :)
[17:06] <nigel_nb> pedro_: got a min?
[17:07] <pedro_> nigel_nb, yes
[17:07] <nigel_nb> you had confirmed bug 401028, but the original bug was in telepathy-butterfly and the upstream task is also actually in telepathy-butterfly
[17:07] <pedro_> no bot?
[17:07] <ubot4> Launchpad bug 401028 in pymsn (Ubuntu Karmic) (and 4 other projects) "telepathy-butterfly crashed with TypeError in b64decode() (affects: 416) (dups: 27)" [Undecided,New] https://launchpad.net/bugs/401028
[17:07] <pedro_> ah just slow
[17:08]  * nigel_nb pets ubot4 :)
[17:08] <pedro_> looking nigel_nb
[17:08] <nigel_nb> :)
[17:10] <nigel_nb> bdmurray: any particular requirements to meet to be part of reviewers?
[17:10] <bdmurray> nigel_nb: no, not really
[17:10] <nigel_nb> bdmurray: I had applied, I guess you'll get to it.
[17:10] <bdmurray> nigel_nb: I actually can't add people
[17:11] <nigel_nb> oh
[17:11] <nigel_nb> Persia and I've worked with expanding the tags for review too.  Mailed you the conclusion of what could be a better workflow
[17:11] <bdmurray> I'll try and get that sorted
[17:11] <bdmurray> nigel_nb: right I need to reply to that but I think its overly complicated
[17:12] <nigel_nb> it sounds complicated, but its practical when you want to work on patches
[17:12] <nigel_nb> I was hitting debdiffs a lot of times
[17:13] <nigel_nb> we actually developed that workflow when I was doing patch review, based on each situation that I faced
[17:14] <bdmurray> okay, fine but have 6 or 8 tags seems like a bit much if you want people to participate in the process easily
[17:15] <nigel_nb> the idea is, it helps filter out bugs that area already dealt with
[17:15] <nigel_nb> or need not be reviewed by reviewers
[17:16] <pedro_> nigel_nb, done, I've closed the pymsn task
[17:16] <nigel_nb> pedro_: I would have done it, but I wasn't really sure :)
[17:17] <nigel_nb> pedro_: when I was going through the SRU, I quite confused
[17:17] <pedro_> nigel_nb, is ok, the bug is actually on papyon rather than at pymsn
[17:17] <nigel_nb> its on papyon
[17:18] <nigel_nb> while the pymsn bug may exisit, it is not related to papyon
[17:18] <nigel_nb> pymsn does not depend on papyon( at least as far as I could see)
[17:18] <nigel_nb> now the trouble is, a lot of people who says "Affects me too" may have said it for pymsn :(
[17:21] <pedro_> well i think the quantity of affected users are counted as a whole at the bug reports and not per task
[17:21] <nigel_nb> I know
[17:22] <nigel_nb> This means there might be a bug in pymsn too
[17:22] <nigel_nb> and that might not be fixed yet
[22:41] <hggdh> bdmurray: on it now
[22:43] <hggdh> bdmurray: "... it is possible comment on the branch in a merge ..." I am not sure what you wanted to state here
[22:44] <bdmurray> hggdh: fixed thanks
[22:47] <Hillshum> Bug #417757 is fixed, but people with similar symptoms keep complaining. What should be done?
[22:47] <ubot4> Launchpad bug 417757 in glibc (Fedora) (and 6 other projects) "[karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups (affects: 158) (dups: 17)" [Unknown,Confirmed] https://launchpad.net/bugs/417757
[22:51] <hggdh> bdmurray: some typos corrected. Also, you talk about ubuntu-core-devs and ubuntu-devs (and give examples with both). Are they interchangeable?
[22:51] <bdmurray> hggdh: yes for now
[22:52] <bdmurray> maybe I'll just use one in there
[23:18] <kklimonda> is there a master bug for all reports about missing mouseover tooltip for all applications ported to the appindicator?


[07:05] <dholbach> good morning
[09:39] <guardian> morning
[09:59] <lool> Morning
[10:08] <lool> StevenK: As your might have noticed, tinymail now needs to be built with libxul-embedding instead of -1.9
[10:08] <lool> StevenK: (With suitable bump in xulrunner-dev build-dep)
[10:10] <lool> StevenK: Also, I confirm you can drop -fPIC from CFLAGS now
[11:11] <StevenK> lool: Huzzah!
[12:38] <TeTeT> does anyone know if standard Ubuntu Desktop version does run on the Menlow with Poulsbo graphics out of the box?
[14:07] <InSearchOf> agoliveira, You around?
[14:07] <agoliveira> InSearchOf: Yes. What's up?
[14:08] <InSearchOf> is there anyway I can talk to you outside of IRC?
[14:09] <agoliveira> InSearchOf: is ICQ or Gtalk ok? I can give you my contact.
[14:09] <agoliveira> or email...
[14:09] <InSearchOf> 477584655
[14:09] <InSearchOf> ICQ
[14:09] <agoliveira> InSearchOf: Hold on...
[14:10] <agoliveira> InSearchOf: Added, waiting for your authorization
[14:11] <InSearchOf> done
[14:12] <agoliveira> InSearchOf: Call me if you need but bare in mind that I'm extrely busy this week as my vacations start saturday.
[14:12] <InSearchOf> ahhh...
[14:22] <InSearchOf> dholbach, you around?
[14:22] <dholbach> InSearchOf: yes
[14:23] <InSearchOf> is there anyway I can talk to you outside of IRC
[14:23] <InSearchOf> if you would rather talk in here that is fine
[14:24] <dholbach> InSearchOf: what can I help you with?
[14:24] <InSearchOf> I'm from pdaXrom... We run an OS made primarily for Sharp Zaurus, X11 based OS
[14:25] <InSearchOf> We were looking at making a change in our roadmap and someone from the team brought up UME
[14:26] <InSearchOf> and I'm seeing would would need to be done to combined our efforts and get the arm platform supported under UME
[14:26] <dholbach> InSearchOf: I'm not sure I'm the right person to talk to
[14:26] <dholbach> Mithrandir and davidm: can you reply to this? ^
[14:27] <InSearchOf> and when I say what would need to be done.... I mean I dont want to announce to the community that we are merging unless I get someones good graces to do so
[14:30] <agoliveira> dholbach: This is not actually a technical issue but community, that's why I asked him to talk to you.
[14:31] <dholbach> agoliveira: I can't setup arm buildds - that's an effort somebody in the mobile team should be driving
[14:31] <InSearchOf> well my team would handle the arm builds
[14:32] <InSearchOf> brb
[14:36] <agoliveira> dholbach: Ok, it's been some crossed lines here :) We can handle the tech problems, of course, I just asked him to join in the talk because he wants to know what's the currect aproach to start a comunnity project related to Ubuntu. He wants to make this "official" if there is such a thing.
[14:37] <dholbach> agoliveira: maybe it's a good idea to present this to the technical board as a community effort and go from there?
[14:37] <agoliveira> dholbach: That's what he wanted to know, how to proceed :) I'll talk to David first and go over from there, thanks.
[14:38] <dholbach> agoliveira: great
[15:30] <davidm> dholbach, agoliveira I'll grab this, just back from getting a flat tire fixed.
[15:31] <davidm> InSearchOf, at the moment we are focused on the Intel MID chipset at least until our initial release.
[15:31] <dholbach> davidm: I have deep sympathies with you :-/
[15:32] <davidm> dholbach, on which the tire or the initial release? ;-)
[15:33] <dholbach> davidm: both... :)
[15:33] <dholbach> davidm: http://daniel.holba.ch/greece/14-Patras/005-IMG_4644.JPG - that's what happened during my holidays :)
[15:34] <davidm> no fun, last night the coldest night of the year, I walk out to the flat, and an urgent task from my wife to get accomplished with a tight deadline.... No fun at all
[15:54] <InSearchOf> davidm, so merging projects isnt an option? or not yet since the primary focus is on the MID chipset
[15:57] <davidm> At the moment the mobile team is focused on getting the first release out the door, and that is on the Intel MID for the moment, but most all of our work is public so you can work with it if you want to.
[15:58] <davidm> But for the moment I have a small team and I have to keep my eye on MID for the moment.
[16:02] <InSearchOf> well currently our dev team can focus on the hardware and core development... it would be the gui components that would merge
[16:03] <guardian> i have a quick question
[16:03] <guardian> should i stick with my current image (gutsy) or should i change the repos ?
[16:14] <agoliveira> InSearchOf: My sugestion would be that you get a working kernel and create an arm-based crosscompilation enviroment (maybe something based on Maemo's sandbox?) and see what happens.
[16:15] <InSearchOf> alright.. well I mean our current crosscomplitation env. works...  will it have to be Maemo?
[16:16] <agoliveira> InSearchOf: Not at all, I just suggested as something to look at as our base GUI is hildon that came from Maemo.
[16:17] <InSearchOf> and the reason I'm asking so many questions is because I put our development on hold...
[16:17] <InSearchOf> waiting for an answer back...
[16:20] <agoliveira> InSearchOf: we will try to help but, as I said, you got us in a very bad time as we are all entering on vacations in 2 weeks and myslef in 1 so we are very busy right now.
[16:22] <InSearchOf> agoliveira, well... I will just keep things on hold. which isnt a problem... I will look into how we would approach the getting things to work.
[16:23] <agoliveira> InSearchOf: Your idea will be proposed to the technical board and I don't see w areason to not be aproved but that will have to wait until January unfortunately.
[16:25] <InSearchOf> agoliveira, that is 100% fine. We aren't looking to move fast... but communication was what I was looking for and I got it.
[16:25] <agoliveira> InSearchOf: Whatever we can do, just come in and ask. We will try to help, that's for sure.
[16:26] <wasabi> So curiously, what makes this inappropiate for the N810?
[16:27] <wasabi> Just size, aka nonwillingness to strip out stuff like perl, etc?
[16:27] <wasabi> And/or lack of packages for the binary crap in Maemo?
[16:28] <mjg59`> And also the hassle of getting kernel support into our tree
[16:28] <agoliveira> wasabi: The lack of openness regarding parts of Nokia tablets, for one.
[16:28] <wasabi> Yeah. Pretty much what I guessed.
[16:28] <wasabi> Alas!
[16:29] <agoliveira> mjg59`: Hey Mathew. I thought that you would be away for some time.
[16:29] <wasabi> Would be nice if Nokia were to work on rebasing to Ubuntu. ;)   Their hacked up Debian cannot be a joy to maintain.
[16:29] <mjg59`> agoliveira: Yeah, on a train right now
[16:29] <mjg59`> THough just arriving
[16:29] <mjg59`> I have just over a week to get this finished, then I'm taking a holiday
[17:11] <lool> InSearchOf: So what would you be providing for an ARM port?  I guess the basic things are buildd hardware, not sure whether these need to be hosted and maintained by Canonical staff (could be a requirement), porting and bootstrapping work (bootstrapping the toolchain, updating dpkg, kernel configs etc., goind through build-dep loops etv/)
[17:11] <lool> And then there's day to day buildd admin, and actual porting of the build failures I guess
[17:20] <InSearchOf> lool,  all builds current run under our own env.  we use ptxdist.. as our builder.
[17:22] <InSearchOf> we have an x86 based live cd that contains all the binaries required to run a full successful build... from building to initial cross compiler...
[17:23] <InSearchOf> from there you can build the image you desire containing all selected apps you want in the build
[17:25] <InSearchOf> I also have sashz (another dev form the pdaxrom team) in the room if you have any questions he is here to respond
[17:31] <lool> InSearchOf: ptxdist is another story; of course you can package ptxdist for Ubuntu and run it under Ubuntu if you like, but the current UME builds are not using this particular build system / rootstrap generation system
[17:31] <lool> InSearchOf: You seemed to be looking at whether Ubuntu would be having ARM support because you target arm; my natural followup question is: what would you be providing for this to happen
[17:33] <lool> ATM, my understanding is that Ubuntu buildds are bought by Canonical and run by Canonical; which is why I wonder what an ARM port would actually need to happen: hardware for sure, but some buildd admins, hosting etc.
[17:33] <lool> And if it's an ubuntu.com or canonical.com port, then this might imply that Canonical runs and owns the buildds
[17:47] <InSearchOf> lool, well when you say hardware do you mean for hosting? or for building?
[17:49] <InSearchOf> we can move our build system over to the standard build system used by Ubuntu, there will be a bit of a learning curve... but it can be done
[17:50] <InSearchOf> but we would initially be able to host our own developement server for the initial configuration (till we get the bugs worked out in the merger)
[17:52] <InSearchOf> and over time we would mesh into UME and our team would focus on getting the underlying OS (kernel/hotplug/apm/etc) functioning and the top lay be UME
[17:52] <InSearchOf> layer* being*
[17:54] <lool> InSearchOf: I mean hardware for building
[17:55] <lool> InSearchOf: Not sure you know about it, but Ubuntu has buildds for many arches already; all are run by Canonical people I think
[17:55]  * lool goes for dinner
[17:57] <InSearchOf> lool,  we can merge our data into your system, that is not a problem at all.


[00:27] <rick_h_> hatch: ugh, ok let's chat in the morning and get a plan together
[00:28] <hatch> +1
[00:28] <rick_h_> our brains need to rest a bit tonight :)
[00:29] <hatch> hah rick_h_  I think the CI is stuck
[00:29] <rick_h_> looking
[00:29] <hatch> I'm not entirely sure what it's even running
[00:30] <rick_h_> all good, killed it. It's done that once/twice before
[00:30] <rick_h_> just login and you can stop the in progress job
[00:30] <hatch> ohh ok cool thanks
[01:11] <gary_poster> so long everybody!  I'll miss you. :-)
[11:19] <rick_h__> morning
[11:31] <hazmat> rick_h__, g'morning
[11:40] <rick_h__> hazmat: still an early bird? little ones not sleeping in for you yet?
[11:42] <hazmat> rick_h__, today was all me.. up at 2 sore throat, and lots to do.
[11:42] <rick_h__> ugh, /me sends some meds down your way
[13:27] <rick_h__> morning hatch
[13:27] <hatch> morning
[13:49]  * benji_ takes the car to the shop.
[14:01] <hatch> rick_h__ so thoughts on upping the timeout and putting that chrome bug link?
[14:01] <rick_h__> hatch: yea, let's chat. I've got a few notes to run through
[14:02] <hatch> ok coffee is on, 2 mins
[14:02] <hatch> :0
[14:02] <hatch> :)
[14:02] <rick_h__> doh
[14:02] <rick_h__> ok, shoot me a link
[14:03] <hatch> bleh it's taking forever https://plus.google.com/hangouts/_/76cpjp39uok6fu53clukspafeg?hl=en
[14:27] <rick_h__> hatch: I can dupe :(
[14:27] <hatch> that seems like a blocker, no?
[14:27] <hatch> :(
[14:27]  * hatch was really hoping it was his branch
[14:28] <rick_h__> hatch: it means it goes to 'feature flagged' :/
[14:28] <rick_h__> so we can still release pretty relation lines for MWC demos
[14:28] <rick_h__> and they can demo in chrome ok
[14:28] <hatch> do we want to 1.0 without local charms?
[14:28] <rick_h__> no, it'll have it, just not public. We won't blog/etc it
[14:28] <rick_h__> but the MWC people can demo it
[14:28] <hatch> I am not sure pretty relation lines are 1.0 worthy :)
[14:29] <rick_h__> yea, true I guess
[14:29] <rick_h__> so maybe it's just another rev, but we need a release for MWC
[14:29] <hatch> no offence to the pretty lines of course :D
[14:29] <hatch> oh yeah I totally agree
[14:30] <rick_h__> hatch: any chance you can look at that today and work on the upgrade afterwards?
[14:31] <rick_h__> hatch: if it's a quick fix maybe we can get it in a release today for monday?
[14:31] <hatch> yep I can, although frankban  wrote it, he might be faster if he has the bandwidth
[14:31] <hatch> if not, I can get on it
[14:31] <rick_h__> we know the upgrade story will take on
[14:31] <rick_h__> but created #1283067
[14:31] <_mup_> Bug #1283067: dropping a local charm in Firefox does not deploy it into the sandbox <juju-gui:Triaged> <https://launchpad.net/bugs/1283067>
[14:32] <rick_h__> frankban: do you have the time to peek at this bug and see if there's a quick fix we can get today for release? ^
[14:32]  * hatch grabs his coffee
[14:33] <frankban> rick_h__: yes I'll take a look
[14:33] <rick_h__> thanks frankban
[14:33] <hatch> cool,
[14:33] <benji_> rick_h__: I had hoped sleeping on it would provide more insight, but I can't get the multi-field indexing approach to work (well it doesn't break anything but it doesn't do what we want), so I'm afraid doing this quickly is a bust.  We need to learn more about ES.
[14:34] <rick_h__> benji: ok, did you and bac get a chance to catch up yesterday?
[14:34] <rick_h__> benji: he's going to be out Mon/Tues so if we can get that doctype search working for Monday deploy that'd still be a partial win
[14:35] <benji> since he was going to be out early next week I figured if I got this working it would have to be someone else so I didn't talk to him.  I wasn't aware that I would be taking his branch.
[14:35] <rick_h__> yea, understood. 0/2 for monday
[14:37] <benji> rick_h__: I bet I can figure out his branch though; should I pick that up next?
[14:37] <rick_h__> benji: I was just looking to see if he pushed up anything before he left
[14:37] <rick_h__> I'm not seeing anything other than his https://code.launchpad.net/~bac/charmworld/improve-bundle-search/+merge/207290
[14:38]  * benji looks
[14:38] <rick_h__> benji: if you can run with it and get that up and going I'd appreciate it. I can get a charmworld deploy done monday and that would be nice to have
[14:40] <rick_h__> benji: yea, see how far you can get. I might be able to run with it some this weekend so let's make sure to catch up before your EOD and hangoff to me.
[14:40] <benji> rick_h__: that doesn't look like the latest code.  He asked me to review that branch on Wednesday and I noted that it didn't actually do what the card was about.  He then began working on it some more.  I can take it from that branch (or perhaps start over, since it isn't on-target) but it'll be rework.
[14:41] <rick_h__> benji: yes, understood. It'll be rework and can't be helped without delaying into Wed or later next week in which case we'll miss the MWC demo time this was asked specifically for.
[14:41] <benji> will do
[14:41] <rick_h__> thanks
[14:49] <hatch> rick_h__ we are going to have to parse the zip contents - on a real env we would need to store the zip filename in the annotations otherwise
[14:52] <hatch> so unfortunately that part is kind of an all-or-nothing approach
[14:58] <rick_h__> hatch: what's wrong with the annotation? I'm confused
[14:59] <rick_h__> benji: one heads up, when brad and I talked the one thing that came out was that the api search and the website search are two code paths
[14:59] <rick_h__> benji: and that a "" search in the api returns all results
[14:59] <hatch> well they get sent along with every request, so it bulks up the requests and it's pretty clunky
[14:59] <hatch> at least imho
[14:59] <benji> yep
[14:59] <rick_h__> while that did not seem true on the website search
[14:59] <rick_h__> benji: cool
[15:00] <rick_h__> hatch: ok, well it was on the roadmap for the feature anyway
[15:00] <hatch> which?
[15:00] <rick_h__> hatch: the zip to help find service by name not zip filename
[15:00] <hatch> ohh yeah - I'm hoping that the sandbox api can be repurposed
[15:00] <hatch> I'll look into that first
[15:00] <rick_h__> hatch: but let's make sure we shortcut, if we dont' have any local charms in the env we can skip it still
[15:01] <hatch> oh yeah for sure
[15:01] <rick_h__> k
[15:01] <rick_h__> friday is not liking us today is it
[15:01] <hatch> this week has just been frustrating all over :)
[15:02] <rick_h__> yea, suppose so
[15:02] <hatch> I need an idea for a Go lang project
[15:04] <hatch> get my head outa js for the weekend
[15:04] <rick_h__> heh, I'll send you my list over
[15:04] <hatch> haha I'm looking for small projects
[15:04] <hatch> maybe a week of personal time sort of things
[15:05] <hatch> benji what was wrong with your car?
[15:05] <rick_h__> hatch: yea, charm proof would be a small something to check out doing. I was thinking of doing my small readable web service in Go as an experiment and test scale
[15:05] <benji> it has a coolent leak (and needs some brake work)
[15:06] <hatch> shitty, what kind of car?
[15:06] <hatch> rick_h__ oh Go can handle scale :)
[15:07] <hatch> charm proof in Go? Isn't it written in python already?
[15:07] <rick_h__> hatch: yea, just mean a good example project to 'port' and compare
[15:07] <hatch> ohh gotcha
[15:07] <hatch> that might not be a bad idea
[15:10] <hatch> maybe I'll write a Bookie competitor in Go :P
[15:10] <hatch> jk
[15:13] <rick_h__> hey, more power to you
[15:14] <hatch> it could be called Gookie
[15:14] <hatch> lol
[15:16] <hatch> rick_h__ http://nightwatchjs.org/ nodejs selenium driver api
[15:16] <hatch> it 'looks' simpler than our python one
[15:19] <rick_h__> hatch: hmm, but this is a selenium server and we use saucelabs for that
[15:19] <rick_h__> https://github.com/beatfactor/nightwatch/issues/53
[15:20] <hatch> oh shoot I misread
[15:20] <hatch> I thought that it interacted with a selenium server
[15:20] <rick_h__> it IS the server
[15:20] <rick_h__> is how I read it
[15:20] <hatch> well it does...but right heh
[15:22] <hatch> teach me for not reading before sharing
[15:39] <hatch> benji hey when you had your git rebase issues did you try creating a patch and applying that on a new branch?
[15:40] <rick_h__> hatch: I tested things out. The key is that if you updated your branch to latest develop to do 'git rebase develop' and all your commits get layered nicely
[15:40] <hatch> rick_h__ following along in #yui?
[15:40] <rick_h__> hazmat: did that on https://github.com/juju/juju-gui/pull/139
[15:41] <rick_h__> hatch: oh no, /me goes to look
[15:41] <rick_h__> hatch: yea, use rebase when push upstream changes into topic branch
[15:41] <rick_h__> that works nicely
[15:41] <benji> hatch: I considered it, that may have even been the final solution; I can't remember exactly.
[15:42] <hatch> rick_h__ well remember benji's issue with a bunch of wips and merges from develop
[15:42] <hatch> I was hoping for a reasonable 'fix' and it looks like creating a patch file is the best
[15:42] <rick_h__> yea, I mean I've done both. Created a new branch from develop and cherry pick.
[15:42] <hatch> rick_h__ so then what are we talking about re the rebase develop if you weren't following along in yui :)
[15:42] <rick_h__> that went ok, but tedious
[15:42] <rick_h__> no, I wasn't at the time
[15:43] <rick_h__> I was just replying to your questoin to benji
[15:43] <rick_h__> as it was something I wanted to test out and just had cause with the safari CI branch since it hung for a week there
[15:43] <hatch> ohhh ok ok
[15:43] <hatch> so you had commit commit merge commit commit ?
[15:43] <hatch> and doing a rebase against develop removed the merge commit?
[15:43] <rick_h__> so I updated my safari branch with latest develop first `git co develop; git juju-sync; git co $mybranch; git rebase develop
[15:44] <rick_h__> it didn't remove it, it avoided it
[15:44] <rick_h__> a merge commit is a merge commit. It's now part of the history
[15:45] <rick_h__> hatch: so https://github.com/juju/juju-gui/pull/139 had a rebase on develop in there, two rebases for lint/etc during review. looks clean :)
[15:45] <frankban> rick_h__, hatch: quick fix for bug 1283067 ready for review -> https://github.com/juju/juju-gui/pull/140
[15:45] <_mup_> Bug #1283067: dropping a local charm in Firefox does not deploy it into the sandbox <juju-gui:Triaged by frankban> <https://launchpad.net/bugs/1283067>
[15:45] <rick_h__> frankban: looking
[15:45] <frankban> thanks
[15:46] <hatch> rick_h__ so how did you get rid of the merge commit there then? the rebase on develop got rid of it?
[15:46] <hatch> s/on/from
[15:46] <rick_h__> hatch: you're saying to get rid of something taht exists
[15:46] <rick_h__> I'm saying that you need to avoid the merge commit to start with by using rebase vs merge
[15:46] <hatch> well in #139 it looks like you did
[15:46] <hatch> there is no merge commit in there
[15:46] <rick_h__> right
[15:47] <rick_h__> I avoided it by doing a git rebase develop
[15:47] <rick_h__> that's how I updated my long running feature branch
[15:47] <rick_h__> hatch: follow? or am I still talking nuts?
[15:48] <hatch> ok so you didn't 'merge' develop in...you rebased it in
[15:48] <rick_h__> hatch: rgr
[15:48] <hatch> me likey
[15:49] <hatch> ok so from what I understand the 'best' way to fix benji 's issue is to use a patch and git 'should' ignore the parts of the diff that are unchanged in upstream
[15:49] <hatch> but the proper way to do it is to rebase upstream in
[15:49] <hatch> upstream in this case being develop
[15:49] <rick_h__> hatch: right
[15:50] <rick_h__> hatch: correct, you should be able to git rebase develop over and over in a long running branch safely, fixing conflicts between trunk and your WIP as you go
[15:50] <rick_h__> jujugui call in 10
[15:51] <rick_h__> frankban: yay works. Want me to :shipit:?
[15:51] <frankban> rick_h__: yes thanks
[15:52] <hatch> stupid browser differences
[15:52] <hatch> frankban how did you figure out that that was necessary?
[15:53] <rick_h__> hatch: there's a bug in zip.js called out in the code
[15:53] <frankban> hatch: ff debugger + feeling lucky with google
[15:53] <rick_h__> lol "I feel lucky, oh so lucky"
[15:54] <rick_h__> nice diff to use that whitespace flag feature on as well <3
[15:54] <frankban> yes indeed
[15:55] <hatch> frankban ok cool :) I was hoping that there might have been some cool technique or something :P
[16:00] <rick_h__> jujugui call now
[16:18] <hatch> frankban have a quick second now to run through my questions?
[16:18] <hatch> https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
[16:19] <frankban> hatch: sure, be there in a minute
[16:26] <frankban> hatch: I am there
[16:34] <Makyo> rick_h__, you mentioned copying me on an email, but having a hard time finding it.
[16:34] <Makyo> What was the subject?
[16:35] <rick_h__> Makyo: sec, it was a document. Looking
[16:36] <Makyo> rick_h__, oh, oops.  Will check.
[16:36] <Makyo> There it is.
[16:36] <Makyo> Sorry, got it :)
[16:36] <rick_h__> Makyo: https://docs.google.com/a/canonical.com/document/d/1ma0U1ZxILTh5s3NoHiuwKiclRSxJLIY-Q2MEMzBO7Dk/edit
[16:36] <rick_h__> Makyo: cool, adding the link to the card as well
[16:40] <Makyo> Cool, thanks.
[16:40]  * Makyo restart for updates.
[16:54] <hatch> http://vimeo.com/58200103
[17:25] <hatch> anyone else excited to see pictures of Pluto?
[17:25] <hatch> like 4 serious!
[17:25] <hatch> :)
[17:33] <rick_h__> we're getting pics of pluto?
[17:36] <hatch> well in a year probably
[17:37] <hatch> http://pluto.jhuapl.edu/index.php
[17:37] <hatch> 9.5 year trip or something hah
[17:47] <hatch> jujugui looking for a really quick review on https://github.com/juju/juju-gui/pull/141 no qa needed
[17:48] <benji> hatch: I'll take a look
[17:48] <hatch> thanks
[18:07] <hatch> rick_h__ do you know where I can find the aforementioned charm-proof repo?
[18:30] <rick_h__> hatch: it's in charm-tools
[18:30] <hatch> ohh duh
[18:31] <hatch> I'll take a look at the Go conversion....if you don't mind
[18:31] <rick_h__> woot, got the ok for the 1.0 release go go
[18:31] <rick_h__> hatch: yea, definitely.
[18:32] <hatch> cool, I have no idea what will come out of it
[18:33] <rick_h__> yea, just something small to tinker with
[19:06] <hatch> so I just looked at it
[19:06] <hatch> it's actually pretty sizeable
[19:06] <hatch> once you include the scripts for actually parsing the stuff
[19:06] <hatch> good couple thousand lines
[19:07] <hatch> which is fine
[19:07] <hatch> I had assumed it would be smaller for whatever reason
[19:38] <rick_h__> now to play "run those functional charm tests!"
[19:39] <benji> to the tune of Play That Funky Music
[19:40] <rick_h__> "get down and boogy and let functional tests pass"
[19:40] <benji> lol
[19:43] <rick_h__> boom and fail
[19:43] <rick_h__> doh
[19:46] <hatch> lol
[19:46] <hatch> it seems anything with 'charm' in it blows up for us
[19:46] <hatch> charmworld
[19:46] <hatch> charm tests
[19:46] <hatch> :P
[19:46] <hatch> lets rename them to trinkets
[19:47] <rick_h__> ERROR empty image-stream in environment configuration
[19:47] <rick_h__> ummm, ok
[19:47] <hatch> uhh what
[19:48] <rick_h__> yea, that's my thought
[19:49] <hatch> Makyo new OneTab record here ....276
[19:49] <hatch> and about 15 more tabs open lol
[20:15] <rick_h__> Makyo: did you have a card today? Were you looking at the video or something else?
[20:15]  * rick_h__ was just kanban gardening while waiting for live tests wheeeee
[20:21] <hatch> I found two really cool sublime plugins, gitgutter and git
[20:21] <hatch> gitgutter shows the changes in your file in the line gutter
[20:21] <hatch> and git gives you git commands in sublime
[20:21] <hatch> sublime > terminal is kind of a pita when you only want to see diffs and stuff
[20:23] <rick_h__> hatch: or Makyo able to help me test this please?
[20:23] <hatch> sure what do you need
[20:23] <rick_h__> preferably non trusty
[20:23] <hatch> I have 12.04
[20:24] <rick_h__> hatch: I pull down lp:~rharding/charms/precise/juju-gui/1.0 and see if you can make test including the live ec2 tests
[20:24] <hatch> sure
[20:25] <hatch> bzr checkout --lightweight should be the default :)
[20:25] <hatch> bzr branch pssshhht
[20:25] <benji> rick_h__: ready for handoff?  I think all we need is review and QA and it'll be done.
[20:25] <rick_h__> benji: sure thing
[20:26] <hatch> rick_h__ running `make test`
[20:26] <rick_h__> benji: https://plus.google.com/hangouts/_/72cpiv9f3hglut66ffdl7mq950?hl=en
[20:26] <rick_h__> hatch: thanks
[20:29] <rick_h__> hah, he runs make test and then loses his internet connection
[20:29] <rick_h__> "thou shall not release!"
[20:32] <hatch> rick_h__ https://gist.github.com/hatched/cba361ff581bf4d51a6d this is the error I get
[20:34] <Makyo> rick_h__, sorry, yeah, video. Have IRC open on the wrong laptop :(
[20:34] <rick_h__> hatch: did you run 'make sysdeps"
[20:34] <hatch> nope i'll try that
[20:35] <rick_h__> hatch: yea, run that first and then make ftest JUJU_ENV="ec2" or whatever your ec2 env is named
[20:35] <hatch> unable to locate libpython-dev
[20:35] <rick_h__> hatch: sudo apt-get install libpython-dev
[20:36] <rick_h__> oh, you don't have it on precise?
[20:36] <hatch> yeah that package doesn't exist
[20:36] <rick_h__> looking
[20:36] <hatch> what's the equivalent for precise?
[20:36] <hatch> pffft python portability issues
[20:36] <hatch> :P
[20:36] <rick_h__> try just 'python-dev'
[20:37] <rick_h__> but make sure you catch the rest of the sysdeps in the Makefile
[20:38] <hatch> already the newest version
[20:38] <hatch> will look at the other deps
[20:38] <rick_h__> k
[20:38] <rick_h__> sudo apt-get install build-essential bzr libapt-pkg-dev python-virtualenv rsync xvfb
[20:39] <hatch> libapt-pkg-dev looks like it was missing
[20:39] <hatch> will see if that was the issue
[20:39] <rick_h__> k
[20:40] <hatch> looks like that was the kicker
[20:40] <hatch> whatever it's for
[20:40] <rick_h__> hatch: cool, it'll run for a while hopefully
[20:41] <hatch> well it apparently doesn't like my JUJU_ENV value
[20:41] <rick_h__> hatch: right, it needs to be whatever you call your ec2 env in your environtments.yaml file
[20:41] <rick_h__> I call mine ec2
[20:42] <hatch> https://gist.github.com/hatched/cd5196ac5b83cc4bf231
[20:42] <rick_h__> ok
[20:42] <benji> rick_h__: I did some basic QA and it looks good.  Here's the MP: https://code.launchpad.net/~benji/charmworld/doctype-search/+merge/207738
[20:42] <rick_h__> make ftest JUJU_ENV="amazon"
[20:43] <rick_h__> benji: awesome, will look when I get this deploy up and done.
[20:43] <benji> cool
[20:43] <hatch> ok will try that
[20:43] <hatch> lol juju-test is missing now
[20:43] <hatch> I'm just going to read this hacking file to see what I am missing
[20:44] <rick_h__> lol ok
[20:44] <rick_h__> yea you need charm-tools
[20:44] <rick_h__> sorry, didn't realize you'd not messed with the charm
[20:45] <hatch> not on this vm I guess
[20:45] <hatch> best way to install charmtools?
[20:45] <rick_h__> sudo apt-get install charm-tools
[20:45] <hatch> installing from ppa now
[20:45] <rick_h__> do you have the stable ppa?
[20:46] <hatch> yay finally
[20:46] <hatch> looks like it's starting the env
[20:46] <rick_h__> yay
[20:50] <rick_h__> benji: does this require the : or is it optional?
[20:51] <benji> rick_h__: required; I figured the structure was a better way to go, but it would be easy to make it optional
[20:51] <rick_h__> benji: ah, see in the tests that they both work cool
[20:51] <benji> well the bare words work, but if you have terms after the word you have to have a colon
[20:51] <rick_h__> benji: well just 'bundle' works for all bundles in the test
[20:51] <benji> right
[20:51] <rick_h__> right, the bare words are what I was worried about. That's the main use case
[20:51] <benji> cool
[20:51] <rick_h__> the : identifier is more advanced optional
[21:01] <rick_h__> hatch: still running?
[21:08] <hatch> yup
[21:08] <hatch> there has been an error though
[21:09] <rick_h__> :(
[21:09] <hatch> https://gist.github.com/hatched/9143581
[21:09] <hatch> doesn't give me any information as to what failed yet though
[21:09] <rick_h__> yea, will have to wait for them to finish
[21:10] <hatch> sorry my internet is very slow right now for whatever reason
[21:10] <rick_h__> you had one 'ok' thuogh so that's more than me
[21:10] <rick_h__> it takes a while
[21:10] <hatch> lol I'm guessing that 1.0 is not being released today? :)
[21:10] <rick_h__> depends on what your errors say
[21:14] <hatch> rick_h__ https://gist.github.com/hatched/a9f7df762c14e797fbc1
[21:15] <rick_h__> hatch: what's your juju version? juju --version
[21:15] <hatch> 1.17.1
[21:15] <hatch> precise
[21:16] <hatch> it's `juju version` btw :P
[21:16] <rick_h__> heh
[21:16] <hatch> that's the Go way
[21:16] <hatch> lol
[21:16] <hatch> unless they fixed that
[21:16] <rick_h__> well --version works
[21:16] <rick_h__> it's what I've been using
[21:16] <rick_h__> hatch: can you test one more thing then please?
[21:17] <rick_h__> can you stick that directory inside a directoy named precise and try to install it and check the unit log?
[21:18] <hatch> oh ok they must have fixed it
[21:18] <hatch> install it in a real env?
[21:18] <rick_h__> yes please
[21:19] <hatch> sure thing
[21:19] <rick_h__> if the tests fail and the unit was in error it'd be helpful to find out what the error is
[21:19] <hatch> bootstrapping
[21:19] <rick_h__> I can't deploy right now, there's some issue core is looking into
[21:19] <rick_h__> thanks
[21:19] <hatch> lxc bootstrap is so much faster
[21:19] <hatch> lol
[21:19] <rick_h__> sorry to distract you. I'll start working on setting up a precise vm to work around the current issues
[21:19] <rick_h__> heh no doubt
[21:19] <hatch> no problem I needed a break from local charm anyways
[21:19] <rick_h__> hatch: you can test it there as well I guess. Maybe it does error in lxc
[21:20] <hatch> so you get me to deploy a local charm....damnnnn youuu
[21:20] <hatch> lol
[21:20] <rick_h__> lol
[21:20] <hatch> ahh it's ok the ec2 setup is already running
[21:20] <rick_h__> but if the tests says it's in error I need to know what error to try to see what's not happy in the charm
[21:21] <hatch> yup I'll keep you posted
[21:21] <rick_h__> thanks, /me goes to get a refill...come on EOD
[21:21] <rick_h__> going to have to start my birthday party drinking early after today
[21:22] <hatch> it's your bday?
[21:22] <hatch> well why didn't you say something!
[21:22] <rick_h__> tomorrow
[21:22] <hatch> well then! Happy early Bday
[21:22] <rick_h__> hah
[21:22] <rick_h__> thanks, where's the wine?
[21:23] <hatch> I'd say you could watch the USA Olympics hockey game tomorrow, but you guys lost :P
[21:23] <rick_h__> I hear it wasn't a very good game all around
[21:24] <hatch> I haven't heard much except my friends who care about hockey texted me lol
[21:25] <hatch> ERROR cannot repackage charm: symlink "tests/.venv/include/python2.7" is absolute: "/usr/include/python2.7"
[21:25] <hatch> have you seen that before?
[21:25] <hatch> running make clean
[21:25] <rick_h__> make clean on the new copy
[21:26] <hatch> ahh that appears to have fixed it
[21:36] <hatch> rick_h__ 2014-02-21 21:31:15 INFO install     raise ValueError('Error: no releases found in the charm.')
[21:36] <hatch> that would be an issue :)
[21:36] <rick_h__> ok, so do me a favor. this is what I was thinking
[21:36] <hatch> favour
[21:36] <hatch> :P
[21:36] <rick_h__> in the releases folder change the version from 1.0 to 1.0.0
[21:36] <hatch> ok changing
[21:36] <rick_h__> I wonder if that's what I'm hitting
[21:37] <hatch> wait....do you want me to do that in the deployed one and retry? or from ground 0
[21:37] <rick_h__> in the local copy and redeploy the charm
[21:37] <hatch> alrighty
[21:37] <hatch> will ping
[21:37] <rick_h__> mv releases/juju-gui-1.0.xz releases/juju-gui-1.0.0.xz
[21:38] <hatch> juju-gui-1.0.xz ?
[21:38] <hatch> I've never seen that extension before
[21:38] <hatch> odd
[21:38] <rick_h__> its ok
[21:38] <rick_h__> it's our special super compression extension. It's rare
[21:39] <hatch> ohh ok :) what does it use?
[21:39] <Makyo> xz :)
[21:39]  * Makyo : jerk.
[21:39] <rick_h__> http://tukaani.org/xz/format.html
[21:40] <hatch> lol SORRY
[21:40] <hatch> I'm doing three things at once here haha
[21:40] <Makyo> It is 100% a Friday.
[21:40] <rick_h__> friday release day!
[21:40] <rick_h__> boom!
[21:40] <Makyo> Woooo...ooo...oo~
[21:42] <hatch> lol we said we would never do that!
[21:42] <rick_h__> well it was supposed to be easy. I think the issue is I left off a .0
[21:42] <rick_h__> just hitting a juju bug causing me to not get passing tests
[21:43] <rick_h__> if this works we're back in business
[21:47] <hatch> rick_h__ started
[21:48] <rick_h__> hatch: woot
[21:48] <rick_h__> so now to rerun the tests for one final check
[21:48] <hatch> oh kay
[21:49] <hatch> runnning
[21:49] <rick_h__> ty much
[21:54] <rick_h__> hatch: have to run and get the boy from day care. Back in 20ish
[21:54] <hatch> no prob
[21:54] <hatch> I'll ping with the results
[22:14] <rick_h__> hatch: getting some OK's ?
[22:14] <hatch> yup rockin the ok's
[22:14] <rick_h__> yay!
[22:14] <hatch> not done yet though
[22:15] <rick_h__> cool, all good
[22:15] <rick_h__> thanks for the help
[22:30] <hatch> rick_h__ passed with flying colours
[22:30] <hatch> well...if the terminal wasn't black and white
[22:30] <rick_h__> hatch: awesome, released
[22:30] <rick_h__> thanks!
[22:31] <rick_h__> we hit 1.0!
[22:31] <rick_h__> now if ES on charmworld didn't go boom we might see it ingested sometime today :/
[22:36]  * Makyo dogwalk
[22:51] <hatch> rick_h__ maybe we need to invest some resources on getting GOOD at ES
[22:51] <hatch> like a few books or something to some people :)
[22:51] <rick_h__> hatch: yea, no kidding
[22:52] <hatch> conveniently you're in the unique position to authorize such expenditures lol
[23:11] <hatch> finally got the sublime gist plugin all configured properly on this machine
[23:11] <hatch> yay
[23:11] <Makyo> hatch, I nominate you to be the ES guru.
[23:11] <hatch> Makyo my brain is running out of guru room
[23:11] <hatch> lol
[23:11] <hatch> it didn't have much to begin with
[23:11] <Makyo> Just set YUI aside for a bit... :)
[23:12] <hatch> haha it's been slowly sliding to make room for Go and Python
[23:12] <hatch> I'm not sure if I can put ES in there, maybe tucked in a corner somewhere
[23:12] <Makyo> Gooooo *fistshake*
[23:12] <hatch> haha
[23:12] <Makyo> Been tinkering with Coffeescript in freetime. I kinda like it.    Fun, but would make management hard.
[23:14] <Makyo> Well, it still reeks of JS/.
[23:14] <Makyo> It's not quite its own thing yet.
[23:14] <hatch> lol
[23:14] <hatch> this weekend I might try and create a juju gui sublime text plugin
[23:14] <Makyo> How would that work?
[23:14] <hatch> have all the make targets keybound :)
[23:15] <hatch> `ctrl+j,l` could run the linter
[23:15] <hatch> for example
[23:15] <Makyo> Oh, hey, that could be neat.
[23:16] <hatch> it has a 'build' option built in, but we need more targets than that
[23:16] <Makyo> I just have multiple terminal tabs and use Ctrl+R :P
[23:16] <hatch> the plugins are in python too so would give me some python practice
[23:16] <hatch> haha yeah so do I lol
[23:16] <Makyo> Yeah, that's cool.
[23:17] <hatch> I found this good Git plugin which allows you do do all the git stuff with keybindings
[23:17] <hatch> and it shows you the modified rows in the code
[23:17] <hatch> I can now properly save a selection, file, multiple files, etc to a gist from sublime
[23:18] <hatch> so with a quality juju gui plugin maybe I won't need to open the terminal
[23:18] <hatch> lol
[23:18] <hatch> the terminal is fast...but keybindings are faster :)
[23:20] <hatch> Makyo you're a vim user, correct? With Gary gone am I now the only ST2 user?
[23:21] <Makyo> I alternate.  Vim for JS/Coffee, alternate for Python, ST2 for Go.
[23:21] <hatch> ahh with https://github.com/DisposaBoy/GoSublime ?
[23:21] <Makyo> I think so?
[23:21] <Makyo> 1sec.
[23:22] <Makyo> Ahoor.
[23:22] <Makyo> Shoot, I mean.
[23:22] <Makyo> My copy of sublime expired.
[23:22] <Makyo> I think that's it, though.
[23:22] <hatch> cool
[23:23] <hatch> I think it just gives you notifications now that it's expired unless you get a key
[23:23] <hatch> it's been so long, I bought a key a while ago
[23:23] <Makyo> This has happened a few times.  Works if I just redownload.
[23:23] <hatch> ohh ok cool
[23:26] <Makyo> Hmm, it may not be that package, not sure.  Mostly just used completion and the gofmt-on-save features.
[23:29] <Makyo> Oh, yeah, it is that plugin.
[23:31] <hatch> hah cool, I was looking for others but havne't found any
[23:31] <hatch> so I was pretty interested
[23:31] <Makyo> It works okay!
[23:35] <Makyo> Better than go in vim, in my experience, but I didn't spend much time on that, since frankban and I were pairing at the time.
[23:37] <hatch> ahh