[02:30] <duflu> kdub_: Hello?
[03:12] <kgunn> duflu: he's actually US eastern standard time (he moved back to michigan)....so its 11pm there
[03:13] <kgunn> just for future reference
[03:13] <duflu> Ah. Forgot
[03:13] <duflu> kgunn: How long for?
[03:13] <duflu> Oh "moved"
[03:13] <kgunn> duflu: yeah...for the foreseeable future
[08:35] <alan_g> alf_: (non-urgent) does the latest version work for you? https://code.launchpad.net/~mir-team/mir/enable-late-release/+merge/227178
[08:44] <alf_> alan_g: yes, although I think that if the failure is consistently reproducible we could have a test for this, checking the process exit status, like we do e.g. for ServerShutdown removes_endpoint_on_signal (but checking for a successful exit)
[08:44] <alf_> alan_g: not sure about any blocking details though
[08:47] <alan_g> alf_: In principle, we could add a test that execs (say) the new test program. In practice, we need to be sure that it exists somewhere to be run. FWIW There are other tests like this I'd like to run but haven't built the infrastructure.
[08:51] <alf_> alan_g: what stops us from just using launch_client_process(client_config) instead of an external client?
[08:53] <alan_g> alf_: I guess that might work, but remember it calls exit() in the teardown code instead of exiting from main() - a scenario with potentially significant differences
[08:54] <alf_> alan_g: ok (in any case, test not a blocker, but a nice-to-have)
[08:56]  * alan_g feels increasing motivation to write yet another test execution framework
[09:15] <alan_g> RAOF: are your (blocking) concerns addressed? https://code.launchpad.net/~mir-team/mir/libmircommon/+merge/226704
[09:26] <alf_> anpok: did you file a bug about Mir not showing the latest frame in some cases?
[09:51] <alan_g> camako: are your concerns addressed? https://code.launchpad.net/~mir-team/mir/libmircommon/+merge/226704
[09:51]  * camako checks
[09:54] <camako> alan_g, yes.. approved
[09:54] <alan_g> thanks
[09:55] <camako> np
[10:03] <anpok> alf_: no I reflashed the device, another time and the issue was gone
[10:03] <anpok> -,
[10:04] <alf_> anpok: do you remember how to (try to) reproduce the issue?
[10:04] <anpok> alf: pin entry dialog - since there is no animation/blinking cursor
[10:31] <alf_> I am cross-compiling libmirserver23 from pristine trunk and copying the shared object to the phone, but unity8 crashes when using it (usc works normally)
[10:31] <alf_> Has anyone seen that?
[11:18] <duflu> alf_: Development branch is libmirserver24 :)
[11:18]  * duflu goes into hiding
[12:11] <greyback> anpok: ping
[12:24] <anpok> greyback: pong
[12:24] <anpok> greyback: thinking about injecting input?
[12:25] <greyback> anpok: slightly different topic, we're getting a crash with QtComp, wanted to ask your advice
[12:25] <greyback> anpok: crash happens running with autopilot, so apps are stopped & started very rapidly
[12:26] <greyback> and input events can be injected after the surface has been destroyed
[12:26] <greyback> anpok: http://pastebin.ubuntu.com/7835652/ is the stacktrace I get
[12:28] <greyback> could it be that if QtComp tries to send event to client which has stopped, but mir hasn't fully cleaned up after it, mir could call mir::AsioMainLoop::register_fd_handler to create a fd for that client again?
[12:29] <greyback> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
[12:29] <greyback>   what():  assign: File exists
[12:29] <greyback> is the exception thrown
[12:29] <anpok> greyback: hm not calling surface->consume?
[12:30] <greyback> anpok: we should be. BT doesn't seem to show that though
[12:30] <anpok> ok
[12:30] <greyback> compiler might have inlined it?
[12:30] <anpok> hm cool devirtualization
[12:37] <anpok> hm we are not creating a fd there..
[12:49] <greyback> anpok: any ideas/theories?
[13:01] <anpok> hm i am following the call down to asio
[13:02] <anpok> the constructor seems to register the fd with the epoll fd
[13:02] <anpok> i would have assumed that happens some time later
[13:03] <anpok> EEXIST -> the supplied file descriptor fd is already registered with this epoll instance..
[13:04] <anpok> do we have strace logs?
[13:08] <greyback> anpok: they can be got. I can also show you how to reproduce, whatever you like
[13:09] <anpok> oh then i take option 2
[13:10] <greyback> ok. Install the qtcomp silo (https://wiki.ubuntu.com/Unity8/QtComp)
[13:10] <greyback> then we want to run an autopilot test suite
[13:10] <greyback> so
[13:10] <greyback> https://wiki.ubuntu.com/Unity8/QtComp
[13:10] <greyback> oops
[13:10] <greyback> phablet-config edges-intro --disable
[13:11] <greyback> adb shell powerd-cli display on bright&
[13:11] <greyback> phablet-test-run -p ubuntu-html5-ui-toolkit-autopilot ubuntu_html5_ui_toolkit
[13:11] <greyback> the last command should run the test. You'll see an app start & stop repeatedly
[13:12] <greyback> I often get the crash during the test suite run
[13:13] <greyback> and it's always after a stream of key events that it crashes
[13:16] <dandrader> greyback, anpok, I got a bt with a tad more details http://paste.ubuntu.com/7836063/
[13:36] <anpok> there is a race but not yet sure how to fix it
[13:45] <dandrader> anpok, a race between who?
[13:48] <anpok> i guess between unregistering an fd and registering another one with the same fd number..
[13:51] <anpok> ah no the fd is kept alive through the InputChannel even when the surface is gone
[14:23] <kdub_> anpok, maybe the new fd type would help :)
[14:44] <racarr_> Morning
[14:45] <anpok> greyback, dandrader: do we have ticket for that issue yet?
[14:45] <greyback> anpok: no
[14:45] <greyback> I can log one
[14:47] <dandrader> ticket?
[14:48] <greyback> bug
[14:49] <anpok> dandrader: wording of my past...
[14:49] <anpok> that sometimes creeps into present
[14:49] <dandrader> :)
[14:51] <anpok> hm trying to reproduce but I dont think that I get the error that I should get -
[14:52] <anpok> 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[14:52] <anpok>   what():  Failed to send message to server: Bad file descriptor
[14:54] <greyback> anpok: https://bugs.launchpad.net/mir/+bug/1346952
[14:54] <greyback> anpok: hmm no, I reliably get a different error
[14:54] <greyback> s/reliably/always/
[14:59] <anpok> you always get the other exception message from above?
[15:02] <dandrader> I do
[15:27] <racarr_> need one more review on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731
[15:27] <racarr_> cemil says he doesnt count as a proper review
[15:27] <racarr_> :p
[15:39] <groot_> I'm trying to port UT in my device, device boots but unity-system-compositor is failing all the time. I've the similar issue as posted here https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-session/+bug/1283326/comments/3
[15:39] <racarr_> what is most recent qtcomp ppa/silo/thing I can install on my phone?
[15:39] <groot_> and here https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-session/+bug/1283326/comments/4
[15:39] <racarr_> trying to avoid rebuilding the whole stack while testing some things
[15:40] <groot_> what should I do to fix this ?
[15:41] <dandrader> anpok, the crash is happening during a long and rapid stream of key events
[15:41] <dandrader> anpok, as autopilot generates those key events synthetically
[15:43] <greyback> racarr_: https://wiki.ubuntu.com/Unity8/QtComp - silo6
[15:44] <dandrader> but I guess you already know this as you're able to reproduce it locally (event if it not yields the same crash)
[15:44] <groot_> Please, anyone can give me a solution? I've some logs if anyone wants to see :)
[15:46] <racarr_> greyback: Ah thanks
[15:46] <racarr_> greyback: Going to add touchspots
[15:46] <racarr_> to qtmir/unity8
[15:47] <greyback> racarr_: why?
[15:47] <racarr_> unless you happen to be jumping with joy for new tasks
[15:47] <racarr_> I figured I had some time to do it
[15:47] <racarr_> thomi wants it
[15:47] <racarr_> to assure quality
[15:47] <greyback> racarr_: I was expecting them to be partof USC
[15:48] <greyback> groot_: I'm guessing that unity-system-compositor didn't start up. You need to investigate if Mir works on your device. Get the "mir-demos" package and try out mir_demo_server_shell and some demo clients with it
[15:48] <racarr_> I mean they could be....bar some other stuff that is taking a while
[15:48] <racarr_> but I kind of feel like why not QML lol
[15:48] <racarr_> because you probably want them to fade or pulse or burn on fire something
[15:48] <greyback> racarr_: MultiPointTouchArea is your friend then
[15:48] <racarr_> not you personally
[15:48] <racarr_> lol
[15:49] <greyback> I want them with particle effects
[15:49] <racarr_> greyback: Oh thats one way...
[15:49] <racarr_> I added a new
[15:50] <racarr_> TouchspotVisualizer interface actually that juset gives raw pressure/point...
[15:50] <racarr_> before they become input events or anything (down at input reader level)
[15:50] <groot_> greyback, thanks. Before I do that, can you take a look at some logs? Maybe this'll help you find the exact problem.
[15:50] <racarr_> so plan was to add an interface for that to qtmir
[15:50] <greyback> sounds complicated. MulitPointTouchArea is very easy
[15:51] <racarr_> hmm *goes to read*
[15:52] <greyback> groot_: show me the logs. I'm not much good to you if mir doesn't work, I'm not a core mir developer
[15:53] <groot_> greyback, no problem. here's syslog http://paste.ubuntu.com/7836697/
[15:53] <groot_> lightdm.log http://paste.ubuntu.com/7836703/
[15:54] <groot_> unity-system-compositor strace http://paste.ubuntu.com/7836711/
[15:54] <ogra_> greyback, i think handholding him through running the test apps might be a start (i sent groot_ here after checking his logs)
[15:55] <groot_> ogra_, you're right :)
[15:56] <greyback> groot_: seems mir fails with "Bad file descriptor" - suspect you'll need someone with more core mir knowledge than I.
[15:57] <racarr_> groot_: We will need to try the demo servers like greyback described to get something more
[15:57] <greyback> groot_: but do install the mir-demos package, and try running the mir_demo_*_shell programs to see if they work
[15:57] <racarr_> specific...the bad fd error is too weird...if you read
[15:58] <racarr_> its a bad fd calling epoll_ctl on two fds which were just created, one an epoll, and one a timer
[15:58] <racarr_> and...I dunno that seems reasonable lol.
[15:58] <racarr_> so hard to get much out of the logs
[15:59] <groot_> greyback, as ogra said, you may have to help me with this demo run :|
[15:59] <groot_> racarr_, ^^
[16:00] <Saviq> AlbertA, hey, I found that if unity-system-compositor crashes, power button wake doesn't work any more
[16:00] <racarr_> groot_: First you need mir-demos then you can run a mir instance
[16:00] <racarr_> i.e. mir_demo_server_shell &
[16:00] <racarr_> and then pick a client i.e. mir_demo_client_*
[16:01] <AlbertA> Saviq: this should help: https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1343919/+merge/227645
[16:01] <AlbertA> alf_: I've updated https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1344101/+merge/227641
[16:02] <groot_> racarr_, via ADB, right? I've to install mir-demos in desktop and run instance through adb ?
[16:02] <alf_> AlbertA: just looking at that... so the power menu has exactly the same issues the greeter (may not have enough time to render and stale frame)
[16:03] <racarr_> groot_: No adb in and then install mir-demos on phone
[16:05] <alf_> AlbertA: perhaps we should apply the workaround you mentioned for the greeter (waiting a bit more to turn on the screen) for the power menu too. So if unity8 shows the menu after 2000ms perhaps we should turn on the screen after 2200ms (or something)?
[16:05] <AlbertA> alf_: so what are you seeing now?
[16:06] <groot_> racarr_, for that I need net connection, right?
[16:06] <groot_> racarr_, it's failing "E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/universe/m/mir/mir-demos_0.4.1+14.10.20140714-0ubuntu1_armhf.deb  Could not resolve 'ports.ubuntu.com'" :(
[16:07] <racarr_> groot_: Yeah...
[16:07] <racarr_> downnload on desktop
[16:07] <racarr_> and adb push :)
[16:07] <racarr_> should be fine
[16:09] <alf_> AlbertA: hmm, I thought I was seeing "power menu hasn't rendered yet" effect, but I now think it's the stale frame effect (I am seeing the greeter momentarily before the power menu shows up)
[16:09] <AlbertA> alf_: ahh, right
[16:09] <alf_> AlbertA: so I am not sure the extra timeout would help
[16:10] <AlbertA> alf_: well I think it would help
[16:10] <AlbertA> alf_: because the dialog doesn't start drawing itself
[16:10] <AlbertA> until that 2s alarm fires
[16:14] <racarr_> alf_: Hey...something I've been meaning to ask.
[16:15] <racarr_> Is there any generic way to write to GBM bos without using an opengl context? gbm_bo_write only works for the dumb bos...
[16:15] <racarr_> which only work for the cursor bo.
[16:15] <racarr_> which has the whole no DRI image problem so you can't EGLCreateImage (as you encountered doing software I guess)
[16:16] <racarr_> The thing is. I can't actually use the cursor buffer for the cursors or touchspots
[16:16] <alf_> AlbertA: YMMV, 2200 doesn't make much of a difference, but 2500 is better: the "not rendered yet" effect is gone, but we occasionally get a stale greeter frame
[16:16] <racarr_> because software wont work on it
[16:16] <racarr_> err
[16:16] <racarr_> not software
[16:16] <racarr_> GL
[16:16] <racarr_> lol
[16:18] <racarr_> I could just use software buffers but then
[16:18] <Saviq> AlbertA, oh cool
[16:19] <racarr_> no overlay on HWC for touchspots
[16:19] <groot_> racarr_, installed mir-demos from here https://launchpad.net/ubuntu/utopic/armhf/mir-demos/0.4.1+14.10.20140714-0ubuntu1
[16:19] <AlbertA> alf_: yeah it looks better with 500ms...
[16:19] <AlbertA> alf_: so would this suffice?  http://paste.ubuntu.com/7836986/
[16:19] <racarr_> groot_: Ok seems about right! So are you able to run mir_demo_server_shell
[16:19] <groot_> which command should I run now?
[16:20] <AlbertA> alf_: or just run another alarm?
[16:20] <groot_> racarr_, ran it but got "segmentation fault (core dumped)"
[16:22] <racarr_> groot_: Can you grab a backtrace with gdb? May have to use the same trick to install it
[16:22] <alf_> AlbertA: Why not make the timeout itself 2500? I don't like too many things running concurrently :)
[16:22] <AlbertA> alf_: because if the screen is on...
[16:22] <AlbertA> alf_: and the dialog shows up, you can let go of the button (so power key up)
[16:23] <AlbertA> before the 2.5 second alarm goes on
[16:23] <AlbertA> i.e. in between 2 and 2.5s
[16:23] <AlbertA> so basically that would turn off the screen
[16:23] <alf_> AlbertA: ahh, right, and the screen would go off
[16:24] <groot_> racarr_, mir_demo_server_shell& gives no error. gdb command is available in phone. What command should I run?
[16:24] <alf_> AlbertA: well, I am OK with the thread if we know that screen_state_handler->set_screen_power_mode() is thread safe
[16:25] <racarr_> groot_: gdb mir_demo_server_shell
[16:25] <racarr_> then run
[16:25] <racarr_> then bt
[16:26] <alf_> racarr_: @"Is there any generic way to write to GBM bos without using an opengl context", no that I know of
[16:28] <groot_> racarr_, it's giving "No stack" output.
[16:28] <alf_> racarr_: do you want to avoid rendering with GL because of the hassle or because there is some problem with it?
[16:32] <alf_> AlbertA: EOD, so preapproving MP to unblock
[16:32] <racarr_> alf_: Mostly because of the hassle and in particular the hassle of
[16:32] <alf_> AlbertA: do what you think is best :)
[16:32] <racarr_> using opengl outside of the renderer
[16:34] <AlbertA> alf_: yeah it's thread safe...but I think I will just setup another alarm
[16:36] <greyback> groot_: just to confirm, you ran "gdb mir_demo_server_shell" and after a brief loading period, ended up at a command line. You entered "run", hit enter, and you should have seen some output about threads, then it stopped with a error? Did you enter "bt" then?
[16:38] <groot_> racarr_, my bad sorry. Here's the output http://paste.ubuntu.com/7837084/
[16:38] <groot_> greyback, thanks for pointing out
[16:38] <racarr_> groot_: Hmm
[16:38] <racarr_> something with your driver is unhappy ;)
[16:38] <racarr_> surprise!
[16:39] <racarr_> kdub_: ^ does that mean anything to you?
[16:39] <racarr_> the stack trace
[16:39] <greyback> groot_: good luck with it, you've gone into alien territory for me ;)
[16:41] <racarr_> the segfault being at 0x0 kind of makes me think its deferencing one of the android device functions...hard to tell without debug info in libmirplatformgraphics
[16:42] <racarr_> I can't find...our debug symbol packages
[16:42] <groot_> greyback, don't say that. I've already spent a month trying to port ;)
[16:42] <greyback> racarr_: http://ddebs.ubuntu.com/pool/main/m/mir/
[16:43] <greyback> groot_: nah, hopefully these guys can help you. I just know nothing about working with the android drivers
[16:45] <racarr_> greyback: Thanks :)
[16:45] <racarr_> groot: If you install the package for libmirplatformgraphics-android from http://ddebs.ubuntu.com/pool/main/m/mir/
[16:45] <racarr_> that corresponds to the version you see from
[16:45] <racarr_> apt-cache policy libmirplatformgraphics-android (on the phone)
[16:45] <racarr_> then repeat the gdb experiment
[16:45] <racarr_> can get a little more info
[16:46] <racarr_> android drivers are not my expertise either, but maybe we can at least distill it down in to a bug report with exactly what is going wrong or some such
[16:48] <groot_> racarr_, thanks. just because you're looking at it gives me hope :). I'll try and let you know after a while.
[16:48] <racarr_> groot_: Cheers :D
[16:48] <racarr_> what kind of device is it?
[16:48] <racarr_> (just curious)
[16:49] <groot_> Sony Xperia U. First android series from sony ;)
[16:51] <racarr_> Ah cool :) that shouldnt be too old or anything
[16:59] <kdub_> groot_, reading through now...
[17:00] <kdub_> lunchtime is over :)
[17:03] <groot_> kdub_, thanks :). I'm installing libmirplatformgraphics now
[17:03] <kdub_> great
[17:03] <kdub_> so it looks like "bad file descriptor" is thrown from mir
[17:04] <groot_> yes
[17:04] <kdub_> it could just be having the mesa platform installed
[17:04] <kdub_> which I assume you're installing the android one
[17:04] <racarr_> kdub_: Look at the segfault from mir_demo_server_shell though
[17:05] <racarr_> http://paste.ubuntu.com/7837084/
[17:05] <kdub_> hmm, yes, more tricky
[17:06] <kdub_> was it run as root? sometimes we have to change udev permissions
[17:07] <groot_> racarr_, here's the output http://paste.ubuntu.com/7837213/
[17:07] <groot_> kdub_, ^^
[17:09] <kdub_> well, thats interesting
[17:10] <groot_> I'll be back in 5 mins. Thanks for looking at it guys :)
[17:13] <racarr_> I guess it means the hwc_composer_device struct
[17:13] <racarr_> is bbad
[17:13] <racarr_> or at leat this callback is
[17:13] <racarr_> 0x0
[17:13] <racarr_> or something...lol
[17:16] <kdub_> racarr_, yeah, thats what I think too.. probably some workaround though
[17:20] <groot_> I'm back. So, it can be fixed right ? :)
[17:21] <kdub_> groot_, maybe :D are you able to compile/test patches?
[17:22] <groot_> kdub_, I'll do anything if you walk me through it :P
[17:24] <kdub_> groot_, its slightly involved, but basically, if you download lp:mir/0.5
[17:25] <kdub_> and then run cross-compile-chroot.sh, that should try to cross compile for the device
[17:25] <racarr_> (bzr branch lp:mir/0.5)
[17:25] <kdub_> and at that point, we can just cherry-pick a library file and push it to the device (not much abi breakage)
[17:28] <groot_> downloading right now. my net is very slow today :(
[17:30] <kdub_> well, the script will go and download a bunch of arm packages and put them in a folder, so not a good day for slow net :)
[17:31] <groot_> kdub_, is there a way to directly download the source without using bzr ?
[17:31] <kdub_> not that I know of
[17:32] <kdub_> and groot_ what's the resolution of the device?
[17:32] <kdub_> i'll leave a patch for you to try if I'm not around
[17:32] <kdub_> with my first idea
[17:32] <groot_> 480 x 854
[17:32] <kdub_> cool
[17:34] <racarr_> out for lunch will be back soon though
[17:35] <groot_> racarr_, yup come soon :p
[17:35] <groot_> dl speed is now 0 !! :(
[17:55] <kdub_> groot_, well, my first shot at figuring out what is wrong is here: lp:~kdub/mir/sony-experiment
[17:55] <kdub_> (just hardcoding some stuff to see if that gets a sane mir environment)
[17:55] <groot_> kdub_, looks like it'll take a while to download the source :(. Will you be available ?
[17:56] <kdub_> a few more hours
[17:57] <groot_> hopefully it'll be complete by then
[17:59] <groot_> very dirty hack :D
[18:17] <groot_> kdub_, is this the correct source https://launchpad.net/mir/0.5/0.5.0/+download/mir-0.5.0.tar.bz2
[18:18] <kdub_> ah, good to know
[18:18] <groot_> downloaded :)
[18:19] <groot_> kdub_, what should I do now ?
[18:20] <kdub_> install the arm cross compiler (g++-4.9-arm-linux-gnueabihf) and try that script (cross-compile-chroot.sh) in the root dir
[18:21] <groot_> first modify framebuffers.cpp like yours?
[18:23] <groot_> kdub_, ^^
[18:24] <kdub_> yeah
[18:28] <groot_> kdub_, I download this one http://packages.ubuntu.com/utopic/amd64/g++-4.9-arm-linux-gnueabihf/download
[18:28] <groot_> but got error "dependency problems - leaving unconfigured"
[18:29] <kdub_> just use apt-get
[18:30] <groot_> kdub_, E: Couldn't find any package by regex 'g++-4.9-arm-linux-gnueabihf'
[18:30] <groot_> guess it's not in the source.list
[18:30] <kdub_> oh, /me is on utopic
[18:31] <kdub_> you could probably try 4.8 (provided the ubuntu touch image is trusty too)
[18:32] <groot_> kdub_, I'm using utopic image
[18:33] <kdub_> the point here :) is that the toolchain version of the host cross compiler should match the version of the phone device image
[18:38] <groot_> kdub_, it says to add the mirror to sources.list. http://packages.ubuntu.com/utopic/amd64/gcc-4.9-arm-linux-gnueabihf/download
[18:38] <groot_> Maybe then I can use apt-get
[18:38] <groot_> I'll try
[18:38] <kdub_> sounds like a good suggestion
[18:46] <kdub_> gmock incantations
[18:48] <groot_> kdub_, still got unmet dependency error :(
[18:49] <kdub_> groot_, maybe apt-get -f install? otherwise, out of suggestions
[18:52] <groot_> kdub_, did that, no change. I just started the cross-compile-chroot.sh. I'll let you know what happens
[18:52] <kdub_> if you dont have the cross compiler, it'll fail
[18:53] <racarr_> back
[18:55] <groot_> kdub_, it's retrieving many things from net. How can I check if I've any cross compileer installed?
[18:55] <groot_> racarr_, welcome back :)
[19:01] <groot_> kdub_, my desktop has 14.04 but phone's got 14.10. So 4.8 or 4.9 compiler?
[19:02] <kdub_> 4.9 i suppose
[19:09] <groot_> kdub_, looks like 4.9 is for 14.10 :(. I'll try with 4.8. What should I expect if all goes smoothly ?
[19:10] <kdub_> something on the screen if running that demo shell
[19:10] <groot_> kdub_, I meant after compilation. What files should I push back to phone ?
[19:11] <kdub_> the other scripts have an enumeration
[19:14] <groot_> kdub_, sorry, I don't understand.
[19:14] <kdub_> the deploy-and-test script
[19:37] <groot_> kdub_, I've to go. Will you be available tommorrow at the same time ?
[19:38] <kdub_> yep
[19:39] <groot_> kdub_, then I'll try to compile within this time. Thanks for everything you've done :)
[19:39] <groot_> I'll check back tommorrow
[19:40] <kdub_> cool
[19:41] <groot_> OK, bye.
[20:15] <AlbertA> ummm, why would an alarm not fire
[20:15] <AlbertA> when coming out of deep suspend...
[20:15] <racarr_> uhoh
[20:15] <AlbertA> so I get the power key down event....which schedules an alarm
[20:15] <AlbertA> that never fires...but only when out of deep suspend...
[20:16] <kdub_> (wild guess) hardware timer got suspended?
[20:17] <racarr_> sorry so its like
[20:17] <racarr_> you set alarm then
[20:17] <racarr_> suspend then come back
[20:17] <racarr_> and alarm doesnt fire, or what?
[20:17] <AlbertA> you suspend...
[20:17] <AlbertA> screen goes off
[20:17] <AlbertA> then you press and hold the power key
[20:17] <AlbertA> so I get a power key down event
[20:18] <AlbertA> so it should be out of suspend...
[20:18] <AlbertA> which then schedules an alarm
[20:18] <AlbertA> that doesn't trigger
[20:18] <racarr_> how are you getting power key down events while its suspended
[20:18] <racarr_> you mean early suspend
[20:18] <racarr_> ?
[20:18] <AlbertA> kernel
[20:18] <AlbertA> usually hooks up the power key
[20:18] <AlbertA> to wake it up
[20:18] <AlbertA> and take it out of suspend
[20:19] <racarr_> oh ok lol
[20:19] <racarr_> hmm
[20:19] <AlbertA> maybe an early resume issue
[20:20] <AlbertA> like kdub_ said...maybe the hw timers are not brought up yet
[20:21] <AlbertA> also something else is waking the screen up before USC actually does
[20:22] <racarr_> hw timers not up yet is weird youd think]
[20:22] <racarr_> someone could give you an error
[20:22] <racarr_> my only other guess is maybe some funny signals flying around that mess things up...
[20:23] <racarr_> ...cant think of anything specific
[20:23] <racarr_> hmm
[20:40] <AlbertA> so apparently it is an early resume thing....
[20:41] <AlbertA> if I wait for powerd to broadcast that it's completely out of suspend before scheduling the alarms...then the alarms fire just fine
[21:01] <racarr_> AlbertA: Very weird...wonder what the rules are
[21:07] <AlbertA> nevermind...it wasn't going to deep suspend that time
[21:08] <AlbertA> so alarm still doesn't fire...weird...
[22:18] <AlbertA> oooh....
[22:18] <AlbertA> why do I get
[22:18] <AlbertA> a power key down and up at the same time?
[22:18] <AlbertA> after coming out of suspend
[22:19] <AlbertA> that's what was cancelling my alarm...
[22:19] <AlbertA> don't know what to do about it though...
[22:20] <racarr_> AlbertA: maybe its the power key up from before
[22:20] <racarr_> you suspend?
[22:20] <racarr_> I guess
[22:20] <racarr_> you suspend on up
[22:20] <racarr_> nvm
[22:21] <AlbertA> right it suspends after power key up is received
[22:55] <AlbertA> umm I don't remember this happening with powerd... which used a more recent version of the android input stack...
[23:52] <racarr_> anyone want any reviews or anything before I end my core day?
[23:52] <racarr_> the active reviewsd is actually kind of benign right now wow
[23:59] <RAOF> :)


[12:05] <ubotu> New bug: #137387 in bzr "Strange error message decorating the output of bzr status" [Undecided,New]  https://launchpad.net/bugs/137387
[12:18] <keir> lifeless: sorry to interrupt your deep hacking. it seems all that's stored in the index layer (the values) are integers. do we actually want to store arbitrary strings?
[12:30] <lifeless> keir: there is a layering concern here
[12:30] <lifeless> right now there is a boolean and two ints stored in the product values
[12:31] <keir> lifeless, i see
[12:31] <lifeless> I would be ok with making them into structured data rather than strings if there is a tangible win; otoh it makes the index less able to be reused - e.g. the pack-names index will need to be different
[12:31] <keir> lifeless,  i am just wondering, because it is potentially useful if there is a fixed-size-data case
[12:31] <lifeless> (it currently stores 4 ints)
[12:32] <keir> in my attempts to compress data structures, i've been known to reuse the lower bits of pointer addresses to store booleans :)
[12:33] <keir> my other question: are most uses repeated traversals?
[12:33] <keir> and why is it in the code you posted above, that it only traverses the first one?
[12:33] <lifeless> our knit deltas are deltas against one parent
[12:34] <lifeless> there are two parent-lists per node in the .tix
[12:34] <lifeless> one parent-list is the per-file graph, which is unrelated to compression
[12:34] <lifeless> the other parent-list is for the compression code
[12:34] <keir> what does tix stand for?
[12:34] <lifeless> and the compression code forms a tree, not a graph, so there is only ever 0 or 1 nodes
[12:34] <lifeless> 'text index'
[12:35] <keir> ok
[12:35] <lifeless> I don't know what the most common traversal is
[12:35] <keir> so there is an index for the compression code?
[12:35] <lifeless> or most common query pattern I should say
[12:36] <lifeless> for .rix its probably breadth first repeated queries on the first node-reference list
[12:37] <lifeless> for .iix it will probably be compression-sequence lookups - repeated queries following the compression parent
[12:37] <lifeless> for .six it will simply be large set queries for (all revisions being pulled at once)
[12:37] <Odd_Bloke> I'm trying to modify my bundle for bug #52479 to work on local branches as well as remote ones.  However, I'm struggling to find a way of working out where an unbound branch is committing to (with a bound branch I just use Branch.get_bound_location()).  What's the best way to do this?
[12:37] <ubotu> Launchpad bug 52479 in bzr "Message at the end of commit for bound branches" [Wishlist,In progress]  https://launchpad.net/bugs/52479
[12:37] <lifeless> for .tix it could be compression-sequence lookups, or it might be file-graph searches
[12:37] <lifeless> Odd_Bloke: branch.base ?
[12:38] <keir> aaaag! i just hit ctrl-L and logging is off in my xchat
[12:38] <keir> does someone have a log of the last few hours?
[12:38] <lifeless> Odd_Bloke: in commit it should simply be 'committed to %s' % master_branch.base
[12:38] <lifeless> Odd_Bloke: you shouldn't need to make any calls about bound branches
[12:39] <lifeless> keir: there is one on the web I believe
[12:40] <keir> no one else has logging on?
[12:40] <keir> i was going to paste our chats into my notes and tidy it up
[12:40] <lifeless> keir: there is not a separate index for compression; the compression code uses the second node-reference list to form the compression-tree
[12:40] <Odd_Bloke> lifeless: Yeah, my one year of CompSci Java had me only looking at methods. :/  I'll modify it as such.
[12:40] <lifeless> keir: its layering - the index layer is agnostic for the exact use its put to, which has allowed me to use it about 3 different ways so far
[12:41] <keir> lifeless, i don't know what a compression-tree is
[12:41] <keir> lifeless, yes, i understand.
[12:41] <keir> lifeless, however i think it is reasonable to add a 'my values are 8 bytes' flag to the graph builder
[12:41] <lifeless> keir: I don't know how to describe it differently. I've tried twice
[12:42] <lifeless> We store a given byte-sequence as either a full copy or as a line based deltas against another byte sequence
[12:43] <keir> lifeless, ok, so that is a compression tree. i understood that, just not that it was named 'compression tree'
[12:43] <lifeless> well we don't have a ideal name for it
[12:43] <lifeless> its not a graph
[12:43] <lifeless> though a graph can store it
[12:43] <lifeless> which is how I fit it into the GraphIndex structure
[12:44] <keir> and i imagine the compression tree, in typical use cases, has a very low branching factor
[12:44] <lifeless> given that the index builder only has to output data when the index has all its entries added to it, I don't see why you add a flag telling it how long the values are: you can determine that by inspection during finish()
[12:45] <lifeless> keir: the compression tree for inventory is about 4 for every one
[12:45] <lifeless> erm
[12:45] <lifeless> thats wrong,t ahts the ratio of non-mainline to mainline
[12:45] <lifeless> best thing to do is to query it yourself and see for a live repository :)
[12:46] <keir> true!
[12:46] <lifeless> you could report on this for inventories and texts - .iix and .tix
[12:46] <lifeless> now
[12:46] <lifeless> byte-sequence reconstruction is performance critical for many operations
[12:46] <keir> what does that mean?
[12:47] <keir> byte-sequence reconstruction
[12:47] <lifeless> I've been referring to 'texts' in an ambiguous way
[12:47] <lifeless> texts can mean 'something in the .tix index' or it can mean 'any sequence of bytes we have stored in the repostiory' which is a superset of the first meaning
[12:47] <lifeless> so I'm disambiguating now to be clear
[12:48] <keir> ok
[12:48] <lifeless> reconstructing things like the contents of an inventory or the contents of a given file version is a common operation
[12:48] <lifeless> and when its slow it multiplies in effect
[12:48] <lifeless> 'bzr checkout mozilla' for instance constructs 55K byte sequences which are delta compressed
[12:49] <keir> ah! so i imagine that's slow
[12:49] <lifeless> so that will be following the compression tree for 55K texts in the .tix and 1 inventory from the .iix
[12:49] <keir> but ideally, there is a pack with a fulltext only a few deltas behind, correct?
[12:49] <lifeless> so for .tix and .iix getting the nodes from the compression tree for a single node is a very common operation
[12:50] <lifeless> well fulltexts are put in when the deltas add to about the size of the full text
[12:50] <lifeless> so a big text gets more fulltexts between deltas than a small text
[12:50] <lifeless> erm switch the words there
[12:50] <keir> yes, i understand.
[12:50] <lifeless> ok
[12:51] <keir> is it often that many files are queried?
[12:51] <lifeless> lets see
[12:51] <keir> for one of my projects, astrometry.net, we use some very clever branch-and-bound algorithms to compare two trees; one is our index, and one is constructed at query time
[12:51] <lifeless> branch and checkout will queries size-of-tree nodes for the compression graph
[12:52] <lifeless> merge will query size-of-difference * two
[12:52] <keir> so in  those cases it may be possible to do better than N * (index lookup)
[12:53] <lifeless> pull does a merge under the hood
[12:53] <keir> so the only time branch is not equivalent to cp -R is when there's a shared repo, and you are only branching one of the branches?
[12:53] <lifeless> same with update
[12:53] <lifeless> branch is never equivalent to cp -R
[12:54] <keir> ok. i fail to see why
[12:54] <lifeless> if there is no shared repo we do a clone, which spiders all the data and verifies
[12:54] <keir> in cases where it's not a shared repo
[12:54] <keir> so just cp -R + md5check
[12:54] <lifeless> you as a user can do that
[12:54] <lifeless> we dont
[12:54] <lifeless> you might be mounting sftp over fuse for instance
[12:54] <keir> ok. just because of portability?
[12:55] <lifeless> being on a file:// url doesn't guarantee data integrity
[12:55] <lifeless> you might have a lot of unreferenced data
[12:55] <keir> ok, right. my question is more one of what is the fundamental operation, and in non-shared branching, it is just copying raw bytes.
[12:55] <lifeless> and we don't copy that - if you make a new branch it only contains the data referenced
[12:55] <lifeless> ok
[12:55] <lifeless> to make a new branch we:
[12:56] <keir> exactly, which is why it is not the case for shared repos, because you only branch one of the severa branches, and the shared repo contains all revs
[12:56] <lifeless>  - ensure there is a repository that can be used at the branch. In the shared repo case we find that up the containing directories. In the non shared repo case we create it.
[12:56] <lifeless>  - we perform a data fetch from the source branch's repository for the revisions referenced by the branch
[12:57] <lifeless>  - we create a working tree of the tip of the branch
[12:57] <lifeless> for a shared repository the fetch operation fast-paths and just asserts that the data requested is in fact present
[12:59] <keir> ok
[01:02] <lifeless> If you have more questions ping; I suggest getting some of the live indices and exmaining them playing with them etc, perhaps instrument to record the sequence of calls or something then use bzrlib and see what's asked for
[01:03] <keir> yeah
[01:03] <keir> where can i get a big pile of live indicies?
[01:04] <lifeless> my repo that I have pointed you at
[01:04] <keir> ok
[01:04] <keir> those are all the uses for the index right now?
[01:04] <lifeless> or follow my dogfooding instructions from the list
[01:04] <lifeless> and make your own pack based repo
[01:04] <lifeless> yes, they are all the uses
[01:04] <lifeless> course, we aren't finished
[01:04] <lifeless> so as a client let me be clear - the scope is-a-changing :)
[01:05] <lifeless> (but not much I hope)
[02:09] <lifeless> poolie: still on the phone ?
[02:09] <poolie> now serving #72
[02:09] <keir> lifeless: can we exploit that most of the keys have large common prefixes?
[02:14] <keir> because of what we are storing, a radix tree for the keys might not be crazy
[02:16] <ddaa> poolie: got a patch for you
[02:17] <abentley> The form of the keys is not guaranteed.  imports from git, for example, may have revision ids of "git:%(hash)s".
[02:18] <ddaa> http://paste.ubuntu-nl.org/36388/
[02:18] <keir> also, i'm not sold that we want multiple adjacency lists for each node; why not use multiple graphs, with a seperate key/value index?
[02:18] <keir> abentley, ok.
[02:18] <ddaa> Make bzrlib.tests.TestCase use super() in setUp and tearDown, and fix a small typo that fucks up emacs syntax highlighting.
[02:19] <ddaa> poolie: poolie need anything else for this patch? It's fairly trivial.
[02:19] <ddaa> (the super stuff is needed now for some Launchpad test case)
[02:19] <abentley> keir: Gnu Arch imports have a common prefix.  bzr-svn 3 does.  Dunno about bzr-svn 4.
[02:20] <keir> what's a reasonable size for a preamble?
[02:20] <keir> i figure there's going to be no way to avoid reading at least a few hundred bytes from the start of each index
[02:21] <abentley> I think lifeless has been talking about reading 64K at a time.
[02:21] <keir> it seems to me that you can shrink down the size of the index if you separate the key/value part from the key->(key)* part
[02:21] <abentley> (for remote access, that is)
[02:21] <keir> yes, of course
[02:22] <abentley> So you would want that 64K to include the preamble and a sizeable number of recent keys.
[02:23] <poolie> ddaa, did you post it to the list?
[02:23] <ddaa> ahem
[02:23] <ddaa> no
[02:23] <ddaa> I do not plan to
[02:23] <ddaa> I do not have time to read the bzr list really.
[02:23] <ddaa> spiv is looking at it now
[02:24] <poolie> hrm
[02:24] <ddaa> I'll have him get through the hoops.
[02:24] <spiv> ddaa: hmm.
[02:25] <keir> hmm, so after a pull, locally an index gets built from the data that got pulled? (for pack repos anyway)
[02:26] <spiv> ddaa: the problem is it's an incompatible API change.  Other people might have subclasses with multiple-inheritance involving bzrlib.tests.TestCase already.
[02:27] <ddaa> if they do, then they're bust
[02:27] <spiv> ddaa: not at all
[02:27] <ddaa> because all the other test classes that derive from TestCase use super() already
[02:28] <lifeless> keir: thats a possibility, consider benchmarking on live data
[02:28] <ddaa> As far as I can tell, there is no way to look at it and not see it as a bug, because TestCase clearly is the one breaking the rules.
[02:28] <spiv> Well, bzrlib doesn't multiply inherit from TestCase via different routes.
[02:28] <lifeless> keir: you can use my dgofooding insutrctyions to convert repos like thepython import on launchpad to packs
[02:28] <poolie> ddaa, posting a patch to the list does not require that you read everything on the list
[02:29] <lifeless> ddaa: python's TestCase doesn't use super FWIW
[02:29] <poolie> it's enough to just say 'please cc me on replies', or pick out that one thread from the list
[02:29] <abentley> ddaa: There are at least a few places we use MI in the test suite: the bundle tests and the versionedfile tests come to mind.
[02:29] <ddaa> lifeless: if that's a problem, then all the classes that derive from bzrlib.tests.TestCase should be changed not to use super()
[02:30] <keir> lifeless, ok. it seems reasonable that there may be multiple indexes with the same keyspace, and possibly differerent or same data
[02:30] <lifeless> ddaa: is this impacking you in some way ?
[02:30] <poolie> what specific problem does it cause?
[02:30] <spiv> ddaa: what lifeless said.  Using super in bzrlib.tests.TestCase isn't going to solve all uses of inheriting from two different unittest.TestCase classes.
[02:30] <ddaa> lifeless: yes, I want to MI from a TestCaseWithTransport and one existing test class in the Launchpad test suite that derives from unittest.TestCase.
[02:31] <thumper> ddaa: best to state what you actually want it to do and why it doesn't currently work
[02:31] <lifeless> -->commit performance
[02:31] <spiv> ddaa: I don't think that can work reliably, sadly.
[02:31] <spiv> ddaa: because you have diamond inheritance
[02:32] <poolie> i wish i'd inherited diamonds :)
[02:32] <spiv> ddaa: but part of the inheritance graph is unittest.TestCase, which doesn't use super.
[02:33] <ddaa> spiv: it is not a problem because there is no diamond above unittest.TestCase
[02:33] <spiv> I *think* the fact that unittest.TestCase is the notional common root might be enough to make it work with current Python.
[02:33] <keir> lifeless, actually, i have a crazy idea. what about having a mapping var length keys -> fixed size id's. then we can support key tuples as (id1, id2) rather than the full string
[02:33] <spiv> But they've changed the MRO before and could easily do it again.
[02:33] <spiv> In general though, I think inheriting from multiple TestCases isn't a good thing to do.
[02:33] <keir> lifeless, then we get to have 1 place that lists all the file id's and one place that lists the rev id's
[02:34] <ddaa> spiv: I find it unlikely that a MRO change would affect a simple case like this one.
[02:34] <spiv> Because you'
[02:34] <lifeless> keir: thats roughly what the current index does, the fixed size ids are byte offsets in this case
[02:34] <lifeless> keir: so its a reasonable thing to do
[02:34] <spiv> re likely to get difficult interactions even without super.
[02:34] <ddaa> spiv: okay, I give up on this patch and just somehow refactor my code.
[02:34] <keir> lifeless, ok. it looks like the file id's and rev id's are used in multiple idx's; so this would be a big win on large indexes
[02:34] <poolie> ddaa, i'd suggest instead
[02:34] <ddaa> I see too much reviewer argument ahead.
[02:35] <poolie> well, to back up
[02:35] <poolie> you need some bzr-related setup and some lp-related setup done for a single test?
[02:36] <ryanakca> for bzr commit, it's 'bzr commit -m "commit message" --fixes:lp:bugnumber' ?
[02:36] <ddaa> poolie: in a nutshell, yess
[02:38] <poolie> i'd be inclined to do it by
[02:38] <poolie> refactoring the parent classes so that all the setup methods are individually callable
[02:39] <poolie> which should generally be the case already for bzr
[02:39] <poolie> then having your setUp just do what it wants
[02:39] <poolie> i think relying on super to do all this is confusing/problematic
[02:39] <ddaa> yes, that what I meant by "refactor my code"
[02:39] <poolie> spiv, do you agree
[02:39] <ddaa> I it just mildly disappointing because MI would have been the natural way to do it IMO.
[02:40] <spiv> Yes, I think that would probably work.
[02:40] <spiv> A hackish way to do that is simply:
[02:40] <spiv> def setUp(self): self.borrowedTest = OtherTestCase('foo'); self.borrowedTest.setUp()
[02:41] <keir> hah, i am redesigning berkely db
[02:41] <ddaa> poolie: BTW, you probably want to clean out the uses of super() in setup() and tearDown() methods of bzrlib.tests.TestCase descendants then.
[02:41] <poolie> :)
[02:41] <spiv> Which doesn't save you from conflicts in the setup (e.g. if both tests want to tweak global state like logging, os.environ, or the cwd).
[02:41] <spiv> But that would be a problem with MI anyway.
[02:42] <ddaa> poolie: either use it everywhere, or use it nowhere. The current situation is just a problem waiting to happen IMO.
[02:42] <spiv> Also, you don't get easy access to custom assertion methods on the OtherTestCase.
[02:42] <ddaa> spiv: which would be an annoyance in this case.
[02:43] <poolie> google says "authentic python handbag" :)
[02:43] <poolie> ddaa, if you want to remove them in fixing this that's ok with me,
[02:43] <poolie> or file a bug
[02:43] <poolie> ddaa, please use the regular review mechanism if you want bazaar changes
[02:43] <lifeless> keir: bdb doesn't have graph awareness; thats a key part of this index logic
[02:44] <poolie> and we will try to make it work efficiently for you
[02:44] <ddaa> poolie: ack
[02:44] <lifeless> ryanakca: what are you asking ? have you read the help?
[02:45] <poolie> if you try it and you think it is eg taking too much time, raise that with one of us or on a company list
[02:45] <keir> lifeless, i know :)
[02:45] <ryanakca> lifeless:   --fixes=ARG           mark a bug as being fixed by this revision.
[02:46] <ryanakca> lifeless: ARG being something. Anyways, I don't need to anymore, since the Ubuntu upload closed them
[02:46] <keir> do we want indexes to scale > 4gb?
[02:46] <keir> or  rather, is it reasonable to expect to be able to fit the entire index in memory? or should i design assuming you can't do that
[02:47] <lifeless> ryanakca: at the end of 'bzr help commit'
[02:47] <lifeless> See also: bugs, uncommit
[02:47] <lifeless> ryanakca: so 'bzr help bugs'
[02:47] <ryanakca> lifeless: thanks
[02:51] <abentley> lifeless: shall I merge Watkins' patch without test case refactorings?
[02:56] <ubotu> New bug: #137407 in bzr "messy error if BZR_HOME does not exist" [Low,Triaged]  https://launchpad.net/bugs/137407
[03:01] <poolie> we seem to have a lot of reviews bounced recently
[03:01] <poolie>  because of disagreements about indenting
[03:01] <poolie> but there is no clear statement in either hacking or pep8 about just what is allowed
[03:01] <lifeless> abentley: sure, that was speculation or I wouldn't have done bb:approve
[03:03] <igc> morning
[03:05] <abentley> poolie: clearly, the reviewer gets to choose the indenting style >:-)
[03:05] <poolie> ok, that works :)
[03:12] <abentley> Well, I'm not sure about double-indenting when doing line-wrapping.  Because you're already down to 67 characters if you're in a method body, 63 if you're in a try block, 59 if there's a loop inside the try block.
[03:13] <keir> lifeless, what is the 'absent' field used for?
[03:15] <ubotu> New bug: #137412 in bzr "Code duplication in tests.blackbox.test_commit" [Undecided,New]  https://launchpad.net/bugs/137412
[03:16] <lifeless> keir: it records keys which are not in the index but are referred to by a key reference
[03:16] <lifeless> I don't line 8-indents on line wraps
[03:17] <poolie> here are the possibilities as i see them:
[03:17] <poolie> a- indent under the delimiter (opening brace or whatever)
[03:17] <poolie> b- indent 4 spaces
[03:17] <poolie> c- indent 8 spaces
[03:17] <keir> lifeless, hmm, what is it used for? in the next layer up?
[03:17] <poolie> d- indent 0 spaces
[03:18] <abentley> I would prefer a where practical, otherwise b.
[03:18] <poolie> a is nice
[03:18] <poolie> a bit more laborious to maintain
[03:18] <poolie> well, for non-emacs users
[03:19] <jml> :)
[03:19] <lifeless> keir: no, consider an index with one entry and one key-reference list:  ('key1',), 'value', [('anotherkey',)]
[03:19] <lifeless> keir: iter_all_entries() needs to yield ('key1',), 'value', [('anotherkey',)]
[03:20] <lifeless> keir: iter_entries([('anotherkey',)] ) needs to yield nothing
[03:20] <lifeless> anotherkey is not present in the index
[03:20] <lifeless> it is absent
[03:20] <keir> ok
[03:20] <lifeless> have a look at the serialisation tests
[03:20] <keir> but aren't keys listed by their position in the file?
[03:20] <lifeless> have a look at the serialisation tests
[03:21] <poolie> lifeless, how about allowing a/b?
[03:21] <poolie>  spiv ^^
[03:21] <lifeless> c?
[03:21] <lifeless> poolie: we currentl use a or b as people feel comfortable
[03:21] <poolie> i thought you didn't like c?
[03:21] <lifeless> I don't like c
[03:21] <poolie> i sometimes use c as that's what vim seems to like
[03:21] <poolie> i am happy to change though
[03:22] <lifeless> vim is on crack
[03:22] <keir> vim rocks!
[03:22] <poolie> i just want it settled rather than being rehashed in every review
[03:22] <lifeless> sure
[03:22] <poolie> it is probably configurable in vim
[03:22] <lifeless> can I ring to bounce an idea
[03:22] <abentley> lifeless, keir: Maybe you can compromise: vim is on crack rocks!
[03:22] <poolie> lol
[03:23] <keir> abentley, heh
[03:23] <abentley> keir: I speak as a vim user.
[03:28] <keir> ok, i just came up with a nice unified way of storing these graphindexes, and i realize it just bakes down to the same thing as a berkely db
[03:28] <spiv> I use a or b.
[03:28] <keir> how does knowing we're storing a graph help again?
[03:29] <keir> i mean, i can make the format amenable to readv() wire access, but it's still just storing k,v pairs
[03:45] <lifeless> keir: you can group data topologically
[03:46] <lifeless> keir: you can reduce latency by adding apis for common graph/tree walking operations where the index layer is able to predict and readahead in the graph order
[03:47] <lifeless> and you can dictionary compress key references because we have 'k,v,r' rather than 'k,v' where the key references would be opaque
[03:55] <keir> alright. time for graphviz
[04:03] <abentley> keir: I don't know if you'll find it useful, but bzrtools includes "graph-ancestry", which uses dot.
[04:04] <keir> abentley, ok, thanks
[04:55] <lifeless> -> poolie
[05:42] <poolie_> jml_, hi?
[06:05] <AfC> Weird. Someone submits a branch to us, including about new 50 files making up something that we decide not to accept (and so revert|delete). We work further on the branch, then merge it to 'mainline'. We then push to the public repo, and bzr does the endless-small-round-trips thing.
[06:06] <AfC> After thinking about it, I realized that it must be creating new knit files server side for each of those files, because they were in revisions that are in the branch even though the files involved were subsequently deleted.
[06:23] <poolie_> yes, because it's still carrying the history for those files
[08:01] <ubotu> New bug: #137449 in bzr "status performance regression compared to 0.17" [Undecided,New]  https://launchpad.net/bugs/137449
[11:29] <dato> uhm, bzr upgrade is not supported over bzr+ssh?
[11:29] <dato> % b upgrade --dirstate-tags bzr+ssh://bzr.debian.org/bzr/pkg-python-debian/trunk
[11:29] <dato> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[11:30] <dato> % b upgrade --dirstate-tags sftp://bzr.debian.org/bzr/pkg-python-debian/trunk
[11:30] <dato> ... finished
[11:32] <mwhudson> https://bugs.launchpad.net/bzr/+bug/125166
[11:32] <ubotu> Launchpad bug 125166 in bzr "Smart server doesn't suppport upgrading" [Low,Confirmed]
[11:33] <pygi> morning
[11:33] <mwhudson> with no knowledge at all, it seems like it should be fairly easy to fix...
[11:33] <dato> mwhudson: ah, thanks.
[12:28] <lifeless> dato: thats right
[01:02] <rschuster> hi bzr-folks
[01:03] <rschuster> i am trying to implement a bzr-fetcher for OpenEmbedded and need your help
[01:03] <rschuster> how can I find out the latest revision number of a certain (remote) branch?
[01:04] <rschuster> something like 'svn info <remote-url>' which will contain the line: "Revision: 8404" (for example)
[01:06] <dato> rschuster: as a command (that is, not using the Python API): bzr revno http://...
[01:09] <rschuster> dato: thanks alot thats it!
[01:09] <dato> rschuster: you're welcome
[01:40] <abentley> rschuster, note that the revision number is not the most accurate indicator of whether a branch has changed.
[01:40] <dato> he left already.
[01:42] <igc> night all
[03:35] <asabil> anyone knows how to make the visual studio integration working ?
[03:57] <Ng> hey folks. If I push a bzr tree to an sftp:// I obviously just get a .bzr directory there. What magic can I do on the remote end to make it generate the working files too (not automatically, just manually is fine)
[03:58] <mwhudson> Ng: 'bzr update'
[03:58] <Ng> mwhudson: that's what I thought, but it said "No WorkingTree exists for file:///blah/branch/.bzr/checkout/."
[03:59] <Ng> (fwiw, the local bzr is 0.18 and the remote is 0.17)
[03:59] <mwhudson> oh
[03:59] <mwhudson> 'bzr co'
[03:59] <Ng> spot on, thanks :)
[06:54] <jelmer> Lo-lan-do: The non-lhs push issue has been fixed in the 0.4 branch of bzr-svn
[07:01] <Lo-lan-do> jelmer: Excellent, thanks.
[07:13] <keir> how difficult would it be to implement git-style branch switching?
[07:13] <keir> so that you only have 1 working tree, which you can switch between branches with a bzr command
[07:14] <jelmer> keir: that should be possible to implement using a plugin
[07:14] <keir> wow, really!
[07:14] <jelmer> and wouldn't be too hard I think
[07:14] <keir> ok, that is high on my list after writing a new index layer
[07:14] <keir> i definitely prefer git's way of working regarding branches
[07:15] <Lo-lan-do> There's already a bzr switch command...
[07:16] <jelmer> bzr switch takes a to_location though
[07:17] <keir> is in not in the main bzr?
[07:17] <jelmer> no, it's in bzrtools
[07:17] <keir> bzr help commands | grep switch -> empty
[07:17] <keir> aah, ok
[07:17] <jelmer> you'd want it to take a tag I guess
[07:17] <keir> no, a branch name
[07:17] <jelmer> right, so you'd want to write a plugin that:
[07:17] <jelmer> keeps a list of branch names in a file somewhere under .bzr/
[07:18] <jelmer> the file would simply contain a dictionary with "branch name -> revid" mappings
[07:19] <keir> how is a branch represented in a shared repo now?
[07:19] <jelmer> and the plugin would have a ocmmand to list the branches, one to add a branch to the file and one to change the active branch
[07:19] <jelmer> keir: there's a .bzr/branch/last-revision file that contains the tip of the branch
[07:19] <jelmer> that's all there is to a branch
[07:20] <keir> ok
[07:20] <dato> or a .bzr/branch/revision-history for v5 branches
[07:20] <keir> so in a shared repo, it's .bzr/branch_name_here/revision-history?
[07:20] <jelmer> keir: you can simply call Branch.set_last_revision(revid) to change the tip of a branch
[07:21] <luks> keir: no, in the branch's .bzr dir
[07:21] <keir> aah, ok
[07:22] <luks> repository doesn't know about it's branches
[07:22] <keir> right, i understand
[07:23] <keir> so i'd basically have to make a new branch format
[07:23] <keir> and by format, i mean placement of branches
[07:25] <jelmer> no, you should be able to use the current branch format
[07:25] <jelmer> the only bit of data that is missing atm is the list of branches
[07:26] <jelmer> the active branch can still be in .bzr/branch
[07:28] <Herodes> I get this :
[07:28] <Herodes> "working tree is out of date, run 'bzr update'
[07:28] <Herodes> bzr: ERROR: exceptions.AssertionError: 257 != 1"
[07:28] <Herodes> how can I fix it ?
[07:29] <Herodes> it is a new branch that I have ,...
[07:29] <Herodes> and I am merging a branch with 257 revisions,..
[07:29] <Herodes> so I suppose I need to push up the revision I have to 257...
[07:30] <james_w> keir: my plugin does stuff like that, so I can give you pointers as well when you do it if you like.
[07:41] <Herodes> I found the problem..
[07:42] <Herodes> I was using the "bzr merge", where I needed to use "bzr branch". Sorry for spaming..
[08:03] <relix> Heya
[08:03] <relix> I'm trying to version my whole /home directory
[08:03] <relix> so I was in my home dir, and used "bzr init"
[08:04] <relix> then I tried "bzr add" and after changing a couple of filenames that made it crash, it said "(amount) files ignored. Add them by name to version them"
[08:04] <relix> I can't go over these thousands of files to add them "by name"
[08:04] <relix> how can I add them?
[08:04] <relix> I tried bzr add *; bzr add /david/home/; bzr add ./; bzr add;
[08:04] <relix> none works
[08:06] <james_w> what files are they? dot files? (bzr ignored would tell you)
[08:07] <yml> hello
[08:07] <yml> good evening
[08:07] <relix> ah thanks james_w
[08:08] <relix> apparantly one of my ignored settings filters a couple of thousand files
[08:08] <relix> so it's entirely my fault and I feel pretty dumb now having wasted your time :s
[08:08] <james_w> relix: no problem.
[08:09] <yml> what is the easiest way to remove some of the revisions of a project hosted on launchpad?
[08:11] <yml> if this is not possible. how can I delete a branch?
[08:12] <james_w> yml: remove completely, or just rewind a branch?
[08:12] <yml> remove
[08:12] <james_w> you have to delete the branch. However if launchpad use shared repositories even doing that might not get rid of it completely.
[08:13] <yml> or remove all the revision below revno60
[08:13] <yml> I mean remove the revision  from 1..59
[08:17] <yml> or is it possible to create a branch from an exiting repository for all the revno>60 and the this new branch to do bzr push --overwrite
[08:20] <Peng> relix: I don't recommend doing that in bzr, if you're going to include dot directories like .opera. I did, and committing got really slow after a few months. OTOH, the bzr guys are working on improving that, so maybe it won't be so bad in the future.
[08:33] <mwhudson> yml: i don't think you can do what you suggest even locally can you?
[08:34] <yml> mwhudson  : I don't know I am trying many combination but so far I have not found anything that do what I would like to do.
[08:35] <mwhudson> bzr pretty firmly assumes that if you have revision X you have all of revision X's parents
[08:35] <yml> I would like to dump the last 2 revsion and build a new rep with this.
[08:36] <mwhudson> you can drop the latest two revisions with 'bzr uncommit' (twice) and then push --overwrite
[08:36] <yml> Ideally I would also like to delete branch on launchpad or at least remove all the content
[08:36] <mwhudson> you can use lftp to rm -rf the .bzr in your branch
[08:37] <mwhudson> (via sftp)
[08:37] <yml> mwhudson  I want to do the oposite keep ONLY the latest 2 revision
[08:37] <mwhudson> yml: that's not what you said :)
[08:37] <mwhudson> yml: and you can't do that
[08:37] <yml> that is clear  :-)
[08:39] <yml> sftp> rm -rf .bzrCouldn't stat remote file: No such file or directoryRemoving /~yml-nospam/django-survey/main-yui/-rfCouldn't delete file: No such file or directory
[08:40] <mwhudson> *lftp*
[08:40] <yml> mwhudson  : unfortunatly I am not able to do this
[08:40] <yml> I am sorry what is lftp?
[08:40] <mwhudson> the default sftp client is surprisingly horrible
[08:41] <mwhudson> http://lftp.yar.ru/
[08:41] <Peng> lftp isn't that great, either. No globbing. :(
[08:41] <mwhudson> actuall
[08:41] <mwhudson> y
[08:42] <mwhudson> bzr uncommit -r 0 --force; bzr push --overwrite
[08:42] <mwhudson> may be sufficient
[08:43] <yml> mwhudson so back to my original question bzr branch --revision=last:2 my path
[08:44] <yml> keep only the history of the file of the last 2 revisions
[08:44] <yml> even if when I do bzr log I can retrieve the complete history?
[08:45] <yml> that mya sound strange on this channel I want to destroy all the information in the revisions 1..59
[08:46] <mwhudson> you can probably create a new branch that has the same content
[08:46] <mwhudson> but they won't be connected in the revision graph
[08:47] <yml> This is fine
[08:55] <brmassa> guys, i did some changes on my working tree but i changed my mind. how can i reset it and restore my last revision?
[08:56] <Lo-lan-do> bzr revert?
[08:56] <brmassa> thanks
[08:57] <yml> mwhudson slap my forehead,your solution of creating a new rep seems to work
[08:57] <yml> I wait that launchpad refresh its history
[08:58] <luks> "bzr uncommit -r 0 --force; bzr push --overwrite" will not actually remove the data from launchpad
[08:58] <relix> peng yeah I'm getting memory errors right now :(
[08:58] <relix> I ignored .opera's cache4 directory though so it shouldn't be much of a problem
[08:59] <yml> luks  : GRRRR!!! I was happy that bzr didn't raise any error message :-)
[08:59] <yml> too easy
[09:00] <luks> it will remove the branch, but the repository with all the data is still there
[09:00] <yml> How can I remove the content of a branch?
[09:01] <luks> use a sftp client that remove remove directories recursively and remove the .bzr directory
[09:01] <luks> er, that can remove
[09:02] <yml> I have an error message when I try to do that
[09:02] <luks> the 'sftp' client can't do that
[09:02] <yml> sftp> rm -rf .bzrCouldn't stat remote file: No such file or directoryRemoving /~yml-nospam/django-survey/main-yui/-rfCouldn't delete file: No such file or directory
[09:03] <yml> luks I do not understand? can I do that with sftp or not?
[09:04] <luks> yml: "<mwhudson> you can use lftp to rm -rf the .bzr in your branch"
[09:05] <yml> I try lftp a couple of minute ago
[09:05] <yml> lftp yml-nospam@bazaar.launchpad.net:~> ls`ls' at 0 [Connecting...]
[09:05] <yml> and for the last 5 minutes it is displaying this error message
[09:07] <yml> Interesting it seems that my history is gone thanks to
[09:07] <yml> http://codebrowse.launchpad.net/~yml-nospam/django-survey/main-yui/changes
[09:08] <yml> bzr uncommit -r 0 --force; bzr push --overwrite
[09:08] <yml> is that possible?
[09:09] <Peng> relix: Ignore opcache/, opthumb.dat, thumbnails/ and widgets/*/ too.
[09:09] <yml> I had 62revisions before
[09:09] <jelmer> well, the data is not easily accessible, but it's still there
[09:10] <relix> good idea Peng
[09:10] <relix> had thumbnails ignored already
[09:10] <relix> but it's crashing on something different: the .incomplete dir of dc++
[09:11] <Peng> relix: I dunno anything about that. Large files or anything?
[09:11] <relix> yeah possibly
[09:12] <Peng> relix: It'll have to hold entire files in RAM occasionally.
[09:12] <Peng> s/have to// ;)
[09:13] <yml> jelmer: does that mean that people without a write access to this rep cannot see them
[09:13] <relix> ah, righ
[09:15] <jelmer> yml: no, they will be able to access it if they try very hard
[09:16] <jelmer> wel, not *very* hard perhaps, but it's not trivial to access
[09:16] <yml> Is there a way to get anything better
[09:17] <yml> I mean more radical
[09:17] <yml> :-)
[09:17] <jelmer> yml: yes, remove the entire .bzr directory
[09:18] <yml> could you guide me to do this ?
[09:18] <jelmer> yml: but I'm not entirely sure how to do that on launchpad, maybe the folks in #launchpad can better tell you
[09:18] <yml> 2 peoples mention lftp
[09:18] <jelmer> "rm -rf .bzr" will work if it's on a local system
[09:18] <yml> but I do not manage to get that far
[09:18] <yml> ok jelmer
[09:19] <yml>  I am going to ask on #launchpad
[09:19] <yml> Thank you very much all
[09:20] <brmassa> guys, i have a project on my pc and also on launchpad.net. how can i have the same branch on my office pc? if i merge with my launchpad, all revisions becomes one.
[09:22] <jelmer> brmassa: you'd want 'bzr branch <launchpad-url>'
[09:23] <brmassa> and for the second time, when i have a branch already? can i do it again?
[09:27] <Lo-lan-do> How about a checkout?
[09:28] <brmassa> hmmm really really
[09:30] <dato> brmassa: bzr pull
[09:32] <brmassa> im gonna check both.
[09:33] <brmassa> the windows version available on site has the python lib for criptography?
[09:33] <brmassa> parakiko or something...?
[09:38] <beuno> who can help me fin out why I'm getting this error on a 500mb branch?   bzr: ERROR: exceptions.MemoryError:
[09:38] <beuno> I'm branching it through sftp
[09:42] <brmassa> 500mb? jezz!
[09:45] <jelmer> beuno: please sent an email to the list
[09:45] <jelmer> beuno: that should work, but the people most likely to be able to help aren't here atm
[09:45] <beuno> jelmer, will do, thanks
[10:20] <lifeless> abentley: yo
[10:28] <james_w> dato: are you around?
[10:29] <dato> james_w, yes
[10:29] <james_w> hi.
[10:30] <james_w> I'm working on the bug with builddeb where it fails when the tarball contains multiple files in the root. #440069. Do you remember it?
[10:30] <dato> yes
[10:32] <james_w> you said that dpkg-source supports it by unpacking to a temporary directory.
[10:32] <dato> I believe it does that
[10:32] <james_w> I already do that, but I need to source directory to copy the debian/ in to.
[10:32] <brmassa> lifeless... will 0.90 be on gutsy repository?
[10:33] <james_w> so I currently rename the contents of the extracted tarball to the package-version that I want, assuming there is one entry and it is a directory.
[10:34] <james_w> do you think checking for a single directory and erroring if there is more that one is a good approach, or will I find even wierder tarballs out there?
[10:34] <dato> the thing is you unpack in a temporary directory. if there's only one item, you move it out of the temp directory, into the name you want. if there's more than one, you rename the *temporary directory* to the name you want.
[10:35] <dato> if you are *building* in a temporary directory, then you need two temporary directories, one under the another
[10:35] <dato> toplevel for building, other one for the unpack steop
[10:35] <james_w> ah, rename the tempdir. Thanks, I'll no that.
[10:36] <dato> right, np
[10:36] <dato> james_w: I have an unpack-in-subdir script that does that, here it is: http://rafb.net/p/GhPw3485.html
[10:36] <dato> but it's pretty much straightforward
[10:38] <dato> though now I notice, that does not do renaming, but other stuff, dunno why
[10:55] <james_w> dato: you rock. thanks.
[11:04] <lifeless> abentley: ping
[11:08] <dato> james_w: you're welcome :)
[11:51] <NfNitLoop> Anyone here have experience with svk and bzr-svn?   I'm looking for a comparison.
[11:51] <NfNitLoop> I've got a svn repo here in the states and developers down in Argentina.   The poor connection between here and there is becoming a headache.
[11:57] <arjenAU> NfNitLoop: well svk is not quite a distributed system. it's a distributed trick bolted onto a very centralised system. if you can choose, I'd go for the pure design, bzr or hg
[12:00] <arjenAU> NfNitLoop: using the svn plugin for bzr does not quite make it distributed either, but it's a good way to migrate to bzr.
[12:01] <NfNitLoop> Well, it was a giant pain to get them to switch to svn.  I don't see us migrating away from it any time soon.
[12:01] <lifeless> AFAICT bzr-svn has more fidelity
[12:01] <NfNitLoop> So I'm looking at a way of "bolting on" a solution to give the remote devs. a more distributed environment.
[12:02] <lifeless> and you can wrk with bzr native as soon as one user has done the conversion