[01:19] <qingluo> hi all, i need to port sfdisk for arm. where can i get the source code?  sourceforge?
[01:20] <Unit193> !source
[01:21] <Unit193> Might not be latest upstream, though.
[01:21] <qingluo> latest is not necessary, but it must be stable
[01:23] <qingluo> ubottu: thankyou
[02:28] <Impossible> !source
[05:19] <mint_> So is the next release using lxde/qt?
[05:21] <Unit193> Nope, GTK.
[05:21] <mint_> awww
[05:21] <mint_> or... gtk3?
[05:58] <santhosh> hai iam getting application database errors in wine on lubuntu
[06:04] <santhosh>  hai iam getting application database errors in wine on lubuntu
[06:07] <santhosh>  hai iam getting application database errors in wine on lubuntu
[06:09] <Monday> santhosh, what version are you using
[06:13] <santhosh> iam using 1.6 iam trying 1.4.1 but is graphics errors
[06:14] <santhosh> is there any sluaton to reslove the application database
[06:17] <santhosh> iam using 1.6 iam trying 1.4.1 but is graphics errors
[06:18] <santhosh> is there any soluaton to reslove the application database error on wine
[06:59] <santhosh> is there any soluaton to reslove the application database error on wine
[07:01] <Monday> what app are you trying to install
[07:18] <brades> Is there a non PAE installation version of Lubuntu 13.04 i386?  I downloaded the 13.04 cd and booted to it to install on an older IBM thinkpad and it stated that I needed a PAE CPU.  This was a surprise as I thought Lubuntu was supposed to be light and support older hardware, hence the reason I'm trying to use it to begin with.
[07:28] <brades> Ubuntu and its various flavors all seem to run just fine on PC's with 1 Gb of RAM, so why would there be a minimum requirement of PAE support?  That just seems silly to me with the name Lubuntu, it implies light version for older hardware.  PAE is new, not old technology in comparison.
[07:41] <qingluo> lol
[07:42] <bioterror> Core2Duo is old hardware
[10:13] <DANNN> hi guys...
[10:13] <DANNN> i have any problems to install flash player...
[10:13] <DANNN> can anybody help me? :D
[10:22] <DANNN> could be the problem related with this post? ... http://askubuntu.com/questions/311453/flash-plugin-not-working-properly-in-lubuntu-13-04
[10:42] <john_rambo> I just installed lubuntu ......How do I install the nvidia non free driver?
[10:48] <bioterror> !nvidia
[11:49] <kiwitinker> I have an older version of lubuntu install, i forget exactly which, the thing i don't understand is when i run update manager and it finds 128 updates if i install these updates does it update my version of lubuntu or does it just update within the version i first installed?
[11:52] <hateball> kiwitinker: just within the version
[11:52] <hateball> if there's a version upgrade, there is a special button for that
[11:53] <kiwitinker> thanks, i don't see any special button
[11:54] <kiwitinker> finally i can do the update without worrying that the version will change
[11:57] <kiwitinker> not that i doubt hateball but it would be sensible for me to get a 2nd opinion on this considering the major hassle it will be if it updates the version
[11:58] <hateball> knowing what version you actually have would be helpful
[11:58] <hateball> lsb_release -a
[11:59] <kiwitinker> 12.04 lts
[12:04] <kiwitinker> how sure are you hateball on the update question, assumption or you actually know?
[12:04] <kiwitinker> what version is lubuntu up to now?
[12:07] <hateball> By default LTS releases only offer version upgrades to new LTS releases
[12:07] <hateball> and 12.04 is the latest LTS release
[12:07] <hateball> but feel free to ask someone else
[12:07] <bioterror> lubuntu does not have lts
[12:08] <bioterror> lubuntu does not support LXDE components like LTS
[12:08] <bioterror> so I advice to use as much as possible the latest version to get the best working LXDE experience
[12:26] <kiwitinker> ok, some confusion here, when i used the version command it actually says ubuntu 12.04.2 LTS, confusing that it does not say anything about lubuntu
[12:29] <kiwitinker> but it is definitely lubuntu that i have
[12:31] <kiwitinker> bioterror the latest version of lubuntu does not work on this computer, the latest one that does is 12.04 hence why it is important that i don't accidentally upgrade to a later version
[12:32] <kiwitinker> i should say release instead of version i think
[16:29] <brades>  Is there a non PAE installation version of Lubuntu 13.04 i386?  I downloaded the 13.04 cd and booted to it to install on an older IBM thinkpad and it stated that I needed a PAE CPU.  This was a surprise as I thought Lubuntu was supposed to be light and support older hardware, hence the reason I'm trying to use it to begin with.
[16:30] <bioterror> https://help.ubuntu.com/community/Lubuntu-fake-PAE
[16:32] <brades> Ubuntu and its various flavors all seem to run just fine on PC's with 1 Gb of RAM, so why would there be a minimum requirement of PAE support?  That just seems silly to me with the name Lubuntu, it implies light version for older hardware.  PAE is new, not old technology in comparison.
[16:35] <bioterror> PAE is quite old technology
[16:35] <brades> That is my exact machine actually mentioned in that article.  It is a Thinkpad T41 with a Intel M processor.  Thanks for the info, hopefully that will help.
[16:36] <bioterror> I just threw T42 away, which did not have PAE
[16:36] <bioterror> it was also slow :D
[16:37] <bioterror> it had a slow Pentium-M
[16:40] <brades> Fast enough for basic use for kids browsing on the internet since Windows is so crappy and gets infected so easily!
[16:40] <wxl> i don't know what your kids are doing but every kid i see browsing the internet is typically playing some sort of flash-based game
[16:40] <bioterror> wxl, I assume they browse web with Lynx
[16:41] <wxl> sheesh you could at least give them w3m bioterror ;)
[16:41] <brades> Come on, basic google searches for innocent things can come up with malformed pages that do harm!  I've done it just doing a search for a picture of a dragon.  It doesn't take much these days.
[16:42] <bioterror> as much as I sit in front of a computer, I dont let my kids
[16:42] <brades> On Windows XP on old hardware it is easy to infect even with enterprise level virus tools!
[16:43] <ianorlin> !offtopic
[17:06] <Monday> hey brades try the Lubuntu fake-PAE iso
[17:07] <Monday> ianorlin maybe you should of tried to help him
[18:18] <ianorlin> yeah I think someone linked it
[18:18] <ianorlin> earlier then they said they threw it away
[18:34] <agrestringere> Hello, having an issue, the desktop background on Lubuntu has disappeared and isnt' working, what can I do?
[18:42] <ianorlin> did you log into lubuntu netbook?
[18:45] <agrestringere> no
[19:14] <Monday> agrestringere, right click on the background and go to preferences and setup your background once again
[19:14] <Monday> there is a bug on lubuntu when it comes to background and monitor setup, which they won't admit
[19:15] <Unit193> What's the bug number?
[19:15] <Monday> i've used LXDE on Mint, Debian, Slitaz and Trisquel and the monitor and background problems only happen in lubuntu
[19:16] <Unit193> Can you link to the LP report?
[22:32] <Guest51241> Hi, guys, my computer is quite old, but I don't think my problem is that. I recently did a clean install of the new upcoming Lubuntu 13. Well, last night, I tried to turn it on, and it said I had "grub rescue>". I tried a boot repair disk which I downloaded, and came up two different times with two different numbers to write down on a piece of paper. That didn't fix it. I am now using a live xubuntu cd that I had awhile back. Even
[22:32] <Guest51241>  loading that took some time. I am not able to clean install. There must be something wrong with the grub of my latest Lubuntu. right? I've looked online about this and found a lot of things, but nothing simple for me. help
[22:34] <wxl> Guest51241: it gave no other errors?
[22:34] <Guest51241> no
[22:35] <phillw> Guest51241: did the cd pass the self test?
[22:37] <Guest51241> I'm sure it did, because I have used all the cd's I've downloaded successfully for sometime, including this one, Xubuntu. I have used a Lubuntu 12.04 and Lubuntu 13 for weeks even. The reason I changed to Lubuntu 13 is because I thought 12.04 wasn't going to be supported by next month. And no, I didn't do a self test of these burned cd's. I don't think I knew how to do that.
[22:38] <wxl> Guest51241: that's confusing. did the md5s pass or fail?
[22:39] <Guest51241> ummm I didn't check for any passes or failers, except my cd burner said it was alright. Kinda computer NOT savy here.
[22:40] <phillw> Guest51241: when you boot with a cd / dvd /usb - one of the options is to test the install media. You really *must* do this.
[22:40] <Guest51241> I did see something about those md5s. They are like tests for the isos, right? I don't know how to use those. So, how do you do that?
[22:41] <genii> !md5
[22:41] <wxl> you can test the iso and then further confirm the cd/dvd/usb by testing it
[22:42] <wxl> md5sum is the command for the iso
[22:42] <tonyt> hope someone can help . just installed lubuntu . trying to install a driver and its telling me i need to do it as a super user . i only set 1 pass during the install and that password isnt working . anyone have any ideas ?
[22:42] <wxl> tonyt: so you have only one account? can you log in with it?
[22:43] <tonyt> ya only 1 and im logged into it
[22:43] <Guest51241> thanks for the site info on the md5. I'll check it out.
[22:43] <tonyt> i opened the terminal and did su root and it asked for a password and it fails
[22:44] <tonyt> i thought the password i set during the install should be the admin pass
[22:44] <phillw> Guest51241: when you download an ISO, check it... when you burn the CD / DVD / USB you will see the option to self check. This is so, so important a step to do.
[22:44] <tonyt> is that correct ?
[22:44] <wxl> tonyt: there is no root
[22:44] <Unit193> tonyt: You use `sudo`, so  sudo make  for example
[22:44] <Guest51241> o.k. philw
[22:45] <wxl> !sudo | tony
[22:45] <wxl> oops :/
[22:45] <wxl> wrong one
[22:45] <wxl> !root | tonyt
[22:45] <tonyt> i tried sudo too
[22:45] <tonyt> k ill read
[22:46] <phillw> tonyt: there is no default login and password on install. you are asked that during the install process for the admin user and asked your admin password. If this does not happen, your ISO you are trying to install off from is corrupt.
[22:46] <tonyt> k got it
[22:46] <tonyt> thanks
[22:46] <wxl> tonyt: so if you do sudo something and it asks for the password, what do you get back?
[22:47] <tonyt> i got it work . i did sudo sh ./amd.run
[22:47] <tonyt> just the vid driver
[22:47] <wxl> congratulations
[22:47] <tonyt> thanks


[00:02] <bryce> cya
[10:56] <mlankhorst> woops, broke switching back
[12:44] <jcristau> fyi http://bugs.debian.org/693158 may be somewhat relevant to ubuntu as well
[12:48] <mlankhorst> proof that nobody uses it? :-)
[12:48] <tjaalton> bah
[12:49] <mlankhorst> hm maybe we use a newer version
[12:50] <mlankhorst> oh we don't
[13:01] <mlankhorst> tjaalton: hey can we drop penmount from universe? :>
[13:03] <tjaalton> sounds like a plan
[13:11] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-penmount/+bug/1082015 weee
[14:51] <Dandel> Sarvatt and RAOF: I spotted a code merge for piglit that enables EGL, opengl es1 and opengl es2 tests.
[15:52] <mlankhorst> waffle one?
[16:01] <Dandel> mlankhorst: yes, waffle is required for opengl es 1/2 tests ( and to use egl w/ opengl on piglit )
[16:02] <Dandel> and there's a missing environmental variable... PIGLIT_SOURCE_DIR needs to be set ( most likely to /usr/share/piglit/ )
[17:07] <mlankhorst> tjaalton: hm can I add recommends xserver-xorg-{video,input}-all, libgl1-mesa-glx to xserver-xorg ?
[17:08] <mlankhorst> should make stack switching slightly more robust
[17:10] <mlankhorst> I fear that may end up installing xserver-xorg-(input,video)-all again on machines that previously removed them, though..
[17:11] <tjaalton> yeah i think it'd have some side-effects..
[17:13] <mlankhorst> I'll try without..
[17:27] <spindritf> hey, how do I view and change my font path? I want programs to search ~/.fonts first and /usr/share/fonts later
[17:27] <spindritf> is that up to X?
[17:41] <mlankhorst> guessing fontconfig cares
[17:43] <mlankhorst> tjaalton: can we recommend xserver-xorg-input-all at least?
[17:56] <tjaalton> mlankhorst: i'm not sure, and not able to check now what issues it might have
[17:56] <mlankhorst> ok :/
[17:56] <mlankhorst> well in the worst case switching back will only leave you with evdev then..
[18:02] <tjaalton> do you have a dl for the stack?
[18:03] <mlankhorst> it's in my experimental ppa
[18:05] <mlankhorst> but still testing a little
[18:08] <mlankhorst> maybe things clear up if I re-add the conflicts/replaces to itself back in *-all
[18:09] <tjaalton> so no immediate deadline then. i should be able to test it tomorrow
[18:09] <tjaalton> the up/downgrade
[18:10] <mlankhorst> it's still broken on -dev packages though
[18:21] <bjsnider> phoronix headline: AMD's New Catalyst Linux Driver Isn't Too Good
[18:27] <mlankhorst> I don't think amd has to worry about catalyst drivers being too good
[18:33] <MCR1> mlankhorst: Stupid fglrx makes it impossible to operate 3 monitors, while open-source gallium has no problem with it...
[18:33] <MCR1> grmpf
[18:38] <mlankhorst> tjaalton: forward switching should be ok though, still seem to hit some bug with multiarch
[18:38] <mlankhorst> apt-get install xserver-xorg-lts-quantal libgl1-mesa-glx-lts-quantal:i386
[18:38] <mlankhorst> works around it
[19:00] <Dandel> MCR1: that's not a issue.
[19:00] <MCR1> Dandel: ?
[19:00] <Dandel> MCR1: just add "Virtual   4096 4096" to the display subsection
[19:00] <Dandel> where the other lines are "viewport 0 0" and "depth 24"
[19:01] <Dandel> MCR1: use xrandr
[19:01] <MCR1> I need more than 4096x4096
[19:01] <Dandel> it's so xrandr plays nicely with hotplugging
[19:01] <Dandel> try higher, but my experience was not good
[19:01] <MCR1> I need 1920+1280+1920 in x axis
[19:02] <MCR1> and in that case fglrx fails with not enough vram error or something like that
[19:02] <MCR1> which is ofc not true
[19:02] <Dandel> care to give me the system information?
[19:02] <Dandel> I know how to get the bug report to the right people
[19:03] <MCR1> ATI HD 5750, Quantal, latest AMD fglrx beta
[19:03] <Dandel> build id?
[19:03] <MCR1> one moment
[19:04] <MCR1> 9.01-121018a-148746E-ATI
[19:04] <MCR1> Driver Packaging Version ^^
[19:05] <Dandel> k... care to get the output from? /usr/share/fglrx/atigetsysteminfo.sh
[19:05] <Dandel> that will need a pastebin tho
[19:05] <Dandel> it'll output to a text file ~/atisysteminfo-report.txt
[19:07] <MCR1> grmpf, it is too long for pastebin.com
[19:07] <Dandel> compress it and file a launchpad report with the file?
[19:09] <MCR1> Dandel: Got it now (pastebin.ubuntu.com): http://pastebin.ubuntu.com/1377782/
[19:09] <Dandel> thanks
[19:10] <MCR1> thanks to you - would be great to have 3 monitors running with fglrx also...
[19:13] <Dandel> MCR1: i think i see the issue.
[19:13] <Dandel> you need 3 seperate screens? or just one large one?
[19:16] <Dandel> MCR1: that configuration is mangled.
[19:16] <MCR1> 3 separate ones... combined to one big desktop, not mirrored
[19:19] <Dandel> do you mind fixing it using xrandr?
[19:21] <bjsnider> MCR1, you have to admit that 3 monitors is really, really, really difficult for them
[19:25] <Dandel> http://pastebin.ubuntu.com/1377815/ - try th is for a second.
[19:25] <Dandel> don't expect immediate fix, because you will need to open up xrandr and move the screen around and disable mirror
[19:26] <Dandel> for now, set the 1920x1200 at point (0,0), the 1280x1024 at point (0,1200), and the 1920x1080 at the point (1920,1080).
[19:28] <Dandel> or if that's hard... two commands: "xrandr --output DFP2 --right-of DFP4" and "xrandr --output CRT2 --below DFP4"
[19:28] <Dandel> if that gives you big desktop, but setup a little odd, it's ok... the next test is to change the virtual size once more.
[19:29] <Dandel> change "Virtual   4096 4096" to "Virtual   6144 6144" then just move the crt and dfp to the positions you desire.
[20:01] <MCR1> Dandel: Thanks a lot for your suggestions and help - I'll try to do that :) Great !
[20:02] <MCR1> Do you think it would be possible to make a 3-screen horizontal config also ?
[20:02] <Dandel> yes.
[20:03] <Dandel> just apply the change i mentioned about a half hour ago.
[20:03] <Dandel> and then use xrandr to move displays around
[20:05] <Dandel> it's mainly the use of the command: xrandr --output "Display to be effected" (--left-of, --right-of, --above, --bellow) "display to anchor by"
[20:08] <Dandel> although, i also know that the gnome monitor preferences ( or mate monitor preferences ) should do a great job also.
[20:09] <Dandel> since what this did is fix the built in desktop manager screen configuration utility on the system... what happens is the login screen will most likely get mirrored, but once you login, the setting will reapply.
[20:15] <Dandel> ricotz: would it be possible to update libwaffle from 1.1.0 to 1.2.0?
[20:23] <MCR1> Dandel: I am sorry for my slow responses, but I was attending a meeting on #ubuntu-desktop - Once again, thanks a lot 4 your help - It is highly appreciated. I will try and report success or failure to you in the next days...
[20:27] <MCR1> bjsnider: Fact is that AMD/ATI advertise their cards for 3-monitor usage and it works with gallium... But maybe I get it to work with fglrx also, thanks to the help of Dandel... I hope so at least as I wanna watch movies on my TV ;)
[20:33] <Dandel> bjsnider and MCR1, amd actually advertises support for up to 6 monitors on a single card, but many cards can only can handle up to 3
[20:33] <mlankhorst> You don' t get what 'up to' means then
[20:43] <ricotz> Dandel, i guess i can do
[20:43] <ricotz> 1.2.1 that is?
[20:44] <Dandel> 1.2.1 works... it's mainly to get the latest fixes ( including the opengl es 3 support )
[20:45] <MCR1> \o/ OpenGL ES 3
[20:46] <ricotz> Dandel, pushed it to the ppa, but precise will probably fail
[20:47] <Dandel> it should work just fine due to the fact that the last piglit worked fine.
[20:47] <ricotz> (due missing cmake multiarch support in precise debhelper)
[20:48] <Dandel> cmake in precise needs a blanket upgrade anyways
[20:48] <ricotz> Dandel, is there any care for the oneiric/lucid builds in there?
[20:48] <Dandel> the debian build using cmake is broken
[20:48] <Dandel> it generates packages that can't be installed
[20:48] <ricotz> i see
[20:49]  * ricotz meants to delete the oneiric/lucid packages there
[20:50] <Dandel> oneiric and lucid, i don't care about... i have one machine using precise, the other using ocelot ( or w/e 12.10 is called )
[20:50] <ricotz> quantal ;)
[20:50] <Dandel> actually, i just had to reinstall on the other machine because grub upgrade balked ><;
[20:51] <Dandel> 10.04.1 ( lts) to 12.04.1 (lts) broke grub and i had to rework the install from scratch.
[20:51] <MCR1> urgh
[20:51] <Dandel> nothing like a grub 2 install without any modules :/
[20:52] <Dandel> MCR1: if fglrx crashes with the 8192x8192, it's because of driver bug ( it fails on the hd6520G i have )
[20:53] <Dandel> that's part of why i suggested 4096x4096 initially since that did not crash the test machine i use.
[20:53] <MCR1> Dandel: I do not have the energy today anymore to try and fix if it fails, so I'll try tomorrow... but IIRC it crashed last time I tried 8192x8192 with some not enough videomem error
[20:54] <Dandel> MCR1: your config was weird
[20:55] <MCR1> yeah, something went wrong during last update I guess, but I did not look at it in detail before, because my 2-screen config was working perfectly - so I did not even know that it was bortched
[20:57] <MCR1> but I could not change config by disabling one monitor and enabling the TV instead via AMDCCC anymore, I guess the weird config was causing this
[20:57] <MCR1> so I still see a chance in your suggestions and will try to apply them ;)
[20:58] <MCR1> Does Virtual always need the same x and y to work ?
[20:58] <MCR1> Or is something like "8192 2048" also valid ?
[20:58] <Dandel> should work
[20:59] <Dandel> but it'd limit the screen orientation changes
[20:59] <MCR1> I do not need to change orientation never, so I would not care
[21:00] <Dandel> then it should be fine.
[21:00] <MCR1> thx again - I'll promise to report the outcome ;)
[21:01] <MCR1> afk
[21:03] <bjsnider> ricotz, pkg-config tool not found
[21:03] <bjsnider> on that waffle build
[21:04] <bjsnider> MCR1, why not use radeon instead of fglrx?
[21:04] <ricotz> bjsnider, i know
[21:12] <MCR1> bjsnider: Used gallium, was very satisfied and it was very stable, had no problems with 3 monitor-config, had a much smoother 2d-scrolling in chromium, no gfx-error with docky, but 3d performance was not comparable and unfortunately weak... I have a quite fast card with lots of fast DDR-5 VRAM and I expect it to max out Compiz framerate on 3 screens, which it wasn't capable of...
[21:13] <bjsnider> it's an exapnsion card?
[21:13] <MCR1> bjsnider: ?
[21:13] <bjsnider> is the gpu built into the board or is it plugged into the mainboard
[21:13] <MCR1> ATI HD 5750 PCI-E
[21:13] <MCR1> plugged-in
[21:14] <bjsnider> i don't understand why you bought an amd card in the first place
[21:14] <MCR1> 3 screens ?
[21:14] <bjsnider> why not nvidia?
[21:14] <MCR1> not possible with nvidia 1 card
[21:14] <bjsnider> sure it isn't
[21:16] <MCR1> and at the time this card offered a good value for the price and was 40 nm GPU tech
[21:16] <MCR1> and DDR5, while Nvidia was still using DDR3
[21:17] <MCR1> other computer uses GTX-570-448 cores...
[21:19] <Dandel> ricotz: there's a pull request for piglit packing that has had 1 approval, and just needs some review... mind looking at it?
[21:31] <ricotz> Dandel, seems fine
[21:32] <Dandel> the only other thing i can see is the missing opencl libs being an issue the stock repo for precise. ( i know there's a backport request for it


[05:13] <TJ-> Trying to report a bug, use the package browser to select the package, but on trying to post the bug report getting ""nvidia-graphics-drivers-340" does not exist in Ubuntu. Please choose a different package.". If you click-through from the package selection list it opens an identical link ( https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/+filebug# )
[05:46] <wgrant> TJ-: That package doesn't exist in Ubuntu.
[05:46] <wgrant> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340
[05:46] <wgrant> " There is no current release for this source package in Ubuntu."
[05:46] <TJ-> Indeed it doesnt, but the package choose has a link that says it does
[05:46] <TJ-> s/choose/chooser/
[05:47] <TJ-> In the "Select a Package" search dialog, the single link that comes up when searching for "nvidia-graphics-drivers-340"
[05:49] <wgrant> That's bug #42298.
[05:49] <wgrant> But how did you come to be on that page?
[05:51] <TJ-> I found a bug in "nvidia-graphics-drivers-340" which has an SRU in packages in main (bug #1247736) which allowed me to add that package as an "also-affects", and then wanted to bring it to the attention of the xorg-edger's team and followed their guidelines which require posting the bug report against the main Ubuntu package and prefixing the report with "[xorg-edgers]" rather than a big report against their repo bug tracker
[05:55] <TJ-> And as I was permitted to add the also-affects against "nvidia-graphics-drivers-340" in Ubuntu, it didn't make sense when it refused the new bug report!
[09:33] <Noskcaj> Could you please ban ~christianandrews29 ? He's posting muscle growth spam in ubuntu bugs
[09:55] <wgrant> Noskcaj: Gone.
[17:36] <patdk-lap> uploads to launchpad are broken, atleast for precise
[17:36] <patdk-lap> trusty gave me an issue, but a retry worked
[17:45] <patdk-lap> looks to be working again
[18:43] <Delemas> One of my builds keeps getting rejected because a previous version has a broken .orig.tar.gz. I've deleted all instances of my package from my PPA but Launchpad keeps rejecting the new build. Is there a workaround?
[18:53] <Delemas> nevermind.


[00:01] <poolie> spiv, call in a sec
[00:19] <Necoro> hi there
[00:19] <Necoro> anyone an idea: http://rafb.net/p/v6LWKW51.html
[00:19] <Necoro> ?
[00:20] <beuno> Necoro, Permission denied (publickey).
[00:20] <beuno> it shouldn't be tracebacking
[00:20] <beuno> spiv, ^
[00:21] <beuno> Necoro, but, it's likely due to Launchpad being down
[00:21] <Necoro> beuno: hmm - the web service is up and running ;)
[00:21] <Necoro> but the traceback is strange though
[00:21] <Necoro> AttributeError: 'ProtocolThreeDecoder' object has no attribute '_in_buffer'
[00:21] <jml> Necoro: the codehosting service is not yet fully up.
[00:21] <beuno> Necoro, the web service, but not the code hosting
[00:23] <Necoro> ok
[00:23] <Necoro> then I'll try again tomorrow morning ;)
[00:24] <Necoro> or in a few hours - depending on how long I stay awake
[00:25] <spiv> Necoro: that's a bug in -Dhpss
[00:25] <spiv> Necoro: it's fixed in bzr.dev (and 1.7rc I think)
[00:25] <Necoro> spiv: *g* - bugs in debug code pathes are always great :D
[00:30] <lifeless> spiv: did you see my comment on that merge request?
[00:31] <lifeless> down to 15 failures btw
[00:35] <spiv> lifeless: yeah, I did
[00:35] <spiv> lifeless: it's still flagged in my inbox as something to address
[00:36] <lifeless> cool
[00:36] <lifeless> 2.45 seconds now btw
[00:37] <lifeless> I've seen hg as low as 2.37
[00:38] <lifeless> so, without plugins, my bzr branch is faster :P
[00:38] <spiv> When I land faster-startup (tomorrow hopefully) that'll get you another 30ms :)
[00:42] <lifeless> btw, did you try my status branch out ?
[00:42] <poolie> nice
[01:20] <lifeless> ok, all tests pass
[01:20] <lifeless> (all the intertree unit tests I mean)
[01:22] <lifeless> still 2.45 seconds with everything passing, which is good
[01:22] <lifeless> lots of fat in there still I think
[01:23] <lifeless> breakfast now, test-parameterisation for this new extension after that, then people can pplay
[01:25] <jml> when's next bzr rc cut due?
[01:26] <jml> jam: ^^
[01:27] <jdobrien> i f
[01:28] <jdobrien> i know this isn't a bzr question but, i know there's a way of getting a line count from bzr diff by piping it through something else. but i can't remember how
[01:28] <jml> jdobrien: bzr di | wc -l will get you a line count
[01:28] <jdobrien> that's it! thanks!
[01:28] <jml> jdobrien: but piping through 'diffstat' is also sometimes useful
[01:28] <jdobrien> jml: thank you
[01:29] <jdobrien> jml: diffstat, very nice
[02:40] <lifeless> 2.42 seconds :P
[03:21] <lifeless> btw
[03:21] <lifeless> there is a faster status branch pushed to ...readdir
[03:22] <lifeless> I'm tuning now, but its currently 1.4/3.84 seconds faster
[03:22] <mwh> lifeless: does it mean a faster diff against wt too?
[03:23] <lifeless> mwh: yes
[03:24] <lifeless> mwh: diff is built on iter_changes
[03:24] <mwh> right
[03:24]  * mwh tries to think what else is
[03:24] <mwh> merge, i guess?
[03:24] <mwh> but that's between revision trees i suppose
[03:32] <lifeless> merge does a local diff
[03:33] <lifeless> so yes, merge on large trees should feel faster
[03:34] <lifeless> mwh: how long does 'bzr st' take you today on lp?
[03:35] <jml> ~540ms for me.
[03:35] <AfC> Is bzr 1.7-rc1 something you want me testing? (alternative answers to "duh, yes" are "ooops, no, it's horridly broken don't touch" and "wait until 1.7rc2" and "no stick with 1.6.1 for day to day use" and "please test the $X which we want feedback on")
[03:35] <lifeless> yah, you would see only a small improvement
[03:36] <lifeless> AfC: rc testing feedback is always welcome; I don't know if there are specific improvements there that are relevant to you
[03:36] <AfC> {shrug}
[03:36] <AfC> Then I'll pull it in.
[03:36] <lifeless> if 1.7c1 was horribly broken the IRC topic would likely say so
[03:36] <AfC> Uh huh
[03:37] <AfC> (I'm more getting at the tension between "it was just a snapshot on a given day" and "our dev tip is where it's at, but don't use that")
[03:46] <lifeless> oh
[03:47] <lifeless> well, I live ahead of tip myself; I think anyone that is interested can safely run tip - just need to track the rss feed for it to know what changes are occuring
[03:53] <jml> AfC: use the tip of the bzr 1.7 branch if you want to test. It's got a couple of fixes that aren't in the rc.
[03:54] <fullermd> I track tip, 'cuz it makes me feel special.
[03:56] <AfC> fullermd: you *are* special. Don't let anyone tell you different.
[03:56] <fullermd> That's what the counselors always told me, while they were smiling and backing away.
[03:57] <fullermd> Anyway, whaddaya get if you run released versions, anyway?  All you do is trip over bugs that other people have already found.  Where's the joy in that?
[03:58]  * spiv sometimes thinks that "Following the tip" sounds like "walking the plank"
[03:58] <fullermd> I mean, that's all like "You: I found this bug    lifeless: Yeah, it's bug 12345".
[03:58] <spiv> Especially when lifeless says he lives ahead of the tip :)
[03:58] <fullermd> With tip, you can be all "You: I found this bug     lifeless: o_O"
[03:59] <spiv> fullermd: the joy is that if the bugs are already known, then maybe the workarounds are too ;)
[03:59] <jml> spiv: 'patches accepted' is not a workaround.
[03:59] <fullermd> Piffle.  What kinda wimp wants to live like THAT?
[04:00] <fullermd> That's like getting pre-digested food.
[04:00] <fullermd> Gotta have something you can sink your teeth into.
[04:00] <fullermd> Even if it responds by sinking teeth into you...
[04:49] <lifeless> mwh: so, did you try the branch? or just curious about whether it will help you ?
[04:59] <spiv> poolie: there's a mostly complete http://bazaar-vcs.org/SmartPushAnalysis1.8 now.  I'm off to lunch.
[05:01] <poolie> hey, great
[05:01] <poolie> i was literally talking about it to thumper right now
[05:04]  * spiv does a couple last touches
[05:04] <spiv> Ok, really lunch now :)
[05:06] <spiv> poolie: buried in the "analysis" section is a description of the 10s win I mentioned this morning.
[05:06] <poolie> spiv, can you tell me more (or add more) to that page about the streaming-push work
[05:07] <poolie> like sending a put_revisions_stream rather than working on packs
[06:10] <mwh> lifeless: no, i didn't get around to it
[06:16] <poolie> spiv, are you back?
[06:21] <spiv> poolie: I am
[06:21] <poolie> quick call? skype or pots?
[06:22] <spiv> Either's fine with me.
[06:26] <jml> will 'bzr upgrade' in a shared repo upgrade the branches in that repo?
[06:36] <lifeless> jml: it didn't do so in the past, but I don't know if it does now
[06:39] <jml> lifeless: thanks.
[06:39] <lifeless> jml: easy enuff to find out
[06:39] <jml> lifeless: yeah, I know.
[06:40] <jml> the answer is "no"
[06:52] <vila> hi all
[07:11] <lifeless> jml: ping
[07:12] <jml> lifeless: pong.
[07:12] <lifeless> jml: AIUI bzr never stacks unless --stacked is passed
[07:13] <lifeless> I refer to your lp documentation
[07:13] <lifeless> if it is stacking without --stacked being passed, or a local default being set, I consider it a pretty big bug we should fix
[07:13] <jml> lifeless: ok.
[07:14] <lifeless> (because stacking generates a truncated database, it can lead to unrecoverable data loss if people think they actually have a full branch)
[07:14] <jml> lifeless: not 100% sure what to say to that.
[07:14] <lifeless> (and then delete something)
[07:15] <jml> lifeless: the work I've been doing on Launchpad has been predicated on the default stacking policy stuff in Bazaar 1.7.
[07:15] <lifeless> jml: I understood that policy to control *where* not *if*
[07:17] <jml> lifeless: ok, then that's definitely something to raise on the Bazaar mailing list.
 jml: AIUI bzr never stacks unless --stacked is passed
[07:17] <mwh> not true, a*i*ui
[07:17] <lifeless> poolie: please read the above, then comment
[07:18] <lifeless> from 16:11 < lifeless> jml: ping
[07:24] <jml> lifeless: in any case, whether or not Bazaar needs to grow a local configuration option is incidental to Launchpad.
[07:24] <jml> lifeless: if the 1.7 release gets one I'll update my instructions.
[07:26] <jml> lifeless: this rollout only defines a stacking policy for projects on a pre-configured shortlist, so the impact is manageable.
[07:32] <poolie> hi
[07:33] <poolie> hm
[07:33] <poolie> my understanding was that it should not normally stack unless --stacked was given
[07:33] <poolie> but when pushing to eg launchpad the server could tell it to do so
[07:35] <jml> this matches how bzr behaves at the moment.
[07:40] <poolie> yay
[07:40] <poolie> i'm so haappy to hear thaht
[07:40] <poolie> that*
[07:41] <jml> :)
[07:42] <jml> ok. well I'm going to take a few deep breaths to recover from that little shock.
[07:45] <poolie> lifeless: is this ok with you?
[07:45] <lifeless> poolie: I don't really feel comfortable with that, but if you are, well, I have bigger fish to fry.
[07:47] <poolie> jml, can we change this later so the server just sends a suggested url but doesn't turn it on?
[07:48] <jml> poolie: I'm not sure I follow. At the moment, all the server does is specify a URL in a control.conf file.
[07:49] <jml> (and a billion things to deal with the fallout of that & Launchpad's own infrastructure)
[07:50] <jml> poolie: presumably Bazaar can change at a later stage to respond differently to this URL.
[07:50] <poolie> ok
[07:51] <poolie> lifeless: thanks for the status update that was super useful
[07:51] <poolie> aside from being a nice set of numbers
[07:52] <lifeless> I'd like to set usertest run across it
[07:52] <poolie> thanks for noting that it may be bottoming out too
[07:52] <poolie> ok
[07:52] <poolie> you can, or i can on escudero
[07:53] <lifeless> is there a HOWTO?
[07:53] <poolie> yes, just google it
[07:53] <lifeless> http://rabbit.eng.miami.edu/dics/amerlen/length08.txt ?
[07:53] <lifeless> thats the only hit
[07:53] <lifeless> for "'usertest' 'escudero'"
[07:53] <poolie> hee hee
[07:54] <poolie> http://people.ubuntu.com/~ianc/plugins/usertest/doc/usertest-tutorial.html
[07:54] <lifeless> uhm
[07:54] <lifeless> I meant on escudero
[07:54] <poolie> https://wiki.canonical.com/Orcadas
[07:54] <poolie> i mistyped
[07:55] <poolie> i'll be here for a few more hours so i'm going to take a break now
[07:55] <lifeless> ok
[07:55] <lifeless> well, I might poke tomorrow
[07:55] <lifeless> reading those two docs suggests to me the answer is 'no there is no howto for running a specific branch'
[07:55] <lifeless> so I'll look at it tomorrow
[07:55] <poolie> i can set it up
[07:55] <lifeless> gnight, enjoy your call :P
[07:56] <poolie> it's in the doc on that machine
[07:56] <lifeless> branch is http://people.ubuntu.com/~robertc/baz2.0/readdir
[07:57] <lifeless> thanks!
[08:36] <imyojimbo> hi, im trying to push a branch to lp , and i get "The server's host key is not cached in the registry"
[09:02] <Odd_Bloke> poolie: Did you see my email regarding payment for the summer?
[09:03] <poolie> Odd_Bloke: hi there
[09:03] <poolie> yes let's see about that
[09:07] <Odd_Bloke> poolie: I'm at work ATM, so email is better than IRC. :)
[09:14] <poolie> ok
[09:25] <poolie> sent
[09:27] <Odd_Bloke> poolie: Thanks.
[09:27] <Odd_Bloke> I'll deal with it when I get home.
[09:27] <Odd_Bloke> Or possibly tomorrow, I'm probably busy this evening.
[09:27] <poolie> maybe we can talk tomorrow my time/uk evening
[09:34] <poolie> lifeless: should be running now in http://benchmark.bazaar-vcs.org/usertest/log/usertest.log.inprogress
[09:35] <awilkins> ls
[09:35] <awilkins> Oops
[12:57] <robsta> hi
[12:57] <robsta> is there anything new in the BzrGit department?
[13:03] <Odd_Bloke> robsta: jelmer wrote (most of) it, so he'll probably know.
[13:05] <robsta> is it usable already?
[13:49] <lifeless> robsta: it can clone locally I believe
[13:59] <robsta> ok, guess i'll stick to svn server-side for the time being, then
[14:47] <antoranz> Hi guys!
[14:47] <antoranz> is it possible to list all the revisions in a branch but ordered by date instead of "revision/branch"?
[14:48] <antoranz> I mean.... instead of having the revision tree, I want toget all the revisions ordered by date
[14:48] <antoranz> is that even possible at all?
[14:50] <vila> jam: ping
[14:56] <Tak> in a bound checkout, does `bzr cat` hit the server?
[14:57] <bob2> I'd assume yes for lightweight,no for regular
[14:58] <Tak> good
[16:33] <Leonidas> how comes that bzr mv -q still shows what it moves?
[16:34] <james_w> Leonidas: it's a bug I expect
[16:34] <Leonidas> Yeah, I think so too. I just encountered again when I wrote it in a script
[16:35] <james_w> Leonidas: I would guess it's an easy fix
[16:36] <Leonidas> james_w: probably. It's not a problem currently, I just wanted to tell that to the developers, so they can fix it when someone has a bit of spare time.
[16:37] <james_w> Leonidas: a bug report would be a better way of doing that of course
[16:38] <Leonidas> james_w: sure, I'll write one in a moment. Just wanted to make sure I'm not the only one with this problem.
[16:38] <james_w> thanks, I'll check now
[16:38] <james_w> yup, I see it too
[16:39] <Leonidas> CLOSED: worksforme with the comment: "Do you think we'd miss something like this?"  O_o
[16:56] <Kittens> (well, an rc, but still)
[16:56] <Kittens> did you hire a team of slaves or such?
[16:58] <awilkins> Kittens: 1.7 was hot on the heels of 1.6
[16:58] <awilkins> 1.6 had a over-long release cycyle
[16:58] <Kittens> ah :p
[16:58]  * rocky is comforted by the fact that there are so few changes between 1.7rc1 and 1.7rc2
[17:01]  * awilkins just wants them to merge his switch-to-sibling patch so he can stop maintaining his own builds
[17:01] <awilkins> markh: Is it hard to build the "exe" version?
[17:35] <Verterok> awilkins: ping
[17:35] <awilkins> Verterok: pong
[17:35] <Verterok> awilkins: hey there!
[17:36] <Verterok> awilkins: patch merged, and also a few other fixes/enhancements in bzr-java-lib (also in bzr-eclipse)
[17:38] <awilkins> Verterok: Excellent :-)
[17:39] <awilkins> Verterok: I love it when my patches get merged, I don't have to maintain the branch anymore :-)
[17:39] <Verterok> awilkins: hehe, indeed.
[17:40] <awilkins> Going to have to keep that callisto branch going though, methinks
[17:41] <awilkins> At least until my PM badgers Borland into coughing up upgrade licenses
[17:41] <Verterok> awilkins: (don't remember if already told this) about the dependency on core.expressions it's only used in the refresh hook
[17:41] <awilkins> So we can use the Ganymede version insdtead of Callisto
[17:41] <awilkins> Verterok: Yes... the refresh seems to work OK, so I'm not sure if it breaks anything to be on Callisto
[17:41] <awilkins> Is there any specific behaviour that it enables?
[17:42] <Verterok> awilkins: that's is only for a specific layout
[17:42] <Verterok> awilkins: when the project root is below the branch root
[17:42] <awilkins> Verterok: Flat or hierarchical or something else?
[17:42] <awilkins> Ah
[17:43] <awilkins> So it would come into play on bzr-eclipse, for example
[17:43] <Verterok> awilkins: i.e: bzr-eclipse project layout: mutliple projects in one branch
[17:43] <Verterok> yes
[17:43] <awilkins> It doesn't affect most of my stuff
[17:43] <Verterok> awilkins: that was my point :) I assume you can remove the refresh hook and so the core.expressions deps
[17:49] <awilkins> Verterok: What exactly is the bit that needs that version? Because if you just take the version number out of the manifest, it compiles and appears to run ok.
[17:49] <awilkins> And a version of "3.2.100" suggests a callisto component to my mind
[17:52] <Verterok> awilkins: I think the 3.2.100 was added in Europa (but just guessing)
[17:52] <Verterok> awilkins: I never specified a version :p
[17:53] <awilkins> Verterok: It's true that I can't find a 3.2.100 version in the Callisto updates, but a europa-specific component should be 3.3, no? I suspect it's a patched version of a europa-compatible library
[17:53] <awilkins> Sorry, callisto-compatible
[17:53] <awilkins> That would fit the version number scheme
[17:54] <Verterok> awilkins: here (3.4) seems to compile without the version number
[17:54] <awilkins> Also does so for 3.2
[17:54] <Verterok> awilkins: the version scheme is not exactly like that :)
[17:55] <awilkins> Well, it should be :-)
[17:55] <Verterok> awilkins: mayor.minor.bug-fix, mayor change *only* if there are api breaks, minor when there are new api or visible changes
[17:57] <awilkins> Verterok: It just makes a sort of internal sense to me that a component of version 3.2 has had the same API since Eclipse 3.2
[17:57] <awilkins> Since there are also 3.4s in Ganymede but not in Callisto
[17:57] <awilkins> esp. for actual eclipse bits
[17:58] <Verterok> awilkins: in ganymede, core.expressions is in version 3.3 :p
[17:59] <Verterok> awilkins: http://wiki.eclipse.org/index.php/Version_Numbering <- from there I taked my lame explanation of versions numbers :)
[18:01] <awilkins> Yes, but you have to admit that the large amount of "3.2" components in Callisto, and 3.3 in Europa, and 3.4 in ganymede... well, I reckon there's a convention operating within the rules there :-)
[18:01] <awilkins> What would fail if it wasn't working properly on this version
[18:01] <Verterok> awilkins: sure, it makes sense that most of the componentes get bumped to 3.3, 3.4, etc :)
[18:02] <awilkins> BUt if the API does not break... then not
[18:02] <awilkins> Hence 3.3. on Ganymede, etc
[18:02] <Verterok> awilkins: right :)
[18:02]  * Verterok just realized that bzr-eclipse should be 1.0.99 :p
[18:03]  * awilkins has had to revise client code several times, you naughty dog
[18:03] <awilkins> :-P
[18:03] <Verterok> :)
[18:04] <awilkins> Since you didn't choose a version number, I suggest it is removed
[18:04] <awilkins> Since it compiles just fine here
[18:04] <Verterok> awilkins: ah, all tests passing on *nix :-D
[18:04] <awilkins> And you don't support 3.2 anyway because you use 3.3 components
[18:04] <Verterok> awilkins: sure, I'll remove it in my next commit
[18:05] <awilkins> I have a little patch for your /tmp dir stuff
[18:06] <awilkins> Hmm.
[18:06] <Verterok> awilkins: patches are more than welcome :)
[18:21] <awilkins> Verterok: They fail to start a client here
[18:21] <awilkins> Verterok: My laptop is passing.
[18:22] <Verterok> awilkins: the client don't start?
[18:23] <Verterok> awilkins: also I added a few goodies related to preferences, let me know if the chicken-egg issue is solved for your case :)
[18:35] <awilkins> Verterok: It doesn't seem to be registering the client factories before it asks to create one
[18:36] <awilkins> It calls into createClient and factories is an empty mapo
[18:36] <Verterok> awilkins: hmm, let me check
[18:36] <Tak> argh, why does `bzr diff` return a nonzero value on a non-error condition?
[18:36] <awilkins> I'll trap my working one and see where regstierAdapterFactory is getting called during the tests
[18:37] <Verterok> Tak: it indicates the result of the diff
[18:37] <Verterok> Tak: take a look at the end of: 'bzr help diff'
[18:38] <Verterok> awilkins: it should be in TestsConfig/TestConfig (If I remember ok)
[18:38] <Tak> I see what they mean
[18:39] <Tak> but the shell treats !0 as an error condition and acts accordingly
[18:39] <fullermd> diff(1) returns non-zero on differences too.
[18:40] <awilkins> Verterok: Badgers, my fault
[18:40] <awilkins> I'm running with xmloutput 0.5
[18:40] <Tak> meh, it does?  I guess that answers my question then
[18:41] <awilkins> My thoughts on that are ; since bzr-java-client can manipulate the PLUGIN PATH, it could have it's own internal xmloutput plugin
[18:41] <awilkins> But it probably needs a test to check the plugin version
[18:41] <Verterok> awilkins: oh, ok. I was thinking that maybe the new "lightweight" checks for the executable broken something on win32
[18:42] <awilkins> Verterok: All the bits of code I suspected haven't changed between our branches, I think
[18:42]  * awilkins pulls xmloutput
[18:43] <Verterok> awilkins: that would be nice, I've been playing with eclipse regarding this "bundled-xmloutput", and it seems quite simple to achieve
[18:43] <Verterok> awilkins: do you know if the PLUGIN PATH override the default plugins location?
[18:49] <awilkins> Verterok: I don't know
[18:49] <awilkins> Verterok: It all passes here apart from index because I don't have the plugin
[18:50] <Verterok> awilkins: great, I must add a conditional in the execution of the test related to bzr-search
[18:51] <awilkins> Now I'll try a startup in a clean workspace
[18:52]  * Verterok cross fingers and wait
[18:53] <Verterok> awilkins: the preferences page should be opened on startup
[18:56] <awilkins> Verterok: Ok, zero prefs
[18:56] <awilkins> So far.
[18:56] <awilkins> Imported a project (because I'd usually do that and forget about VCS for a while)
[18:57] <awilkins> Ok, menus are available.... go to prefs now
[18:58] <awilkins> Set the .bat file... it's happy
[18:58] <awilkins> Took a moment to show overlays because this is a large tree
[18:59] <awilkins> So the "can't set prefs" issue is clear
[19:00] <Verterok> awilkins: gooooood :D
[19:00] <awilkins> This is a slightly patched branch because I've removed callisto things to make it compile
[19:01] <awilkins> *europa
[19:01] <awilkins> But only those changes required (no SaveableEditor)
[19:03] <awilkins> My wife is waving cake
[19:03]  * awilkins departs, drooling
[19:38]  * beuno points everyone at: http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/
[19:39] <Verterok> hi beuno
[19:39] <beuno> hey Verterok
[19:40] <beuno> lifeless, igc, jam, abentley ^
[19:41] <LarstiQ> anam I missing some navigation, or isn't there much to the review?
[19:42] <beuno> well, it's not very profound
[19:42] <beuno> but it showcases bzr quite weel
[19:42] <beuno> well even
[19:44] <LarstiQ> ok :)
[19:45] <beuno> TBH, it's a site that normally features design stuff
[19:45] <beuno> so it was surprising to me to see that entry
[19:45] <beuno> so I had to share it   :)
[19:50] <Tak> "Monotone places higher value on integrity than performance."
[19:50] <Tak> I thought that was bzr's claim :-P
[19:58] <LarstiQ> Tak: you obviously haven't tried monotone lately ;)
[20:02] <Tak> haha, no
[20:02] <Tak> one experience was enough for me
[20:03]  * awilkins has a monotone server that's run untouched on his DVR for ages
[20:03] <awilkins> I think I'll transfer the source to bzr branches and leave it at that
[20:04] <ronny> yo
[20:04] <Spaz> ew monotone
[20:04] <Spaz> hello ronny
[20:05] <ronny> monotone is certainly nice and powerfull, just dog-slow cause poor data-store
[20:05] <awilkins> SQLite is not poor ... but RDBMS are a poor idea of version control
[20:06] <awilkins> Another reason to shy away from TFS
[20:06] <LarstiQ> it's a bit sad, they did some nice stuff
[20:06] <ronny> awilkins: well, given the context sqlite is poor
[20:06] <awilkins> VSS! With SQL Server as a backend! Yay
[20:06] <ronny> well
[20:07] <rocky> is there anything compareable to svn authz access via http/apache for bzr? where you can control access to various repos and/or folders-within-repos via a config file?
[20:07] <Tak> eh, tfs is a bit more like svn with sql server as a backend ;-)
[20:07] <awilkins> rocky: You can only do authorization on a whole-tree level
[20:08] <beuno> there is a script in contrib/
[20:08] <rocky> awilkins: well, is there anything making that (on whole-tree level) simple for a http based bzr serving?
[20:08] <beuno> for SSH keys
[20:08] <ronny> hmm, well, will bzr branches stay to limited to one head and having the workdir point to that
[20:08] <rocky> beuno: what i'm asking for would need to be read/write via http
[20:09] <beuno> rocky, ah, webdav. vila is the man to ask about that
[20:09] <rocky> vila: ^^ :)
[20:09] <beuno> it's late-ish for him, so he may not be around
[20:09] <beuno> if you don't get an answer, sending an email to the list is the next best thing
[20:10] <awilkins> Hmm, I like the domo-kun eating trees on their picture of git, why isn't the real git like that....
[20:10] <rocky> since the main bzr http serving thing is just a python wsgi app (well at least it looks that way) it seems fairly straightforward to write my own access middleware for that
[20:10] <rocky> but i'd love to see if someone's already one that
[20:10] <rocky> *done
[20:11] <beuno> rocky, well, contributions to loggerhead are *very* welcome  :)
[20:11] <awilkins> I've only gone as far as configuring access via IIS auth
[20:11] <AmanicA> I've managed to do read & write through apache  (bzr+http://)
[20:11] <beuno> anyway, I'm off to the dentist
[20:11] <awilkins> You just use IIS user impersonation and normal NTFS ACLs
[20:11] <beuno> IIS, eeeeew!
[20:11] <Spaz> ew
[20:11] <beuno> ok, that's it for unproductive comments from me
[20:11] <awilkins> I know, but the production site is ASP classic
[20:11] <rocky> ew is right ;)
[20:11]  * Spaz threw up a little
[20:12] <awilkins> I could change it to PHP in short order though
[20:12] <awilkins> THe ASP is only being used for a very few things
[20:12] <awilkins> Mostly inserting "1" and "0" into links in strategic places
[20:13] <awilkins> Might be nicer... but without it, Bazaar would not have working IIS support yet, so ner.
[20:13] <AmanicA> rocky: using AuthType Basic and AuthUserFile like with svn
[20:13] <LarstiQ> awilkins: I for one think you're a hero :)
[20:13] <Spaz> i think IIS discussion is off-topic in here
[20:13] <Spaz> and quite frankly i think it's flamebait :P
[20:14] <rocky> well as long as everyone here acknowledges that MS tech beats all i don't need to argue....
[20:14]  * rocky couldn't resist throwing out some bait
[20:14] <Spaz> hurhurhur
[20:14] <Spaz> :P
[20:15] <awilkins> Yes, MS tech is a violent assault, we agree
[20:15] <Spaz> i think m$'s technology is their attempt at conquering the world...and it seems to be working
[20:15] <Spaz> :p
[20:15]  * Spaz forks himself into the background
[20:16] <LarstiQ> Spaz: nah, not as it concers
[20:16] <LarstiQ> meh
[20:17]  * LarstiQ kicks freezing laptop
[20:17] <Spaz> don't kick it too hard
[20:17] <awilkins> markh: Ping?
[20:28] <ferrouswheel> hi all, is there any way to pull individual file changes from a revision?
[20:31] <ferrouswheel> ahh, dumb question, just found out merge supports that
[20:31] <Spaz> bzr help diff
[20:31] <Spaz> or that
[20:40] <bpierre> hi
[20:45] <LarstiQ> bpierre: hey, did you try `bzr add subtree`?
[20:45] <LarstiQ> s/hey/hi/
[20:45] <ferrouswheel> looks like i spoke to soon... online some refers to using individual files with merge... but i can't find anything in the help about it
[20:46] <ferrouswheel> oh actually it does work... it just doesn't accept wild cards.
[20:51] <bpierre_> does it work if the directory containing the subtree is added but not yet commited?
[20:58] <bpierre_> LarstiQ: here is what I did: http://www.pastie.org/275241
[21:02] <LarstiQ> bpierre_: I think that should work. The root fileid won't be set yet of ruby, so _possbily_ that could go wrong
[21:02] <bpierre_> I tried to commit, then add, no luck
[21:02] <LarstiQ> no luck in what way?
[21:02] <bpierre_> I'm using the right format, right?
[21:03] <LarstiQ> bpierre_: yes, old, but alas
[21:03] <bpierre_> add src, commit src, branch ../c src/c, add src/c
[21:03] <LarstiQ> bpierre_: what does that give?
[21:03] <bpierre_> nothing, if I do a status, src/c is still unknown
[21:06] <LarstiQ> hmm
[21:06] <bpierre_> 0.373  opening working tree '/home/bpierre/projs/test/ptree/ruby/trunk/src/c'
[21:06] <bpierre_> 0.390  skip control directory '.bzr'
[21:07] <bpierre_> in ~/.bzr.log
[21:07]  * LarstiQ tries to find a workable machine
[21:13] <LarstiQ> bpierre_: oh wait, which bzr is that you're using?
[21:13] <LarstiQ> bpierre_: path/to/nested-trees/bzr ?
[21:14] <bpierre_> installed http://bazaar.launchpad.net/%7Elarstiq/bzr/nested-trees/ with --prefix=~/progs
[21:14] <bpierre_> bzr --version: Bazaar (bzr) 1.3.0.dev.0
[21:14] <LarstiQ> bpierre_: ok, so bzr in your path is that one?
[21:14] <bpierre_> yep
[21:16] <LarstiQ> bpierre_: bah, you're right
[21:16] <fm> how do i publish my local bzr repo to an ftp server?
[21:16] <bpierre_> ?
[21:17] <LarstiQ> bpierre_: that means I'll have to refamiliarize myself with the code
[21:17] <bpierre_> ok
[21:17] <jcomeau> hi all, i can't seem to find the right lines on your webpage to add to /etc/apt/sources.list... any clues?
[21:17] <jcomeau> this is on Debian, of course
[21:18] <LarstiQ> bpierre_: I'm sorry I don't know currently why that is so :/
[21:18] <LarstiQ> jcomeau: testing or sid should not need anything extra
[21:18] <bpierre_> LarstiQ: how can I execute the test suite?
[21:19] <LarstiQ> bpierre_: bzr selftest <pattern>
[21:19] <LarstiQ> bpierre_: without the latter it will run the entirety
[21:19] <bpierre_> ok
[21:19] <LarstiQ> bpierre_: there are on the order of 10 failures/errors atm
[21:20] <bpierre_> ok, and I don't need to be in a specific directory?
[21:20] <LarstiQ> bpierre_: (if you're bored, you can look at `bzr help join`, and see how well that models your components usecase)
[21:20] <bpierre_> ah, ok
[21:21] <LarstiQ> bpierre_: join is also in regular bzr fwiw
[21:21] <LarstiQ> bpierre_: I believe at least Debian/Ubuntu run the suite after building packages, and not from the source tree, so I expect that to work
[21:21] <bpierre_> really? I noticed split was
[21:22] <bpierre_> (part of the regular bzr)
[21:22] <LarstiQ> bpierre_: in development, most people will run it from a bzr source tree
[21:22] <bpierre_> ok
[21:22] <LarstiQ> bpierre_: yeah, bzr-svn uses (or used) the same functionality under the hood
[21:22] <bpierre_> the rich root format?
[21:23] <LarstiQ> bpierre_: splitting and joining
[21:23] <bpierre_> what are the differences between all those format? rich-root, development-subtree, dirstate-with-subtree?
[21:24] <jcomeau> LarstiQ: that's what i gathered, but apt-get -t unstable install bazaar tells me it's already the latest version... and it's 1.4.2
[21:24] <LarstiQ> jcomeau: s/bazaar/bzr/
[21:24] <pl0sh> i have installed the new release and i got this message always i use the bzr command.
[21:24] <LarstiQ> jcomeau: the 'bazaar' package is unfortunately named, it is not the bzr Bazaar
[21:25] <LarstiQ> bpierre_: different ages basically
[21:25] <jcomeau> LarstiQ: thanks! looks like that'll do it...
[21:26] <LarstiQ> bpierre_: rich-root is a part of what the nested-trees needed, but that got integrated a while ago
[21:26] <LarstiQ> bpierre_: dirstate-with-subtree is the old dirstate format, plus subtrees
[21:26] <LarstiQ> bpierre_: and development-subtree I don't know but assume to be current development format plus subtree
[21:26] <bpierre_> ok, and rich-root?
[21:27] <LarstiQ> pl0sh: what error?
[21:27] <bpierre_> in the blueprint, rich-root is required, so is rich-root part of subtree format
[21:27] <bpierre_> ?
[21:28] <LarstiQ> bpierre_: no, the rich-root feature is necessary but not enough
[21:28] <pl0sh> bzr-svn is not up to date with installed bzr version 1.7rc1.
[21:28] <pl0sh> There should be a newer version of bzr-svn available.
[21:28] <pl0sh> Standalone tree (format: pack-0.92)
[21:29] <LarstiQ> bpierre_: rich-root _is_ enough for bzr-svn though, part of the reason why rich-root formats exist in released versions
[21:30] <bpierre_> ok, it's what I understood then
[21:30] <bpierre_> thanks
[21:30] <LarstiQ> pl0sh: either update bzr-svn to a version that works with bzr 1.7rc1, downgrade bzr to a version that works with your bzr-svn, or disable the bzr-svn plugin
[21:30] <LarstiQ> bpierre_: np
[21:30]  * LarstiQ really needs to start going home
[21:31] <pl0sh> ok, so, what version of bzr-svn works with bzr 1.7rc1?
[21:32] <LarstiQ> pl0sh: no released versions according to http://bazaar-vcs.org/BzrForeignBranches/Subversion
[21:32] <LarstiQ> pl0sh: two other options, run with --no-plugins, or ignore the message.
[21:33] <LarstiQ> pl0sh: you do realise bzr 1.7rc1 is a release candidate, and not a released version? :)
[21:33] <awilkins> pl0sh: silly question ; do you use it?
[21:33] <pl0sh> sure i know it
[21:33] <awilkins> (bzr-svn, that is)
[21:33] <LarstiQ> pl0sh: if you don't use bzr-svn, disabling it is probably the easiest solution
[21:34] <pl0sh> i don't use it i think i'll disable it or anyway just ignore the message
[21:34] <awilkins> You can just find it and move it to the parent folder
[21:34] <bpierre_> LarstiQ: mmm, did a join, without --reference, commit, but then noticed --reference, and how it matched more by usecase, so uncommit, revert, add (after renaming src/c/.bzr.retired.0/), and now commit
[21:34] <LarstiQ> pl0sh: if you do want to use bzr-svn and 1.7rc1, you could use a non-released bzr-svn version as well
[21:34] <bpierre_> but it fails
[21:34] <bpierre_> :P
[21:35]  * LarstiQ slaps self
[21:35] <LarstiQ> bpierre_: reference, that's it! :)
[21:35] <bpierre_> bit I'm not really going gentle with it, what with the uncommit and all
[21:35] <pl0sh> alright, thank you
[21:35] <bpierre_> LarstiQ: the error is: bzr: ERROR: already in a write group
[21:35] <LarstiQ> pl0sh: which would be lp:bzr-svn/0.4 I think
[21:35] <LarstiQ> bpierre_: huuuu
[21:35] <bpierre_> :D
[21:36] <bpierre_> I'm going to try all over again, start from a clean state
[21:36] <pl0sh> btw, i'm not very expert using bzr, and i'd want to use it better, where can i start?
[21:36] <LarstiQ> bpierre_: I like your abilities as a tester ;)
[21:37] <LarstiQ> pl0sh: that depends. Reading the documentation is a start, but imo interacting with other people works best.
[21:37]  * LarstiQ really heads home now
[21:37] <LarstiQ> bpierre_: thanks for trying this stuff out btw, I can use the kick under my rear :)
[21:38] <pl0sh> i just use the basics of bzr
[21:38] <LarstiQ> pl0sh: well, what more do you want to do?
[21:39] <LarstiQ> pl0sh: plugins can be fun to write, if you have the time and the inclination
[21:39] <LarstiQ> pl0sh: as can reading the mailing list
[21:39] <pl0sh> that would be great
[21:40] <pl0sh> actually i use bzr to keep tracking my development and as a helper when a make a mistake (i.e. delete a file or something like that..)..
[21:41] <pl0sh> but actually i don't know how to use bzr in a team, like merging branches (i think)
[21:41] <shawn_1> I have been using svn for a long time, and I am trying to migrate to bazaar. I have the repository set up on a remote box and I am having trouble checking out from it.
[21:42] <bpierre_> LarstiQ: same error: http://www.pastie.org/275273
[21:43] <shawn_1> bazaar is not liking my proxy settings
[21:43] <VanL> Is there a way to list the available repositories at a URL? For example, I have access to<EMAIL_ADDRESS>[21:44] <VanL> I can push something there
[21:44] <VanL> but I want to see what others are doing in the same tree
[21:44] <mwh> hmm, seems having a gannotate window open makes bzr pull fail with
[21:44] <mwh> bzr: ERROR: Could not acquire lock "[Errno 11] Resource temporarily unavailable"
[21:44] <awilkins> Wah, wah, wah
[21:44] <VanL> but I don't know the exact path to their repository.
[21:44] <awilkins> I built bzr.exe for windows, and it doesn't work
[21:45] <awilkins> mwh: Yes, many things I think should be read only use too many locks
[21:46] <fullermd> VanL: Not exactly.  There's a 'branches' command in bzrtools that will walk around a given location and try to list all the branches there.
[21:47] <VanL> fullermd: Does it come with the basic bzr install?
[21:47] <fullermd> No, but it's a common plugin.
[21:48] <fullermd> There's a package for it on most OSen that I know of [that bzr is packaged for, at least]
[21:50] <bpierre_> part of the windows setup exe too
[21:50] <kiko-phone> hey lifeless, are you around?
[21:51] <VanL> In bzrlib/plugins?
[21:51] <GaryvdM> VanL: qlog from qbzr will find the branches and show the tips form the branches. See http://garyvdm.googlepages.com/qlog-repo.png
[21:51] <bpierre_> any direction on how to rebuild the setup exe for windows?
[21:51] <VanL> GaryvdM: thanks
[21:52] <VanL> fullermd: thanks, now installed.
[21:56] <mwh> is it new that remotebranches support set_stacked_on_url?
[21:56] <mwh> i think they do something really weird with relative paths
[22:10] <mwh> ah no
[22:10] <mwh> it's that RemoteBzrDir.find_branch_format opens the branch
[22:21] <lifeless> jam: ping
[22:21] <lifeless> jam: do you know, offhand, where Py_ssizet is defined, getting buildfailures of all our extensions on a python2.4 box
[22:22] <jam> lifeless: You need a new-ish version of pyrex
[22:22] <jam> which will do a proper "if python_version < 2.5: #define Py_ssize_t int"
[22:23] <jam> lifeless: looking at the file I have right now:
[22:23] <ronny> re
[22:23] <jam> http://rafb.net/p/47rI8Y78.html
[22:23] <lifeless> this is still running dapper :P
[22:23] <jam> Py_ssize_t only exists on python >2.5
[22:23] <jam> sorry, >= 2.5
[22:24] <jam> lifeless: I'm trying to debug why PQM is running into autopack failures
[22:24] <jam> And I seem to have run into a *very* strange situation
[22:24] <jam> Where I'm seeing a revision text 6 times in the same pack file
[22:24] <jam> each time with different content
[22:24] <lifeless> just whacking that into _)dirstate_helpers_c.h has helped
[22:24] <lifeless> jam: if you're analyzing the pack content, remember that knit hunks only have a revision field
[22:25] <lifeless> jam: so you'll see file texts and inventories etc willynilly
[22:25] <lifeless> jam: there is a bug open on the autopack issue, its not just pqm (FWIW)
[22:25] <jam> lifeless: sure, but how would you get 6 items?
[22:26] <jam> ah, just multiple file texts?
[22:27] <LarstiQ> bpierre_: same thing here, I'll look at it tomorrow, after some sleep
[22:27] <bpierre_> ok, thanks
[22:27] <ronny> lifeless: about that only having a single tip per branch + always having the workdir point to that tip, is there any chance to ever change that?
[22:29] <lifeless> jam: rev, inv, sig, 3 file changes
[22:31] <lifeless> ronny: well, everything can be changed, if the community agree its an improvement
[22:31] <lifeless> ronny: I'm not quite sure what you mean though, because branch, in every VCS I know of, refers to one of two things: a line of development, or a bifurcation in the revision graph
[22:31] <fullermd> Well, the workdir can already point elsewhere than the tip.   I didn't think that was possible
[22:32] <mwh> jam: cherrypicks are done by the osas i think
[22:32] <lifeless> ronny: in the former, a revision is the definition of an entry point into the graph; I guess you could define multiple revs as all being 'part of branch X'
[22:32] <lifeless> jam: manual merges by LOSAs
[22:33] <fullermd> Well, mtn can have multiple heads because "on a branch" means "has a given certificate attached"...
[22:33] <lifeless> ronny: and in the latter case, its structural rather than user facing
[22:33] <jam> I don't know what an OSA or a LOSA is, but it is getting the PQM user-id
[22:33] <lifeless> fullermd: indeed; mtn is the exception :)
[22:33] <ronny> lifeless: well, git, hg and monotone allow me to go to previous/alternative versions in a branch, i build my workflows around that, bzr really differs there
[22:33] <bpierre_> monotone allows multiple heads for a branch
[22:33] <lifeless> jam: 'sudo' :>
[22:33] <jam> anyway, I have the feeling that the manual editing is where the problem is happening
[22:33] <jam> *why* I'm not sure
[22:33] <jam> but that seems to be causing the later problems.
[22:33] <lifeless> jam: I don't, because the same thing has happened to beuno on a normal push
[22:33] <jam> I'll check another example (I have 2)
[22:34] <ronny> bpierre_: not just monotone
[22:34] <lifeless> jam: there is a bug open, with tarballs of the branch as it happened live
[22:34] <beuno> are we talking about the packs collisions?
[22:34] <bpierre_> can be interrested to go back (maybe using something like bisect), and fix the bug where it was added
[22:34] <lifeless> jam: don't get confused by pqm hitting it :P
[22:34] <bpierre_> then merge the multiple heads
[22:34] <beuno> if we are, it's happened multiple times already, with different branches
[22:34] <lifeless> ronny: AFAIK bzr allows precisely the same workflow, spelt a little differently, but the same overall picture and work
[22:34] <bpierre_> also, you can pull/push with monotone, without having to merge, which can be great (you can always do the merging on one machine)
[22:35] <lifeless> ronny: if there is a something you want to do and bzr doesn't help you do it, thats definitely a bug.
[22:35] <ronny> lifeless: as far as i got that i have to make a multi-branch repo and create multiple branches on different paths, and thats just not what i want to do
[22:35] <LarstiQ> lifeless: I want to find bugs in bzr? :)
[22:35] <fullermd> ronny: Well, I think it IS just monotone.  The others have multiple branches.
[22:36] <LarstiQ> ronny: bzr switch <sibling> ?
[22:36] <toytoy> guys how would i resolve the pending merges? or can i also abort that pending merges? this exist when i issue 'bzr status'
[22:36] <bpierre_> wouldn't the -r fix to update fix that?
[22:36] <bpierre_> being able to go back
[22:36] <LarstiQ> toytoy: normally, you'd commit them
[22:36] <fullermd> Not exactly.
[22:36] <ronny> LarstiQ: not really
[22:37] <fullermd> update -r fits different uses.
[22:37] <ronny> LarstiQ: not nearly as flexible
[22:37] <LarstiQ> ronny: then it isn't clear to me what you want to do.
[22:37] <bpierre_> fullermd: ?
[22:37] <toytoy> LarstiQ: oh yeah thanks i did and it's lost i thought it will still show :)
[22:37] <lifeless> toytoy: after you do a merge, you need to do a commit to action the merge
[22:37] <lifeless> toytoy: bzr stops after ocmbining the content, so you can review it
[22:38] <ronny> fullermd: well, in monotone multiple heads with the same name are pretty much 2 "branches", too they just happen to have the same name
[22:38] <fullermd> bpierre_: update -r lets you flind your WT around easily (and with better semantics for various things than using revert), but it's not the same as jumping among branches at all.
[22:38] <lifeless> bpierre_, ronny: perhaps a little detail will help. We have 3 objects:
[22:38] <lifeless> WT - your source code unpacked on disk, and some metadata such as the revision bzr set the tree to be
[22:38] <toytoy> lifeless: oh i see, thanks for that :)
[22:39] <fullermd> ronny: Not really; as far as mtn is concerned, it IS one branch.  Leads to some impressively large small differences.
[22:39] <lifeless> Branch - a tip in the revision graph, with attached user editable metadata like push-location, tags etc
[22:39] <bpierre_> well, my first concern is being able to switch revision, not branch, and being able commit on the same branch
[22:39] <fullermd> Anyway.  I do agree that branches being tied to directories makes a number of things more cumbersome.
[22:39] <lifeless> Repository - history store
[22:39] <bpierre_> but being able to switch a workspace to another branch could be handy too
[22:39] <fullermd> With a lot more support code, a fair bit of that could be papered over, but...
[22:40] <ronny> fullermd: well, from a technical point its just 2 heads in the dag with the same name tag, it works exactly the same in hg
[22:43] <lifeless> bpierre_: you can switch workspaces easily - the switch command does this.
[22:43] <lifeless> a shared history store gives you disk space optimisation, for large projects this is useful
[22:44] <lifeless> bpierre_: when you say commit on the same branch, do you mean 'manage branches roughly like mtn' ?
[22:45] <lifeless> wife calling, I'll be back in a bit. ronny - look into tags; they may do what you want [though using a single workspace N branches should do it too - I'd like to know the downsides]
[22:45] <bpierre_> well, what happen if I go back, and try to commit?
[22:46] <bpierre_> all on the same branch?
[22:46] <ronny> lifeless: i mostly want to deal with stuff like i do with git/hg, im not using mtn these days
[22:46] <bpierre_> isn't switch only part of the loom plugin?
[22:47] <GaryvdM> no
[22:47] <ronny> bpierre_: well, the dirstate has to be linked to the revision you are at, so you would create a new line of history thats to be merged at a later point
[22:47] <bpierre_> I really liked monotone, but conflicts were a pain, and bzr is so much faster
[22:47] <bpierre_> ronny: ok, that's what I want
[22:47] <bpierre_> how would I merge?
[22:47] <bpierre_> merge .
[22:47] <bpierre_> ?
[22:48] <ronny> if you got 2 heads, you would just merge, else yo'd have to refer to the revisions
[22:49] <bpierre_> how would revision number be constructed?
[22:50] <lifeless> ronny: well, git gives you a new ref in the same repository, which is equivalent to a separate branch in a shared repo in bzr
[22:50] <ronny> well, there are bzr's uuid's and bzr could also infer a local linear numbering (hg does that, works like a charm)
[22:50] <bpierre_> I have revnos 1 2 3 4 5, go back to 3 with update -r 3, commit
[22:50] <lifeless> ronny: have you tried this, and of so what didn't it do for you?
[22:51] <ronny> lifeless: i disliked the workflows of shared repos
[22:52] <lifeless> ronny: local linear numbering conflicts rather badly with concurrency
[22:53] <bpierre_> yeah
[22:53] <lifeless> so I think there are ~ 3 discussions going on here at once
[22:53] <lifeless> a) how to do what bpierre_ wants
[22:54] <lifeless> b) how to do what ronny wants, in a way that works for ronny
[22:54] <lifeless> c) some technical stuff about design/scaling etc
[22:54] <ronny> lifeless: you mean concurrent multiple writers to the repo?
[22:54] <lifeless> bpierre_: in the current design, if you want another line of development, you need a new branch object; branches in bzr are like branches in git in this way - they are not inferred, they are explicit references
[22:54] <lifeless> ronny: by concurrency - yes
[22:55] <ronny> hmk, nice
[22:55] <bpierre_> mmm
[22:55] <lifeless> bpierre_: branches are cheap though; I have a repo with ~12K branches, and it performs fine
[22:56] <bpierre_> the problem is more how a branch is tied to a directory
[22:56] <ronny> lifeless: any locks involved for stuff like tags? or completely lockfree?
[22:56] <lifeless> bpierre_: what about that gives you problems (damn, I sound like eliza)
[22:56] <bpierre_> I mean in monotone, there is a clear difference between the database, and a workspace
[22:56] <lifeless> ronny: tags are per-branch, and as such the branch-lock surrounds mutation to tags
[22:57] <ronny> ah, ok
[22:57] <bpierre_> each revision can have multiple branch certs, and monotone just try to follow the DAG for update operation
[22:57] <lifeless> ronny: so two branches can be pushed concurrently to the same repo, they don't conflict or collide
[22:57] <bpierre_> an complain if it find a fork
[22:58] <bpierre_> then you can reconcile multiple heads on the branch
[22:58] <fullermd> I've hit some ugly corners in mtn on that sort of thing, to be sure.
[22:58] <bpierre_> with bzr, a branch is tied to a directory, no?
[22:58] <fullermd> The flexibility is nice to have, though.
[22:58] <bpierre_> fullermd: what corners?
[22:58] <lifeless> bpierre_: yes, branches are tied to a directory, but you can consider that a user-accessible database if you like
[22:59] <lifeless> bpierre_: try this, just quickly, if you would:
[22:59] <fullermd> Well, to take one example, I propogated a change where there was no divergeance.  Only the head got the new certificate, so one side of the 'branch' wasn't connected.  mtn-viz had a total fit for somebody else.
[22:59] <lifeless> bzr init-repo --no-trees /tmp/bzr-db
[22:59] <bpierre_> my only real problem, was how you resolve conflict, with a use case where you have a simplifed project, and you propagate with new/modified files in a directory that don't exists anymory in the target branch
[23:00] <bpierre_> yeah, I could consider a no tree repo has my db
[23:00] <bpierre_> and then I can create has many branches
[23:00] <fullermd> (a lot of things about mtn bugged the snot out of me.  I don't particularly enjoy working with it.  But the multi-head capability makes doing daggy fixes REAL easy, and I miss that)
[23:00] <lifeless> bpierre_: right
[23:00] <bpierre_> which might be different revision of the same branch
[23:00] <bpierre_> logical branch
[23:00] <lifeless> bpierre_: trunk is one branch, and feature branches a,b,c
[23:01] <bpierre_> but, it's more work
[23:01] <bpierre_> than with monotone
[23:02] <lifeless> bpierre_: ok. I take it you've tried working with this?
[23:02] <bpierre_> btw, can you easily add custom certs/properties to a revision?
[23:02] <lifeless> there is a revision_properties facility
[23:02] <bpierre_> lifeless: multiple branches for each feature?
[23:02] <lifeless> we use it for recording branch nicknames and plugins use it for recording arbitrary things
[23:02] <bpierre_> ok
[23:03] <lifeless> bpierre_: multiple branches, switch between them, etc.
[23:03] <lifeless> bpierre_: I'm going out on a limb here, but are you trying to do 'daggyfixes' ?
[23:03] <bpierre_> no, but it is one use case
[23:03] <bpierre_> last time, I wanted to use the bisect plugin
[23:04] <bpierre_> to find a bug
[23:04] <bpierre_> which was a waste of time since it was a hardware bug on my project, but I disgrees, anyway, right know, what the plugin does is revert to a revision
[23:05] <bpierre_> so stat, show the differences with the tip of the branch
[23:05] <bpierre_> which is not practical
[23:06] <bpierre_> and might be tempted to fix it in the revision that introduced it, so yes, a daggyfix, no?
[23:06] <ronny> well, basically 2 things about branches suck, 1. dirstate is allways bound to the latest rev, 2. there is no way to have more than one head
[23:06] <ronny> i want to jump back to rev x, commit a fix, merge with head
[23:06] <bpierre_> also my tree is big, so all those operation take time/space
[23:06] <bpierre_> ronny: exactly
[23:07] <lifeless> bpierre_: switch is mostly O(difference), so total tree size and history are not really factors
[23:07] <awilkins> I found the dirstate bound to tip thing confusing
[23:07] <fullermd> 1. isn't true; there's just no real capability to manage it not being.
[23:08] <lifeless> yah, 1. is false, though bzr tries to keep it always the same to allow commit() to work
[23:08] <ronny> commit cant commit to revs that already have children?
[23:08] <lifeless> ronny: commit commits to the tip of a branch
[23:08] <bpierre_> ;(
[23:08] <fullermd> (which is to say, the dirstate can easily point at any rev in the branch history, but there's no way, sans deep hacking, to MOVE it to anywhere but the current tip)
[23:08] <lifeless> ronny: branch is defined as 'a tip'
[23:08] <ronny> uh, thats well bad
[23:08] <awilkins> Commit therefore makes a new tip
[23:09] <lifeless> ronny: so its a tautology
[23:09] <awilkins> So it should be able to make a new tip from any revision ; it already has done, for every revision before this one...
[23:09] <lifeless> oh
[23:09] <lifeless> terminology overlap
[23:09] <awilkins> You can certainly have multiple tips in a repo
[23:10] <lifeless> 'tip' here -> 'tip of the line of development', *NOT* 'a leaf node in the DAG'
[23:10] <awilkins> Or heads
[23:10] <lifeless> the DAG is unknowable, because its simultaneously distributed and disconnected
[23:11] <lifeless> its also O(history) to do anything with it that involves inferring 'unmerged' from the entire dataset. this simply doesn't scale well without complex caches or long critical-lock sections around insertions to the db
[23:11]  * mwh waves https://bugs.edge.launchpad.net/bzr/+bug/271924
[23:11] <lifeless> ronny: so if you change the branch tip and dirstate rev you can commit against *any* rev in your local database
[23:11] <mwh> around
[23:12] <bpierre_> ok
[23:12] <lifeless> this just mutates your existing branch - its what commit does, it mutates a branch to add a commit object to it, which is likewise inserted in to the repository
[23:12] <lifeless> (actually the ordering is 'new commit object in repo; update branch tip; update dirstate'
[23:13] <ronny> hmm, it generaly sounds a __lot__ more complicated to do in bzr, than it is in git/hg/monotone
[23:14] <lifeless> ronny: git is the same - create a new commit object (done by linking to the index), update the branch reflog and basis reflog
[23:14] <lifeless> ronny: hg is the same - insert content into all the modified revlogs, then the manifest revlog and revision revlog, then update the dirstate
[23:14] <lifeless> I haven't read the code for commit in monotone but I bet it is ~=
[23:15] <lifeless> we're having a deep technical discussion rather than one about getting you working well, because you seem to want to do that:)
[23:15] <ronny> well, bzr doesnt seem to allow me to work like i want
[23:16] <ronny> well, in hg i just do hg up -r rev; commit; merge
[23:16] <bpierre_> +1
[23:16] <ronny> in mtn i do the same
[23:16] <lifeless> ronny: so, question.
[23:16] <lifeless> ronny: if you do the first two commands, and someone clones you, what do they get ?
[23:17] <ronny> 2 heads
[23:17] <lifeless> ronny: and how do they know which one really represents the branch ?
[23:17] <lifeless> (vs being an experiment that failed)
[23:17] <ronny> both do
[23:17] <bpierre_> they don't
[23:18] <lifeless> bingo, that confusion is exactly my point
[23:18] <bpierre_> know which one is best, an experiment
[23:18] <lifeless> in bzr we don't have that, because the branch tip is well defined at all times
[23:18] <ronny> well
[23:18] <bpierre_> yeah, but with a process, a common location with a gatekeeper
[23:19] <bpierre_> where is the problem?
[23:19] <abadger1999> There very often isn't a good process or a gatekeeper.
[23:19] <ronny> people cant pull my local repos, no problem, i wont push before the merge
[23:19] <lifeless> bpierre_: what if the gatekeeper does that ? :P Or more pragmatically, consider shared branches, where there are many gatekeepers
[23:19] <bpierre_> also, a good use case with multiple heads, is being able to commit on one machine, push to another, and do the merge on the second one
[23:19] <lifeless> bpierre_: you can do that with bzr just fine
[23:20] <ronny> also pushing is pretty much prohibited without explicit force if there are more than 1 heads as a result
[23:20] <bpierre_> you have to create another branch, no?
[23:20] <ronny> so remote branches are well-defined
[23:20] <bpierre_> you can't push if you have diverged
[23:20] <lifeless> bpierre_: no, though its the simplest way IMO
[23:20] <ronny> i just want to do what the heck i want locally
[23:20]  * abadger1999 often works on git repos where there's multiple branches with no well defined method of finding which a given piece of work should be done on.
[23:20] <bpierre_> lifeless: how do you it without a new branch?
[23:20] <abadger1999> I note that it's a social problem though... launchpad makes the same thing happen to collections of bzr branches.
[23:21] <lifeless> bpierre_: bzr push, ignore the error about divergence, bzr heads on the other machine, bzr merge . -r <head you want>
[23:22] <bpierre_> wait, push will have pushed the revisions?
[23:22] <lifeless> bpierre_: though I prefer to just make a new branch when I have that situation, it remembers it for me then
[23:22] <lifeless> bpierre_: yes, the repository will have them, they just aren't reference from the branch
[23:22] <bpierre_> mmm, but you have to remember the revid
[23:23] <lifeless> bpierre_: thats what heads will tell you, and heads --dead only lists unmerged heads
[23:23] <bpierre_> ok
[23:23] <lifeless> what I like about separate branches is that they are cheap, they are easily managed (I can have arbitrary number of pending-review, pending-merge, in-progress, etc)
[23:23] <lifeless> by cheap I mean no workspace
[23:23] <lifeless> and no separate history store
[23:24] <awilkins> Does uncommit mark revisions?
[23:24] <lifeless> as for the use case of 'make a new branch from an arbitrary rev', well - I think bisect can definitely be improved; there already is 'bzr branch -r XXX' to make a branch @ a rev
[23:24] <awilkins> Because one thing I found is that "heads" is really fouled by uncommits
[23:24] <lifeless> awilkins: If I understand you correctly, no
[23:25] <fullermd> Branches being directories does necessarily make them heavier weight than ref-based branches, though.
[23:25] <bpierre_> yeah, but you don't want a new workspace for each revision you try
[23:25] <lifeless> awilkins: that would be nice wouldn't it. needs some thought
[23:25] <awilkins> It would be nice if uncommit marked a rev as having been uncommitted
[23:25] <lifeless> fullermd: yes, but thats the same weight as git and svn and cvs and a few others besides
[23:26] <bpierre_> although, you could cheat with a new branch, cloning the tip, and then pull --overwrite -r ?
[23:26] <fullermd> No (well, maybe svn/cvs, but I don't count them)
[23:26] <fullermd> I don't mean heavier technically; I mean heavier psychologically.
[23:26] <fullermd> You have to switch a lot more gears.
[23:26] <fullermd> There needs to be a whole lot more UI magic happening to make dir-based branches seamless in a way that ref-based are naturally.
[23:26] <lifeless> fullermd: mmmm, I don't see why; single tree, switch between, branches to list, push-repo, modulo bugs
[23:26] <lifeless> fullermd: please define 'ref-based'
[23:27] <fullermd> Well, ref-based can be dir-based, but meaning managed entirely by the tool behind your back.
[23:27] <lifeless> bpierre_: yes, new branch, pull --overwrite -r X, should be fast
[23:27] <awilkins> branch-and-switch would cover a lot of it
[23:27] <fullermd> Consider the case: I have my branch of $PROJ.  You suggest a branch I should merge in.
[23:27] <lifeless> fullermd: ok
[23:28] <fullermd> If bzr were ref-based, I could "bzr branch $NEW beblatz ; bzr switch beblatz ; <check stuff> ; bzr switch mine ; bzr merge beblatz ; bzr ci"
[23:28] <fullermd> But with dir based, I can't do that directly; I have to switch to knowing about the filesystem, and "bzr branch $NEW /wherever/my/repo/is/beblatz", etc.
[23:28] <lifeless> fullermd: but you can do that today, with one change:
[23:28] <fullermd> Ditto when I'm done, and can "bzr rm-branch beblatz" instead of "rm -rf /some/where... crap, where is that..."
[23:29] <lifeless> "bzr branch $NEW ../beblatz ; bzr switch beblatz ; <check stuff> ; bzr switch mine ; bzr merge ../beblatz ; bzr ci"
[23:29] <lifeless> fullermd: have you tried the switch branch-finding heuristic?
[23:29] <fullermd> No, because I don't generally work that way.  But until it's a branch branch-finding heuristic and a merge branch-finding heuristic and a diff branch-finding heuristic...   it means you're switching a lot of gears.
[23:29] <LarstiQ> so right now, switch is the only command that has the ref-behind-your-back heuristic, afaik
[23:30] <bpierre_> switch is provided in 1.7?
[23:30] <lifeless> fullermd: note that for hg, you have to rollback to decide you didn't like it, which is fugly, for git you need a branch-name, (so its system-managed, and thats nice)
[23:30] <fullermd> I don't claim that dir-based branches are _inherently_ psychologically heavier, but there needs to be a lot of UI magic to make them FEEL the same weight.
[23:30] <lifeless> fullermd: oh, I agree, the heuristic needs to be pervasive
[23:30] <lifeless> fullermd: I was asking if you had tried it
[23:30] <lifeless> bpierre_: switch is single, um, 0.92 or something; been in for ages
[23:31] <bpierre_> ah
[23:31] <lifeless> bpierre_: what we're talking about here, is a heuristic where switch will look for branches in oldbranch/../, which means less typing for you
[23:31] <fullermd> Unfortunately, it's a lot like the performance question, in a way.
[23:31] <lifeless> bpierre_: but other commands don't yet do that
[23:31] <fullermd> It's not "bzr can't", but "bzr presently doesn't".
[23:32] <fullermd> And each side of the question is going to put a very different emphasis on that phrase   :|
[23:32] <fullermd> Being branch-based we have an inherent [not insoluble, but] problem, in that we HAVE to have that heuristic.
[23:33] <lifeless> how many paths does mysql have in it ?
[23:33] <fullermd> And it's a lot of places to sprinkle it.  Even if we get all the commands, then we have branch: and ancestor: and such revspecs to handle too.  And then there are plugins...
[23:33] <bpierre_> I can live with the typing, it's just that the use of checkout can sometime be confusing (at least to me) so I didn't think about using it with a regular (disconnected) branch
[23:33] <bpierre_> (after reading the help for switch)
[23:33] <fullermd> Heck, look how long it's taken us (still taking?) just to get all the commands to understand the metadir format, and stop demanding WT's when they don't need them, etc.
[23:34] <fullermd> (not that that's in any real way related to the issue, just the same on some level in the amount of distributed assumptions)
[23:37] <awilkins> I agree, I keep finding myself wishing that merge had the same sibling-heuristic as switch (and that someone would merge my sibling finding patch for switch)
[23:37] <bpierre_> wait, switch only work for a checkout ...
[23:37] <awilkins> bpierre_: Yes, but the sibling heuristic only works on lightweights
[23:37] <awilkins> bpierre_: My patch fixes it so it works on eavies too
[23:37] <bpierre_> sibling?
[23:38] <awilkins> brother, sister
[23:38] <ronny> well, basically the workflow enfocements and the speed issues basically make me avoid bzr for all of my own projects
[23:38] <jam> lifeless: so I have an idea of what is causing the auto-pack problem. And it *is* related to the cherrypicking, but only tangentially
[23:38] <awilkins>  bzr switch sibling   ==   bzr switch <my bound branch>/../sibling
[23:38] <LarstiQ> bpierre_: repo/{foo,bar}, cd foo, switch bar == switch ../bar
[23:38] <bpierre_> I guess lightweigts is ok, I think I'm starting to understand how you use it lifeless
[23:39] <bpierre_> LarstiQ: yeah, just syntaxic sugar
[23:39] <bpierre_> :P
[23:39] <LarstiQ> bpierre_: exactly
[23:39] <jam> lifeless: consider if we have packs of 10*9, and one of 1, and then we fetch another pack of 19. This will trigger an autopack, and try to create a pack of 100, 10. It can fill the 100 one from all the large packs
[23:39] <jam> and the size 1 pack gets "promoted" to size 10, but there is nothing else to put in with it
[23:39] <jam> Anyway, I'll poke at it more, but I think it is something worth trying out.
[23:40] <awilkins> I think BB needs some work. 'tis down again. Does it do many hardworking things?
[23:41] <bpierre_> so you create a repo, with x no tree branches, and then you work with one checkout of those branches, which you can then switch depending on your activity, right?
[23:41] <awilkins> bpierre_: That's it
[23:41] <bpierre_> thanks
[23:41] <bpierre_> :D
[23:41] <awilkins> bpierre_: Rather the same as git, only the branches are out there in the filesystem for you to look at
[23:41] <bpierre_> yeah
[23:42] <awilkins> (can git do hierarchical branch organization by the wa?)
[23:42] <fullermd> I don't think as such, but you can mostly fake it via naming.
[23:42] <lifeless> jam: ok.
[23:42] <lifeless> jam: it may help to simplify things there, I realised a while ago that autopack should be a little simpler.
[23:42] <fullermd> We fake naming via hierarchy; they fake hierarchy via naming   ;)
[23:43] <awilkins> fullermd: You can just move those folders around, right?
[23:43] <bpierre_> and if I want do to a daggyfix, I can just push -r to clone at a revision, and switch to it, than back to where I was, and merge?
[23:43] <awilkins> fullermd: As long as they stay in the repo?
[23:43] <lifeless> jam: specifically, rather than going for N packs of specific sizes, when we were past a pack boundary, it should (still using the 1, 10, 100 etc logic - thats fine), just calculate the ones it wants to combine, and output one single big pack
[23:43] <fullermd> In bzr, you mean?  Sure.
[23:43] <lifeless> jam: e.g. rather than making a 100, and a 10, it would just make one of 110
[23:43] <jam> lifeless: sure
[23:43] <awilkins> Only thing it screws with is the bindings
[23:44] <Odd_Bloke> D'oh, poolie's not around.
[23:51] <jam> lifeless: triggered it
[23:51]  * fullermd scampers off to a meeting.
[23:51] <jam> now I need a simpler test case :)
[23:53] <lifeless> bbiab, food
[23:58] <poolie> hello
[23:58] <Odd_Bloke> poolie: Hey.
[23:58] <poolie> hello
[23:58] <Verterok> poolie: hi
[23:58] <jam> lifeless: instructions on how to get it to fail easily are on bug #242510
[23:59] <Odd_Bloke> poolie: I'm afraid I can't really chat now. :(


[03:20] <ojwb> hi, I'm trying to download hardy-dvd-i386.iso using jigdo, but it's ended complaining 150 files could not be downloaded
[03:21] <ojwb> e.g. http://archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/ubiquity-frontend-gtk_1.7.2_i386.deb
[03:21] <ojwb> looking in that directory, there are older versions, and 1.7.3
[03:26] <LaserJock> ojwb: does jigdo download the .debs directly?
[03:26] <ojwb> essentially, yes
[03:27] <LaserJock> I would think it'd download the .iso
[03:27] <ojwb> I tried, but it was awfully slow
[03:27] <ojwb> so I gave up and used jigdo
[03:27] <ojwb> which is much faster
[03:27] <LaserJock> hmm
[03:27] <LaserJock> well that would be odd to me
[03:27] <LaserJock> since packages come and go
[03:27] <ojwb> it has splits the DVD up into all the bits it can get from packages (which it gets from the archive) and everything else (which is in a ~700MB "template")
[03:28] <ojwb> it does rely on the packages being available
[03:28] <LaserJock> perhaps a torrent would work better
[03:28] <ojwb> given the jigdo template was in an official download directory, I assumed they'd be stable
[03:28] <ojwb> given I've just downloaded ~4GB, I'd really like to get this to work
[03:28] <ojwb> I did try the torrents, but nobody was seeding them
[03:29] <ojwb> unless I can somehow get the torrent to "fill in the gaps"
[03:32] <ojwb> aha!
[03:33] <ojwb> it seems I can just use rsync to fill in the gaps
[03:33]  * ojwb tries
[03:53] <ojwb> that seemed to work until the disk filled up (d'oh!)
[04:24] <ojwb> cool, that worked
[04:24] <ojwb> just in case anyone else hits the same problem, I got the answer here:
[04:24] <ojwb> http://tldp.org/HOWTO/html_single/Debian-Jigdo/#AEN384
[04:25] <ojwb> anyway, bedtime for me
[09:15] <bunset1> hello, i am not able to start using ubuntu without some help
[09:16] <bunset1> anyone would to help me please ?
[09:17] <bunset1> I am with hp 510 notebook and ubuntu gutsy, having problems to understand wireless configuration
[09:18] <bunset1> after restarting I have to reconfigure wep params to connecting
[09:18] <bunset1> Im glad if someone wants to help me.
[09:36] <johnny> what method are you using? the applet ?
[09:36] <johnny> afaik, it should save the settings, and then only ask for keyring password and not make you reconfigure
[09:36] <johnny> if it doesn't.. i don't know why, and my ubuntu box is unavailable to test
[12:48] <danishka> hi
[12:48] <danishka> I would like to contribute to edubuntu l10n
[12:49] <danishka> pls assist me to start the work