[01:17] <ianliu> My messaging menu indicator is gone... Any hints on how I can put it back?
[01:33] <jbicha> ianliu: do you have ubuntu-desktop installed?
[01:35] <ianliu> jbicha: yes, I upgraded from 12.04 long ago, at Alpha phases. I guess after some updates, my messaging menu is gone. All seems to be installed: indicator-messages, libmessaging-menu.
[01:41] <jbicha> ianliu: do you have empathy installed? are you using a different theme?
[01:42] <ianliu> jbicha: I did removed empathy some days ago, but installed now to see if this was causing the problem. My theme is Radiance
[01:43] <ianliu> jbicha: although I've changed the icon theme to Faenza
[01:43] <jbicha> try changing the theme back to Ambiance or Radiance to see if that fixes the problem
[01:44] <jbicha> do you use Gwibber?
[01:45] <ianliu> jbicha: changed themes, no luck. Maybe I should logout/login? I will try that, brb
[01:47] <ianliu> jbicha: ohh, it appeared again! I guess it was empathy (or any app that uses messaging menu). I've removed them all since I don't use them, but I would like to test the integration with websites
[01:49] <jbicha> a new feature in 12.10 is that the messaging menu will go away if you don't have any messaging apps
[01:49] <jbicha> I've not found webapps to be that useful yet; maybe I'm not using it right
[02:19] <wilee-nilee> Hello channel, so with gnome 3 the bottom panel looks like this any news with this. http://imagebin.org/229966
[02:23] <bjsnider> i think that's normal sir
[02:25] <wilee-nilee> bjsnider, Should be clear has been on all other setups and about 1/4 in vertical height
[02:25] <wilee-nilee> in size
[02:26] <jbicha> wilee-nilee: http://library.gnome.org/misc/release-notes/3.6/users-message-tray.html
[02:27] <bjsnider> gnome users = things must never change
[02:27] <wilee-nilee> Ah I wondered if it was a cough development. ;)
[02:27] <wilee-nilee> the whole screen moves, kind of disconcerting oh well.
[02:28] <jbicha> people complained that the message try covered up what they were working on
[02:29] <wilee-nilee> jbicha, Yeah that was a irratant I have the cairo-dock on the bottom it moves up with the showing of the tray, it will be better I suspect.
[02:29] <wilee-nilee> irritant*
[03:08] <BebopSteve> HELP I'm drunk and I'm not sure if I'm qualified to be using my ubuntu system without fucking shit up as root, but oh wait I
[03:08] <BebopSteve> http://askubuntu.com/questions/192283/how-do-i-restore-previous-launcher-icons-in-docky THIS
[03:09] <BebopSteve> again with the wrong window
[03:09] <BebopSteve> I am really sorry, mischat
[03:09] <BebopSteve> I need to close this because I don't use betas often
[03:10] <BebopSteve> HAVE A GOOD NIGHT EVERYONE, DRINK MORE RUM
[07:00] <gnomefreak> anyone else notice the following command no longer works.
[07:00] <gnomefreak> gconftool-2 --set "/apps/metacity/general/button_layout" --type string "menu:maximize,minimize,close"
[07:00] <gnomefreak> i tried changing metacity to unity compiz act... nothing works
[07:23] <frybye> Hi any ideas for fixing problem with deb's like google-earth and acroread which produce fault report with "bad package?"
[07:24] <frybye> deleting packages and re-download does nothing..
[07:42] <frybye> is there a net split or something - no dialogue here...?
[07:44] <gnomefreak> no no netsplit but seeing as it isnt yet 4am here others may still be a sleep or just afk
[07:47] <frybye> in berlin here 9:46h but you have a point...
[07:50] <frybye> gnomefreak: are you using 12.10 - any issues with installing from deb's?
[07:59] <gnomefreak> frybye: i am using 12.10 and so far i havent had anyy issuers with apt or dpkg
[08:01] <frybye> you don't use the software center...?
[08:02] <frybye> I guess under the hood that also uses same code or..?
[08:05] <gnomefreak> frybye: i cant stand the software center
[08:10] <frybye> ok
[08:39] <X-tonic> hi, is 12.10 expected to have lightdm equivalent of gdm 3.6 lock screen?
[11:08] <vega-> hasn't that been already in many releases..
[11:16] <BluesKaj> Hey all
[11:20] <X-tonic> vega
[11:20] <X-tonic> u mean the unity-greeter?
[11:21] <X-tonic> what i mean is the gdm redisgned lock screen which shows time, notification, volume access, network info in the lock screen. I did browse launchpad but i got nothing
[11:22] <X-tonic> is there an equivalent for 12.10?
[11:22] <vega-> oh, no idea
[12:17] <whitman> Which package should I report a bug against when I don't know which it is? One of my monitors is corrupted on the login screen and after login, the only way to fix is to disable the monitor in the display settings and re-enable.  Previously worked fine 12.04.
[15:27] <Milos_SD> hi
[15:27] <Milos_SD> I'm trying to upgrade to Ubuntu 12.10 beta, but I have i little problem
[15:28] <Milos_SD> upgrade manager does it's thing to change repositories, but then I get this error: Unable to get exclusive lock when doing upgrade
[15:28] <Milos_SD> I don't have apt, dpkg or synaptic running ..
[15:39] <genii-around> Are you using sudo?
[15:39] <genii-around> Or rather... what command are you using
[15:40] <Milos_SD> "update-manger -d" from dash run command
[15:40] <Milos_SD> and then I click Upgrade to 12.10 ...
[15:40] <philinux> thats the right way
[15:40] <genii-around> Milos_SD: Put sudo in front
[15:40] <Milos_SD> I used that last 6 years :D
[15:40] <philinux> you dont need sudo it will ask for password when needed
[15:40] <philinux> try it from a terminal
[15:41] <Milos_SD> philinux, you mean, to try to start update-manger -d from terminal, or to use terminal command for upgrade ?
[15:42] <philinux> start a terminal then use the command
[15:45] <philinux> Milos_SD: any joy
[15:45] <Milos_SD> philinux, half the way :)
[15:45] <Milos_SD> philinux, now I get the error I know how to fix :D
[15:46] <philinux> Milos_SD: what is the error?
[15:46] <Milos_SD> can't calculate packages size or something like that
[15:47] <Milos_SD> I need to restore default xorg
[15:47] <Milos_SD> I have one from xorg-edgers
[15:47] <Milos_SD> :)
[15:47] <philinux> Milos_SD: ah yes and I would disable all ppa's
[15:51] <Milos_SD> I guess I'll need to do a clean install ... it is a pain in the *** to restore default xserver without ppa-purge (it doesn't work on 64bit ubuntu)
[15:51] <Milos_SD> prossponing upgrade to the final release :)
[15:52] <philinux> Milos_SD: ppa purge works on 64 bit I always thought
[15:53] <Daekdroom> I had trouble getting rid of xorg-edgers on x64 12.04 LTS when I wanted to upgrade to 12.10
[15:53] <Milos_SD> philinux, it doesn't have good multiarch support
[15:53] <Daekdroom> I eventually was able to do it.
[15:53] <Daekdroom> Yeah. The issue was exactly the multiarch support.
[15:53] <Milos_SD> so it wants to delete all system :D
[15:53] <Daekdroom> I solved it by removing all 32-bit packages, purging, then reinstalling them, then upgrading.
[15:54] <Milos_SD> Daekdroom, purging all 64bit packages from xorg-edgers?
[15:54] <Daekdroom> Yeah.
[15:54] <Daekdroom> You could try ppa-purge -i as well
[15:54] <Daekdroom> -i should make it use apt-get instead of aptitude. aptitude is what has trouble with multiarch.
[15:56] <Milos_SD> Daekdroom, the same problem :)
[16:03] <philinux> Milos_SD: post a thread in here. There's a bunch of peeps use that ppa. http://ubuntuforums.org/forumdisplay.php?f=416
[17:30] <penguin42> anyone else using konsole - I'm finding the 'copy link address' isn't working
[17:33] <djazz> how long is it to ubuntu 12.10 beta 2?
[17:36] <penguin42> https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
[17:36] <penguin42> djazz: ^
[17:36] <penguin42> ooh, today apparently
[17:36] <djazz> yeah i know..
[17:36] <djazz> today
[17:37] <djazz> but its usually earlier, around 16-17. here its soon 20:00
[17:37] <djazz> i keep refreshing http://releases.ubuntu.com/12.10/
[17:37] <djazz> :
[17:37] <djazz> :D
[17:41] <konqui> Hi the quantal beta 2 is installing and the x button to cancel scanning apt mirrors does not work; it continues refreshing represitories
[17:45] <bjsnider> penguin42, you use kde man?
[17:46] <penguin42> nod
[17:46] <bjsnider> ugh
[17:46] <penguin42> it's very nice thank you :-)
[17:51] <Filar> Hello, where can I find beta2 download? I can't find it in google.
[17:53] <trism> Filar: beta2 isn't officially out yet
[17:54] <djazz> beta2 is out!
[17:54] <djazz> yay
[17:54] <djazz> http://releases.ubuntu.com/12.10/
[17:55] <trism> looks like beta1 to me
[17:55] <Filar> ah, I saw these previews, and thought it's already out
[17:55] <Filar> thank you
[17:55] <djazz> the torrent dont work..
[17:55] <djazz> "Downloading from 0 of 0 clients"
[17:56] <Filar> djazz: it's beta 1
[17:56] <djazz> title says Beta 2 and so does all files
[17:56] <Filar> april fools?
[17:56] <trism> not here
[17:57] <djazz> http://releases.ubuntu.com/12.10/ubuntu-12.10-beta2-desktop-amd64.iso
[17:58] <Filar> djazz: can you travel in time?
[17:58] <djazz> hm, the last modified times on the page, what timezone are those?
[17:58] <djazz> Filar: time is 19:58 here
[17:58] <Filar> same here
[17:58] <Filar> but perhaps you have a different timezone :P
[17:59] <djazz> "26-Sep-2012 06:46" for ubuntu-12.10-beta2-desktop-amd64.iso
[17:59] <djazz> :S
[17:59] <Filar> still beta1 here
[17:59] <djazz> the iso link dont work?
[17:59] <Filar> 404
[17:59] <djazz> hm
[17:59] <Filar> well, now it works
[17:59] <Filar> weird
[18:00] <djazz> heh
[18:00] <Filar> but few minutes ago I had file not found on this server
[18:00] <Filar> and the page still indicates beta1
[18:00] <Filar> or no, it does not
[18:00] <Filar> :D
[18:01] <Filar> but how did you have it a few minutes before us?
[18:01] <djazz> Filar: i got F5 skills
[18:01] <Filar> I was also trying F5
[18:01] <djazz> brb make ubuntu tea (well, tea in ubuntu mug)
[18:01] <Filar> w/o any result
[18:01] <djazz> different server maybe?
[18:01] <djazz> DNS?
[18:02] <Filar> google's
[18:02] <Filar> <IP_ADDRESS>
[18:02] <Filar> trism, did you have the same situation as me?
[18:03] <trism> Filar: indeed, actually it still says beta1 for me
[18:03] <Filar> trism, so maybe try to chenge dns to <IP_ADDRESS>?
[18:04] <Filar> change*
[18:04] <djazz> lol
[18:04] <djazz> now i see Beta 1
[18:04] <trism> Filar: oh I don't really mind I am already on quantal
[18:04] <Filar> hahah
[18:04] <djazz> now beta 2, now beta 1 again
[18:04] <djazz> :S
[18:04] <yofel_> the DNS would still be the same...
[18:05] <Filar> mindf*ck
[18:05] <penguin42> hey that's the wonders of mirrors, let it propagate out
[18:07] <PeterME_> Hi, after I installed Beta 2 my wm doesn't seem to be working..
[18:07] <Filar> PeterME_: so you managed to download beta2 :)
[18:07] <PeterME_> Yup
[18:08] <trism> PeterME_: not working in what way?
[18:08] <PeterME_> I followed this guide while still running 12.04 to get rid of Unity and I think that might have messed something up
[18:08] <PeterME_> I followed this guide while still running 12.04 to get rid of Unity and
[18:08] <PeterME_> http://superuser.com/questions/411850/after-installing-ubuntu-how-do-i-get-rid-of-unity-and-go-back-to-gnome
[18:08] <PeterME_> No borders on windows, no resizing buttons and unable to move windows around (kind of all related to each other)
[18:09] <trism> PeterME_: I would start with: sudo apt-get install ubuntu-desktop;
[18:10] <trism> PeterME_: or actually you may want to try ubuntu-gnome-desktop
[18:10] <PeterME_> It says it's already in the newest version
[18:11] <PeterME_> Second one seems to do something
[18:12] <trism> PeterME_: oh so did you only install gnome-panel? (the first answer in that thread suggested removing a bunch of stuff that should have removed ubuntu-desktop)
[18:12] <PeterME_> I did remove all that stuff, but some of it may have been reinstalled during upgrades (either to 12.10 or by accident earlier)
[18:13] <djazz> writing iso to usb.. :D
[18:15] <trism> PeterME_: which session are you using? (Gnome Classic I would guess, might try Gnome Classic (no effects), see if it is a compiz issue)
[18:15] <PeterME> Hmm, tried logging in and logging out
[18:15] <PeterME> Didn't help much
[18:15] <PeterME> (After installing ubuntu-gnome-desktop)
[18:16] <trism> PeterME: yeah that probably won't help, I thought initially you may have been missing packages if ubuntu-desktop wasn't installed during the upgrade (but since you already had it that probably isn't it)
[18:17] <trism> PeterME: perhaps an issue with your user settings, if you were to create a new user, does their session look alright?
[18:18] <PeterME> Hold on, I'll check
[18:19] <PeterME_> Nope, didn't work
[18:20] <trism> PeterME_: hmm, notice any major errors in ~/.xsession-errors?
[18:20] <trism> PeterME_: sounds like something is crashing
[18:23] <PeterME_> (gnome-panel:15701): Gtk-CRITICAL **: gtk_accelerator_parse_with_keycode: assertion `accelerator != NULL' failed
[18:23] <PeterME_> Not sure what that is but it's the only one that seems, well, critical
[18:24] <trism> PeterME_: does the panel show up?
[18:24] <PeterME_> Yes, everything but window borders
[18:24] <trism> PeterME_: if gnome-panel is there and works then that probably isn't the issue
[18:25] <trism> PeterME_: is this Gnome Classic with compiz or Gnome Classic (no effects) with metacity?
[18:25] <djazz> hm
[18:25] <djazz> the computer froze during the writing of the usb
[18:26] <djazz> had to reboot
[18:26] <djazz> never happened before
[18:26] <djazz> and omgubuntu has ofc already made a video about the new beta
[18:26] <PeterME_> I chose the Gnome Classic option, so I guess that's with compiz?
[18:26] <djazz> joey is so fast
[18:27] <trism> PeterME_: might try the other one, maybe compiz is having issues
[18:28] <PeterME_> https://www.dropbox.com/s/gx29w2u2hp2tx0y/Screenshot%20from%202012-09-27%2020%3A24%3A43.png
[18:28] <trism> PeterME_: is compiz-gnome installed?
[18:28] <PeterME_> There's a screenshot btw, just to make sure you understand the problem
[18:28] <trism> PeterME_: yeah that looks like compiz crashing
[18:29] <trism> PeterME_: any crash reports in /var/crash/?
[18:29] <PeterME_> Yup, compiz-gnome is installed
[18:29] <PeterME_> A couple
[18:29] <PeterME_> Hmm, one gnome-panel crsh
[18:31] <PeterME_> And a Nautilus crash..
[18:31] <trism> PeterME_: but no compiz crashes?
[18:32] <PeterME_> No, got one gnome-control-center crash
[18:32] <PeterME_> Hold on, I'll try Gnome Classic (No effects)
[18:32] <trism> not really stuff you want to crash but nothing that should cause what you are seeing
[18:33] <PeterME> Well, that works fine
[18:34] <trism> PeterME: yeah would definitely seem to be a compiz issue, can you pastebin your full ~/.xsession-errors?
[18:34] <PeterME> But all the Window buttons are back on the left hand side. Not a big problem though
[18:34] <PeterME> Sure
[18:34] <trism> PeterME: after logging into the compiz session that is
[18:36] <PeterME_> http://pastebin.com/j6bpVpNW
[18:37] <trism> PeterME_: ah hah, I saw this earlier in the cycle, it is only loading core and ccp plugins
[18:37] <trism> PeterME_: thought it was fixed though
[18:37] <PeterME_> trism: hmm
[18:38] <trism> PeterME_: let me see if it works for me, one sec
[18:38] <trism> PeterME_: ah, not working here either
[18:39] <trism> jbicha: did a patch get dropped in gnome-session 3.6?
[18:39] <PeterME_> Guess I'll just use it without compiz for the time being
[18:39] <trism> I suppose I could look at the package and see
[18:55] <jbicha> PeterME_: do you have ubuntu-desktop installed?
[18:55] <PeterME_> Yes
[19:00] <PeterME_> Hmm, how to I get the close, minimize and maximize buttons over to the right hand side?
[19:13] <prodnix> Hi all, Im lookin for help to get my passthrough ATI VGA card to work in ubuntu 12.10 guest. I have the device in lspci, i have the driver installed (fglrx) and used aticonfig to make a default xorg.conf but I am unable to get the card to work. Everytime I boot the machine i get the popup at boot sayin my devices could not be configured. Any help would be hugely appreciated
[19:14] <trism> jbicha: PeterME_ sorry gnome-session not to blame, looks like we don't have a default compiz profile anymore, bug 1036752
[19:23] <PeterME_> trism: okay, looking forward to a fix. Do you know how to move the close, minimize and maximize buttons to the right hand side by the way?
[19:32] <trism> PeterME_: something like: gsettings set org.gnome.desktop.wm.preferences button-layout ":minimize,maximize,close"; maybe?
[19:34] <PeterME_> Worked like a charm, thanks
[20:28] <FernandoMiguel> we are getting to that point, aren't we ?
[20:28] <FernandoMiguel> few updates, more or less stable system


[00:19] <lifeless> I really want a 'bzr edit-diff' which gives me the diff, lets me edit it, then saves the result back
[00:23] <verterok> Obmar: yes, that's an ugly bug, need to get some time and fix it
[00:26] <Obmar> verterok: That would be great.  I would love to be able to do bzr from in the IDE.
[00:28] <lifeless> spiv: ping
[00:29] <lifeless> spiv: the _commit_write_group check; I think that that may be better on the RepositoryPackCollection level ?
[00:33] <spiv> lifeless: rather than on the KnitPackRepository?
[00:33] <spiv> lifeless: sure, I essentially flipped a mental coin when deciding where to place that.
[00:36] <lifeless> I've moved it down
[00:36] <lifeless>     def _commit_write_group(self):
[00:36] <lifeless>         all_missing = set()
[00:36] <lifeless>         for prefix, versioned_file in (
[00:36] <lifeless>                 ('revisions', self.repo.revisions),
[00:36] <lifeless>                 ('inventories', self.repo.inventories),
[00:36] <lifeless>                 ('texts', self.repo.texts),
[00:36] <lifeless>                 ('signatures', self.repo.signatures),
[00:36] <lifeless>                 ):
[00:36] <lifeless>             # We use KnitVersionedFiles exclusively so can rely on _index.
[00:36] <lifeless>             missing = versioned_file._index.get_missing_compression_parents()
[00:36] <lifeless>             all_missing.update([(prefix,) + key for key in missing])
[00:36] <lifeless>         if all_missing:
[00:36] <lifeless>             raise errors.BzrCheckError(
[00:36] <lifeless>                 "Repository %s has missing compression parent(s) %r "
[00:36] <lifeless>                  % (self, sorted(all_missing)))
[00:37] <lifeless> ^ ok ?
[00:37] <lifeless> self.repo at the end obviosuly
[00:40] <spiv> Looks ok.
[00:44] <lifeless> spiv: ok, that branch is on its way to pqm
[00:44] <lifeless> where is the next one?
[00:55] <lifeless> spiv: ping
[00:58] <poolie> (some people at) nasa \heart bzr
[00:58] <poolie> yay
[00:58] <lifeless> nice
[01:04] <spiv> lifeless: tests all passing now I think; just removing a cruft
[01:12] <lifeless> beuno: http://blog.crisp.se/davidbarnholdt/2009/02/18/1234986060000.html really is nice
[01:21] <lifeless> spiv: well the scan api is gold
[01:21] <lifeless> spiv: I'd like to take the next lowest layer on, or ?...?
[01:23] <spiv> lifeless: I think I've removed the worst of the cruft now
[01:23] <spiv> lifeless: I still haven't added a flag to add_records, but otherwise I'm happy with this
[01:24] <spiv> lifeless: I'm pushing it up to lp:~spiv/bzr/missing-parents-integration
[01:25] <lifeless> spiv: k, give me a shout when its done
[01:27] <lifeless> spiv: also, have you had a chance to review network-name?
[01:27] <lifeless> spiv: if not thats fine, I might interrupt poolie
[01:28] <lifeless> who has the context for this
[01:28] <spiv> lifeless: I haven't, but now is a good time for me to do so
[01:40] <spiv> lifeless: reviewed, one typo found :)
[01:45] <lifeless> spiv: bombs away
[01:46] <lifeless> decided against a comment, because of too much duplication
[01:47]  * spiv nods
[01:54] <poolie> lifeless: nice drawings :)
[01:55] <lifeless> spiv: so, I'll review this branch; make any changes i need, and you ack the changes?
[01:55] <spiv> lifeless: +1
[02:00] <lifeless> spiv: looking at it, it seems easier to put back the older buffer code, and just make a single call at the end with the new flag, to add_records
[02:00] <lifeless> spiv: sound ok?
[02:02] <spiv> lifeless: yep
[02:03] <spiv> lifeless: having a single call to add_records would be more clearly correct, I think.  Less room for accidental double-insertion.
[02:03] <spiv> (Which is a bug I noticed I had during our phone chat this morning...)
[02:09]  * spiv -> lunch
[02:15] <poolie> lifeless: ping for a quick question
[02:15] <poolie> i'm just looking at mark's vcsrace on status
[02:15] <poolie> the results are generally really good except for status which spends a considerable amount of user time compared to the competition
[02:16] <poolie> i think this is because of overhead of building tuples from the dirstate etc
[02:17] <lifeless> poolie: [waiting for the question]
[02:18] <poolie> would you agree?
[02:19] <poolie> from memory i mean
[02:19] <lifeless> well
[02:20] <lifeless> One planned experiment is to write a pure C implementation
[02:20] <poolie> yes
[02:20] <poolie> actually i see something interesting in the profile
[02:20] <lifeless> we may be able to squeeze some more out of chdir
[02:20] <poolie> the system time is actually pretty good
[02:20] <lifeless> running up oprofile over it would be interesting too
[02:20] <poolie> the interesting thing is that we're using the generic InterTree.compare
[02:20] <lifeless> poolie: pending merge?
[02:20] <poolie> because mark's measuring the special case of changes from the empty tree
[02:21] <lifeless> oh
[02:21] <poolie> i suspect dirstate just gives you an EmptyTree
[02:21] <poolie> and this is unoptimized
[02:21] <lifeless> grah
[02:21]  * lifeless hates on special cases
[02:21] <poolie> i may be wrong
[02:21] <poolie> quick, add another special case :)
[02:21] <lifeless> measurement is the only way to be sure :)
[02:22] <poolie> well, it is definitely using the generic one
[02:23] <poolie> hm no it's not literally EmptyTree, which is deprecated
[02:24] <lifeless> spiv: get_missing_compression_parents: perhaps on _index only ?
[02:24] <lifeless> spiv: I don't think it needs to be top level
[02:25] <lifeless> spiv: actually scratch that, the tests would be ugly
[02:25] <lifeless> spiv: its fine
[02:34] <jml> crapzor.
[02:34] <jml> it's doing it again
[02:34] <jml> same branch. one more revision.
[02:38] <jam> poolie: IIRC we've gone back and forth on the patch that removes the special case when there is no entries
[02:38] <jam> at least, I seem to remember fixing that in the past
[02:38] <jam> # the source revid must be in the target dirstate
[02:38] <jam> if not (source._revision_id == NULL_REVISION or
[02:38] <jam>     source._revision_id in target.get_parent_ids()):
[02:38] <lifeless> spiv: done; bzr sending it
[02:39] <jam> Looks like we should be handling the NULL tree
[02:40] <jam> If we aren't, something else is wrong
[02:41] <lifeless> spiv: mail sent; review @ will. next is suspend/resume yeah?
[03:00] <PHPlover> hi when I use ftp push, Does it actually upload the files. So that if I were to have a HDD failure, i could retrieve those files from the FTP server?
[03:02] <PHPlover> It does it just upload some kind of data about changes to the files [I Dont understand versioning systems]
[03:02] <lifeless> PHPlover: it creates a database
[03:03] <lifeless> PHPlover: you can inspect what it has uploaded by using bzr - e.g. 'bzr log URL'
[03:03] <PHPlover> ok, and does that database store the complete data of every file in my project, Or just info about the files
[03:03] <lifeless> it stores the complete copy of each commit, which includes the files that *are versioned*, but not those that are not
[03:04] <lifeless> PHPlover: the easiest way to see what its done, is to 'bzr branch URL /tmp/spare-directory' and have a look at what bzr puts in spare-directory
[03:05] <lifeless> poolie: ping
[03:05] <lifeless> poolie: does bencode avoid \n ?, or can/should I avoid a \n some other way . (network_name currently has \n, but that breaks SmartServerRequest.do()
[03:08] <spiv> lifeless: \n in HPSS args are fine with HPSS v3
[03:08] <lifeless> spiv: interesting.
[03:08] <spiv> bencode length prefixes strings.
[03:08] <lifeless> spiv: how do a I register a verb to be only used with one HPSS version then ? :P
[03:08] <lifeless>   File "/home/robertc/source/baz/push.roundtrips/bzrlib/remote.py", line 2002, in _translate_error
[03:09] <lifeless>     raise errors.UnknownErrorFromSmartServer(err)
[03:09] <lifeless> UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'do() takes exactly 4 arguments (3 given)')
[03:09] <lifeless> the blackbox tests pass
[03:09] <lifeless> but the per-repository RemoteRepositoryFormat-v2 tests are failing
[03:09] <lifeless> for the reason-under-discussion
[03:09] <spiv> Currently that's taken care of in the client; the client never tries sending various requests to older servers
[03:09] <lifeless> ok, so I should guard based on a check?
[03:10] <spiv> Right.  The client asks the medium if .is_remote_before((1,2)) or whatever.
[03:11] <spiv> And also does _remember_remote_is_before((x,y)) when it notices a smart method is not implemented to save it trying that or other new methods again.
[03:11] <lifeless> is that _protocol_ or _bzrlib version_
[03:12] <lifeless> [how do I get these tests to work :P]
[03:12] <spiv> It's the bzrlib version.
[03:12] <spiv> When the protocol is v2, the medium immediately "remembers" that remote is before (1,6) (or whenever v3 was added).
[03:13] <lifeless> ok, so its a lie, but don't look under the hook ?
[03:13] <lifeless> *hood*
[03:13] <spiv> Yeah.
[03:13] <spiv> I'm not 100% happy with it, but it does the job.  Well, jobs.
[03:14] <spiv> (Avoid trying calls that require \n in args and whatever that are new in v3, and also avoid repeatedly trying an RPC once we know the server doesn't implement it.)
[03:15] <lifeless> where is the code so I can figure out what .is_remote_before to use
[03:15] <lifeless> like is 1,6 right
[03:15] <lifeless> or 1,2
[03:15] <lifeless> or ?
[03:16]  * spiv is looking
[03:17] <lifeless> protocol_version in medium still returns '2' :P
[03:18] <lifeless> or should I say is_before(1,13) ?
[03:20] <spiv> Probalby 1,13 would be best.
[03:21]  * spiv can't find where the remembered version is set low for v2 protocols.
[03:23] <lifeless> ok I'm unblocked on that, though 1,13 fails the current version test :P
[03:23] <lifeless> spiv: *and*
[03:23] <lifeless> it still runs the verb on the Remotev2 tests
[03:23] <lifeless> hmm, checking
[03:24] <spiv> Ah, found it.
[03:24] <lifeless> ok fixed
[03:24] <lifeless> cool
[03:24] <lifeless> so the branch for partial insertion is polished and up for review
[03:24] <spiv> bzrlib/smart/client.py calls self._medium._remember_remote_is_before((1, 6))
[03:25] <spiv> once it finds out that v3 doesn't work.
[03:25] <spiv> Cool, I'll take a look.
[03:25] <lifeless> I'm waiting on the next unit of work
[03:26] <lifeless> the network data serialisation for record streams is also outstanding for review
[03:26] <lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1234854080.11037.18.camel%40lifeless-64%3E
[03:36] <lifeless> spiv: ok, and I've just flushed the new verbs to qm
[03:36] <lifeless> *pqm*
[03:36] <lifeless> spiv: how should we split up the remaining work? Want a quick call?
[03:41] <spiv> lifeless: ok
[03:41] <spiv> lifeless: (I'm reviewing the network serialisation atm)
[03:42] <lifeless> ok, I'll ring you now if thats ok
[03:42] <spiv> Yep
[03:48] <spiv> lifeless: http://people.ubuntu.com/~andrew/bzr/streaming-push
[03:48] <spiv> lifeless: ...nearly pushed
[03:49] <spiv> lifeless: done.
[03:50] <lifeless> spiv: cool
[03:54]  * igc lunch
[04:05] <lifeless> spiv: so RemoteVersionedFile has some of our fetch refactoring
[04:09] <lifeless> spiv: it looks like RemoteVersionedFile is a little confused, the loom basically resets @ Very fetching
[04:10] <lifeless> spiv: or something. econfused:P cherrypicking and reviewing
[04:12] <spiv> lifeless: weird.
[04:12] <lifeless> jam: dropping the group size will shrink things because of the full texts at new groups
[04:42] <Peng_> mwhudson: ping?
[04:43] <poolie1> igc, can you remind me why content-filtering needs to change dirstate?
[04:43] <poolie1> would it be at all possible to avoid it?
[04:43] <lifeless> poolie: sha on disk != sha in storage ?
[04:46] <poolie1> well, of course that's true for filtering
[04:46] <igc> it's been a while but what lifeless says sounds right
[04:47] <igc> poolie1:^
[04:47] <poolie1> it was more the next logical step after that that I'm thinking about
[04:47] <lifeless> spiv: testing a massaged Very fetching with the lower layers removed
[04:47] <lifeless> spiv: I'm keeping length_prefix, though really its in the wrong home
[04:49] <Raawfle> aaargh
[04:50] <lifeless> Raawfle: some context might help
[04:50] <lifeless> spiv: as we knew, progress breaks
[04:52] <lifeless> spiv: so I'm going to commit it, and then start working on the progress bars
[04:53] <spiv> lifeless: sounds good
[05:01] <lifeless> poolie: can you decode what this means for me ?
[05:01] <lifeless> /home/robertc/source/baz/fetch.sinks/bzrlib/ui/__init__.py:91: UserWarning: ProgressTask(0/1, msg='fetch texts') is not the active task ProgressTask(None/None, msg='')
[05:01] <lifeless>   % (task, self._task_stack[-1]))
[05:04] <poolie1> lifeless: probably that you're missing a finally block
[05:05] <poolie1> prior to the code that constructs  ProgressTask(0/1, msg='fetch texts')
[05:05] <poolie1> hth
[05:05] <lifeless> poolie1: ok, will look for that
[05:05] <lifeless> poolie1: if it helps we have generators around generators
[05:06] <poolie1> no, that doesn't help :-)
[05:06] <poolie1> the previous pb seems to contain nothing
[05:07] <poolie1> so you can probably just remove it
[05:07] <lifeless> is previous a higher one?
[05:07] <lifeless> or one that wasn't cleaned up from an earlier test?
[05:07] <poolie1> so, there's supposed to be a stack
[05:08] <poolie1> this message indicates that you tried to finish the one that's not on top of the stack
[05:08] <poolie1> so actually "prior" is not necessarily true
[05:08] <poolie1> so there are (at least) two here
[05:08] <poolie1> A and B
[05:09] <poolie1> it may be that B is conceptually inside A, and now all of A is finished but you forgot to finish B first
[05:09] <poolie1> or, it may be that B is a sibling of A, and you forgot to finish A before starting B
[05:09] <poolie1> if you see what i mean
[05:10] <lifeless> yeh
[05:10] <lifeless> I'm worried that generators are interacting badly
[05:10] <lifeless> spiv and I overhauled fetch()
[05:11] <lifeless> one answer is to remove the progress entirely for now
[05:12] <poolie1> for many generators i'd say that giving an activity indicator may be more appropriate
[05:13] <poolie1> because, firstly you may not know how many things are generating
[05:13] <lifeless> indeed
[05:13] <poolie1> and, as a technical reflection, finishing up is hard
[05:15] <lifeless> ah found it
[05:15] <lifeless> we have a function that passses a pb into a method
[05:15] <lifeless> that method finishes it and rebinds it
[05:15] <lifeless> I'll change it to an instance variable, bet it fixes it
[05:15] <poolie1> hm as i may have said in a review, i think passing pbs around is whack
[05:15] <poolie1> it's one thing i'd like to fix here
[05:16] <poolie1> except in pretty special cases, a progress bar should correspond to a for loop in one function
[05:16] <lifeless> poolie1: I'm not justifing the current code ;)
[05:16] <poolie1> and the nesting of them i think can be done by the ui global :)
[05:16] <poolie1> i know, i'm just repeating this thought in case you want to agree :)
[05:17] <lifeless> oh, I agree
[05:18] <lifeless> no warnings now, that was it
[05:18] <poolie1> ok
[05:19] <poolie1> well, i'm glad it wasn't spurious and didn't take too long to track down
[05:19] <lifeless> :)
[05:19] <poolie1> igc, so, i'm not quite done on filtering but it's not all that hadr
[05:20] <poolie1> i am inclined to see if doing it on top of dirstate is within reach
[05:20] <poolie1> at the least i'd like to document why
[05:20] <lifeless> poolie1: did you see my comment about sha on disk and sha in repo?
[05:20] <poolie1> yes but no but yes but
[05:21] <poolie1> obviously they are different,
[05:21] <poolie1> but this doesn't change dirstate to store both of them
[05:21] <lifeless> what does it do
[05:22] <poolie1> it seems to change it to record the filtered sha1
[05:23] <poolie1> sorry, i mean the sha1 of running the input filters on the file
[05:24] <mwhudson> Peng_: hola
[05:28] <Peng_> mwhudson: Hi.
[05:28] <Peng_> Um.
[05:31] <Peng_> mwhudson: I have a dumb question about your changes to LH's served_url stuff. I used to monkeypatch served_url to return URLs relative to /bzr instead of /loggerhead, but now that doesn't work. So...what do you think I should do?
[05:32] <mwhudson> Peng_: um
[05:32] <Peng_> :D
[05:32] <lifeless> spiv: sending it for review, I'm happy and only trivial changes; if you're happy with my arbitrary cleanups we can just land it
[05:32] <mwhudson> Peng_: think of a way you'd like this to work and tell me about it :)
[05:33] <Peng_> mwhudson: Heh. I was happy with how I was doing it before. :P
[05:33] <mwhudson> Peng_: you can probably monkey patch BranchFileSystem.app_for_branch
[05:35] <mwhudson> Peng_: alternatively, one could extract the calculation of the default value out into a method that you could then monkey patch
[05:40] <Peng_> I'm barely awake enough to understand what that means, but I think it sounds good.
[05:41] <spiv> lifeless: fancy that, I just sent you a review too.
[05:41] <spiv> lifeless: If you only made arbitrary trivial cleanups to my code, then yes I'm definitely +1 on principle :)
[05:41] <spiv> lifeless: I can eyeball it anyway if you want.
[05:41] <lifeless> spiv: just sent it
[05:41] <lifeless> spiv: its basically - delete the RVF stuff
[05:42] <lifeless> spiv: fix progress bars
[05:44] <lifeless> spiv: we can't do RemoteStreamSink until the vf network bytes lands
[05:45] <spiv> I know.  I tried not to let immiment achievements cloud my review judgement, though...
[05:49] <spiv> lifeless: there's some odd stuff in that diff you just sent; additions to the makefile etc.
[05:49] <spiv> lifeless: perhaps the branch you sent has more recent bzr.dev than bzr send diffed against?
[05:51] <lifeless> unlikely
[05:51] <lifeless> however wrong parent is likely
[05:54] <spiv> Ah, yeah.
[05:54] <lifeless> resent
[05:55] <poolie1> out to the shops before they close, will finish igc's review today though
[05:56] <ronny> morning
[05:58] <spiv> Heh, I see _length_prefix did sneak into that diff.
[05:59] <lifeless> spiv: I kept it deliberately
[06:00]  * spiv nods
[06:00] <spiv> lifeless: reviewed (tweak)
[06:01]  * spiv keeps reviewing
[06:03] <lifeless> spiv: ok network serialisation on its way to pqm
[06:04] <lifeless> spiv: so we can merge that into the fetch refactoring branch
[06:08] <spiv> lifeless: just bb:approved your "insert record streams with missing compression parents" patch
[06:08] <lifeless> excellent
[06:08] <lifeless> I'll kick that off now
[06:09] <lifeless> spiv: so what do we have left
[06:09] <lifeless> suspend resume? is that up for review yet?
[06:11] <spiv> Hmm, I don't think so.
[06:11] <lifeless> so it depended on missing parents and partial streams
[06:11] <lifeless> both are fully acked
[06:11] <lifeless> why don't you polish that, and I'll get the network stream integrated with RemoteSink
[06:11] <lifeless> which will fail on stacked branches until suspend resume is done
[06:12] <spiv> Ok.  Let's see if I can figure out which branches to merge into suspend-resume to bring it up to date...
[06:12] <lifeless> :P
[06:12] <lifeless> so administrivia
[06:12] <lifeless> I'd *love* to finish this today
[06:12] <lifeless> but its after
[06:12] <lifeless> 5
[06:13] <lifeless> if you're up for a sprint-to-finish, so am I. And I'm sure we can convince poolie for some slack on Monday :)
[06:13] <spiv> Oh that's right, we were sensible and made that a branch off bzr.dev.  That helps ;)
[06:14] <spiv> I'm still going strong atm ;)
[06:14] <lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1235097663.6233.119.camel%40lifeless-64%3E is what you need for suspendresume
[06:14] <spiv> I'll probably need to stop about 6:30
[06:14] <lifeless> the clock is on :)
[06:15] <spiv> :)
[06:18] <lifeless> you probably want bzr.dev too or that matter
[06:21] <spiv> Yeah, already grabbed that :)
[06:31] <lifeless> spiv: ok, failure in my streams bytes thing in reconcile
[06:31] <lifeless> while I investigate that the other approved patch is on the way
[06:31] <poolie1> igc, still around at all?
[06:38] <igc> poolie1: yep
[06:40] <poolie1> i'm going to send a review in a sec
[06:40] <poolie1> do you want to talk about it/
[06:41] <spiv> lifeless: http://rafb.net/p/wgjSMm15.html is failing on the assertRaises; because the add_lines after the resume_write_group doesn't actually make a record with a compression parent.
[06:42] <spiv> lifeless: what's a good way to add a record with a compression parent there, should I crib from test_versionedfiles perhaps?
[06:42] <spiv> With a *missing* compression parent, specifically...
[06:42] <lifeless> spiv: you need two repos
[06:43] <lifeless> in repo one you do add_lines(base, (), [... ... ...])
[06:43] <spiv> lifeless: that's what I feared :)
[06:43]  * spiv does that
[06:43] <lifeless> and add_line(child, (base,), [.....])
[06:44] <lifeless> then repo2.texts.insert_record_stream(repo1.texts.get_record_stream(base,...)
[06:44] <lifeless> sorry not base there
[06:44] <lifeless> just delta
[06:44]  * spiv nods
[06:45] <lifeless> or
[06:45] <lifeless> use knit.make_pack_factory
[06:45] <lifeless> to get a vf object
[06:45] <lifeless> in lieu of a second repo
[06:53] <spiv> Existing tests passing, I think...
[06:53] <lifeless> cool
[07:02] <spiv> Ok, wrote a test for filling in a missing parent after a suspend/resume, currently failing :)
[07:02] <spiv> Fixing...
[07:02] <lifeless> spiv: I'm modifying RemoteSink to fallback to _real when stacked, pending the stuff you're doing
[07:04] <lifeless> spiv: minor tweak needed, our substreams need to encode a prefix record
[07:05] <lifeless> spiv: dealing with the keywidth mismatch
[07:08] <spiv> Oh, right.
[07:09] <lifeless> so in do_chunk on the reader
[07:09] <lifeless> does it know its a pack stream and give us only the bytes_record ?
[07:09] <spiv> Ok, filling in a missing parent after suspend/resume works.
[07:10] <lifeless> woooooooooooooo
[07:10] <lifeless> ooooo
[07:10] <lifeless> ooo
[07:10] <lifeless> and the current branch is into ascii tests
[07:10] <lifeless> which is fetch refactor
[07:11] <spiv> Hmm, I think I need more context to understand your question.
[07:11] <spiv> do_chunk is called as bytes of the request *body* arrive.
[07:11] <lifeless> yes
[07:11] <lifeless> SmartServerRepositoryInsertStream
[07:12] <lifeless> I think it will be fine
[07:12] <spiv> So long as the client is generating a request body stream of a pack, which IIRC it is...
[07:13] <spiv> i.e. it's basically just sending what the ContainerWriter is emitting
[07:13] <spiv> So that should be fine, yeah.
[07:20] <vila> hi all (completely forget my ping this morning :)
[07:20] <spiv> Ok, added what I think is the last test, that suspend/resume doesn't accidentally make an uncommittable write group committable.
[07:20] <spiv> Not passing yet :)
[07:21] <poolie1> hello vila
[07:22] <vila> hi poolie1 :)
[07:30] <spiv> lifeless: passing, just fixing up duplication added to make it pass
[07:32] <lifeless> spiv: cool
[07:32] <lifeless> spiv: I think I'm done too, bit of staring involved
[07:32] <lifeless> spiv: the glue is a little awkward, pack -> bytes -> pack reader -> bytes -> NetworkRecordStream
[07:33] <spiv> lifeless: ok, pushing
[07:33] <spiv> lifeless: it'll be at http://people.ubuntu.com/~andrew/bzr/suspend-write-group shortly
[07:33] <lifeless> spiv: was there a test to run to check this works
[07:34] <lifeless> spiv: one branch landed
[07:34] <lifeless> pulling .dev and sending the next
[07:35] <spiv> lifeless: there were acceptance tests in that loom
[07:36] <spiv> lifeless: although now that I look at it again, the test_push_smart_stacked_streaming_acceptance test is slightly wrong :)
[07:37] <spiv> lifeless: we expect 2 insert_stream RPCs now, not 1.
[07:37] <spiv> If things are working, that is :)
[07:37] <lifeless> spiv: cool cool
[07:37] <spiv> lifeless: so, my branch is pushed, and all tests seem to be passing here.
[07:38] <spiv> (running a bigger selftest to be sure, but so far so good)
[07:38] <lifeless> spiv: whats a good test to test RemoteSink ?
[07:39] <spiv> lifeless: hmm
[07:40] <lifeless> fetch tests pass
[07:41] <jml> lifeless: https://code.edge.launchpad.net/~lifeless/subunit/polish/+merge/2735
[07:42] <lifeless> dammit, its creating manually ><
[07:42] <spiv> lifeless: I suppose a simple test_remote test that shows that RemoteRepo._get_sink().insert_stream(...) invokes the right RPC would be good.
[07:42] <jml> lifeless: btw, "bzr send --no-bundle" to<EMAIL_ADDRESS>Just Works.
[07:42] <spiv> Possibly even with a stream of []  ;)
[07:46] <spiv> I'm sending up the suspend-write-group branch for review
[07:46] <lifeless> cool
[07:46] <lifeless> resending partial inserts (typo :()
[07:47] <spiv> :(
[07:49] <lifeless> jml: thank; commonprefix?
[07:50] <jml> lifeless: os.commonprefix.
[07:50] <jml> lifeless: it's a blight on the standard library. only use it if you want your file operations to be broken
[07:50] <spiv> lifeless: oh, heh, I already had that exact one-liner in my suspend-write-group branch.
[07:50] <jml> lifeless: os.commonprefix('/foo/bar/baz', '/foo/baz/bop') => '/foo/ba'
[07:50] <lifeless> spiv: the typo ?
[07:52] <spiv> lifeless: yeah
[07:53] <lifeless> spiv: :)
[07:54] <lifeless> spiv: I don't see the patch
[07:59] <lifeless> spiv: ok, its writing a pack directly
[08:00] <poolie> night all
[08:02] <spiv> lifeless: ok, patch sent.
[08:03] <spiv> lifeless: I'm done for the evening, but I'm very happy with the shape of the resume_write_group code.  Maybe it's my Friday evening judgement, but I think that patch only has a few minors warts, rather than any glaring problems ;)
[08:04] <spiv> lifeless: thanks for helping me get it into shape
[08:04]  * spiv -> food, weekend, world of goo, etc!
[08:11] <lifeless> spiv: approved
[08:12] <lifeless> spiv: I'm going to keep plugging at joining these dots
[08:12]  * lifeless will be begging for reviews I think
[08:12] <spiv> lifeless: I'll pqm-submit it, thanks.
[08:13] <lifeless> the dependent patch is onto ascii
[08:13] <lifeless> should land fine I think
[08:19] <lifeless> spiv: woo, 74 -> 60
[08:20] <spiv> lifeless: the ratchet?
[08:20] <lifeless> for non-stacked
[08:20] <lifeless> stacked goes 99 -> 101
[08:20] <spiv> Nice.
[08:20] <lifeless> the latter is uninvestigated as yet
[08:20] <lifeless> but I think its going to be due to my if block pending suspend integration
[08:20] <spiv> Is stacked still hitting the thing in InterPackRepo that explicitly uses something dumb?
[08:20] <lifeless> so commiting and sending for review
[08:21] <spiv> (the "if len(fallback_repos) > 0" check)
[08:21] <nhaines> I have a merge request from a friend who didn't set his 'whoami' info on the shared computer he was using.  How can I modify the commit email address before I merge into my main branch?
[08:24] <lifeless> spiv: yes
[08:25] <lifeless> nhaines: you can't, because commits are immutable; you can either degrade to a regular patch (do a merge, then bzr revert --forget-merges), or not
[08:27] <nhaines> lifeless: both what I feared and what I needed to know.  Thanks.  :)
[08:34] <lifeless> spiv: one more landed
[08:46] <lifeless> I'm looking for a reviewer for http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1235118639.6233.151.camel%40lifeless-64%3E
[08:55] <ronny> lifeless: bzrlib/smart/protocol.py -> wouldnt just raise do?
[08:57] <lifeless> ronny: no, interim revisions in called code trash state
[08:57] <lifeless> s/revisions/exceptions./
[08:59] <ronny> ah, i see
[09:00] <lifeless> thats actually a pretty standard python recipe
[09:01] <ronny> never ran across it
[09:01] <ronny> wont that go away in python3 anyway?
[09:01] <ronny> (afair they put the traces on the exception)
[09:10] <faspell> \quit
[09:17] <spiv> lifeless: haha, that diff removes _length_prefix again :)
[09:18] <spiv> Ah, and moves it to a different file.
[09:18] <spiv> lifeless: looks good.  bb:approve
[09:18] <spiv> Ok, really gone for the night now.
[09:23] <lifeless> spiv: ciao :
[09:23] <lifeless> spiv: just finishing the whole thing off now :)
[09:29] <ronny> lifeless: hmm, i made up a small testcase, and it doesnt seem to trash state, was this a bug in earlyer python?
[09:29] <lifeless> ronny: possibly
[09:29] <ronny> unless im misstaken http://paste.pocoo.org/show/104633 demonstrates that it works in 2.4/2.5
[09:31] <lifeless> ronny: I'd need to check theexact way things propogate
[09:31] <lifeless> your test does look plausible to me at ist consideration
[09:33] <ronny> bbl, need to solve some snow issues
[09:56] <lifeless> ok
[09:56] <lifeless> 83 round trips
[09:56] <lifeless> so 18 less
[09:56] <lifeless> and massively less for non-muppet content
[10:57] <EricHerman> I just installed using Bazaar-1.11-OSX10.5.dmg and I see a strange message: "WARNING: bzrlib version doesn't match the bzr program"
[10:57] <EricHerman> which goes on to print: bzrlib from ['/Library/Python/2.5/site-packages/bzrlib'] is version (1, 11, 0, 'final', 0)
[10:57] <EricHerman> which looks like a match to me.
[10:57] <EricHerman> http://pastebin.com/m1260cb9a
[10:58] <EricHerman> Any suggestion as to what I might look at next?
[10:59]  * beuno pokes verterok and vila
[11:19]  * verterok is not here
[11:19] <verterok> hi beuno
[11:20] <beuno> hi verterok
[11:20] <verterok> EricHerman: hi, check you have another bzrlib in your PYTHONPATH
[11:20] <beuno> this is what you get for being an apple fanboy
[11:20] <EricHerman> looking
[11:21] <beuno> pings for support on it  ;)
[11:21] <verterok> beuno: apple fan boy? where? I use Ubuntu ;)
[11:22] <EricHerman> verterok, I do not have PYTHONPATH set in my envrionment
[11:23] <beuno> verterok, oh, don't tempt me...
[11:24]  * EricHerman tries find / -name bzrlib
[11:30] <EricHerman> find only reports /Library/Python/2.5/site-packages/bzrlib
[11:35] <verterok> EricHerman: weird, I didn't installed 1.11, but 1.10 works ok.
[11:36] <verterok> EricHerman: I'll download and install 1.11, and report back if I hit any issues
[11:36] <verterok> EricHerman: did you upgraded from a previous version?
[11:37] <EricHerman> I /had/ 1.6 which was built from source, but I removed it.
[11:37] <EricHerman> it's possible that there was something left over, but I don't know what that might have been.
[11:38]  * domas hands over strace to Eric :)
[11:38] <james_w> EricHerman: which bzr script are you running?
[11:40] <EricHerman> james_w, I'm not sure how to answer that question. I envoke /usr/bin/bzr ....
[11:40] <EricHerman> (that file itself does not have a version number in it)
[11:41] <EricHerman> ls -ld $(which bzr)
[11:41] <EricHerman> -rwxrwxr-x  1 root  wheel  4313 Mar 22  2008 /usr/bin/bzr
[11:41] <EricHerman> date is suspicious on that, hmmm!
[11:42] <james_w> EricHerman: yeah, just wondered if you had an old /usr/local/bin/bzr or something
[11:42] <verterok> EricHerman: please check if you have a bzr in /usr/local/bin
[11:43] <domas> 'which bzr'
[11:43] <EricHerman> Indeed! but oddly it *also* gives that message.
[11:43] <EricHerman> I think I'll try to remove everything and start again.
[11:44] <verterok> EricHerman: good idea :)
[12:22] <EricHerman>  well, having done a full rm -rf of all the potentailly bzr related stuff I could find on the system (with luck I didn't nuke *too* much!), then doing a reinstall using Bazaar-1.11-OSX10.5.dmg ... I no longer see the strange message. Conclusion: something stale on the filesystem was at issue. Had to be one of these: http://rafb.net/p/X85tuO44.html
[12:23] <EricHerman> on a clean system Bazaar-1.11-OSX10.5.dmg should be just fine.
[12:50] <harobed> hi, I can I do with bzr the same thing than svn status -r HEAD ?
[12:53] <maxb> harobed: svn status -r HEAD is not a valid svn command
[12:54] <harobed> sorry, svn status -u
[12:54] <harobed> or svn diff -r HEAD
[12:55] <harobed> to see differences between repository and local working copy
[12:56] <Lo-lan-do> "bzr diff :parent --new ."
[12:57] <Lo-lan-do> Or maybe "bzr diff :bound --new ." if you're in a checkout/bound branch.
[12:57] <Lo-lan-do> (Not tested, but I think that should work)
[12:58] <harobed> ok, I'll test it
[12:59] <Lo-lan-do> Please tell me if it works, it might interest me in the future :-)
[13:00] <Lo-lan-do> Although I usually do "bzr status" and "bzr missing :bound".
[13:01] <harobed> I've this message : bzr: ERROR: No bound location assigned.
[13:03] <harobed> ok, I've binded to parent bancsh
[13:03] <harobed> branch
[13:03] <harobed> bzr diff :bound --new . work as svn diff -r HEAD
[13:04] <harobed> but I don't know how to do : svn status -u
[13:04] <fullermd> Well.  If you don't want it to be a checkout, don't bind it...
[13:06] <Lo-lan-do> bzr diff :bound --new . | lsdiff
[13:07] <james_w> does "bzr status -r branch::bound" work?
[13:10] <harobed> james_w: yes, it work
[13:48] <Lo-lan-do> Er... I constantly get "Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)" messages, even after upgrading the server to 1.12...
[13:49] <Lo-lan-do> (In a branch bound to a bzr+ssh://foo branch in a remote repo)
[13:53] <Lo-lan-do> Hah.  It helps if I upgrade the correct server.
[13:53] <james_w> heh :-)
[13:53]  * Lo-lan-do hides
[13:53] <Odd_Bloke> :D
[13:54] <Lo-lan-do> Damn.  I upgraded my workstation to 1.12 and now I can't reinstall bzr-svn.
[13:55] <Lo-lan-do> (Current bzr-svn depends on subvertpy, which is stuck in NEW)
[13:56] <Lo-lan-do> I'll make do with a local install in the meantime.
[14:00] <Odd_Bloke> Lo-lan-do: You could build subvertpy yourself.  jelmer has published the packaging branch somewhere.
[14:01] <Lo-lan-do> Yeah, I did that already :-)
[14:01] <jel> hey guys :)
[14:03] <jel> What's the status of nested-tree support in bzr?  I see some stuff in the wiki about a branch jelmer was working on being merged in 0.15, and that it just requires a manual bzr add path but it doesn't seem to work -- just ignores the subtree, listing it as unknown.
[14:03] <jel> That branch was back in 2005, so It's hard to believe it's not finished.   IIRC abentley is planning on working on it near full-time in ~the  next month
[14:14] <jam> vila: just thought I'd say hi. Also, a quick question about the EC2 machine
[14:15] <jam> Are you interested in setting it up with my help? Or should I just do it?
[14:15] <jel> jam: ah, that's great news.  Are there any details of how it will be implemented/used?
[14:15] <jam> jel: So the original design was that if you did:
[14:15] <jam> bzr branch $METAPROJECT project
[14:15] <jam> cd project
[14:15] <jam> bzr branch $SUBPROJECT subdir
[14:15] <jam> bzr add subdir
[14:15] <jam> bzr commit
[14:16] <jam> Then you would have a "combined" project
[14:16] <jam> such that in the future doing "bzr branch $METAPROJECT" would give you both
[14:16] <jam> but the project histories would be versioned independently
[14:16] <jam> just that when you do "bzr commit" in the outer-dir, it would recursively commit the children
[14:16] <vila> jam: I'm still uncomfortable with using Windows remotely, I still plan to set one up as a VM locally (with an emphasis on using only free software and an automated setup) so I will certainly monitor what happen on the EC2 machine
[14:16] <jam> and track the committed revision in the parent
[14:16] <jel> jam: ok, cool, sounds like the old plan, which looked very usable :)
[14:17] <jam> vila: k, I thought I might get you to write my documentation for me again. :) I have 3-4 emails about when I set up kerguelen
[14:17] <jam> and I just need to turn it into a real "setting up a win32 build host" document
[14:17] <vila> jam: certainly something I plan to do anyway :)
[14:17] <jam> Since we're setting up yet-another host, it is a good time to do so
[14:18] <jel> abentley: Is there a name for your nested-tree project, or a branch/feed somewhere where I can track its progress?
[14:19] <vila> jam: yes, that's the "yet-another" that triggers my desire to automate it (and the aim to allow others to do it as well, no matter what degree of automation I'll achieve)
[14:19] <abentley> jel: I haven't set anything up yet.
[14:19] <jel> ok, thanks
[14:20] <jel> abentley: Not to push you, but can you confirm that you're planning to work on it soon?  It's an important feature for me, and I need to make a decision on which vcs to use, is all.
[14:20] <abentley> jel: I am planning to work on it soon.
[14:21] <jel> k, thanks :)
[14:22] <vila> abentley: have you seen my mail about iter_changes bogus indentation regarding tree-reference handling ?
[14:23] <abentley> vila: Yes.  Thanks for that.  I'm surprised it didn't break any test cases.
[14:23] <vila> abentley: yeah, same here, shame :-(
[14:58] <barry> jam: ping
[14:59] <jam> hi barry
[14:59] <barry> jam: hi!  i upgraded code.python.org to bzr 1.12 today
[14:59] <barry> jam: but i think i want to upgrade the repo formats of the mirrors
[15:00] <beuno> barry, you can use recursive upgrade plugin: http://bazaar-vcs.org/BzrPlugins
[15:00] <beuno> or
[15:00] <barry> jam: we're on rich-root-pack right now.  thinking about 1.9-rich-root, but i'm trying to decide whether the performance improvement would be worth (potentially) forcing people to upgrade their clients
[15:00] <beuno> jam has a nice script in contrib/
[15:01] <jam> barry: from my experimentation with the python repo, I would say yes
[15:01] <jam> but I don't create the policy for upgrading clients
[15:01] <beuno> 0.92 -> 1.9 was a big improvment for me, FWIW
[15:01] <jam> beuno: for python.org it is even better, because the bzr-svn conversion compresses astoundingly well
[15:01] <jam> barry: I don't know how hard it is for your clients to upgrade
[15:01] <jam> so I can't really make that decision for yo
[15:01] <jam> you
[15:02] <jam> I can say that for incremental updates
[15:02] <jam> it should be at least 3x faster
[15:02] <jam> for initial branch of everything, I know there is 20% less data to copy
[15:02] <jam> but that isn't necessarily an across-the
[15:02] <jam> sorry
[15:02] <jam> 20% isn't necessarily worth upgrading clients
[15:02] <barry> beuno, jam that's significant.  i don't think there are /that/ many users of the mirrors and it's mostly early adopters anyway
[15:02] <jam> barry: so for *my* anecdote
[15:03] <jam> doing "bzr up" for bzr.dev
[15:03] <jam> went from 45s to 15s
[15:03] <jam> when there are about 3 revisions to update
[15:03] <jam> I would expect python.org to do even better
[15:05] <santagada> sorry to ask but, 15 seconds is still a lot no?
[15:05] <barry> jam: thanks.  sounds like it's worth it unless i get cries of objections
[15:07] <jam> santagada: I was going to respond...
[15:07] <jam> Anyway, it just took 20s to update 7 mainline revs == 67 ancestry revs
[15:07] <jam> and all that over a dumb transport
[15:08] <jam> I'm not entirely sure how long things should be, but given that connecting ssh to launchpad takes 7-8s...
[15:12] <oldman> is it possible/easy to change the e-mail address associated with a commit that has been made?
[15:12] <oldman> i.e., the `bzr whoami` entry
[15:12] <oldman> or once its in, can you no longer do anyrthing about it?
[15:13] <Odd_Bloke> oldman: You can 'uncommit' back to it, but that'll break your history.
[15:15] <oldman> a simple sed -e 's/<EMAIL_ADDRESS>of .bzr would not be safe?
[15:16] <Odd_Bloke> oldman: I very much doubt it.
[15:16] <oldman> ok
[15:16] <oldman> so if I...
[15:16] <oldman> bzr branch lp:project; bzr uncommit; bzr uncommit; bzr commit -m 'reapplied x'
[15:17] <oldman> and then bzr push lp:project
[15:17] <oldman> would that work? :)
[15:19] <Odd_Bloke> oldman: You would have to 'bzr push --overwrite'.
[15:19] <Odd_Bloke> And it would break anyone else's branch of lp:project.
[15:20] <oldman> it would only break their branch if they were > the revno I uncommit to though wouldn't it?
[16:20] <phinze> is there a quick way to clean up all ~1~ back ups in a working tree?
[16:20] <jelmer> phinze, bzr clean-tree --detritus
[16:20] <Peng_> (which is provided by bzrtools)
[16:21] <phinze> beautiful
[16:21] <jelmer> Peng_, See my last post to the mailing list :-)
[16:21] <phinze> --detritus ...? what strange voodoo is this? :)
[16:21] <LarstiQ> phinze: it's a beautiful English word akin to 'cruft'
[16:21] <Peng_> jelmer: Well, it hasn't been merged yet. :P
[16:21] <phinze> "debris: the remains of something that has been destroyed or broken up "
[16:21] <phinze> nice
[16:26] <phinze> hmm might it make sense to have an option to bzr switch that performs clean-tree as well?
[16:28] <phinze> i use it on lightweight checkouts to switch branches and focus, and i don't need old detritus lying around
[16:32] <jam> jelmer: quick question about svn import layouts
[16:32] <jam> I'm accessing a repo which is of the form "trunk/project"
[16:32] <jam> rather than "project/trunk"
[16:32] <jam> do you have a standard format for that?
[16:33] <jam> maybe it is the "itrunk" layouts
[16:36] <jam> doesn't seem to work
[16:39] <jelmer> jam, yeah, itrunk is for that
[16:39] <jam> itrunk 1/2/3 always gives me "specified URL is under a branch"
[16:39] <jam> The specific URL is: http://xdelta.googlecode.com/svn/trunk/xdelta3
[16:40] <jelmer> jam, if you're interested in just that branch, "bzr branch" should work
[16:40] <jam> Importing as "trunk" just worked, but gave me both projects
[16:40] <jelmer> "bzr branch http://xdelta.googlecode.com/svn/trunk/xdelta3 xdelta3" should work
[16:40] <jam> jelmer: it did... so why doesn't svn-import work?
[16:41] <jelmer> jam, bzr branch always works, it assumes the URL you give it is a branch
[16:41] <jelmer> svn-import imports multiple branches
[16:41] <jelmer> so it has to guess what the layout is
[16:42] <jam> sure. though I would have thought it matched the "itrunk" layout pretty closely
[16:42] <jam> which is why it is strange that "bzr svn-import --layout=itrunk1" never worked
[16:43] <jam> then again, it isn't clear (to me) what 'level' means
[16:43] <jelmer> jam, which URL did you give it ? http://xdelta.googlecode.com/svn ?
[16:43] <jam> http://xdelta.googlecode.com/svn/trunk/xdelta3
[16:44] <jam> I should give it the root of the repo?
[16:44] <jam> For auto-detect import: http://xdelta.googlecode.com/svn/trunk worked just fine
[16:44] <jelmer> jam: svn-import on a branch should fail
[16:45] <jelmer> http://xdelta.googlecode.com/svn/trunk doesn't work here:
[16:45] <jelmer> bzr: ERROR: http://xdelta.googlecode.com/svn/trunk appears to contain a branch. For individual branches, use 'bzr branch'.
[16:45] <jam> I just did "bzr svn-import  http://xdelta.googlecode.com/svn/trunk" I'll try to verify that
[16:46] <jam> nope, you're right
[16:46] <jam> I must have used .../svn the first time
[16:48] <jam> jelmer: so would doing "bzr branch .../svn/trunk/xdelta3" give me the same final branch as "bzr svn-import --layout=itrunk1" ?
[16:48] <jam> (are they compatible?)
[16:49] <jelmer> jam, yes
[16:49] <jelmer> jam, well, if you're using 0.5
[16:52] <jam> jelmer: yeah, I ame
[16:52] <jam> interestingly I get an error at the very end
[16:53] <jam>   File "/home/jameinel/.bazaar/plugins/svn/revmeta.py", line 1188, in get_revision
[16:53] <jam>     cached.metaiterators.add(metaiterator)
[16:53] <jam>   File "/home/jameinel/.bazaar/plugins/svn/revmeta.py", line 963, in __hash__
[16:53] <jam>     return hash((type(self), self.from_revnum, self.to_revnum, tuple(self.prefixes), hash(self.layou
[16:53] <jam> t)))
[16:53] <jam> TypeError: 'NoneType' object is not iterable
[16:53] <jelmer> which bit is None ?
[16:53] <jam> I don't know
[16:54] <jam> self.prefixes probably
[16:54] <jam> anyway, "bzr branch" is great for what I need. Just wanted to understand things a bit better.
[16:54] <jam> thanks for your tie
[16:54] <jam> time
[16:58] <jelmer> jam, Thanks, I think what's wrong
[16:58] <jelmer> jam, bug in itrunk1
[16:58]  * jelmer fix0rs
[16:58] <jam> :) \o/
[17:03] <nevans> jelmer: for #332116, I had already tried svn-upgrade... but for some reason, it refuses to upgrade that branch.
[17:03] <jelmer> nevans, what's the error?
[17:03] <nevans> it successfully upgraded trunk and another branch.
[17:03] <nevans> no error.  it just doesn't do anything.
[17:04] <nevans> lemme try again.  I'll attach the bzr.log
[17:22] <Peng_> jelmer: How much of an impact does svn 1.5 have on performance and whatnot?
[17:22] <jelmer> Peng_, svn 1.5 or bzr-svn 0.5 ?
[17:41] <Peng_> jelmer: svn 1.5.
[17:42] <Peng_> jelmer: The revision "Use global needed variable." vanished from bzr-svn 0.5's history. Was that intentional?
[17:50] <Peng_> I've got a mix of 1.3 and 1.4, so I'm wondering if it's worth doing anything about it. bzr-svn is already fast enough with them, I guess, but I dunno.
[17:52] <jelmer> Peng_, the main advantage of 1.5 is that you can use revision proeprties for bzr-svn metadata
[17:52] <jelmer> retrieving that metadata will also be faster with 1.5
[17:52] <jelmer> other things won't be significantly faster
[17:52] <jelmer> Peng_, yeah, it's correct that revision vanished
[17:58] <Peng_> Poor, unloved revision. :(
[17:58] <Peng_> Anyway, thanks for the information. :)
[17:58] <rockstar> abentley, hey
[17:59] <abentley> hey
[18:01] <rockstar> abentley, I'm looking at the integrating with bazaar wiki page, and there's a line that reads:
[18:01] <rockstar> source.create_checkout('/tmp/newBzrCheckout', None, True, accelerator_tree)
[18:01] <rockstar> Does that operate in place, or return the checkout?  The wiki makes it look like it operates in place.
[18:01] <jfroy> jelmer: good morning
[18:01] <rockstar> abentley, and so that would make me think that source would change types.
[18:02] <jelmer> jfroy, hi
[18:02] <abentley> rockstar: I believe source.create_checkout returns the working tree.
[18:02] <rockstar> abentley, okay, that's better.
[18:03] <abentley> rockstar: It does not change the type of the branch.  The branch remains a branch.  It's just a branch that is checked out somewhere.
[18:03] <rockstar> abentley, okay, so when I reference branch now, it's still the remote branch that I opened with Branch.open('lp:blah')
[18:04] <abentley> Yes.
[18:34] <jelmer> jam, any chance you can do a quick review of my InterBranch patch?
[18:34] <jelmer> jam, That one would really help a lot of things wrt bzr-svn UI and performance and is a requirement for bzr-git pull from remote branches
[19:03] <LaserJock> I can't seem to branch with bzr-svn 0.5
[19:03] <jelmer> hi LaserJock
[19:03] <jelmer> LaserJock, what doesn't work?
[19:03] <LaserJock> I just get bzr: ERROR: Not a branch:
[19:04] <jelmer> which SVN url?
[19:04] <LaserJock> svn://anonsvn.kde.org/home/kde/trunk/extragear/sysadmin/kiosktool/
[19:04] <LaserJock> svn co works fine
[19:05] <jelmer> LaserJock, the layout for the KDE repository is hardcoded
[19:05] <jelmer> LaserJock, try svn://anonsvn.kde.org/home/kde/trunk/extragear
[19:06] <LaserJock> jelmer: ok, well that works
[19:07] <LaserJock> jelmer: so is there a way to get sysadmin/kiosktool ?
[19:08] <jelmer> LaserJock, you can set layout = itrunk3 in the configuration for the KDE URL
[19:09] <jelmer> LaserJock, patches to bzrlib.plugins.svn.layout.custom.KDELayout are also welcome
[19:18] <LaserJock> jelmer: where do you set layout = itrunk3 ?
[19:18] <jelmer> LaserJock, ~/.bazaar/subversion.conf or ~/.bazaar/locations.conf
[19:18] <jelmer> in the section related to the KDE repo
[19:19] <LaserJock> jelmer: there isn't a KDE section yet as I haven't branched, can I make one or do I need to branch something first?
[19:21] <jelmer> LaserJock, you can add one
[19:22] <jelmer> LaserJock, you might want to add use-cache = False too
[19:24] <LaserJock> jelmer: got it going
[19:25] <LaserJock> jelmer: this is *way* faster than 0.4 . I've been stuck with svn for KDE but this definately seems usable
[19:29] <jelmer> LaserJock, cool !
[19:30] <jelmer> LaserJock, that was one of the main goals of 0.5
[19:36] <jelmer> LaserJock, Ideally the KDELayout class should be customized to properly recognize all branches in the KDE svn repository
[19:37] <jelmer> LaserJock: that would, among other things, fix "bzr svn-import svn://anonsvn.kde.org/home/kde"
[19:47] <jelmer> abentley: Hi
[19:47] <abentley> jelmer: hi
[19:47] <jelmer> abentley: Is there some way to register a remote branch on Launchpad?
[19:48] <abentley> jelmer: I believe so.
[19:48] <jelmer> abentley: Any pointer ? Where should I be looking?
[19:49] <abentley> Go to your profile page, hit the code tab, click the big orange "register a branch".
[19:49] <jelmer> abentley: Ah, thanks
[19:50] <abentley> jelmer: np
[19:50] <jelmer> abentley: Do you happen to know if there's something similar for the remote API?
[19:50] <abentley> jelmer: I don't know.
[19:51] <jelmer> abentley: ok, thanks again
[19:58] <jfroy> jelmer: is push now safe to use to create a new branch with bzr-svn?
[19:58] <jfroy> the svn-push command is gone, but the release notes are not clear if push will work right now or is currently broken pending some changes to bzr
[19:58] <jelmer> jfroy, svn-push still works for now
[19:58] <jelmer> jfroy, "bzr push" working out of the box is waiting for a patch to enter bzr.dev
[19:59] <jfroy> OK, so it's just gone from the command help topic.
[20:03] <jelmer> jfroy: yep
[20:16] <etenil> Hi there
[20:16] <etenil> I'm having trouble splitting a tree with bzr
[20:16] <etenil> doing bzr split only produces an error
[20:17] <Peng_> ...What's the error?
[20:17] <etenil> bzr: ERROR: No WorkingTree exists for "file:///home/guillaume/sandbox/bzr_tree/Bell/trunk/.bzr/checkout/".
[20:17] <etenil> don't understand it
[20:19] <Peng_> It seems "bzr split" needs the branch to have a working tree. You could run "bzr co" to create it and "bzr remove-tree" to remove it again afterwards.
[20:19]  * Peng_ shrugs
[20:20] <etenil> ?
[20:20] <etenil> I'm trying to branch the tree and split from there maybe
[20:21] <etenil> now it says:
[20:21] <etenil> bzr: ERROR: To use this feature you must upgrade your branch at file:///home/guillaume/sandbox/bzr_branch/.
[20:22] <etenil> I try a checkout as you suggested
[20:22] <jelmer> etenil, I think you need to upgrade to a rich-root format (such as 1.9-rich-root) to be able to use split
[20:22] <etenil> how can I upgrade the tree?
[20:23] <etenil> is there a command?
[20:23] <jelmer> bzr upgrade --1.9-rich-root
[20:23] <etenil> ok, I'll give it a try
[20:24] <etenil> bzr: ERROR: no such option: --1.9-rich-root
[20:24] <etenil> -_-
[20:24] <etenil> I can just use --rich-root
[20:24] <etenil> from what the help says
[20:27] <etenil> Once I have split my tree, will the created branch have its versions renumbered?
[20:33] <Peng_> etenil: It would be better to use --rich-root-pack than --rich-root.
[20:34] <Peng_> etenil: What version of bzr are you running?
[20:40] <Peng_> jelmer: Not to be excessively stalky, but why did you just rename lp:bzr-svn's branch?
[20:41] <Peng_> Oh, it's not mirrored now.
[20:42] <jelmer> Peng_, Yep
[20:42] <jelmer> Peng_, this should save me some explanation when people try lp:bzr-svn and it's out of date
[20:42] <Peng_> Ah.
[20:43] <Peng_> The email alerts for new revisions were nice, but oh well.
[20:43] <jelmer> Peng_, ah, there's no emails for remote branches?
[20:44] <Peng_> jelmer: I dunno. Probably not, since it doesn't show the log.
[20:44] <jelmer> Peng_, ideal would be a mixture of mirrored and remote branches
[20:44] <jelmer> where it would redirect .bzr to the actual branch but still keep a lp-specific mirror
[20:45] <Peng_> That would be neat, but kind of confusing.
[20:46] <Goundy> bzr update returns tree is up to date (rev 42) and my repo is at revision 43 (using launchpad)...
[20:46] <Goundy> I don't know what to do :/
[20:46] <Peng_> Goundy: "bzr pull"?
[20:46] <Goundy> Peng ah
[20:47] <Goundy> Peng I don't get it... I get an error ^^
[20:47] <Peng_> You do?
[20:48] <Goundy> Peng I think I understand I did a bzr pull and kicked out my mainline before ><
[20:48] <Goundy> forgot
[20:48] <Goundy> thank you Peng
[20:49] <etenil> the conversion worked
[20:49] <etenil> i try the split
[20:49] <Peng_> Goundy: You figured it out? That's good. :)
[20:49] <Goundy> Peng_ yea >_< thanks !
[20:51] <Tak> jelmer: md 2.0b1 packages in debian/experimental
[20:52] <jelmer> Tak, w00t!
[20:55] <Tak> the libpython md-bzr backend is rocking
[20:55] <etenil> that works!!!!
[21:01] <jelmer> Tak, I'll give it a try :-)
[21:07] <etenil> alright, thanx for your help all
[21:07] <etenil> bye
[21:18] <etenil> Hi again
[21:18] <etenil> I have split up a directory from a tree
[21:19] <etenil> but there are gaps in the revisions
[21:19] <etenil> is it possible to renumber the revisions?
[21:24] <jelmer> etenil, what do you mean with gaps?
[21:24] <etenil> well
[21:25] <etenil> my bzr tree comes from a svn tree. And many projects were in there. Some revisions are only relevant to some of them
[21:27] <jelmer> etenil: bzr and svn revision numbers are different - the svn revision numbers are per-repository, the bzr revision numbers are per-branch
[21:27] <etenil> or maybe I should split and renumber with svn then convert
[21:27] <jelmer> etenil, if you have bzr-svn installed then "bzr log -v" will show the original svn revno as well as the bzr revno
[21:28] <etenil> ok
[21:28] <etenil> but I don't want to keep the svn tree
[21:28] <jelmer> etenil, the information about the original svn revno is in the bzr tree
[21:28] <etenil> I want to split it per project and port to bzr
[21:29] <jelmer> etenil, why are you running "bzr split" btw? If you need just a subdir of the svn repository, you can just "bzr branch" that instead
[21:30] <etenil> jelmer: that's ok, I think svndumpfilter can split the svn repo and renumber it
[21:30] <etenil> I can import it after that
[21:40] <lifeless> jelmer: 'bzr register-branch' ?
[21:40] <jelmer> lifeless, that registers a mirrored rather than a remote branch
[21:42] <lifeless> oh
[21:42] <lifeless> is that a problem?
[21:42] <jelmer> lifeless, in some situations it's useful to be able to register remote branches
[21:43] <jelmer> since they don't have a delay
[21:44] <jelmer> lifeless, not that I would register remote branches very often, being able to do it through the web ui keeps me happy enough
[21:56] <lifeless> jam: hi
[21:57] <jam> hi lifeless, just writing up some summary stuff about my latest version of gc, and I just put together an xdelta repo
[21:57] <lifeless> I saw
[21:57] <lifeless> is it faster than last time you looked at xdelta?
[21:58] <jam> the way it is implemented right now, not really
[21:58] <jam> I'm doing multi-parent with unlimited delta chains
[21:58] <jam> it is faster to compress than gc
[21:58] <jam> but slower to extract
[21:58] <jam> (3m45s versus 10min to compress, but 1m30s versus 17s to extract)
[21:59] <lifeless> very interesting
[22:00] <lifeless> any feeling on why its faster? [Can we use the compressor in gc ?]
[22:01] <jam> lifeless: why the compression is faster?
[22:01] <jam> it probably has less *stuff* to compare against
[22:02] <jam> doing multi-parent
[22:02] <jam> means you are comparing 1k lines versus 2k lines
[22:02] <jam> while gc is comparing with all texts inserted so far
[22:02] <lifeless> OTOH gc doesn't have to build new dicts all the time
[22:02] <jam> sure
[22:03] <lifeless> I'm wondering if xdelta simply has a better compare logic we could adapt
[22:03] <jam> xdelta is also written in C by people who have been spending a lot of time optimizing it :)
[22:03] <jam> at least, more time than you and I have probably spent on GC
[22:03] <jam> oh, and for the record, I should mention that the "repository-details" time for the knit repo is 30s
[22:04] <jam> so it is ~18s to extract all texts for gc, 30s for knits, and currently 1m30s for xdelta
[22:04] <jam> though when gc was experiencing bad paging, it was down at 7min
[22:04] <jam> so I'm willing to give xdelta a bit of margin here.
[22:04] <lifeless> me too
[22:05] <lifeless> xdelta certainly has a good[same as knit] story for skinny packs/delta reuse
[22:05] <jam> lifeless: I should also mention that your new changes to the streaming logic confuse existing plugins
[22:05] <jam> "knit-delta-closure" isn't in the adapter registry
[22:05] <lifeless> I'm very concerned about getting good compression out of it though
[22:05] <jam> lifeless: well, for multiparent versus my best gc so far, I get 9M for xdelta, versus 11MB for gc
[22:06] <jam> so at least *right now* the story is just fine
[22:06] <lifeless> jam: yah, one reason we pushed hard on this is that its the start of the release cycle, best time for disruption
[22:06] <lifeless> as far as being in the adapter registry, just try for fulltext
[22:07] <lifeless> you can see the change in knit.py in insert_record_stream
[22:07] <jam> k
[22:08] <jam> anyway, I need to get going
[22:08] <jam> have a good weekend, lifelessf
[22:09] <lifeless> ciao
[22:09] <lifeless> I'm going to send up the final parts this morning
[22:09] <lifeless> if you have a chance to review it, would love that:)
[22:11] <lifeless> jam: thats *very* interesting that mp is smaller than gc; even with reordered texts?
[22:46] <ameoba_> I have a directory with a few hundred files in it.  I want to ignore most of them, but not all.  if I ignore $DIR/*, will it cause problems down the line if I want to add/modify specific files from there?  I'm asking because of the "Warning: the following files are version controlled and match your ignore pattern" when I added the ignore
[23:00] <fullermd> ameoba_: No, it's just letting you know.
[23:01] <ameoba_> fullermd-  that's what I was hoping for.  thx
[23:01] <fullermd> ignore means "Don't add this file we we find it recursively".  It doesn't have any effect on files that are already versioned or added explicitly.
[23:06] <phinze> uh oh, i think i broke shelve
[23:06] <phinze> i shelved on a bound checkout before running bzr up and then tried to unshelve
[23:21] <tyhicks> Trying to find an equivalent to git-cherry-pick. I want to grab individual patches from other branches and don't want a seperate merge message.
[23:22] <tyhicks> Any tips for how I can do this?
[23:23] <lifeless> phinze: it should unshelve fine; what happens?
[23:23] <lifeless> tyhicks: merge -r x..y does a cherry pick
[23:24] <lifeless> tyhicks: because its not a transitive link in the graph the old revisions are not shown in log; you do need to supply a commit message (but it's scriptable with a tiny bit of python if you are doing this a lot and want to carry the commit message and author across automatically)
[23:25] <tyhicks> lifeless: IIRC, I have to do a commit afterwards and that creates another merge message
[23:25] <lifeless> tyhicks: it will create a new commit object; just like git-cherry-pick does
[23:25] <lifeless> tyhicks: it won't show as a merge, because cherry picks are not full merges
[23:25] <spiv> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/332314
[23:26] <lifeless> spiv: guess what
[23:26] <spiv> lifeless: short story: the client isn't falling back when Repository.insert_stream is unavailable.
[23:27] <lifeless> spiv: doh!
[23:27] <lifeless> spiv: I'm seeing something very similar, in the stacked case, which hasn't landed yet
[23:27] <lifeless> FAILED (failures=8, errors=19, known_failure_count=20)
[23:28] <lifeless> spiv: are you going to do some bzr coding today?
[23:28] <spiv> lifeless: sadly no :(
[23:28] <lifeless> spiv: I'm hoping to get the stcked case up for review
[23:28] <spiv> lifeless: I have to head up to the blue mountains today/tomorrow
[23:28] <lifeless> nice
[23:29] <spiv> "have to".  Woe is me ;)
[23:29] <lifeless> spiv: hiking?
[23:30] <spiv> A bunch of stuff, farewell party, visiting family, possibly a small bushwalk might happen too...
[23:30] <lifeless> enjoy!
[23:32] <spiv> Thanks!
[23:34] <lifeless> can you look at remote.py, 1370
[23:34] <lifeless> that looks like it should fallback fine to me
[23:34] <lifeless> spiv: perhaps the stream is being eaten partly?
[23:35] <spiv> lifeless: ah, hmm
[23:36] <spiv> lifeless: It *might* be an interaction with body_stream?
[23:36] <spiv> lifeless: oh!
[23:36] <lifeless> I think the stream is consumed
[23:36] <lifeless> the error is raised
[23:37] <lifeless> remaining elements are consumed
[23:37] <spiv> yes, I bet the stream is being at least partly consumed
[23:37] <lifeless> no error, but data not getting there
[23:37] <spiv> I'd only *expect* partly, but I've been wrong before.
[23:37] <lifeless> your bug report shows the case that the entire stream is eaten
[23:37] <spiv> Right -- but I was also only pushing one new rev.
[23:37] <lifeless> thats why the pack is deleted (it showed up as a no-op insertion)
[23:37] <lifeless> one rev has a inventory too at minimum
[23:37] <lifeless> so 2 records
[23:38]  * spiv nods
[23:38] <lifeless> If I guard it with 1,13
[23:38] <lifeless> and make it mandatory
[23:38] <lifeless> that will be safe I think
[23:38] <spiv> (That rev should have a text and sig, too)
[23:39] <spiv> So long as some prior RPC notices that remote is not 1,13
[23:39] <spiv> But that guard is a good idea anyway, avoid trying the RPC when we know it won't work.
[23:39] <lifeless> if its mandatory - no fallback - then we won't insert a partial stream
[23:39] <lifeless> thats the correctness aspect
[23:39] <spiv> Oh, I see.
[23:40] <spiv> An ugly hack would be to first try with a stream of []
[23:40] <lifeless> garh no
[23:40] <spiv> I definitely don't want that as the final solution.
[23:41] <spiv> But it would fix the current bug that's breaking bzr.dev...
[23:41] <spiv> Oh, right.  Of course, you are unlikely to get an error back until the whole stream is consumed,
[23:41] <spiv> because the whole request is sent before a response is sent.
[23:42] <spiv> So yeah, the entire stream will be consumed... so I guess you're thinking of moving the fallback logic to closer to where the stream is being generated?
[23:43] <lifeless> assuming this passes is it ok, to stop people running trunk corrupting repos
[23:43] <lifeless> http://paste.ubuntu.com/120786/
[23:44] <spiv> _is_remote_before((1,13)) will not be true most of the time, though.
[23:44] <spiv> Unless the server is *really* old ((1,6) or earlier)
[23:45] <lifeless> so unknown is > everything?
[23:45] <spiv> Nothing ever does _remember_remote_is_before((1,13)) or whatever the magic is.
[23:45] <lifeless> I thought v3 got the servers version
[23:45] <spiv> Right.  It assumes "current", and then ratchets down based purely on RPCs that are unknown.
[23:46] <spiv> There's a header, but it's currently purely advisory.
[23:46] <lifeless> ah
[23:46] <lifeless> so this is critical to fix:P
[23:46] <spiv> (And its value is not necessarily parseable, it's more intended for human-consumption)
[23:46] <lifeless> uhm, inserting [] will probably work
[23:47] <spiv> You could make a new version of get_parent_map that's only in 1.13 ;)
[23:47] <jfroy> hey people, quick census / survey: what would you consider to be the "essential plug-ins you should have"?
[23:47] <lifeless> jfroy: depends on what I'm doing
[23:47] <jfroy> I'm building a bazaar distribution and I'm now selecting the plug-ins I will include along with core.
[23:48] <spiv> jfroy: for me personally, it's bzrtools, loom, pqm, launchpad, gtk, svn
[23:48] <lifeless> jfroy: but see my patch for bundling some plugins for a list of ones we concluded were good to bundle
[23:48] <spiv> But it definitely depends on what the person is doing.
[23:48] <spiv> lifeless: so I need to go
[23:48] <jfroy> The target audience is people who use primary subversion (bzr-svn is already in), and people who may be using another DVCS, likely git.
[23:48] <spiv> lifeless: I think you now have all the relevant info for this bug, though.
[23:49] <lifeless> spiv: ok; I'll insert []
[23:49] <jfroy> lifeless: where is that patch? mailing list, bug?
[23:49] <lifeless> bb:approve for that?
[23:49] <spiv> lifeless: ok
[23:49] <lifeless> jfroy: bundle buggy somewhere; its not finished {doesn't run the install for each plugin}
[23:50] <lifeless> spiv: I'm surprised the RemoteV2 tests dont' trigger this
[23:50] <spiv> lifeless: yep.  Ideally add the _remember_remote_is_before / _remote_is_before guard like other client methods do.
[23:50] <spiv> lifeless: RemoteV2 tests know _remote_is_before((1,6))...
[23:50] <spiv> lifeless: oh!
[23:50] <lifeless> spiv: I'll get the simplest possible correctness fix up now
[23:50] <spiv> lifeless: RemoteV2 also triggers an instant UnknownSmartMethod when you try call_with_body_stream
[23:50] <lifeless> spiv: ah
[23:51] <spiv> lifeless: it never consumes the stream in that case, because the encoder knows it can't be done :)
[23:51] <jfroy> lifeless: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1217210104.21600.106.camel%40lifeless-64%3E?
[23:51] <spiv> lifeless: perhaps it should consume the stream, just to make it harder to get confused...
[23:51] <spiv> lifeless: after all, the caller has to cope with a consumed stream anyway...
[23:56] <lifeless> spiv: well, we could look at buffering the stream in a T join, until we know success/fail (HTTP can error before a post completes)
[23:56] <lifeless> jfroy: yes


[00:44] <BenC> lamont: newer == better, IMO
[00:44] <BenC> No idea what is in the ubuntu changes though
[00:46] <lamont> the current changes are using tcl8.4 instead of 8.5 (could proabbly chnage for intrepid??) and dropping the cvsps depends (universe)
[00:46] <lamont> I was curious so I looked
[00:46] <lamont> if I get bored tonight, maybe I'll prepare a merge to pester folks with
[00:46] <lamont> just wanted you to have a chance to say "nonono" if you wanted to, before i worked.
[09:26] <qense> I've got a bug with a patch for ubuntu-modules inside a comment: https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/196811
[09:27] <qense> Do you think you can use it?
[09:27] <qense> The patch comment: https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/196811/comments/16
[12:37] <gnomefreak> what are the general rules for backporting kernels? AFAIK its a big no but would like it confirmed for someone here
[16:48] <BenC> gnomefreak: yeah, big NO
[16:48] <BenC> gnomefreak: we've considered it, but never justified the time and testing it would take
[16:48] <BenC> gnomefreak: that may change for hardy (LTS) if we find it is warranted at some later point
[16:49] <gnomefreak> BenC: thanks if i see the bug again ill let them know that its not gonna happen :)
[16:50] <gnomefreak> its a driver IIRC that the bug is about but it requires kernel backport someone added but ill be back later and look at it
[20:14] <soren> mjg59: You're probably most likely to know this: Is the wattage reported by powertop reliable? I can get my laptop to report under 10W, which is only around twice that of my NSLU2, which sort of brings its usefulness/wattage ratio into question.
[20:15] <soren> ...or does it not actually represent the "real" power consumption (i.e. what I will be billed by the power company)?
[21:43] <mpetersen> Can anyone tell me the best way to build a kernel module package that will replace a linux-ubuntu-module (specifically drbd 0.8 to 0.8.2)  I built the package no problem, but I have to either --force-overwrite to install or end up with 2 drbd.ko modules?
[23:07] <BenC> mpetersen: put the other module in /lib/modules/`uname -r`/updates/ and it will override the one in lum
[23:10] <mkrufky> !
[23:10] <mkrufky> i wish i knew that
[23:11] <mkrufky> BenC: i can tell the v4l/dvb build system to install modules to THAT location if it detects an ubuntu dir
[23:11] <mkrufky> ...that might help users that want bleeding edge driver support without worrying about trashing LUM or whatever's in-tree
[23:18] <BenC> mkrufky: it's default for module-init-tools to handle that (IOW, not ubuntu/debian specific)
[23:19] <mkrufky> thats very good to know -- i was previously not aware of that
[23:19] <mkrufky> perhaps v4l/dvb should install to that location for everybody
[23:19] <mkrufky> ....that would have avoided all the cx88 / saa7134 complaints after that alsa issue was addressed
[23:28] <BenC> mkrufky: just remember, that's where lbm installs them too (which is how we can override drivers ourselves)
[23:30] <mkrufky> hmm... "lbm" ?
[23:30] <mkrufky> apparantly thats a popular acronym
[23:32] <BenC> linux-backports-modules
[23:32] <mkrufky> i should have known
[23:32] <mkrufky> lol
[23:32] <mkrufky> i will leave v4l/dvb as it is
[23:41] <mpetersen> BenC: so 'install -m644 -b -D drbd/drbd.$(KO)o $(CURDIR)/debian/$(PKGNAME)/lib/modules/$(KVERS)/updates/drbd.$(KO)o' instead of 'install -m644 -b -D drbd/drbd.$(KO)o $(CURDIR)/debian/$(PKGNAME)/lib/modules/$(KVERS)/ubuntu/block/drbd/drbd.$(KO)o' should work?  nifty, I'll try that.


[06:24] <alkisg> alkisg: stgraber: there's a packaging problem ltsp-client-core.install that breaks ltsp-update-image in 5.2.1:
[06:24] <alkisg> client/initramfs/conf-hooks.d/ltsp usr/share/initramfs-tools/conf.d
[06:24] <alkisg> should be:
[06:24] <alkisg> client/initramfs/conf-hooks.d/ltsp usr/share/initramfs-tools/conf-hooks.d
[13:13] <mgariepy> good morning everyone
[13:15] <highvoltage> good morning mgariepy and everyone
[13:44] <sbalneav> Morning all
[16:09] <highvoltage> howdy sbalneav
[16:10] <highvoltage> good morning dinda
[18:40] <highvoltage> Edubuntu meeting in 20 minutes.
[18:56] <highvoltage> Edubuntu meeting in 4 minutues.
[18:59] <highvoltage> Edubuntu meeting about to start in #ubuntu-meeting
[19:00] <highvoltage> ^^^ stgraber, sbalneav, Lns, dinda, mgariepy, mhall119, nixternal
[19:38] <highvoltage> sbalneav: ping
[19:58] <sbalneav> highvoltage: Pong
[19:58] <sbalneav> What for can I do you?
[19:59] <highvoltage> sbalneav: well you just missed the edubuntu meeting!
[20:00] <sbalneav> heh
[20:00] <sbalneav> I had about 2.98x10^8 things lined up here :(
[20:00] <highvoltage> sbalneav: not a biggie, I'll post notes to the list, we'd like to plan a doc day for late next week or early in the following one, what does your schedule look like for then? will still have some deadlines to run for?
[20:01] <sbalneav> Early following one.  I'm taking spring break off so's I can work on the cottage :)
[20:01] <sbalneav> but yeah, I'd host a doc day.
[20:01] <highvoltage> nice :)
[20:02] <sbalneav> I need the break.
[20:02] <alkisg> stgraber: could we change the gconf files that are generated by the fat client script so that they're part of the package and not generated? So that they can be updated on package upgrades?
[20:02] <sbalneav> last 6 weeks have been hellish
[20:02] <highvoltage> sbalneav: cool, I'll give you a ping when the artwork is done then we can work out the details
[20:02] <sbalneav> kk
[20:03] <highvoltage> sbalneav: ouch, sounds so, well I hope the cottage does its magic!
[20:05] <sbalneav> Always does.
[20:05] <highvoltage> I heard a rumour that we might have an edubuntu hackfest there some time :)
[20:05] <sbalneav> That's what it's (hopefully) being fixed up for :)
[20:07] <alkisg> stgraber: it might even be better to make an ltsp-fat-client package, with all the necessary files, that would depend on ubuntu-desktop|edubuntu-desktop etc, and which could be installed/uninstalled separately from ltsp-build-client..
[20:10] <mhall119> sorry, work pulled me away
[20:11] <mhall119> was there anything in the meeting I needed to be a part of?
[20:17] <stgraber> alkisg: yep, though that won't happen for lucid
[20:49] <highvoltage> mhall119: well, we want to add a dialog where you can choose between the default, young and plain theme packs
[20:49] <highvoltage> mhall119: so the idea is that we could add a qimo option too for 10.10
[20:50] <highvoltage> mhall119: so when the archives open for 10.10 we can just work on getting the qimp packages in early
[21:42] <joerg> hi
[23:49] <mhall119> highvoltage: sounds good to me, I just haven't had the time I need to work on Qimo lately