[07:06] <Cimi> morning
[07:06] <Cimi> starting earlier today so I can watch italy later on  :D
[07:26] <Cimi> Saviq, I am doing tests
[07:26] <Cimi> Saviq, found more bugs fixing them
[07:26] <Cimi> (some conditions where the layout was breaking)
[07:31] <tsdgeos> Saviq: taaaaaaaaags
[07:32] <Cimi> hah
[07:34] <Saviq> tsdgeos, damn :|
[07:34] <tsdgeos> no idea how they got to my unity8
[07:35] <Saviq> tsdgeos, I do
[07:35] <tsdgeos> seems they are not upstream
[07:35] <Saviq> tsdgeos, they were, yesterday
[07:35] <Saviq> tsdgeos, or well, a few days before
[07:35] <tsdgeos> but somehow i ended up infecting swipe_down_close_no_remove_dash
[07:35] <Saviq> tsdgeos, Kaleo's branch
[07:35] <tsdgeos> cleaning up now
[07:35] <Saviq> tsdgeos, I will do some checking again
[07:36] <Saviq> before the next landing
[07:36] <tsdgeos> oki
[07:37] <Saviq> ooh 5.3 is a landeded
[07:38] <Saviq> crap
[07:54] <mzanetti> facundobatista: hey, was on holiday yesterday
[07:55] <mzanetti> facundobatista: if you have an utopic machine now, you can branch lp:unity8 and run ./build.sh in there. Then you'll have a "cardtool" somewhere in the builddir
[07:55] <mzanetti> facundobatista: ping when you're around I can give you better instructions then
[09:57] <Saviq> tsdgeos, hmm we seem to be missing some  "don't animate height" on the VJ
[09:58] <Saviq> tsdgeos, I did http://paste.ubuntu.com/7673731/
[09:58] <Saviq> AAARGh
[10:00] <tsdgeos> Saviq: i think i missed half of what you said
[10:00] <tsdgeos> i only got
 tsdgeos, hmm we seem to be missing some  "don't animate height" on the VJ
[10:00] <Saviq> tsdgeos, https://code.launchpad.net/~aacid/unity8/dashviews_integration/+merge/222192/comments/537179
 tsdgeos, I did http://paste.ubuntu.com/7673731/
[10:01] <Saviq> tsdgeos, and there's a small inline comment on the doxy comment
[10:01] <tsdgeos> ok
[10:01]  * tsdgeos reads
[10:01] <tsdgeos> oh come on, got disconnected again :/
[10:01] <Saviq> tsdgeos, no, you're still here
[10:01] <Saviq> wow
[10:02] <mzanetti> Saviq: known troubles with QtFeedback?
 oh come on, got disconnected again :/
 tsdgeos, no, you're still here
[10:02] <Saviq> <-- tsdgeos has quit (Read error: Connection reset by peer)
[10:02] <Saviq> tsdgeos, you knew it before it happened ;)
[10:02] <Saviq> mzanetti, context?
[10:02] <mzanetti> plugin cannot be loaded for module "QtFeedback": The plugin '/usr/lib/x86_64-linux-gnu/qt5/qml/QtFeedback/libdeclarative_feedback.so' uses incompatible Qt library. (5.3.0)
[10:03] <Saviq> mzanetti, looks like you didn't upgrade completely
[10:03] <mzanetti> yeah... but apt doesn't agree on that
[10:03] <tsdgeos> yeah it's kind of weird
[10:03] <tsdgeos> i was disconnected when i wrote that
[10:03] <tsdgeos> then reconnected
[10:03] <tsdgeos> and client quite
[10:03] <tsdgeos> no idea why
[10:03] <Saviq> mzanetti, you using a mirror?
[10:03] <Saviq> mzanetti, you probably upgraded in-between migrations from proposed
[10:03] <mzanetti> looks like...
[10:03] <mzanetti> qtsensors coming in noe
[10:05] <tsdgeos> Saviq: 4-indented ? you mean with tabs? or 4 spaces?
[10:05] <Saviq> tsdgeos, 4 space
[10:05] <Saviq> tsdgeos, like my patch did ;)
[10:05] <Saviq> tsdgeos, I'll prep one for the other places where that happens
[10:06] <Saviq> but separate MP
[10:08] <Saviq> tsdgeos, you know what I meant for resize-on-creation?
[10:10] <tsdgeos> Saviq: hmmm, not really
[10:10] <tsdgeos> can't see anything wrong after applying your patch
[10:10] <Saviq> tsdgeos, scroll fast
[10:10] <Saviq> tsdgeos, expand first category, scroll past it, scroll back up
[10:11] <Saviq> tsdgeos, you should see it not being expanded (which it should) and animating height (which it shouldn't)
[10:12] <tsdgeos> erhmmmm
[10:12] <tsdgeos> something's very wrong
[10:12] <tsdgeos> i'm just not getting the VJ :D
[10:12] <Saviq> tsdgeos, did you build? ;)
[10:12] <tsdgeos> i did
[10:13] <Saviq> tsdgeos, did you build your VJ branch?
[10:13] <tsdgeos> yeah
[10:13] <tsdgeos> http://paste.ubuntu.com/7673799/
[10:14] <Saviq> tsdgeos, well, it might be grid in fact, it's not like it's easy to discern ;)
[10:14] <tsdgeos> well i replaced the carousel too
[10:14] <tsdgeos> and still get it :D
[10:14] <Saviq> tsdgeos, so maybe my bug is in trunk ;)
[10:14] <tsdgeos> it may
[10:14] <tsdgeos> i can't repro though
[10:15] <Saviq> tsdgeos, anyway there's a few template defs above as well
[10:15] <Saviq> ah but that's for special
[10:15] <tsdgeos> ah i changed the wrong ones
[10:15] <tsdgeos> ...
[10:16] <tsdgeos> silly me
[10:17] <tsdgeos> yeah, why is it doing that?
[10:17]  * tsdgeos checks
[10:32] <tsdgeos> Saviq: ok, should be better now, can you check?
[10:37] <Saviq> tsdgeos, yeah, checking
[10:39] <Saviq> tsdgeos, it needs 4 spaces *more* than normal text ;)
[10:39] <tsdgeos> ¿?¿?
[10:39]  * tsdgeos is confused
[10:39] <Saviq> tsdgeos, normal text is * foo
[10:39] <Saviq> the ascii art
[10:40] <Saviq> needs to be *     foo
[10:40] <tsdgeos> so i'm missing 1 space still?
[10:40] <Saviq> tsdgeos, yes
[10:40] <Saviq> tsdgeos, make -C builddir doc
[10:40] <Saviq> and builddir/doc/unity8/class_responsive_vertical_journal.html
[10:40] <tsdgeos> uh oh
[10:41] <tsdgeos> do you guys get http://paste.ubuntu.com/7673886/ on make testShell?
[10:41] <Saviq> tsdgeos, looks like it, yes :|
[10:41] <tsdgeos> http://nooooooooooooooo.com/
[10:42] <Saviq> tsdgeos, yeah, same trace
[10:44] <tsdgeos> this crash in valgrind seems veeeeeery similar to the other one we were having
[10:44]  * tsdgeos builds with debug again
[10:45] <Saviq> tsdgeos, ACK on VJ
[10:45] <tsdgeos> \o/
[10:49] <Saviq> MacSlow, there's still inline comments in https://code.launchpad.net/~macslow/unity8/combo-button-support/+merge/221499 that need action (reply at least)
[10:49] <MacSlow> Saviq, I'm on those...
[10:49] <Saviq> MacSlow, ah ok, thought you were done with that one, too
[10:49] <MacSlow> Saviq, was surprised I didn't see them (all) before.
[10:49] <Saviq> MacSlow, yeah, they're not easily visible indeed
[10:50] <MacSlow> Saviq, the other three branches seem fine
[10:50] <Saviq> MacSlow, and then if you change, the diff changes and so you need to switch to the previous diff to be able to see them
[10:50] <MacSlow> Saviq, yeah... by now I'm aware of that new LP-diff-comment feature
[10:51] <MacSlow> Saviq, after all that new way is nicer for comments... especially for the commenter
[10:51] <Saviq> MacSlow, indeed, well, as submitter you can reply to those, so that's good, too
[10:52] <Saviq> there's stuff to improve for sure
[10:52] <Saviq> but it's a start
[10:53] <tsdgeos> Saviq: one for the lazyimage test https://code.launchpad.net/~aacid/unity8/fix_lazyimagetest_53/+merge/223896
[10:53] <tsdgeos> then there's the multigreeter one
[10:53] <tsdgeos> in which html behaviour has changed
[10:54] <tsdgeos> someone needs to check if we're fine with that change or not
[10:54] <tsdgeos> mterry probably
[10:54] <tsdgeos> and then the crash i'm investigating
[10:54] <tsdgeos> i'll create a bug for mterry and the multigreeter test failures
[10:54] <Saviq> tsdgeos, great, thanks
[11:05] <Saviq> k folks, taking second half of my holiday o/
[11:08] <Cimi> Saviq, you off now?
[11:18] <kgunn> Cimi: i'm pretty sure this was fixed in our latest release, can you double check  it ?
[11:18] <kgunn> https://bugs.launchpad.net/mir/+bug/1319907
[11:19] <Cimi> kgunn, phone dead at the moment and without carousel
[11:19] <Cimi> kgunn, let me ask mzanetti
[11:19] <Cimi> mzanetti, do you remember the bug with the carousel?
[11:19] <kgunn> Cimi: i can do it actually
[11:19] <Cimi> ok
[11:19] <Cimi> kgunn, thanks!
[11:19] <mzanetti> Cimi: hmm... which one?
[11:19] <mzanetti> ah... that one
[11:19] <mzanetti> haven't seen it any more lately
[11:19] <Cimi> mzanetti, flick on carousel, no overlay
[11:19] <Cimi> kgunn, ^
[11:19] <kgunn> thanks
[11:20] <Cimi> I'll reopen it in case
[11:20] <kgunn> Cimi: for future...how to reproduce ? add like 10 music files or something ?
[11:20] <Cimi> kgunn, yes, just flick
[11:20] <mzanetti> kgunn: yep, just drop some music or videos on the phone
[11:20] <mzanetti> and carousels start appearing
[11:20] <Cimi> kgunn, quite almost every time the overlay wasn't shown
[11:20] <Cimi> no title/song
[11:21] <mzanetti> that said, I think I saw the one in the recent apps category again lately, where whe thought it would be related
[11:21] <mzanetti> but I didn't really investigate, so... take it with caution
[11:22] <mzanetti> can't reproduce it right now...
[11:31] <kgunn> mzanetti: Cimi yeah...seems pretty solid, i can't repro
[11:35] <mhr3> jhodapp, got a u8 crash with 5.3  coming from media-hub http://paste.ubuntu.com/7674074/ sorry for crap debug, don't have all the symbols, but fwiw it should be uploaded to daisy
[11:37] <Cimi> tsdgeos, I refactored my card emblem as saviq asked https://code.launchpad.net/~cimi/unity8/card_emblems_single_container/+merge/223899
[11:39] <Cimi> tsdgeos, I tested a bit, seems fine
[11:39] <Cimi> tsdgeos, I am happy to get it merged and wait for bugreports if there are
[11:39] <Cimi> there are so many nested cases that there is a chance something is broken
[11:40] <Cimi> but I tested most
[11:40] <tsdgeos> Cimi: i'll be away next week, and i'm having a look at a qt crash right now, maybe you should look for someone else to review
[11:40] <Cimi> ok Saviq then
[11:42] <tsdgeos> Cimi: did the new infographics already got merged?
[11:42] <Cimi> tsdgeos, no
[11:42] <Cimi> tsdgeos, unity side they work
[11:43] <Cimi> tsdgeos, but camera app doesn't populate the service
[11:43] <Cimi> tsdgeos, so we wait next week to talk with pete who is on holiday
[11:44] <Cimi> tsdgeos, basically you can manually add infographics to the backend and you see them in unity... but there is something broken on the backend
[11:45] <tsdgeos> oki
[12:04] <jhodapp> mhr3: yeah, we weren't ready to switch to qt 5.3
[12:41] <facundobatista> mzanetti, saw your instructions from some hours ago; I'm currently installing stuff in this Utopic machine for build unity, thanks!
[13:40] <mzanetti> dpm_: kgunn: hey, one of you should move the meeting to a different time slot. I don't mind which one :)
[13:40] <mzanetti> talking about reminders weekly and kevin/michael 1:1
[13:41] <dpm_> mzanetti, I can move it, sorry, didn't want to step on your 1:1
[13:41] <mzanetti> dpm_: no... kevin stepped on the reminders meeting
[13:41] <dpm_> aha! :)
[13:41] <mzanetti> dpm_: but I figured we're moving the reminders one often enough to probably move it for real
[13:42] <dpm_> mzanetti, yeah, the last weeks have been quite hectic with other things and that's meant some movement there. Let me change the time for the one this week and then I'll find a better weekly time for the one next week
[13:43] <kgunn> dpm_: appreciate it....i got a lot of guys...so shuffling is a challenge of all the 1on1's
[13:44] <dpm_> kgunn, no worries
[13:45] <dpm_> mzanetti, ok, moved this one to Monday, as Riccardo pinged me earlier he might not be able to make it today
[13:54] <mzanetti> dpm_: works for me
[13:58] <dpm_> ok, thanks
[14:25] <kgunn> greyback: i had a moment to tinker, export renderer_timings & when i tried to relaunch using
[14:25] <kgunn> QT_QPA_PLATFORM=mirserver
[14:25] <kgunn> it aborted
[14:25] <kgunn> am i doing it wrong ?
[14:25] <greyback> kgunn: need to also set MIR_SOCKET=/run/mir_socket
[14:26] <greyback> kgunn: if you pulled today, the PPA is broken again, since Qt5.3 landed
[14:26] <greyback> working on fixing it now
[14:27] <kgunn> greyback: ack... sorry man
[14:27] <greyback> kgunn: np
[14:27]  * kgunn wonders about qt5.3 so close to rtm
[14:27] <greyback> kgunn: I'll let you know when PPA back up and running
[14:27] <greyback> the gcc transition also didn't help
[14:28] <kgunn> yeah :-/
[14:28] <tsdgeos> kgunn: i just discovered a few crashers too :/
[14:28] <tsdgeos> in qt5.3
[14:29] <kgunn> olli_: ^ to keep in mind for discussions about how upstream migrations occur
[14:33] <kgunn> greyback: mirserver doesn't seem to exist...
[14:33] <kgunn> Available platform plugins are: eglfs, kms, linuxfb, minimal, minimalegl, offscreen, ubuntu, ubuntumirclient, ubuntumirserver, xcb.
[14:33] <kgunn> i tried the obvious ubuntumirserver
[14:34] <kgunn> Failed to connect to "/run/user/32011/ubuntu-keyboard-info" after 10 failed attempts
[14:35] <mterry> kgunn, if you have time today, you could also be my welcome-wizard guinea pig.  Not urgent, still waiting on some test script changes to be reviewed.  But might be a nice Friday activity
[14:35] <kgunn> mterry: is there something available now ?
[14:36] <kgunn> i'm taking off for the day at lunch
[14:36] <mterry> kgunn, just install ubuntu-system-settings-wizard and run 'adb shell rm /home/phablet/.config/ubuntu-system-settings/wizard-has-run' to reset state
[14:36] <greyback> kgunn: you'd better just hold on until I have the PPA working again
[14:37] <mterry> kgunn, again, not urgent though
[14:38] <kgunn> greyback: my apologies...i'm a distraction, just ignore me...note: i'm not on the ppa
[14:39] <greyback> kgunn: I'm confused, what are you testing? Trunk?
[14:39] <kgunn> greyback: yep...just straight devel-proposed image
[14:40] <kgunn> again..just ignore me
[14:40] <greyback> kgunn: ok, sorry, "mirserver" threw me off - that's PPA only.
[14:40] <greyback> kgunn: QT_QPA_PLATFORM=ubuntumirserver and MIR_SOCKET=/run/mir_socket should be enough
[14:41] <kgunn> greyback: yeah that worked...but failed on keyboard
[14:41] <greyback> kgunn: those "Failed to connect" messages are normal, as maliit-server hasn't been started (it's usually started by unity8's upstart job)
[14:42] <kgunn> maybe i didn't wait long enough
[14:43] <paulliu> Cimi: hi. Can you help me review this branch? https://code.launchpad.net/~paulliu/unity8/lp1330957/+merge/223779
[14:43] <Cimi> paulliu, sure
[14:43] <paulliu> Cimi: not a large one but fixes some FAILED in testCard
[14:43] <cwayne> Saviq: any chance of the vertical journal fixes landing today?
[14:44] <kgunn> cwayne: i think Saviq is off... tsdgeos might know
[14:44] <Cimi> paulliu, is this a typo? headerLeftAnchorHasMagin
[14:44] <tsdgeos> cwayne: it's approved
[14:44] <tsdgeos> cwayne: https://code.launchpad.net/~aacid/unity8/dashviews_integration/+merge/222192
[14:44] <kgunn> tsdgeos: do  you just need a silo to land it ?
[14:44] <tsdgeos> cwayne: but it needs a lander
[14:44] <tsdgeos> not sure if Saviq has something prepared or not
[14:44] <greyback> kgunn: but you're not starting the unity8 job, you're starting unity8 manually. So no dependent processes (like maliit, indicators) won't autostart.
[14:45] <kgunn> tsdgeos: i'll check and get a silo if not...
[14:45] <tsdgeos> oki
[14:45] <paulliu> Cimi: No. The original code are using that variable. Or I should change all of them?
[14:46] <Cimi> paulliu, you can skip the fix
[14:46] <Cimi> paulliu, I will add it in my emblems branch
[14:46] <greyback> kgunn: you could run "initctl set-env QSG_RENDER_TIMING=1" and then "start unity8" as usual, and the ~.cache/upstart/unity8.log file will have the timings printed there
[14:46] <Cimi> paulliu, the entire fix I mean
[14:46] <paulliu> Cimi: ok. because I'll rebase my another branch about the attribute UI on your emblems branch.
[14:46] <Cimi> paulliu, or you can do that
[14:46] <greyback> but that means *every* Qt process will do the same, unless you unset that right after
[14:46] <greyback> kgunn: ^
[14:46] <Cimi> paulliu, but I think is easier for you if you leave it to me
[14:47] <Saviq> kgunn, no, no silo - we could land stuff that's there in u8 queue, unity-notifications could use a landing, too
[14:47] <Cimi> paulliu, that code is quite awful to see (that js)
[14:47] <paulliu> Cimi: OK, maybe I should do that. Because this bug fixing branch is smaller.
[14:47] <paulliu> Cimi: yours are large.
[14:47] <Cimi> paulliu, I mean I can add the fix to my branch
[14:48] <paulliu> Cimi: ah. got it. Please do.
[14:48] <Cimi> paulliu, but you can keep fixes for the card tests
[14:49] <paulliu> Cimi: actually I need to fix the margin.
[14:49] <Cimi> paulliu, ok fix it then
[14:49] <paulliu> Cimi: ok.
[14:49] <Cimi> paulliu, but please rename the variable
[14:50] <paulliu> Cimi: ok.
[14:52] <kgunn> Saviq: you know time off means off :)...but since you're on, do you mean you want me to create a silo and land everything that's approved+ready for unity8+unity-notifications ?
[14:52] <kgunn> (sorry parse error on your last post)
[14:52] <Saviq> kgunn, yeah
[14:53] <kgunn> ack
[15:06] <kgunn> cwayne: just an fyi...might not land until monday...looks like ci train is unmanned for the moment
[15:06] <kgunn> so suspect i won't get a silo until late afternoon
[15:07] <cwayne> kgunn: ack, thanks for the update, monday should be fine
[15:18] <mhr3> mhall119, mind running your nice script to update the scopes docs?
[15:18] <mhr3> mhall119, or is it running as a cron job somewhere?
[15:18] <mhall119> mhr3: no cron yet, the changes are in trunk?
[15:18] <mhr3> mhall119, in U even, yes
[15:19] <mhall119> I'm still on trusty, so doing it from the branch is easier than from the package
[15:27] <Saviq> paulliu, hey, charles fixed the failure in indicator-session, but unity8 still didn't log out for him
[15:28] <Saviq> paulliu, I kicked a rebuild of everything in silo 008
[15:28] <charles> saviq, I sent paulliu a mail about it on (wednesday?)
[15:29] <Saviq> charles, yes, seb128 fwd'ed it back to me
[15:29] <Saviq> charles, so I don't have a reply, if there was any :)
[15:29] <mhall119> mhr3: please check http://<IP_ADDRESS>/api/scopes/sdk-14.10/
[15:29] <charles> paulliu, are you able to trigger a logout in unity8 via dbus-send?
[15:29] <charles> I'd like to decouple the testing of the indicator-session parts and the unity parts
[15:30] <Saviq> paulliu, you could test on the phone btw, if your desktop doesn't run unity8
[15:31] <Saviq> paulliu, you just need to run the dbus command, or you could even export the UNITY_INDICATORS_PROFILE="desktop" into upstart to get the session indicator on the phone
[15:33] <mhr3> mhall119, +1, we moved some stuff to a new unity::scopes::experimental namespace, but it's actually good that it's not in the docs, discouraging use of classes from there was why we did it
[15:33] <seb128> Saviq, there was no reply
[15:33] <mhall119> mhr3: do any old classes need to be removed?  remember that the import script never deletes things, only adds and updates
[15:34] <mhr3> mhall119, hm, even if they were you wouldn't be linked from anywhere, no?
[15:34] <mhr3> they wouldn't be*
[15:35] <mhall119> mhr3: if you moved things from a supported namespace into experimental, they would still be in the old location
[15:35] <mhr3> mhall119, right, but there wouldn't be any pages linking to that now
[15:36] <mhr3> mhall119, or wait the index page is hardcoded, right?
[15:36] <mhall119> no
[15:37] <mhall119> http://<IP_ADDRESS>/api/scopes/sdk-14.10/ is generated from the API website's data
[15:37] <mhr3> where does it get the categorization from?
[15:37] <mhall119> mhr3: for scopes, I hand-crafted them
[15:37] <mhall119> because the source docs don't have that data
[15:38] <mhr3> so it is kindof hardcoded?!
[15:38] <mhall119> for QML docs, I can get that from the sources
[15:38] <mhall119> mhr3: only the categories
[15:38] <mhall119> and those are hardcoded in the importer, not in the api-website
[15:38] <mhr3> mhall119, ok, nonetheless, it looks good to me
[15:39] <mhall119> ok, I'll push to production
[15:41] <paulliu> Saviq: yes, I can do the logout by dbus-send
[15:41] <Saviq> charles, ↑
[15:41] <mhall119> mhr3: please verify http://developer.ubuntu.com/api/scopes/sdk-14.10/
[15:41] <paulliu> charles: Can't you logout with dbus-send?
[15:42] <charles> paulliu, can you paste to me the recipe you're using for that?
[15:42] <paulliu> charles: I think tsdgeos also tested the dbus-send already.
[15:42] <paulliu> charles: https://bugs.launchpad.net/unity8/+bug/1302213
[15:43] <charles> paulliu, no it didn't work for me when I tried dbus-send from the command line.
[15:43] <paulliu> charles: the unity8 didn't kill itself?
[15:44] <charles> paulliu, I'm happy to re-test, could you paste the invocation you used, so I can repeat it hee?
[15:45] <mhr3> mhall119, oh wait one leftover - "Deprecated List"
[15:45] <mhr3> mhall119, should be gone now
[15:46] <mhall119> mhr3: the full page?
[15:47] <mhr3> mhall119, yep
[15:47] <mhall119> ok, gone
[15:48] <mhall119> mhr3: removed from staging as well, so it won't cause confusion on a future update
[15:48] <mhr3> mhall119, awesome, thx
[15:53] <paulliu> charles: ok. wait.
[15:56] <paulliu> charles: first, bzr branch lp:~paulliu/unity8/logout and then ./run_on_device.sh  (you might want to adb shell install some build-deps first).
[15:56] <Saviq> paulliu, just upgrade from silo 008
[15:56] <Saviq> https://launchpad.net/~ci-train-ppa-service/+archive/landing-008
[15:56] <charles> paulliu, thanks. I'll try that here
[15:57] <Saviq> still building latest unity8, but shouldn't be a problem (and should finish soon)
[15:57] <paulliu> charles: And source this shell script. http://paste.ubuntu.com/7675317
[15:57] <Saviq> paulliu, if you ssh onto the device, that should be there in your env already
[15:57] <paulliu> charles: And use qdbus com.canonical.Unity /com/canonical/Unity/Session com.canonical.Unity.Session.RequestLogout
[15:57] <paulliu> Saviq: ah. ok
[15:57] <Saviq> or use sudo -u phablet -i
[16:00] <charles> well, I was testing on desktop since indicator-session doesn't have a profile on the phone
[16:00] <charles> unless I'm misunderstanding what I'm needing to test here...
[16:01] <paulliu> charles: Another way to test on desktop is use KDE, and then run ./run.sh, qdbus will also trigger a kill of unity8.
[16:10] <paulliu> charles: I'm thinking if it is because I didn't modify debian/*.install. The plugin might not be installed.
[16:10] <paulliu> charles: I'll check the silos
[16:11] <paulliu> charles: hmm, no, there is the plugin.
[16:14] <paulliu> charles: I'm testing silos right now. But I'll need some time for that. The network to ports and ppa isn't stable.
[16:15] <paulliu> charles: Some Taiwan sites are under attack now.
[16:22] <charles> paulliu: okay, on my laptop I'm logged into a unity8 session
[16:23] <charles> paulliu: I ssh in from my desktop and run that script to get DBUS_SESSION_BUS_ADDRESS set
[16:23] <charles> (nice script, by the way. I'd been sourcing the upstart file, but this is more convenient ;)
[16:24] <paulliu> charles: try "qdbus com.canonical.Unity". It should prints all the objects
[16:25] <charles> paulliu: doesn't exist. I'm wondering if an update I've run since Wednesday overwrote the silo
[16:25] <charles> paulliu: 5 minutes :)
[16:26] <paulliu> charles: what? Session might not be there, but there should be some other objects there already.
[16:27] <paulliu> charles: I now only have 5000 B/s to ports and ppa.
[16:27] <paulliu> charles: Cannot get anything.
[16:28] <seb128> charles, paulliu: I'm installing that ppa to try here
[16:29] <charles> paulliu: to answer your question, this is what I see:
[16:29] <charles> $ qdbus | grep Unity
[16:29] <charles>  com.canonical.Unity.WindowStack
[16:29] <charles>  com.canonical.Unity.Launcher
[16:29] <charles>  com.canonical.UnityGreeter
[16:29] <paulliu> charles: hmm. So Session isn't there. I'll check.
[16:30] <charles> paulliu: but I suspect I'm not installed right from silo 8, so as I said, give me a minut :)
[16:30] <paulliu> charles: ok
[16:30] <charles> seb128, thanks :)
[16:31] <seb128> charles, paulliu: the ppa doesn't work on utopic unity8-mir-desktop session :/
[16:32] <charles> seb128, do you mean when trying to log out through indicator-session, or when manually sending the RequestLogout call over the bus via dbus-send / qdbus?
[16:34] <seb128> the indicator
[16:34] <seb128> tryin qtdbus now
[16:34] <charles> seb128, thanks
[16:35] <charles> if that works, maybe there's still a different bug remaining in indicator-session
[16:35] <kgunn> mterry: only thing i noticed is that the delay between the wizard and the spinner is kinda big...
[16:36] <kgunn> long enough that as a user i wanted to start punching buttons
[16:37] <seb128> charles, trying to get qdbus to work first...
[16:37] <charles> seb128, you have qdbus5 installed?
[16:38]  * charles is waiting on apt-get upgrade :)
[16:38] <seb128> charles, installing it
[16:38] <seb128> thanks
[16:40] <seb128> "qdbus com.canonical.Unity /com/canonical/Unity/Session com.canonical.Unity.Session.RequestLogout" doesn't do anything to unity8
[16:40] <seb128> charles, paulliu: ^
[16:41] <paulliu> seb128: ok.
[16:41] <paulliu> seb128: I'll check. I'm still on apt-get update.
[16:43] <paulliu> seb128: what does "qdbus com.canonical.Unity" say?
[16:44] <seb128> charles, paulliu: unity8-mir.log has "Signal QQmlEngine::quit() emitted, but no receivers connected to handle it."
[16:44] <seb128> displayed every time the dbus request is emitted
[16:45] <seb128> paulliu, http://paste.ubuntu.com/7675560/
[16:51] <seb128> paulliu, is the "no receivers connected" error helping? what code is supposed to be the receiver?
[16:56] <paulliu> seb128: let me check.
[16:56] <greyback> that usually means in the main.cpp where the QQmlEngine is created, that no slot was connected to the QQmlEngine::quit signal to actually call QGuiApplication::quit()
[16:57] <paulliu> greyback: yes. I think I did that already when you told me.
[16:58] <paulliu> greyback: But might be cleaned after some trunk merge. I'll fix it.
[16:58] <greyback> paulliu: you've a better memory than I do. I don't remember saying that :)
[16:58] <charles> :)
[16:58] <seb128> paulliu, https://launchpadlibrarian.net/178057888/unity8_7.89%2B14.10.20140618-0ubuntu1_7.89%2B14.10.20140620-0ubuntu1.diff.gz is what we got in the ppa upload
[16:59] <seb128> ups, sorry
[16:59] <seb128> launchpad seems confused
[17:04] <paulliu> Saviq: I push a new commit to logout branch based on seb128 and greyback's comments.
[17:05] <paulliu> Saviq: add QObject::connect(view->engine(), SIGNAL(quit()), application, SLOT(quit())); in main.cpp
[17:07] <seb128> Saviq, charles, paulliu: I'm kicking a rebuild for unity8 so it picks up that change
[17:08] <seb128> paulliu, do you know how that code got dropped/why you had it in your local version and no in the branch?
[17:09] <paulliu> seb128: My local branch also dropped sometime after merge trunk. But I don't know why it still works on all my devices. Even on phone.
[17:09] <seb128> ok, let's see if that rebuild makes it work for us
[17:39] <seb128> Saviq, charles, paulliu: ok, works now with the unity8 signal connect change
[17:40] <charles> seb128: \o/
[17:40] <seb128> well "works", it logout without asking for confirmation
[17:40] <Saviq> finally
[17:40] <Saviq> seb128, yeah, that comes later
[17:40] <seb128> but I guess that's what that change is supposed to do?
[17:40] <seb128> k
[17:40] <seb128> Saviq, so feel free to land the silo
[17:40] <charles> seb128: right, i-session tries to pull up the dialog, but when it gets a failure response, that's treated as confirmation now...
[17:40] <Saviq> seb128, Monday ;)
[17:40] <charles> :)
[17:41] <charles> seb128: thanks for being the scratch monkey
[17:41] <seb128> Saviq, yeah, I was thinking the same/going to add "if you feel adventurous" ;-)
[17:41] <seb128> charles, no worry!
[17:42] <Saviq> seb128, I'm even on holiday today ;)
[17:42] <seb128> charles, btw did you see my ping about reviewing cyphermox's bluetooth setting changes? do you think you would have review slot for that?
[17:42] <seb128> Saviq, stop being on IRC then, go enjoy your extended w.e ;-)
[17:43] <charles> seb128, no sorry I didn't see that ping. Yes of course I'll take a look
[17:43] <charles> (cyphermox: ^)
[17:43] <seb128> charles, thanks
[17:49] <charles> seb128: are there any others you want me to look at besides https://code.launchpad.net/~mathieu-tl/ubuntu-system-settings/discoverability-annd-fixes/+merge/223955
[17:49] <seb128> charles, no, that's the one, thanks!
[18:04] <cyphermox> aye


[00:43]  * lifeless watches the dustweeds
[01:25] <lifeless> spiv: bug 457952
[01:27] <spiv> lifeless: what about it?  I guess the question is "what precisely should the 'check' target do?", and then just land that.
[01:28] <lifeless> spiv: I proposed an idiom earlier in the bug report
[01:28] <spiv> lifeless: feel like proposing an actual patch? :)
[01:28] <lifeless> I think something like tee test.log && subunit-stats < test.log
[01:29] <lifeless> spiv: or subunit-filter --no-skip < test.log | subunit2pyunit
[01:30] <spiv> lifeless: sure, the idea sounds fine.  But it seems to me that you're the best person to decide on the details.
[01:31] <lifeless> spiv: I'll add it to my queue
[01:31] <lifeless> spiv: possibly in the weekend
[01:32] <lifeless> spiv: I may be the best person; I don't think it needs the best person.
[01:34] <spiv> Well, partly I'm a bit hesistant because last time I turned on subunit things broke.  But that change was also simpler... and I haven't got all the various subunit-* utils paged in, so discovering the options for achieving this and evaluating them is not trivial effort.  If you propose a patch I can pilot it though ;)
[01:38] <lifeless> its not really on my radar workwise
[01:47] <lifeless> spiv: I guess what I'm thinking is that : it will help folk landing stuff; having at least one other person happy with the tool chain is important :)
[02:27] <stewart> hi! i'm having issues with a plugin I wrote. it's trying to commit.run with author= as a parameter, but i'm getting "author: s, t, e, w" etc instead of "author: stewart@"  any clues?
[02:27] <stewart> running bzr 2.0.2
[02:29] <stewart> (this used to work okay)
[02:32] <spiv> stewart: a commit can have multiple authors
[02:32] <spiv> stewart: so IIRC you need to pass a list of author strings, not just a single author string.
[02:32] <stewart> ahh...
[02:32] <stewart> let's try that
[02:33] <spiv> That feature was added in 1.13 according to the news file.
[02:34] <stewart> subtle API change :)
[02:34] <spiv> Yeah.  It would have been nicer I guess if the API had renamed that param.
[02:35] <spiv> And also calling it 'authors' would be clearer, really, but I think that's a limitation of our command-line processing infrastructure.
[02:35] <stewart> as i don't think i'm that important that each character in my email address should be listed :)
[02:36] <stewart> i should actually rip this plugin out of the internal mysql tree and just publish it.... was the original intention.
[02:37] <spiv> Probably ListOption should grow a feature where the name of the --option does not have to precisely match the param in the API, because the CLI will have a singular word (possibly repeated), but the API ideally would have a plural.
[02:38] <RenatoSilva> verterok: hi
[03:46]  * fullermd slaps lying 'merge' around.
[03:52] <fullermd> Is it actually expected that merge bleats about being unable to find a common ancestor when there are two of 'em?
[03:56] <lifeless> fullermd: thats a criss cross
[03:57] <lifeless> and it recurses deeper in that case
[03:57] <fullermd> Well, no, it just dies.
[03:57] <lifeless> fullermd: you may have a special case.
[03:57] <lifeless> bug filed?
[03:57] <fullermd> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[03:58] <lifeless> theres no sign of two common ancestors there
[03:59] <fullermd> Well, I know.  But there are two.
[04:03] <fullermd> bug 483388
[04:13] <fullermd> (adding an explicit merge type doesn't change anything; I conjecture that it blows up before it gets to anything merge-type varies)
[04:26] <RenatoSilva> verterok: hope you read this later, I've got the new update site, but it works only if extracted. Some users like me get confused because update sites usually work as a zip. But anyway, I've extracted it and got bzr-eclipse installed without errors
[04:26] <RenatoSilva> verterok: however, when I try to get a lp branch as new project, it's not working if I put a non-ascii path :(
[04:27] <RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 302
[04:28] <RenatoSilva> verterok: iirc that error is related to xmloutput
[05:28] <verterok> RenatoSilva: Hi
[05:28] <RenatoSilva> verterok: hi
[05:28] <verterok> RenatoSilva: yes, there is a bug with the bundled xmloutput in windows :/
[05:28] <verterok> RenatoSilva: I'm working on a fix ATM
[05:29] <RenatoSilva> verterok: ok let me know if I'm still here, so that I can test it
[05:29] <verterok> RenatoSilva: ok, probably I'll finish it by tomorrow, I need to sleep a few hours before go to work ;)
[05:30] <RenatoSilva> verterok: ah ok :)
[05:30] <RenatoSilva> verterok: just to note: I think there are remaining encoding problems in xmloutput
[05:30] <verterok> RenatoSilva: oh, that's bad :(
[05:31] <RenatoSilva> verterok: do you remember a bug when I said about 2 approaches about the XML Header? Always declare and  UTF-8 vs. detect system encoding?
[05:31] <verterok> RenatoSilva: yes
[05:33] <RenatoSilva> verterok: I've noted that your fixes to the encoding problems I've reported tend to go to detecting, but as I said, we must be careful about valid entries. For example, we can't get <?xml... encoding="cp850"?> because cp850 is an invalid entry for an XML document.
[05:34] <RenatoSilva> verterok: besides, I wonder if the fixes you've committed are adding more issues. In a nutshell: we need to take a better look at xmloutput. Feel free to ask me for testing :)
[05:34] <verterok> RenatoSilva: regarding, bzr-eclipse, in the preference page, try adding the path to the bzr plugins directory to the plugins path , e.g: in my winxp vm, it's: C:\Documents and Settings\guillermo\Datos de programa\bazaar\2.0\plugins
[05:34]  * RenatoSilva checks his xmloutput bugs
[05:35] <verterok> RenatoSilva: and click the Recheck button after setting it :)
[05:35] <RenatoSilva> verterok: but the bundled xmloutput is the same as trunk
[05:35] <RenatoSilva> verterok: or is it for something else?
[05:36] <verterok> RenatoSilva: yes, but there is a bug in bzr-eclipse, the code that builds the BZR_PLUGIN_PATH value is broken for windows paths
[05:36] <verterok> RenatoSilva: it's trunk
[05:36] <RenatoSilva> ok but why does it need to be aware of that path?
[05:37] <verterok> RenatoSilva: to override the path of the bundled xmloutput...I didn't testted :/
[05:41] <verterok> RenatoSilva: looks like adding the path to plugins dir works, at least in my spanish win xp :)
[05:42] <RenatoSilva> override the path?
[05:43] <verterok> RenatoSilva: in the bazaar preference page, there is an option to add plugins path
[05:44] <verterok> RenatoSilva: bzr-eclipse trunk, don't handle windows paths ok, and so the BZR_PLUGIN_PATH used contains a wrong path.
[05:44] <verterok> RenatoSilva: in order to use trunk build, you need to add the plugins path manually
[05:45] <RenatoSilva> verterok: ok but I mean, why does bzr-eclipse need to know that plugins path? to override the bundled's? but what's that?
[05:46] <verterok> RenatoSilva: bzr-eclipse trunk, bundle xmloutput so users don't have to install it...basically to simplify the install process
[05:46] <Peng> What's the right way to make push default to --no-strict? An alias?
[05:47] <verterok> RenatoSilva: but to do that, it need to set BZR_PLUGINS_PATH when it launchs the xmlrpc service
[05:48] <verterok> Peng: probably that's the way to go :)
[05:49]  * RenatoSilva installing bzr-eclipse again
[05:50] <verterok> RenatoSilva: or you can wait until tomorrow night, for the new build ;)
[05:51] <RenatoSilva> verterok: you said I could set the path manually, do you think it may be cause of the parse error I mentioned above?
[05:51] <Peng> verterok: Eh, ok
[05:51] <verterok> RenatoSilva: don't know :/
[05:52] <RenatoSilva> verterok: ok will test now
[05:52] <verterok> RenatoSilva: that error is the same we were getting in hudson a few days ago...
[05:52] <RenatoSilva> verterok: I remember that error as being something regarding encoding for sure
[05:54] <poolie1> spiv, how did the pilotage go?
[05:56] <RenatoSilva> verterok: there's no executable set, can't get how it was finding it...
[05:57] <verterok> RenatoSilva: it will look for it in PATH
[05:57] <RenatoSilva> ah ok, just added bzr's plugin path, will test
[06:00] <RenatoSilva> verterok: bah, same error, even setting the path manually :(
[06:00] <verterok> RenatoSilva: :(
[06:00] <RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 302
[06:01] <RenatoSilva> verterok: would be easy to find out what's happening if I debug, but I'm afraing not getting the source code debug working
[06:01] <RenatoSilva> afraid
[06:01] <verterok> RenatoSilva: bzr-eclipse code?
[06:02] <verterok> RenatoSilva: it should bo ok now, I updated all deps in the pom(s).xml
[06:02] <RenatoSilva> verterok: yes, and we'd need bzr-java-lib too...
[06:02] <verterok> *be
[06:02] <spiv> poolie1: it's going pretty well, although it's a bit tedious figuring out who has signed the contributor agreement
[06:02] <poolie1> there's an lp team for it?
[06:03] <poolie1> i think?
[06:03] <RenatoSilva> verterok: but bzr-eclipse does not come configured to work with the source code of bzr-java-lib
[06:03] <spiv> There is, but a) I'm not confident it's up to date, and b) I don't see any way to go from a team page to a complete list of members.
[06:03] <verterok> RenatoSilva: yes, it will pull bzr-java-lib from the maven repository
[06:03] <spiv> Or rather, I see a way that *should* do that, but doesn't.
[06:03] <spiv> You can go backwards, from the lp user check their team memberships.
[06:04] <RenatoSilva> verterok: if the problem is not with xmloutput, it is with bzr-java-lib likely, so I will need the source of that too
[06:05] <verterok> RenatoSilva: oh, ok
[06:05] <RenatoSilva> verterok: I've got it working before, let me try again (feaaaar)
[06:05] <verterok> RenatoSilva: /me needs to get some sleep :)
[06:05] <RAOF> Hm.  How can I tell if a bzr-git dpush is actually going to finish or not (halting problem notwithstanding)?  This one seems to have pushed ~400MiB of data, which is substantially larger than the repository.
[06:05] <RenatoSilva> verterok: ok see you, thanks
[06:06] <verterok> RenatoSilva: np, thank you :-)
[06:06] <verterok> seey'a later!
[06:10] <RenatoSilva> Is there any issues related to running two bzr.exe instances at the same time?
[06:10] <RenatoSilva> I suspect I have one or more
[06:24] <poolie1> spiv: seriously? that seems like quite a gap
[06:24] <RAOF> Oooh.  2GB ram & 600MiB upload later it seems that dpus is almost done :)
[06:26] <poolie1> spiv, in theory one can write a bot that marks mp depending on whether the contributor is a member of the team or not
[06:26] <spiv> poolie1: yeah, just filing a bug on that now.  There's an "All members" link, but it leads to disappointment rather than the information I seek.
[06:26] <poolie1> https://edge.launchpad.net/~contributor-agreement-canonical/+members#active
[06:26] <poolie1> oh because it doesn't expand ubuntuone-hackers?
[06:26] <poolie1> it's safe to assume they're all staff
[06:27] <spiv> poolie1: that page says "54 people are members in total", then only lists 9 people
[06:27] <fullermd> "New bug filed: Plz delink disappointment"
[06:28] <spiv> Hmm, I'm not sure if that's a correct assumption.
[06:28] <spiv> Anyway, I think that means that page isn't complete, given that there are many more on the internal wiki page.
[06:36] <poolie1> i still think it's a bug
[06:36] <poolie1> that's true too
[06:36] <poolie1> we should pull them across
[06:37] <poolie1> can i suggest you mention this in a mail about the pilot project sometime
[06:37] <poolie1> hm
[06:37] <poolie1> actually it might just be flamebait
[06:38] <poolie1> we probably should reconcile that team with the other list/s though
[06:38] <spiv> Yes, a single canonical (hah!) list would be nice.
[06:38] <poolie1> if only there was a massive sql db guaranteed to have the precisely correct schema and data
[06:39] <fullermd> You can just use the web as one.  First, you become Google...
[06:39] <spiv> That's just begging for another joke about the word "canonical" :P
[06:44] <poolie1> we only give you $5 for lunch? that doesn't go far...
[06:45] <spiv> poolie1: for breakfast
[06:49] <lifeless> hmm, I need to do expenses too
[06:49] <lifeless> we did what, three group meals? mon, wed, friday
[06:50] <poolie1> and also thursday, without you
[06:51] <lifeless> yes :)
[09:26] <bialix> Hi GaryvdM
[11:33] <maxb> Where is the correct place to discuss a compatibility-breaking UI change? Namely, I would like to propose dropping the 'bzr rebase --always-rebase-merges' option and making its behaviour the default
[11:35] <balor> Is there a nice linux GUI tool for resolving conflicts?
[11:35] <bob2> meld
[11:35] <bob2> if you use emacs, smerge-ediff is very nice, too
[11:36] <bob2> (aside from the ridiculous colours)
[11:36] <balor> bob2, How does meld help? do I diff3 the BASE OTHER and THIS files?
[11:50] <gioele> balor: yes, also try kdiff3
[11:53] <balor> gioele, Thanks.  Meld worked brilliantly well.
[11:53] <balor> meld foo.c.BASE foo.c.OTHER foo.c.THIS, make them all agree then cp foo.c.BASE foo.c, bzr ci
[11:57] <gioele> balor: no "bzr resolve"?
[11:59] <Peng> "bzr resolved" is for telling bzr that the conflicts have been resolved, not for actively resolving them (unlike hg, which always bites me).
[12:00] <gioele> Peng: yes, but I thought that you needed "bzr resolve" before "bzr commit"
[12:09] <Peng> Oh oh, that's what you meant. Yes, you're correct.
[12:09] <Peng> Sorry I misunderstood.
[12:31] <gioele> spiv: (pilot) could you help me with <https://code.launchpad.net/~gioele/bzr/forgot-commit-message>? Is there something missing or wrong?
[12:50] <RenatoSilva> what is .bzr\checkout\lock\releasing.ed3xwzvx48mik4q2lqhl.tmp?
[12:50] <RenatoSilva> and .bzr\checkout\lock\held?
[12:50] <RenatoSilva> and how access denied errors are related to such files?
[13:12] <bialix> RenatoSilva: break-lock is your friend
[13:12] <RenatoSilva> sorry?
[13:13] <RenatoSilva> bialix: this is happening in unit tests, *randomly*
[13:13] <bialix> RenatoSilva: windows?
[13:14] <RenatoSilva> procmon is my friend and gives the this info about the error: Path "C:\Documents and Settings\Renato\Configura├º├Áes locais\Temp\bazaar_client_tests8941769694356864996\working_copies\localBranch\original\.bzr\checkout\lock\held"
[13:14] <RenatoSilva> Detail "ReplaceIfExists: False, FileName: C:\Documents and Settings\Renato\Configura├º├Áes locais\Temp\bazaar_client_tests8941769694356864996\working_copies\localBranch\original\.bzr\checkout\lock\releasing.rcgp0djgibyborcys2tx.tmp"
[13:14] <RenatoSilva> * gives me, and yes WinXP SP3 updated
[13:14] <bialix> I'd suggest to using shorter path for temp directory
[13:14] <RenatoSilva> I don't know what ReplaceIfExists and the related FileName means though
[13:14] <bialix> something like C:\TMP
[13:15] <RenatoSilva> Already tried
[13:15] <RenatoSilva> I probably tried anything that you can imagine :P
[13:15] <bialix> this is test for smart server? or dumb server perhaps
[13:15] <RenatoSilva> sorry?
[13:16] <bialix> I'd say this is race condition
[13:16] <bialix> RenatoSilva: bazaar_client_tests
[13:16] <bialix> the name of this tests suggest me that some sort of server is tested
[13:16] <bialix> perhaps some code runs in thread
[13:17] <RenatoSilva> what's that I'm sorry? The test errors are with bzr-java-lib project, only in my Windows XP
[13:17] <bialix> therefore race condtion
[13:17] <bialix> so what?
[13:17] <bialix> .bzr\checkout\lock is lock
[13:18] <bialix> if you have file with lock info still opened/read by one process you can't delete it by other
[13:18] <RenatoSilva> a dir right? and releasing.*.tmp?
[13:18] <bialix> RenatoSilva: there is file inside, named info
[13:18] <bialix> text file with info about lock
[13:18] <bialix> *.tmp is fancy_rename trick
[13:19] <bialix> see bzrlib/osutils.py fancy_rename
[13:20]  * RenatoSilva has no idea on what could be causing this problem, he's into this since days
[13:20] <Peng> Something that doesn't release locks, perhaps?
[13:20] <bialix> if you say it's random failures then I'd say it's either path length limit or race condition
[13:21] <bialix> or you have aggressive anti-virus
[13:21] <RenatoSilva> bzr-java-lib uses an XML-RPC server started with "bzr start-xmlrpc", then it sends commands to the server and reads the response. The tests work the same way
[13:22] <bialix> so you have 2 concurrent processes. race condition?
[13:23] <RenatoSilva> I'm currently running one specific test in Eclipse, and I'm catching the above error in procmon, it seems unreleased lock but has no sense (why? how? when? who? etc)
[13:23] <bialix> perhaps raised error
[13:24] <bialix> logs are you friends
[13:24] <RenatoSilva> bialix: I don't understand how my anti-virus would be causing this without notifying anything....
[13:25] <RenatoSilva> bialix: besides I tried disabling it...
[13:25] <bialix> anti-virus monitor can start reading/checking new files therefore effectively blocking file deletion
[13:25] <RenatoSilva> bialix: 2 processes? why? what processes?
[13:26] <bialix> XML-RPC server = 1st process, client = 2nd process, right&
[13:26] <bialix> XML-RPC server = 1st process, client = 2nd process, right?
[13:26] <RenatoSilva> bialix: but if I disabled the monitor for a while, it would stop monitoring and therefore stop blocking, however shutting down the anti-virus didn't work :(
[13:27] <bialix> that's bad if it won't help
[13:27] <RenatoSilva> bialix: client does not access the temp repo afaik, it only sends commands to xml-rpc server and handles response
[13:28] <bialix> do you have some pastebin to show?
[13:28] <RenatoSilva> I don't know if it serves as a clue, but during the test, procmon reports 3 executions of bzr.exe with different command lines, let me see
[13:29] <RenatoSilva> bialix: I can give you may pastebins, you just have to choose of what exactly :D
[13:29] <bialix> I have no idea about your code
[13:29] <bialix> why you need to run bzr.exe 3 times?
[13:30] <RenatoSilva> I'm just an user/contributor
[13:30]  * bialix is not user even
[13:31] <bialix> RenatoSilva: sometimes tests written in linux way, so it's hard to understand what's wrong
[13:32]  * bialix don't understand Java either
[13:32] <RenatoSilva> bialix: I don't --need-- 3 times, I've --found-- it
[13:33] <bialix> so maybe this is error?
[13:33] <bialix> sometimes one strange error masked actual error
[13:33] <RenatoSilva> I wonder if for any reason and somehow another bzr.exe tries to do something in the same branch
[13:34] <RenatoSilva> The question is why it was working perfectly a few days ago....
[13:34] <bialix> oh, my favorite question
[13:35] <RenatoSilva> anything that I've done of different I tried to revert back
[13:36] <RenatoSilva> I reverted windows back to a previous state, before insatlling AVG9 (over 8.5) and updating windows
[13:36] <RenatoSilva> I had problems with that, but after fixing them, I've got it wroking
[13:37] <RenatoSilva> then while I was here talking to verterok a thsi week, it stopped working again
[13:37] <RenatoSilva> the only thing I could figure out have done different was that I cancelled mvn test in cmd line, and that verterok pushed a new lib version to repo that was dowloaded
[13:38] <RenatoSilva> So I tried to change permisssions of mvn, c:/program files, ~, etc....
[13:38] <RenatoSilva> tried to reinstall bzr and mvn, tried many things...and nothing....
[13:39] <RenatoSilva> I even installed recent windows updates one by one, like one of them was causing this, but no
[13:40] <RenatoSilva> Therefore, I don't even know what action caused this starting to happen
[13:40] <bialix> sorry, it seems I can't help here
[13:40] <RenatoSilva> I'm looking for someone with mvn + winxp sp3 updated [+ avg9] to try at least reproduce the problem
[13:41] <RenatoSilva> is bzr.exe.Local a bzr stuff?
[13:47] <bialix> bzr.exe.Local? no
[13:55] <RenatoSilva> bialix: there are mainly 2 kind of errors that randomly happen, first one is access denied about the lock
[13:55] <RenatoSilva> bialix: not sure but seconde one seems to happen when first one passes
[13:55] <RenatoSilva> bialix: 2nd is  unknown command "C:\Arquivos de programas\Bazaar\bzr.exe"
[13:56] <RenatoSilva> which is absolutely non-sense, the file exists
[13:56] <bialix> do you have this file?
[13:56] <RenatoSilva> it's bzr!
[13:56] <bialix> yes, I see it's bzr
[13:57] <bialix> if this string process be something like shlex.split you'll have a problem
[13:57] <bialix> much better if there will be forward slashes using
[13:57] <RenatoSilva> I mean, it's the one that works all the time, and exists all the time, it can't say it's unkonw (and worse, tell that *sometimes*)
[13:58] <RenatoSilva> about the bzr.exe count, don't know the right order but they are "bzr xmlversion --short", "bzr xmlplugins", and "bzr start-xmlrpc"
[13:59] <RenatoSilva> verterok: ^^^ does this give you any clue?
[14:00] <RenatoSilva> god, fatal error in procmon itself o.O
[14:03] <verterok> RenatoSilva: hi
[14:04] <RenatoSilva> verterok: hi, good morning :)
[14:04] <verterok> RenatoSilva: bzr-java-lib need to check the if xmloutput is installed and the version, and after that it starts the xmlrpc service
[14:06] <RenatoSilva> verterok: I've sent you a few emails
[14:07] <verterok> RenatoSilva: yes, reading them ATM :)
[14:24] <verterok> RenatoSilva: I just finished a deploy of bzr-java-lib snapshot to the maven repository, the snapshot num. is: bzr-java-lib-0.5.3-20091116.142139-1
[14:26] <verterok> RenatoSilva: actually, the connection timedout..hang on :)
[14:27] <RenatoSilva> verterok: man, 0.5.3 is in sync with the code? I don't understand how can bzr-eclipse bundle not work, but when you get the source code, it does
[14:28] <RenatoSilva> verterok: I mentioned this file in email:  http://verterok.com.ar/maven-repo/org/vcs/bazaar/client/bzr-java-lib/0.5.3-SNAPSHOT/bzr-java-lib-0.5.3-SNAPSHOT-sources.jar,
[14:28] <verterok> RenatoSilva: probably because of how it's started when executed from inside eclipse
[14:28] <verterok> RenatoSilva: hmm, that file shouldn't exists in the repository...
[14:28] <RenatoSilva> verterok: that file is not the latest code, and its related binary is expected to not be either
[14:29] <verterok> RenatoSilva: I'll delete all -SNAPSHOTs files
[14:30] <RenatoSilva> verterok: so you mean these source jars are not generated by the same process than the one for the binary version?
[14:30] <verterok> RenatoSilva: maven deployed snapshots use a timestamp
[14:30] <verterok> RenatoSilva: yes, but I missed the source generation (an extra parameter to mvn :/)
[14:32] <verterok> RenatoSilva: remvoe all -SNAPSHOT from your local maven repo and run 'mvn compile' in bzr-eclipse again :)
[14:32] <RenatoSilva> verterok: about the xml enc detection, cat is not done through xmlrpc, right? but there's no detection involved right, because it's not xml...
[14:33] <verterok> RenatoSilva: right, there is no xml
[14:33] <RenatoSilva> verterok: source code is working, I don't use bzr-java-lib jars in it
[14:34] <RenatoSilva> verterok: ok so I think for cat we'll have no problem, need to check just if there's any xmloutput command that is not run with XMLRPCCommandRunner
[14:34] <verterok> RenatoSilva: xmlplugins & xmlversion for sure
[14:36] <RenatoSilva> hmmm ok...
[14:37] <verterok> RenatoSilva: is the xmloutput plugin installed in a path with non-ascii name?
[14:37] <verterok> RenatoSilva: or bzr itself?
[14:37] <RenatoSilva> no
[14:37] <RenatoSilva> just spaces
[14:38] <verterok> RenatoSilva: run xmlversion in a cmd.exe, probably the log file is in your user dir
[14:40] <verterok> RenatoSilva: is there any non-ascii path?
[14:40] <RenatoSilva> verterok: bzr log seems ok, no error
[14:40] <RenatoSilva> verterok: non-ascii path where? you're talking about which email specifically? :)
[14:40] <RenatoSilva> oh xmlversion? let me see
[14:41] <verterok> RenatoSilva: no email :) the output of xmlversion
[14:43] <RenatoSilva> humm no, it is ascii-only
[14:43] <verterok> RenatoSilva: and xmlplugins?
[14:44] <RenatoSilva> the output is bigger, not sure how to check it, looking....
[14:45] <RenatoSilva> seems ascii-only too
[15:36] <aguafuertes> Hi, is somebody here who has 5 minutes to explain some Bazaar concepts that I could not figure out by reading the documentation?
[15:36] <RenatoSilva> maybe
[15:37] <aguafuertes> :) great
[15:37] <RenatoSilva> I said maybe :)
[15:37] <aguafuertes> ;)
[15:37] <aguafuertes> I try to set up a branch that I want to work an with one colleguae
[15:37] <aguafuertes> we are a Windows environment, I'm the only Ubuntu user
[15:38] <aguafuertes> I installed an ssh server on my machine
[15:38] <aguafuertes> my colleague tries to branch my work, but always receives the error "bzr: ERROR: Not a branch:"
[15:39] <aguafuertes> interestingly, when branching directly in the file system, everything works fine
[15:39] <Peng> Your colleague has SSH access to your machine?
[15:39] <aguafuertes> yes, I set up an extra user for him
[15:40] <aguafuertes> interestingly, I can branch via the file system without problrm
[15:40] <Peng> Huh. Um. Note that bzr+ssh:// paths are relative to the root, not the user's home directory (though you can use ~ for that on recent versions. Probably.)
[15:40] <aguafuertes> mm, ok, that is a good hint
[15:40]  * Peng goes /away again
[15:40] <aguafuertes> I'll try that first
[15:43] <aguafuertes> Peng, thanks so much!
[15:43] <aguafuertes> that was it :)
[15:44] <Peng> Really? It was? I'm surprised. Well, I'm glad it's fixed. :)
[15:44] <aguafuertes> yes, I simply assumed that the it would be relative to the ssh user's login
[15:44] <aguafuertes> is that somewhere in the documentation?
[15:45] <aguafuertes> if not, maybe it can be added for people like me, coming from a web developer background
[15:45] <aguafuertes> were we deal more with document roots ;)
[15:46] <mgedmin> bzr 2.0.2 (karmic ppa) burns and crashes (TooManyConcurrentRequests) if I try to bzr pull over ssh from a server running bzr 1.13
[15:47] <Peng> TooManyConcurrentRequests: The most useless error message ever, aside from "Segmentation fault".
[15:48] <mgedmin> nah, segfault is very informative
[15:48] <mgedmin> TMCR is ... interesting
[15:54] <mgedmin> hm, maybe this is because I'm using a checkout
[15:54] <Peng> You're trying to "bzr pull" inside a checkout? Don't do that. Use "update".
[15:54] <Peng> Although it obviously shouldn't fail with such an error...
[15:54] <Peng> File a bug?
[15:55] <mgedmin> I don't want to update
[15:55] <mgedmin> I'm pulling from a different branch, not the one I'm bound to
[15:55] <mgedmin> bug filed here: https://bugs.launchpad.net/bzr/+bug/483661
[15:56] <mgedmin> "don't do that" sounds like something to suggest to people who say "I'm trying to use bazaar"
[15:56] <LarstiQ_> Peng: hmm, it's valid if you want to pull into the branch you're bound to
[15:56] <mgedmin> fwiw bzr pull over http worked fine
[15:56] <mgedmin> I wonder if pull over ssh would work if the two branches lived on different hosts
[15:57] <mgedmin> hm, bzr pull over ssh works now that there are no changes to pull
[15:57] <mgedmin> lemme update the bug
[16:01] <mgedmin> anyway, found a workaround (pull over http), got ideas for other workarounds (bzr unbind; bzr pull; bzr push; bzr bind), hope you get the bug fixed sooner or later
[16:01] <mgedmin> cheers!
[16:36] <jam> is there a losa about that can create a bzr-2.1 branch for me?
[16:36] <mthaddon> jam: sure
[16:36] <jam> basically, just "bzr branch lp:~bzr-pqm/bzr/bzr.dev lp:~bzr-pqm/bzr/2.1" should be sufficient.
[16:37] <jam> thanks mthaddon
[16:37] <mthaddon> jam: is there an RT for this, or could you give me a quick run down on why it's needed?
[16:37] <jam> and, of course, setting up pqm to allow access to that (if anything needs to be done there)
[16:37] <jam> mthaddon: No rt (yet), needed because I'll be releasing 2.1.0b3 ~ today
[16:38] <jam> I'm going to try to use a 2.1 branch rather than 2.1.0b3 so that we don't have to pester you every month
[16:45] <mthaddon> jam: ok, should be good to go
[16:50] <jam> mthaddon: thanks. I did end up sending an RT request
[16:51] <jam> #36509
[16:51] <jam> if you want to tick off that you already finished it
[16:51] <mthaddon> thx
[18:09] <maxb> Is there a shortcut way to deal with merge conflicts where both sides added the same file with the same text content independently?
[18:10] <jelmer_> maxb: not really, the two files will have different file ids
[18:10] <jelmer_> and there is no way to join file ids
[18:10] <maxb> ok.... I was hoping for a "bzr resolve --obvious" :-)
[18:12] <vila> maxb: bzr resolve <file> should do it
[18:13]  * Tak bzr resolve --duh
[18:15] <maxb> How do I ask bzr to show me the log of a file according to the merge-source branch?
[18:15] <dOxxx> maxb: have you tried using kdiff3 as an external merge tool?
[18:16]  * maxb tries installing
[18:16] <maxb> bzr log a-filename -r branch:../../the-merge-source  makes bzr crash :-/
[18:17] <dOxxx> maxb: make sure you have the extmerge plugin for bzr installed if you want to use kdiff3
[18:17] <dOxxx> maxb: try bzr log -n1 filename ?
[18:18] <maxb> bzr: ERROR: Path unknown at end or start of revision range: debian/patches/svn2cl-upstream
[18:18] <dOxxx> hmm that one's out of my league :)
[18:19] <dOxxx> maybe try bzr log filename --include-merges
[18:19] <maxb> Sorry, this is an uncommitted merge in progress
[18:20] <dOxxx> oh...
[18:21] <bialix> bzr qlog shows pending merges
[18:21] <dOxxx> I suspect there isn't really an easy way to do it other than constructing a URL to the file using the merge-source URL
[18:21] <dOxxx> I stand corrected.
[18:22]  * maxb tries that
[18:22] <maxb> also, what do I do when bzr erroneously decides a file is binary?
[18:30] <bialix> maxb: there is opposite problem
[18:38] <bialix> maxb: do you still compare bzr and hg?
[18:38] <maxb> Yes. We are currently doing "should we switch from svn and if so what?" at work
[18:41] <bialix> any results so far?
[18:41] <Meths> maxb: Is your choice between anything other than git, hg and bzr?
[18:42] <maxb> Well, I seem to be the only person with truly strong opinions, so I'm driving the whole thing
[18:42] <bialix> maxb: many people likes bzr-svn plugin to work directly with svn and to soften the transition
[18:44] <maxb> Meths: Not really - we acknowledge that other things exist, but we don't really have any knowledge of others in house, so it's tricky to evaluate anything else without a lot of effort
[18:44] <maxb> bialix: Sadly, bzr-svn gets really very slow when all your company's code resides in a single svn repository
[18:44] <maxb> Meths: Why, is there something else that we should keep on the table? :-)
[18:45] <bialix> understand
[18:47] <Meths> maxb: NAFAIK.  They seem to be the only sensible options going forward, similar command sets, private sector supporters, Internet project space...
[19:22] <jam> bialix, garyvdm: Hey guys, I'm getting ready to put together 2.1.0b3 and wanted to know what qbzr version to bundle
[19:28] <jam> mthaddon: I just tried to submit to 2.1.0 and it tells me I'm not authorized to commit to that branch
[19:28] <jam> it is http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1.0 right?
[19:30] <dOxxx> looks like it's 2.1, not 2.1.0 ?
[19:33] <dOxxx> jam: bzr branch lp:bzr/2.1 works for me
[19:33] <jam> dOxxx: looks like you're right
[19:33] <jam> good enough I guess
[19:33] <jam> Probably the right thing anyway
[19:33] <jam> though I wish PQM's messages were better
[19:34] <jam> (not allowed to commit, versus branch doesn't exist)
[19:34] <dOxxx> I'm going by the Series 2.1 page on LP
[19:35] <dOxxx> it lists lp:bzr/2.1 as the branch
[19:35] <jam> dOxxx: yeah, and *I* just updated that :)
[19:35] <jam> just didn't notice the .0
[19:35] <jam> or lack thereof
[19:36] <jam> dOxxx: thanks for the pointer, it seems to be going now: http://pqm.bazaar-vcs.org/
[19:37] <dOxxx> cool :) I'm looking forward to being able to install 2.1.0b3 here so I can get the proxy fixes.
[19:45] <jam> dOxxx: well, those are also in 2.1.0b2 I believe
[19:45] <jam> and you only *need* 2.1.0b3 if you are running python2.4
[19:45] <dOxxx> jam: were there windows installers built for 2.1.0b2?
[19:45] <jam> yep
[19:46] <jam> not announced, but they are available
[19:46] <dOxxx> oh! I never saw them announced anywhere.
[19:46] <dOxxx> Where can I find them?
[19:46] <jam> I thought I would have 2.1.0b3 last Monday
[19:46] <jam> https://launchpad.net/bzr/2.1/2.1.0b2
[19:46] <jam> should have them
[19:46] <jam> though 2.1.0b3 will be out in the next day or two
[19:48] <dOxxx> I don't mind reinstalling ;)
[19:50] <KhaZ> Sorry if this is a basic question, but I just want confirmatino on what I'm about to do.  I've commited my 10th revision to a repository, but I'd like to temporarily bring my working tree back to revision 9.  Do I use bzr revert -R 9 to do this?
[19:51] <dOxxx> -r9
[19:51] <dOxxx> lowercase
[19:51] <KhaZ> OK, but revert doesn't actually force a commit, or revert in the repo or anything?
[19:53] <dOxxx> I believe so.
[19:53] <dOxxx> As I understand it, bazaar has a policy of not automatically committing changes.
[19:57] <KhaZ> Sweet.  The word 'revert' scares me.  :)  I'm used to Perforce lingo for syncing to a particular revision, so my first inclination was to bzr up, but that didn't seem to take a -r parameter.
[19:58] <dOxxx> yeah, that's update. I'm not actually sure when one would use update. checkouts?
[19:59] <KhaZ> I believe you use update when you want to pull chnages from the repo that someone has pushed
[20:01] <dOxxx> how does that differ from pull then?
[20:03] <Tak> update is for updating a working tree from the branch to which it's bound
[20:04] <Tak> pull is for pulling changes from one branch into another
[20:06] <dOxxx> bound is not the same as have a push branch set, right?
[20:07] <Tak> right
[20:07] <KhaZ> Stupid question, can I recursively revert somehow?
[20:08] <KhaZ> Oh, bzr revert * works for some reason, but I have to be down a level.  Weird.
[20:09] <Tak> doesn't `bzr revert` with no arguments do that?
[20:11] <KhaZ> I haven't the foggiest.  I'll try it out next time I need to do that. ;)
[20:11] <KhaZ> I wonder if that works with bzr add as well
[20:11] <KhaZ> I find bzr add * is nice to recursively add files, but it doesn't seem to respect files that are in bzr ignore
[20:12] <KhaZ> Maybe bzr add will respect that.. Hrmm.
[20:26] <jam> KhaZ: if you explicitly name a file with "*" then add will always add it
[20:26] <jam> bzr add .
[20:26] <jam> or bzr add
[20:26] <jam> will recurse from current dir down, or everything respectively
[20:26] <jam> respecting ignores
[20:26] <KhaZ> Ah, awesome.  SO bzr add or bzr add . will respect the ignore list?
[20:26] <jam> and yes "bzr revert" no args should revert the whole tree
[20:26] <jam> KhaZ: yes
[20:26] <KhaZ> Yeah, I figured bzr add * would not respect the ignore list, since technically I"m explicitly saying "add this!".
[20:26] <KhaZ> Awesome.  Good to hear.
[20:27] <dave_> I have a problem where I installed bzr on a windows comp and put some things under bzr, then the comp crashed. I can access the drive from linux, is there a way to get at those files?
[20:28] <jam> dave_: well, if you can get access to the drive, then generally you'll have access to the .bzr directory
[20:28] <jam> and you can "bzr branch /path/to/win32/"
[20:28] <jam> etc
[20:28] <dave_> and the .bzr directory isn't in the root directory, though, yes?
[20:30] <dave_> well, thanks
[20:32] <stuartpb> Uh, how am I supposed to install Bazaar on Slackware?
[20:33] <dOxxx> stuartpb: download the source distribution and 'python setup.py install' I think?
[20:34] <bialix> hi jam: please use qbzr 0.16 for 2.1.0b3
[20:34] <jam> bialix: sure
[20:34] <bialix> you're asked, me answered
[20:35] <bialix> gnight
[20:35] <dOxxx> I just got a very odd error when pushing to lp:
[20:36] <dOxxx> http://pastebin.com/m23fbb00c
[20:37] <dOxxx> when creating a local branch of bzrtools, I created it in a 2a shared repository
[20:37] <dOxxx> I guess bzrtools is not a 2a format branch and so stacking on it doesn't work?
[20:43] <jam> dOxxx: right, though if you do "bzr push -r -1" again it will push without stacking
[20:44] <jam> probably more accidentally than anything, but it should work
[20:44] <dOxxx> I'm trying to recreate my feature branch with the correct format
[20:45] <jam> I think bzrtools is in 1.9-rich-root, which means it should be able to merge any changes from a 2a format repo
[20:55] <dOxxx> yup, success :)
[20:56] <dOxxx> lp:~doxxx/bzrtools/shell-dir
[20:56] <fullermd> jam: Hey, I've got a Q or two...
[20:57] <jam> fullermd: QQ ?
[20:58] <fullermd> Nono, that's perl   8-}
[20:58] <jam> more pew-pew, less QQ fullermd
[20:58] <fullermd> Somewhat re that merge thing.  I was under the impression that when we merge3 on a criss-cross, it bleats at you and tells you to lca or weave.
[20:58] <jam> not exactly
[20:58] <jam> it still tries merge3
[20:58] <jam> it just bleats at you
[20:58] <jam> however, for the tree-shape info, etc
[20:59] <jam> we still use a common base
[20:59] <fullermd> But when I use -r0..-1 to force that merge to go through, it doesn't.  Is that because I explicitly -r'd, or because of the null LCA in that case, or something else?
[20:59] <jam> fullermd: you actually want "-r1..-1"
[20:59] <jam> but it doesn't bleat when you supply a base
[20:59] <jam> because it doesn't search for one
[20:59] <jam> yes
[21:00] <fullermd> Ah.  Should it?  In the real case, the criss-cross caused a lot of really ugly spurious conflicts.
[21:00] <fullermd> (using weave left it with 2 real ones)
[21:00] <jam> fullermd: so if you used "-r 1..-1" I would expect fewer conflicts
[21:00] <jam> though possibly you'd still end up with a bunch from side-2
[21:00] <fullermd> That wouldn't work in the real case, because r1 on both sides are totally unrelated.
[21:01] <jam> fullermd: sure, but supplying 0 is probably saying also look at all the changes from this side
[21:01] <jam> at least 1 skips that initial import
[21:01] <jam> anyway, only --weave and possibly --lca will work in this case
[21:01] <jam> since there is clearly no "clean" base
[21:02] <jam> fullermd: in case you didn't get my joke: http://www.urbandictionary.com/define.php?term=less%20qq%20more%20pew%20pew
[21:03] <fullermd> Anyway.  *I* know that, because I know (or would have known had I pondered it) that it was a criss-cross.
[21:03] <fullermd> It feels like bzr probably should have known to prompt me, though.
[21:03] <jam> well, it did warn you :)
[21:03] <jam> I've really wanted to get merge3 to use per-file merge bases
[21:03] <jam> which might get you out of this as well
[21:04] <jam> if the code bases were truly disjoint
[21:04] <fullermd> Not as such, it just dumped me a big pile of conflicts...
[21:04] <jam> ENOTUITS
[21:04] <fullermd> Actually, I thought the plan was just to make lca the default.  Did that just fall in the tuit hole, or are there reasons not to?
[21:04] <jam> well, if you specifically request -r0 we'll give you -r0
[21:04] <jam> at *this* point, *I* prefer --weave to --lca
[21:04] <jam> but I worked on --weave
[21:04] <jam> abentley worked on lca
[21:05] <jam> We've talked about changing
[21:05] <jam> but people also like getting .THIS .OTHER .BASE files
[21:05] <jam> which is why people like mysql use --merge3 most of the time
[21:05] <fullermd> Going back and retrying the real branches with 1..-1 instead of 0..-1 doesn't make any visible difference on the conflicts.
[21:06] <fullermd> 8 conflicts encountered.   one way and   20 conflicts encountered.  the other.
[21:07] <fullermd> (and actually, I think one of the real ones is spurious, but I s'pose it's possible bzr can't really tell.  1 of them is real.)
[21:07] <fullermd> Anyway.
[21:08] <fullermd> I also got an eye-twitch at that btree padding change.  Could that trip up pre-2.1 versions?
[21:08] <jam> fullermd: shouldn't
[21:08] <jam> we never read those bytes
[21:08] <fullermd> (I have no reason necessarily to believe it does, it just caught my eye as something that played in that court)
[21:09] <jam> we allow a single page to be <4096 bytes
[21:09] <jam> we reserve 120 bytes at the start
[21:09] <jam> but if it is less than that
[21:09] <jam> we write the info right away
[21:09] <jam> and pad at the end to make up the loss
[21:09] <jam> and generally we just throw away those bytes anyway
[21:10] <jam> so the change was to just not write the
[21:10] <jam> them
[21:12] <fullermd> Good 'nuff for me.
[21:12] <fullermd> Danke.
[21:13] <jam> fullermd: any more Q.Q ?
[21:13] <jam> or :,( :)
[21:13] <jam> :'( I mean
[21:14] <fullermd> Well, I'm massively piled up and way behind at work.  Does that count?
[21:14] <fullermd> But I'm hopeful that if I can get a good long day in today, I can take care of the stuff we need for the Oct 30 deadline and start looking at what we need for the Nov 16 one...
[21:14] <jam> fullermd: could you put that in the form of a QQ?
[21:15] <jam> fullermd: so only 2 weeks behind?
[21:15] <jam> I've certainly been far worse than that
[21:15] <fullermd> Well, so far...
[21:16] <fullermd> We've still got almost a month until the hard deadline when the whole thing has to be done.
[21:27] <lifeless> fullermd: what are you working on?
[21:32] <jam> morning li
[21:32] <jam> lifeless:
[21:32] <jam> ^^
[21:33] <fullermd> Oh, it's just $CURRENT_PROJECT.  The client has their big annual convention thingy in December, and we're supposed to have this all ready for them to show off then.
[21:33]  * fullermd is losing optimism.
[21:33] <vila> fullermd: yeah, next time I have to debug some ntp stuff, I'll be sure to not ask you (two weeks... and you were criticizing my VMs getting some *hour* skew... sheesh)
[21:34] <vila> :-p
[21:34]  * vila refocus on the session :)
[21:34] <fullermd> Hey, *I* know what time it is.  's not my fault my clients are getting ahead   :P
[21:34] <kfogel> is there any documentation on tags in bzr?  Google turns up pages about their existence, but http://doc.bazaar-vcs.org/latest/en/search.html?q=tags gives pretty thin results...
[21:38] <lifeless> kfogel: bzr help tag
[22:54] <spiv> Good morning.
[23:01] <igc> morning
[23:05] <lifeless> aloha
[23:10] <spiv> Hey wow, a bug report about TooManyConcurrentRequests that's actually due to bzr attempting to make concurrent requests on an HPSS connection.
[23:18] <Peng> ...Wow.
[23:19] <Peng> And I joked about that bug this morning. Whoops.
[23:31] <poolie1> biab
[23:31] <poolie1> hello jam, vila
[23:43]  * spiv boggles as a bug search for "hpss upgrade" fails to find a bug with tags of "hpss" and "upgrade"
[23:43] <fullermd> jam: (btw, looking back at it, merge -r1..-1 would have been a really bad idea, since it's a cherry pick)
[23:43] <spiv> Or any bugs, in fact.
[23:43] <fullermd> Hey, cool, that means the hpss upgrade is perfect!
[23:44] <spiv> fullermd: 107173 disagrees :P
[23:44] <fullermd> Pfft.  Who you wanna believe, 107173 or LP?
[23:49] <dOxxx> spiv: going through bzr merge proposals?
[23:54] <spiv> dOxxx: yup
[23:54] <dOxxx> must be a pile of work
[23:54] <spiv> Yeah, but we get bug fixes and other improvements out of it :)
[23:55] <spiv> Which is going to be work one way or another ;)
[23:55] <dOxxx> yep
[23:56] <poolie> hi spiv
[23:57] <poolie> spiv, it might be good to send a brief reply to the pilot thread just saying you're doing it and how it's going
[23:59] <spiv> Yeah, that's a good idea.  Although I did just send a similar mail in reply to a related thread.
[23:59] <poolie> i saw
[23:59] <poolie> but people don't read all mail
[23:59] <poolie> sending _more_ mail is a questionable fix :-) but i think worthwhile here
[23:59] <spiv> :)