[00:31] <Noskcaj> phillw, ping
[00:34] <phillw> Noskcaj: present...
[00:35] <Noskcaj> phillw, i just had a look at the lubuntu wikipedia page, you might want to look over it. https://en.wikipedia.org/wiki/Lubuntu
[00:35] <Noskcaj> is beta 2 12.10 still the current unstable release?
[00:36] <phillw> I'll go have a read, I do not maintain that page.
[00:37] <phillw> Noskcaj: as you may have seen on ##phillw I'm currently working with JasonO to prep the pages for 13.04 :)
[00:37] <phillw> feel free to join in :)
[00:37] <Noskcaj> i will soon
[00:42] <phillw> Noskcaj: I only skim readed that article, where does it state that?
[00:42] <Noskcaj> in the info box in the top right
[00:46] <phillw> found it :) Just logged on and edited it :)
[06:34] <pitti> Good morning
[07:47] <jibel> good morning
[07:48] <dholbach> good morning
[12:21] <xnox> jpds: you made me chuckle with latest quote ;-)
[12:22] <jpds> xnox: wrong network.
[12:22] <xnox> jpds: I have no idea which channel/network it was. Just a first channel I knew you would be on ;-)
[19:09] <njin> balloons, hallo
[19:09] <balloons> njin, hello!
[19:10] <njin> can you please take a look if it is right ?  https://code.launchpad.net/~fabiomarconi/ubuntu-manual-tests/Netboot_Install_Desktop
[19:10] <njin> balloons, ^^
[19:11] <njin> finally netbook is working
[19:11] <balloons> njin, looks pretty good
[19:12] <njin> balloons ok, thanks
[19:12] <balloons> I'll merge in.. njin Noskcaj10 can you look at what is on the tracker now for netboot?
[19:13] <balloons> I want to make sure there are testcases assigned properly for everything, etc
[19:13] <Noskcaj10> ok
[19:13] <njin> balloons, now for amd64 netboot install desktop there's the arm testcase
[19:13] <balloons> just a moment this netboot desktop case will also be in there
[19:13] <balloons> then we can get them all lined up properly :-)
[19:15] <Noskcaj10> balloons, every precise testcase is outdated except ppc
[19:20] <balloons> k, test is up
[19:20] <balloons> where does it need to go
[19:20] <njin> great
[19:20] <balloons> Noskcaj10, we'll fix precise after we get raring set
[19:20] <balloons> I'll just mirror it
[19:21] <balloons> ok, so I see this old testcase 	Netboot Install (Desktop)
[19:21] <balloons> err, sorry, http://iso.qa.ubuntu.com/qatracker/testcases/1452/info
[19:22] <njin> balloons, still FAMILY not converted ?
[19:22] <balloons> should we move it to armel
[19:22] <balloons> njin, it converts on the test result screen
[19:23] <balloons> on the info screen it will show family
[19:23] <balloons> no worries :-)
[19:23] <njin> balloons, the Netboot install (Desktop) is the new testvcase not the old
[19:23] <balloons> yes.. the id 1452 is the old one
[19:23] <balloons> we need to move it to only being present for which images?
[19:23] <balloons> Netboot armel+omap
[19:24] <balloons> and the armhf images?
[19:24] <balloons> also, this netboot install server is wrong too
[19:24] <balloons> http://iso.qa.ubuntu.com/qatracker/testcases/1453/info
[19:24] <njin> the test i write is for desktop, not for arm
[19:25] <balloons> yes, exactly.. so we'll need to rename the old one to say it's for ARM
[19:25] <njin> oh, ok
[19:25] <balloons> :-)
[19:27] <balloons> so let me try fiddling here.. in a min I'll have you 2 look and confirm things
[19:28] <njin> now needs to update the JeOS case
[19:28] <balloons> question -- can ppc share the same testcases as i386/am64?
[19:31] <Noskcaj10> balloons, the very start is slightly different, i believe the rest is the same
[19:34] <njin> good night, I go sleep
[19:35] <balloons> k, how does it look now njin, Noskcaj10 ?
[19:35] <Noskcaj10> seems good
[19:36] <balloons> so the question I have is can netboot ppc share the other tests that i386 and amd64 share?
[19:36] <njin> good for me too
[19:38] <balloons> if so, I'll add them to the testsuite.. at the moment, it has it's own testcase special to ppc
[19:38] <balloons> which is ok if it's needed
[19:38] <balloons> Noskcaj10, also, precise should be fixed
[19:38] <Noskcaj10> :)
[19:45] <balloons> so exciting.. netboot is in good shape
[19:51] <Noskcaj10> balloons, now we just need to get it (and kylin) into testdrive
[20:01] <Letozaf_> balloons, hey
[20:12] <balloons> Letozaf_, howdy
[20:12] <balloons> Noskcaj10, did you file a bug to get them into testdrive/
[20:12] <balloons> ?
[20:12] <Letozaf_> balloons, fine and you ?
[20:13] <Noskcaj10> balloons, yeah. i'll find the number now
[20:13] <balloons> Letozaf_, trying to prep everything for ubuntu unity testing
[20:14] <Letozaf_> balloons, oh, fine!
[20:14] <Letozaf_> balloons, I was working on file-roller autopilot test, got stuck
[20:14] <Letozaf_> balloons, I was wondering If I could push it to ubuntu-autopilot-tests so you can take a look at it when you are not too busy
[20:14] <balloons> Letozaf_, sure
[20:15] <balloons> at this point, consider trunk open once something is in a semi-usable state
[20:15] <Noskcaj10> bug 1095432
[20:16] <Letozaf_> balloons, ok i will push it
[20:16] <Noskcaj10> bug 1077158
[20:18] <balloons> Noskcaj10, excellent.. at least there on the list
[20:19] <Noskcaj10> balloons, testdrive hasn't had a bug fix for two years, except the Vbox4. 2 one
[20:21] <balloons> Noskcaj10, yes.. but it's on the list.. so it's at least noted
[20:21] <Noskcaj10> true
[20:31] <Letozaf_> balloons, file-roller test pushed :)
[20:31] <balloons> :-)
[21:32] <Letozaf_> balloons, I was reading about the hackfest automated tests and wanted to pick thunderbird but if you run 'autopilot launch thunderbird' you get an Error: Cannot auto-detect introspection plugin to load
[21:32] <balloons> Letozaf_, hmm
[21:32] <balloons> Letozaf_, well, you could force it to load gtk
[21:32] <Letozaf_> balloons, how ?
[21:35] <balloons> autopilot launch --help
[21:35] <balloons>   -i {Gtk,Qt,Auto}, --interface {Gtk,Qt,Auto}
[21:36] <balloons> so try -i Gtk
[21:36] <Letozaf_> balloons, :P thanks
[21:36] <balloons> if it doesn't work then :-(
[21:36] <balloons> blame thomi like always.. haha!
[21:37] <Letozaf_> balloons, it works!
[21:37] <balloons> excellent
[21:37] <Letozaf_> balloons, mmm
[21:38] <Letozaf_> balloons, I saw this just now:  Gtk-Message: Failed to laod module "autopilot"...
[21:38] <Letozaf_> balloons,  will I have to blame thomi ?
[21:40] <balloons> Letozaf_, ahh.. perhaps.. it might also just prove to not be possible
[21:40] <balloons> qt apps are much nicer in this regard.. I believe they almost universally work without issue
[21:42] <Letozaf_> balloons, so no thunderbird test!
[21:42] <balloons> might be the case..
[21:42] <balloons> i'd have to look
[21:42] <balloons> and we can tomorrow ;-)
[21:43] <balloons> we'll finalize a yes/no answer
[21:43] <Letozaf_> balloons, sure!
[21:43] <balloons> but yes, it appears if might not be possible atm
[21:43] <Letozaf_> balloons, anyway it's late for me ... so I will be back tomorrow :)
[21:43] <balloons> Letozaf_, sure thing
[21:44] <balloons> see you tomorrow night!
[21:44] <Letozaf_> balloons, ok, good night!
[23:18] <SergioMeneses> hi all


[00:04] <greg-g> bdmurray: bug 185543 which has 70 some odd duplicates, was converted into a question by a user asking a question.  But, it shouldn't be a question.
[00:04] <ubotu> Launchpad bug 185543 in system-config-samba "system-config-samba.py crashed with SystemError in __init__()" [Undecided,Invalid] https://launchpad.net/bugs/185543
[00:05] <bdmurray> greg-g: that's a new one
[00:06] <greg-g> yeah, I was confused for a second why it was a question.
[00:06] <bdmurray> look at this "Convert back to bug"
[00:07] <greg-g> oh, hah!
[00:07] <bdmurray> That is probably be worth documenting
[00:07] <greg-g> yeah, hmm, how should I word this
[00:10] <greg-g> "Converting back into a Bug as this issue is a bug, not a support request.  For support requests please file a question at https://answers.launchpad.net/ubuntu"
[00:10] <greg-g> or something similar
[00:11] <bdmurray> The comment is optional and I wouldn't want to spam that many people
[00:11] <bdmurray> It might not notify them w/o a comment
[00:11] <greg-g> ah, ok, good point
[00:13] <bdmurray> I think the conversion process to a question and back needs some documenting though
[00:14] <greg-g> probably
[00:31] <bdmurray> greg-g: were you subscribed to that bug at all?  I wonder if everyone will get question and bug e-mail now.
[00:40] <greg-g> bdmurray: I wasn't.  And I decided not to subscribe since there was going to be a lot more mail most likely :)
[00:40] <greg-g> in retrospect, yes, I should have
[00:56] <danage> is it a known bug in gvfs that on ftp servers, you cannot delete entire directories including all their content?
[00:58] <pedro_> danage: that works fine for me, which ftp server are you using?
[00:58] <pedro_> is there anything on the logs of the server?
[00:58] <danage> i think filezilla
[00:59] <danage> let me check real quick
[00:59] <pedro_> sure
[01:00] <danage> ok here is what happens: "preparing delete" under file operations. it fetches the number of the files. Then: Couldn't remove the folder XYZ. under more details then: directory not empty
[01:00] <danage> i skip all
[01:00] <danage> look inside the directory and suprise: it is empty
[01:03] <danage> i shall file a bug report
[01:03] <danage> seems like a release critical behavior
[01:04] <danage> http://bugzilla.gnome.org/show_bug.cgi?id=522933 might be related
[01:04] <ubotu> Gnome bug 522933 in ftp backend "copying or deleting a directory leads to a file not available error" [Normal,Unconfirmed]
[01:04] <pedro_> is that the same error you're getting?
[01:04] <danage> no
[01:05] <danage> i should file a bug report, i think
[01:05] <danage> this has been going on
[01:21] <danage> ok i filed a bug report, #217975
[01:21] <danage> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/217975
[01:21] <ubotu> Launchpad bug 217975 in gvfs "Cannot delete folders on FTP" [Undecided,New]
[01:24] <lifeless> is there a hidden ('.' prefixed) file in that directory?
[01:48] <danage> lifeless: let me check
[01:49] <danage> lifeless: no, empty even when i turn on "show hidden files"
[01:51] <danage> ok now this is strange
[01:51] <danage> the directory isn't empty!
[01:51] <danage> i just connected with firefox
[01:51] <danage> and it shows a couple of files in the folder
[01:51] <danage> gvfs doesn't!
[01:52] <danage> (the files don't start with .(something))
[01:52] <danage> is there some kind of directory cache?
[01:58] <lifeless> I don't know sorry
[02:34] <saivann> lifeless : I can reproduce it there too
[02:35] <saivann> nautilus does not show files with filenames that start with . , even when it is configured to show hidden files, so I can't delete the folder unless I take filezilla to delete the hidden file before.
[02:44] <lifeless> saivann: sounds like a bug in its use of ftp
[02:46] <saivann> lifeless : I'm currently writing a detailed list of steps to reproduce the bug. Seems that nautilus is not able to access hidden files through gvfs FTP plugin..
[02:48] <danage> hmm... my files aren't even hidden and it doesn't show it
[02:49] <saivann> danage : do you have files that does not start with . that are not shown with nautilus?
[02:49] <danage> exactly
[02:49] <danage> they are shown with firefox though
[02:49] <saivann> danage : Really!
[02:49] <danage> yes
[02:50] <danage> is there some sort of cache?
[02:50] <saivann> well that's really strange
[02:50] <danage> that i might need to wipe out
[02:50] <danage> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/217975
[02:50] <ubotu> Launchpad bug 217975 in gvfs "Cannot show/delete hidden files or delete folders that contains hidden files on FTP" [Low,Confirmed]
[02:50] <saivann> danage : I don't know, but you might try the "reload" button
[02:51] <danage> same behavior
[02:51] <saivann> danage : Ho sorry, I did not read your description correctly "do not have a . in front of them"
[02:52] <danage> the problem might be related though
[02:52] <saivann> danage : I though that you said "do have a . in from of them"
[02:52] <danage> i could point that out more clearly
[02:52] <saivann> danage : maybe, can you give me a list of filenames that does not appears in your case? Just to test it
[02:52] <lifeless> FTP can hide files
[02:53] <lifeless> there are protocol options to say list all
[02:53] <danage> yes, sec
[02:54] <danage> /Music/will be deleted soon/Ada - Blondie/
[02:54] <danage> folder name
[02:54] <danage> 02 - Ada - Cool My Fire (I'm Burning).mp3
[02:54] <danage> filename
[02:54] <danage> this one didn't get deleted
[02:54] <danage> AND doesn't show on nautilus list
[02:55] <danage> it's not the () though, other files don't show either
[02:55] <saivann> danage : Interesting, let me try
[02:58] <saivann> danage : It does not show for me either
[03:00] <saivann> danage : Remove all "-" from the filenames, does it show?
[03:06] <danage> hm i have no other ftp client
[03:06] <saivann> danage : If it's possible for you, you can install filezilla
[03:07] <saivann> sudo apt-get install filezilla
[03:07] <danage> will do, just a second
[03:07] <saivann> danage : Great, thanks
[03:08] <danage> the funny thing though is: some files in that folder had all the - - - 's
[03:08] <danage> and DID show and DID get deleted
[03:08] <saivann> danage : Wow, really weird :P
[03:08] <danage> will you be able to fix it?
[03:10] <saivann> danage : Actually not me but more the bug report is detailed and clear and well reported, more developers will be able to do a great job. I aim to make this job as simple as possible and to report this to the right people so it can be fixed as fast as possible
[03:10] <saivann> danage : Testing is always good :)
[03:10] <danage> yeah, let's narrow this one down
[03:10] <danage> in my opinion, it's release critical
[03:13] <danage> we shoiuld probably make separate bugs out of these
[03:13] <danage> 1) the hidden files
[03:14] <danage> 2) tbd.
[03:15] <saivann> danage : According to https://wiki.ubuntu.com/Bugs/Importance , I believe that low is a correct priority. Anyway the priority is not the more important point, good bug description is what will really help the bug getting fixed
[03:15] <saivann> danage : tbd? What is tbd?
[03:15] <danage> :) to be determined
[03:15] <saivann> danage : s/low/medium/ , sorry
[03:15] <saivann> ah :D
[03:16] <saivann> danage : Finally did you try without the "-" ?
[03:16] <danage> sec
[03:16] <saivann> ok
[03:17] <danage> suspense....
[03:18] <saivann> hehe
[03:18] <danage> ok removing the "0" didn't help
[03:18] <danage> dash next
[03:19] <danage> one -: nothing happens
[03:19] <saivann> danage : You really know how to create suspense :
[03:19] <danage> 2: success
[03:19] <danage> it shows now
[03:19] <danage> wtf
[03:19] <danage> strange bug
[03:19] <danage> let me fiddle around a bit
[03:20] <saivann> danage : That's what I thought!! I think that I just found why some files worked while other did not, try to put a - at the beginning of the filename without spaces, in my case the file appears in nautilus
[03:20] <danage> the file fjhdkjhkj-- shows
[03:20] <saivann> danage : exactly
[03:20] <danage> it's the space and the -?
[03:20] <saivann> danage : Then the problematic character is "- " or " -"
[03:20] <danage> ah
[03:20] <saivann> danage : Apparently
[03:21] <danage> funny
[03:21] <danage> let's narrow it down further
[03:21] <saivann> danage : Like you suggested, can you open a new bug report for that?
[03:21] <danage> also: does it also affect directories?
[03:21] <danage> yes i can
[03:21] <saivann> danage : Interesting point
[03:21] <danage> we will change the existing one to include your info onl
[03:21] <danage> y
[03:21] <saivann> danage : No, Ada - Bloundie shows
[03:22] <danage> ah you are already
[03:23] <saivann> danage : Perhaps you can modify the description of the first bug report to speak only about the "dot" since it might be a different issue than the "- " one. I also wonder if other characters cause this kind of issues
[03:23] <danage> i just changed it- check it out
[03:23] <danage> i think it could stay like this
[03:23] <danage> now, i will open a new report
[03:24] <danage> it might be (space) - (space)
[03:24] <danage> yes, it is not " -"
[03:24] <saivann> danage : Yes that's fine IMO, anyway my steps are sufficient and the bug is evident so..
[03:24] <saivann> danage : really? Thanks for finding this out
[03:26] <danage> ok here is what i have: no problem are: " -", "- ", "--" and " - "
[03:26] <danage> occurring ONCE
[03:26] <danage> WTF???
[03:26] <danage> hfds - hjkd - hgfjhkd
[03:26] <danage> works!
[03:27] <danage> where is the friggin difference?
[03:27] <saivann> danage : Yes... I'm also finding almost the same strange behavior with nouveau - fichier
[03:27] <danage> t'es fraincais`
[03:27] <danage> francais
[03:27] <saivann> danage : ouep :)
[03:27] <danage> :)
[03:27] <danage> canadien?
[03:28] <danage> parce que c'est un peu tard en france a ce moment
[03:28] <saivann> danage : Oui, et toi Francais de France?
[03:28] <danage> non, allemand mais j'habite en californie
[03:28] <saivann> danage : Hehe, ici c'est presque tard
[03:28] <saivann> danage : J'adore internet :)
[03:28] <danage> ok so should i just put the original filenames that i have problems with in the bug report?
[03:29] <danage> whoever wrote the code will prolly know much quicker
[03:29] <saivann> danage : If you still have some time, I believe that looking at this deeper can be helpful
[03:29] <saivann> danage : Well the actual filename is enough yes, we can add more comments later if we find interesting new stuff
[03:30] <danage> yes
[03:30] <danage> let me know what i should do
[03:30] <danage> https://bugs.launchpad.net/bugs/211748
[03:30] <ubotu> Launchpad bug 211748 in gvfs "gvfs can't list hidden files through ftp" [Low,Invalid]
[03:31] <danage> ???
[03:33] <saivann> danage : Well... that would really be awful if it's true, but since it works with filezilla and not nautilus, I doubt that this bug is really invalid
[03:33] <danage> me too
[03:34] <saivann> danage : And in my case, the FTP server is ProFTPD
[03:34] <danage> try this one: 05 - fdf - fdfsd fdfsd fdsfs.mp3
[03:34] <danage> it will list!!!
[03:34] <saivann> danage : Maybe Capital letters?
[03:34] <danage> maybe
[03:36] <saivann> danage : 02 - F'm Nouveau Test Test Test Test.mp3 does not work
[03:36] <danage> hm
[03:36] <danage> wtf
[03:36] <saivann> danage : The name seems to be limited in lenght
[03:36] <danage> ah
[03:37] <danage> or it's the spaces
[03:37] <danage> 05 - fdf - fdfsdfdfsdfgsdfgsdfgsddsfsFdfs.mp3
[03:37] <danage> works!
[03:39] <saivann> danage : 02 Fm test test test setse Nouveau Test Test Test Tesddt.mp3 does not works. My understanding is that it's probably more the lenght of the filename that cause the problem then the special characters, special characters only get really long when they get translated and cause the real filename to exceed the limit
[03:39] <saivann> danage : I don't know what you think about that theory :)
[03:40] <danage> special characters get three digits right?
[03:40] <danage> %20 for spacew
[03:40] <danage> for example
[03:40] <danage> i am submitting it now
[03:40] <danage> let's see what happens
[03:40] <danage> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/218010
[03:40] <ubotu> Launchpad bug 218010 in gvfs "Certain filenames on FTP don't list in Nautilus" [Undecided,New]
[03:42] <saivann> danage : great, your theory is better than mine, fgdfgklsdfklgjsldfgjsldfgnjsldfkgnjsldfkgnjsldfkgnjsldfjkgndjsafgjkaseyfgksaerjfgykaerjyfjkdsjkdfjkjkjkdgjkdgdgnogslgngsrdkubgsdlrgbskljghkergt.mp3 show correctly :) Spaces might be a part of the problem
[03:43] <saivann> Testing this bug is kind of funny
[03:43] <danage> yeah
[03:43] <danage> make sure to add it to the description
[03:43] <saivann> and d d d d d d d d d d d d d d d d d d.mp3 does not show!
[03:44] <saivann> danage : I believe that our bug report will show really relevant informations :)
[03:44] <danage> and i want sebastien to fix it tomorrow!!!!!
[03:44] <danage> hahahah
[03:44] <danage> so it's not the uppercases either
[03:44] <danage> and not the "-"
[03:44] <saivann> danage : Hehe, Sebastian is so active, that's incredible
[03:45] <saivann> danage : Apparently not..
[03:46] <saivann> danage : No, the real problem is : More than 7 spaces in filename does not show
[03:46] <saivann> danage : Your guess was right
[03:47] <danage> i count >6
[03:47] <saivann> danage : Oh yes, sorry
[03:47] <danage> ok
[03:47] <danage> let me put it in description
[03:47] <saivann> danage : Now THAT is accurate :)
[03:48] <danage> good job
[03:48] <saivann> yes!
[03:49] <danage> nice and short
[03:49] <danage> please confirm and set priority
[03:50] <danage> ok now it's perfect
[03:50] <saivann> yep!
[03:51] <greg-g> wow, well done! :)
[03:51] <saivann> thanks for your great testing on this :)
[03:51] <danage> sure
[03:51] <danage> you know, with open source i see it like this: if i want it to work, why don't i make it to work
[03:52] <danage> and if i can't: why don't i kindly ask someone to make it work and giving him the easiest time fixing it
[03:53] <danage> should we mark 217975 as double of the invalid one?
[03:53] <saivann> danage : sure, I really agree
[03:54] <saivann> danage : I prefered to add a little notice in the bug description about it
[03:54] <danage> ok
[03:54] <saivann> so Sebastian will see it at the first look
[03:54] <danage> ok
[03:54] <danage> i hope we didnt spam people too much with all the changing around
[03:55] <saivann> hehe, well, my opinion is that we never have enough people fighting bugs
[03:56] <danage> yeah
[03:56] <danage> i wish i could
[03:56] <danage> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/208524
[03:56] <ubotu> Launchpad bug 208524 in gvfs "Gvfs ftp module doesn't display file whose name is longer than 42 characters" [Medium,Triaged]
[03:57] <danage> kinda related, probably
[03:59] <saivann> danage : I tested 42 characters and it works, looks like we have the real problem here..
[04:00] <danage> so we should probably add that to the bug report and link to ours
[04:00] <danage> u gonna take care of it?
[04:00] <danage> it might in both instances be a problem though
[04:00] <danage> too long
[04:01] <danage> by itself doesnt work
[04:01] <danage> and 7 spaces by itself doesn't work
[04:03] <saivann> danage : I will comment on the upstream bug report and subscribe to all these bugs (and look if I can find other similar bugs). Also, I will report our bugs upstream
[04:03] <danage> ok
[04:03] <danage> cool
[04:03] <danage> hope it gets fixed before the release
[04:03] <saivann> danage : I really don't know how it can be hard to fix..
[04:07] <danage> how come you can confirm bugs?
[04:07] <danage> and set priority
[04:09] <saivann> danage : I applied to be a part of the bug control team. Anybody who demonstrate a strong devotion to bug triaging can apply. All you need to do is to seriously follow these rules https://wiki.ubuntu.com/Bugs/HowToTriage and to ask questions, Brian Murray is the one who approuve new members
[04:10] <danage> hm i should maybe ask him
[04:11] <saivann> danage : Read all informations at the link that I provided to you and become a member of the bugsquad team, then once you have a couple of good bugs triaged, ask for your inclusion to the team and provide at least 5 good example of your work to Bria
[04:12] <saivann> Brain*
[04:12] <saivann> danage : Would be great to have you in the team tought :)
[04:12] <danage> :)
[04:12] <saivann> Brian*..
[04:13] <danage> ok
[04:13] <danage> eventually, i will qualify
[04:13] <danage> i lack knowledge of coding
[04:13] <danage> so most of my bugs are kinda like: i found the bug, how do i provide more info
[04:13] <danage> kinda thing
[04:14] <saivann> danage : You actually don't need coding knowledge, but debugging knowledge, and good logic
[04:15] <danage> i can debug
[04:15] <saivann> danage : Then maybe you can start with the bug squad and start triaging bugs, but without "super powers", then if you're confortable, you can go for the bug control team if you want
[04:15] <danage> ok
[04:17] <saivann> the bug control team needs you to really know and follow the rules, but all bug triager knows some package better than other packages. I'm very active with usplash and gnucash for an example, but there are a lot of packages scare me
[04:17] <danage> gvfs for example is something i could never understand
[04:18] <danage> but i am highly impressed by the way they pulled it off in such a short time
[04:18] <saivann> danage : this is indeed very impressive
[04:18] <danage> i like it a lot
[04:18] <danage> what they might wanna put though is a pause/resume feature
[04:20] <danage> ok, i have to get back to work
[04:20] <saivann> danage : There is similar ideas in ubuntu brainstorm, also people want file transfert queue instead of multiples transfert at once
[04:20] <danage> fun working with you
[04:20] <danage> queue is a good idea too
[04:20] <saivann> danage : Yes, thanks again for this great work!
[04:21] <danage> that would be a serious advantage over mac os and windows
[04:21] <saivann> yes, really, the brainstorm is full of good ideas
[04:21] <saivann> yes... really, I voted up :)
[04:21] <danage> :)
[04:21] <danage> not that easy to implement though: queue only makes sense if transfer is on the same channel
[04:22] <danage> i dont want a ftp transfer be queued after a hdd copy
[04:22] <saivann> danage : That's the kind of reflection that come with improvement :D
[04:23] <danage> you sent our two bugs upstream?
[04:24] <saivann> danage : Yes
[04:24] <danage> cool
[04:24] <saivann> danage : sorry if it takes time, I'll do it in the next miniutes
[04:24] <danage> really excited now to see what they say
[04:24] <danage> all cool, i was just curious
[04:32] <saivann> I'm finding upstream bugs that really sound like our bug.. so I'll mark comments about this too
[04:32] <danage> url?
[04:32] <danage> hah, we might have found the key to eliminate a couple of bugs
[04:32] <danage> that would be killah
[04:36] <danage> seen upstream bug
[04:36] <danage> cool
[04:36] <danage> u can remove my "to reproduce" though
[04:37] <danage> it's in there twice nw
[04:37] <danage> yours is better
[04:38] <saivann> danage : Where is your "to reproduce", note that I can only modify descriptions like you, comments are invincible :)
[04:39] <danage> http://bugzilla.gnome.org/show_bug.cgi?id=528346
[04:39] <danage> here
[04:39] <ubotu> Gnome bug 528346 in ftp backend "Files on FTP with >6 spaces in filename don't list in Nautilus" [Major,Unconfirmed]
[04:49] <saivann> danage : ah... I did not do it correctly. we'll have to leave it like that, but at least it is well documented
[04:50] <danage> shouldnt be a problem
[04:50] <saivann> I don't think so
[04:50] <danage> let's see what happens!!! :)
[04:52] <saivann> danage : Yes, I hope that they will have time to fix it, but perhaps that it will be fixed as a Stable Release Update since the RC is almost there
[04:52] <saivann> We did a very good job
[04:52] <danage> :)
[04:52] <danage> stable release update= service pack for windows?
[04:53] <saivann> danage : Hehe, no, windows service pack changes UI and important things, SRU are bug fix and generally security fixes that are enough important to be accepted while the distribution is stable
[04:54] <danage> ah
[04:54] <saivann> danage : Once a ubuntu release pass the Release Candidate state, updates must be really tested and require to fix important things
[04:54] <danage> hm they might make an exception for gvfs since it is so new
[04:55] <saivann> but I'm not an expert on this
[04:55] <danage> we'll see
[04:55] <saivann> possible, MOTUs will take the decision..
[04:55] <bdmurray> saivann: hello
[04:55] <saivann> Or maybe that it will be backported
[04:55] <saivann> bdmurray : hi!
[04:56] <saivann> bdmurray : I hoped that I did not disturbed your activity when I said your name :)
[04:56] <bdmurray> saivann: nope, no problem
[04:57] <danage> are you brian who is resposible for bug squad?
[04:58] <bdmurray> danage: Yes, I am brian
[04:58] <danage> can i apply for the bug squad?
[04:59] <danage> i dont know if my record supports an application, but i would kinda like to
[04:59] <bdmurray> Do you mean the bug control team?  They are the ones who can set bug importance.
[05:00] <danage> saivann: do i mean the bug control team? lol
[05:00] <danage> ah ok my fault
[05:00] <saivann> danage : You can become a bug squad member without approval https://edge.launchpad.net/~bugsquad and I suggest you to start taking experience with this team before thinking about the bug control team. You will see if you are confortable
[05:01] <saivann> danage : That's what I did, after some time I was ready for the bug control team, and I knew that it was for me :)
[05:02] <bdmurray> saivann: and you've been doing great work!
[05:02] <saivann> bdmurray : Thanks, it's always great to ear this, i'm working hard and never quite sure that I do "ideal" work :)
[05:03] <danage> bdmurray: you are from la?
[05:03] <danage> i live in westwood
[05:03] <bdmurray> I'm actually in Oregon
[05:03] <danage> :(
[05:04] <saivann> And I'm in Canada, it's quite cold here!
[05:07] <saivann> bdmurray : If danage ask you to become a member of the bug control team after some time, just a little comment : he does very good testing and it's great to work with him
[05:07] <bdmurray> saivann: okay, I'll remember that!  What bug were you two working on just now?
[05:08] <lifeless> ftp listing bug in gvfs/nautilus
[05:08] <danage> Bug #217975 and #218010
[05:08] <ubotu> Launchpad bug 217975 in gvfs "Cannot show/delete hidden files or delete folders that contains hidden files on FTP" [Medium,Triaged] https://launchpad.net/bugs/217975
[05:08] <ubotu> Launchpad bug 218010 in gvfs "Files on FTP with >6 spaces in filename don't list in Nautilus" [Medium,Triaged] https://launchpad.net/bugs/218010
[05:08] <saivann> here they are
[05:11] <saivann> It tooks a good amount of time to find exactly what was the problem, and we might have finally found the real cause of some upstream bugs
[05:16] <danage> saivann: you know what though
[05:16] <danage> for me, the hidden files/not hidden files thing works
[05:17] <danage> i just renamed a file to .lshglkhdflj
[05:18] <saivann> danage : does .lshglkhdflj show in nautilus this time?
[05:18] <danage> yes
[05:18] <danage> try it yourself
[05:18] <danage> we might have mislead ourselves on that one
[05:19] <danage> i tried again just now, just to make sure
[05:19] <danage> and it worked
[05:20] <saivann> danage : Well from my side, it still does not work, even after multiple re-try. If you click on the reload button, is it still here?
[05:21] <danage> yes
[05:21] <danage> then, there is a bug
[05:27] <saivann> danage : The hidden file problem might be more complex than we think. The problem now happens for me with filezilla, it worked perfectly and multiple times before. This would maybe mean that the problem is on the server side like described in duplicate bug 211748, but that would be very strange since it's two different FTP servers.
[05:27] <ubotu> Launchpad bug 211748 in gvfs "gvfs can't list hidden files through ftp (dup-of: 217975)" [Low,Invalid] https://launchpad.net/bugs/211748
[05:27] <ubotu> Launchpad bug 217975 in gvfs "Cannot show/delete hidden files or delete folders that contains hidden files on FTP" [Medium,Triaged] https://launchpad.net/bugs/217975
[05:27] <danage> yes, really strange
[05:28] <danage> do you have a server log?
[05:28] <saivann> danage : That's a good idea, looking..
[05:28] <danage> also: my ftp server is a filezilla server too
[05:28] <danage> running under windows
[05:28] <danage> my linux filezilla is the one from the ubuntu repo
[05:28] <saivann> danage : My fileserver is a FTPdPro, and my client is filezilla
[05:29] <bdmurray> Aren't there some public anonymous ftp servers out there still too?
[05:29] <danage> good idea, we should try those. do you know any with write access=?
[05:30] <bdmurray> I was thinking more about the spcaes bug
[05:30] <saivann> I don't have logs, that the FTP server of my website
[05:30] <danage> saivann: i have the same problem. my brother is hosting it on a windows virtual machine
[05:33] <saivann> bdmurray : What were you thinking about the spaces bug?
[05:34] <saivann> anonymous ftp sites : http://www.ftp-sites.org/anonymous_ftp_sites_list_com_1.html
[05:34] <bdmurray> Just that having a public ftp server for anyone to see it at might be helpful.
[05:36] <saivann> We can use my FTP server, ftp://leservicetechnique.com/ username: brother password: ubuntu
[05:40] <saivann> danage : You know what? I believe that concerning hidden files bug, we were wrong, the server is the problem. I had the illusion that filezilla was able to list the hidden files just because filezilla remember the files that he created by himself, but otherwise forcing filezilla to list the directory make all files starting with a . disappears. The only way to show the files is to use "Server / force showing hidden files"
[05:42] <saivann> danage : At least, the major part of the problem is the server. However, unless it can lead to bad directory listing or other problems, I still believe that nautilus should be able to show these files like filezilla even when there hidden by the server since apparently a lot of servers hide files
[05:43] <saivann> but the problem about spaces is really a nautilus bug
[05:43] <saivann> s/nautilus/gvfs
[05:45] <danage> saivann: ok, even better
[05:45] <danage> you could add that information to the bug report
[05:45] <danage> and pull it
[05:45] <danage> so that other people who might want to report the same bug
[05:46] <danage> will find ours, and refrain from reporting a new one
[05:49] <saivann> danage : I'm doing this right now, also I will set the priority to low since a part of the problem is caused by the server and not gvfs itself
[05:59] <saivann> danage : Great, thanks for finding this out! Bug updated
[05:59] <danage> yes and thanks for improving this
[05:59] <saivann> ;)
[05:59] <danage> ubuntu = getting better and better
[06:00] <saivann> I agree to this :)
[06:00] <danage> it is coming REALLY close to being a real alternative to windows, even for the average user
[06:00] <danage> i am never going back to windows
[06:01] <saivann> danage : Actually, I can do pretty more things with linux ubuntu than any other systems! Each time I repair a computer or try to restore a corrupted Hard Drive, I use linux
[06:01] <danage> yeah me too
[06:01] <danage> same thing
[06:01] <saivann> And I have a lot of customers that use linux
[06:01] <saivann> hehe :)
[06:02] <danage> also, the workflow is getting much better
[06:02] <danage> thumbnails on desktop, these kinds of things
[06:02] <danage> gvfs is also part of this process in my opinion
[06:02] <danage> i don't know much about backends
[06:02] <danage> but on the front end, it's much of an improvement
[06:03] <danage> nice description. sums it up pretty well
[06:03] <saivann> danage : Yes, ubuntu is just unlimited :)
[06:03] <saivann> danage : thanks, I think that it will do the trick
[06:03] <danage> should
[06:17] <saivann> Well, great job.. I'm going to sleep now, good night every one
[06:17] <saivann> danage : Nice to work with you
[06:19] <danage> good night
[06:19] <danage> it was fun, see you around
[06:19]  * saivann sleepzzzz
[08:16] <afflux> morning
[08:29] <DOOM_NX> Good Morning :)
[08:35] <afflux> gah. another report where upstream devs thought they can just change the ubuntu task :(
[08:37] <seb128> afflux: is that wrong?
[08:37] <afflux> (set to fix commited, no wonder it won't be fixed in ubuntu)
[08:37] <seb128> the desktop team usually use fix commited when the bug is fixed upstream so that doesn't seem to be an issue
[08:37] <afflux> huh
[08:38] <afflux> I was thinking fix committed is for "the fix is available in ubuntu somewhere", propably uploaded to the archives but not yet built, or a VCS-managed package or something
[08:38] <afflux> I thought that's what upstream tasks are for.
[08:39] <seb128> that's how launchpad means it I think, but that's not how it's used for desktop bugs for example
[08:39] <afflux> hm
[09:52] <afflux> omg. Didn't we have a discussion on people "I can confirm this too"ing in LP bugs recently? Now that the bug is fixed, they say "I can confirm that this bug is fixed in version xyz" :/
[10:37] <Arby> mvo: you might be interested to know that dapper->hardy on kubuntu went without a hitch
[10:38] <Arby> using the gtk upgrader as you said
[10:38] <Arby> this was in a VM with a completely clean dapper install
[10:38] <Arby> fully up to date
[10:39] <mvo> Arby: great!
[10:39] <mvo> Arby: happy to hear that :)
[10:39] <Arby> yeah I was impressed
[10:39] <Arby> even if it is the simplest possible test case
[10:43] <Arby> mo while you're around, bug 216907
[10:43] <ubotu> Launchpad bug 216907 in update-manager "update-manager does not accept debian proxies" [Undecided,Incomplete] https://launchpad.net/bugs/216907
[10:43] <Arby> mvo: ^^
[10:43] <Arby> I'm not even sure if what he's trying to do is supposed to be possible
[10:49] <mvo> Arby: let me look
[10:50] <mvo> Arby: yeah, that is a use-case we do not support very well, I will look into it and see what I can do about it
[10:50] <Arby> will you comment on the bug?
[10:50] <mvo> yes
[10:50] <Arby> thanks
[11:07] <mvo> Arby: I replied, I would like to test his setup, I think with a internal mirror (and no network for the client to the outside) and the altnerative CD the upgrade should go just fine, but I would like to run a test on this just to be sure
[11:18] <Arby> mvo: if you can explain how to set up a mirror I can try and test this evening.
[11:18] <Arby> (am at work now)
[12:18] <Mez> bug #217772
[12:18] <ubotu> Bug 217772 on http://launchpad.net/bugs/217772 is private
[13:07] <Iulian> Hey
[13:08] <pedro_> hello Iulian
[13:09] <Iulian> Hiya pedro
[13:18] <mvo> Arby: thanks, that sounds interessting, we could try something together. I think apt-proxy is sufficient for the test, lets talk later
[14:51] <smallfoot-> hardy is on 8 days, please hurry up and fix the pink shadows & window decoration bug in the nvidia-utils drivers package
[14:52] <qense> what's the bug number?
[14:52] <smallfoot-> there are many dupes for it
[14:52] <smallfoot-> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/194851
[14:52] <ubotu> Launchpad bug 194851 in compiz "Pink shadows with Compiz (dup-of: 186382)" [Low,New]
[14:52] <smallfoot-> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/186382
[14:52] <ubotu> Launchpad bug 186382 in linux-restricted-modules-2.6.24 "[nvidia 169.xx] gtk window decorator somtimes draws decoration ugly or not at all" [Low,Confirmed]
[14:52] <smallfoot-> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/194933
[14:52] <ubotu> Launchpad bug 194933 in linux-restricted-modules-2.6.24 "Compiz + 169-series NVIDIA drivers: frequent visual corruption of window title bars upon various title bar events (dup-of: 186382)" [Undecided,New]
[14:52] <smallfoot-> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/195436
[14:52] <ubotu> Launchpad bug 195436 in linux-restricted-modules-2.6.24 "Compiz - no shadows (dup-of: 186382)" [Medium,Confirmed]
[14:53] <smallfoot-> Ubuntu & ArchLinux users experience this bug, but installing the official drivers from nvidia.com removes this bug
[14:53] <qense> one master report is enough :)
[14:53] <smallfoot-> the bug seem to be in the packaging of the drivers, and specificly nvidia-utils
[14:54] <smallfoot-> there is a thread about it here too http://www.nvnews.net/vbulletin/showthread.php?t=109546
[14:54] <smallfoot-> and discussion here http://bbs.archlinux.org/viewtopic.php?pid=353101
[14:54] <qense> are those threads mentioned in the bug report?
[14:54] <smallfoot-> not sure
[14:55] <qense> there isn't much else that can be done
[14:55] <qense> we just need to wait for someone to pick up the bug and start working on it
[14:55] <smallfoot-> well there is like many bug reports about it, you must fix the bug
[14:55] <qense> that's the way  things go in opensource development
[14:55] <smallfoot-> yeah, it needs to be repackaged better
[14:55] <qense> you could try to fix it :) see http://wiki.ubuntu.com/MOTU for more information
[14:55] <smallfoot-> because the official drivers work when you install them from nvidia.com, but when you get them from apt-get it got that pink bug
[14:56] <smallfoot-> i've never fixed anything
[14:56] <qense> this could be your first :)
[14:56] <smallfoot-> :)
[16:00] <bddebian> Boo
[16:02] <qense> hello bddebian
[16:03] <bddebian> Hello qense
[16:10] <Iulian> Hey bddebian
[16:12] <bddebian> Hello Iulian
[16:33] <danage> saivann: you here?
[16:33] <saivann> danage : Hi!
[16:33] <danage> hi
[16:35] <saivann> danage : (a bit busy on the phone though)
[16:37] <saivann> danage : As you can see, we finally triaged a existing bug that had a wrong description, I updated the launchpad and upstream bugs to contain te result of our tests
[16:37] <danage> cool, but someone else gets our props!!!! :)
[16:45] <saivann> I believe that the more important is that the bug get reviewed by developers. I'm surprised that our bug as been set as the duplicate one but that's probably because developers already knew the older one.
[16:47] <danage> yeah, i was just kidding
[16:48] <danage> most importantly the bug needs fixed, the rest i somewhat care less about
[16:54] <greg-g> dang you pedro_! ;)  I just reported that bug upstream also!
[16:54] <greg-g> we were doing it simultaneously
[16:54] <pedro_> greg-g: evince one?
[16:54] <greg-g> yeah
[16:54] <greg-g> :)
[16:54] <pedro_> greg-g: I'll mark mine as dup of yours, dont worry :-)
[16:55] <greg-g> haha, mine does have more info :)
[16:55] <greg-g> http://bugzilla.gnome.org/show_bug.cgi?id=528430
[16:55] <ubotu> Gnome bug 528430 in general "Displays "-1" as first page" [Normal,Unconfirmed]
[16:55] <pedro_> greg-g: change the watcher in the meantime :-)
[16:56] <greg-g> got it
[16:56] <pedro_> done
[16:57] <greg-g> cool.  you're too quick sometimes ;)
[16:58] <pedro_> hehe sorry about it
[16:58] <greg-g> I haven't finished my first cup of coffee yet though, that is my excuse
[16:58] <pedro_> and thanks for let me know :-)
[16:58] <greg-g> don't be
[17:06] <Tuv0k> !ubotu
[17:06] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
[17:07] <saivann> danage : ;)
[17:13] <bigon> does anybody has troubles to print something that is send to an other cups server?
[20:23] <mvo> Arby: bug #186465 might be a local customization problem, I suspect that for some reason /usr/bin/sudo is not set suid root
[20:23] <ubotu> Launchpad bug 186465 in update-manager ""distribution upgrade" hangs during update to hardy" [Undecided,Confirmed] https://launchpad.net/bugs/186465
[20:23] <mvo> Arby: at least for the person that provided the strace
[20:27] <Arby> mvo: how would I un-suid /usr/bin/sudo to test that
[20:27] <Arby> some kind of chmod foo?
[20:29] <mvo> Arby: chmod 755 /usr/bin/sudo - but keep a root shell open somewhere so that you can change it back
[20:30] <Arby> it's a VM, if I break I'll just make a new one
[20:30] <Arby> snapshots++
[20:30] <mvo> heh :) fair enough
[20:31] <Arby> just finishing an install test then I'll give it a go
[20:31] <mvo> Arby: the gutsy2hardy cdrom upgrade seems to work for me (at least on a stock install) - did you use the altnerative CD for the test?
[20:32] <Arby> mvo: I used the alternative CD from yesterday and the DVD from today
[20:32]  * mvo checks with the dvd
[20:33] <Arby> I wonder what's wrong with that VM then, hmm
[20:33] <Arby> I got the same result with both so it suggests it could be my test system
[20:33] <mvo> or some different setup maybe, its a bit odd
[20:35] <Arby> I have today's alternate CD here. I'll try that too


[00:03] <Leonidas> I have branched off some line of development with my own changes, now I'd like to get a complete, clean patch of my changes to the trunk revision. How to do that?
[00:04] <Leonidas> I tried with merge --preview, but it does not work, since I'm working treeless. And I don't really plean to do a merge anyway.
[00:04] <Leonidas> s/plean/plan/
[00:05] <Peng> Leonidas: bzr send?
[00:05] <Leonidas> Furthermore, I'd like to merge in the latest trunk changes since branching, but they should not appear in my patch.
[00:06] <Peng> Leonidas: bzr send?
[00:06] <Leonidas> Peng: thanks. I'll see whether this is what I want.
[00:06] <james_w> Leonidas: there is also "bzr diff -r ancestor:URL"
[00:07] <Peng> Leonidas: 'bzr send' produces a bundle file, which by default includes a diff and the (base64-encoded) meta data.
[00:09] <lifeless> poolie: did you ring?
[00:10] <Leonidas> Peng: bzr send sounds good, but I'd need to get the patch only, since it's only me who is using bzr. The other people have no use for bundles.
[00:11] <Leonidas> bzr send --output=- is nice, now compine it with no-bundle
[00:13] <Leonidas> huh? Am I missing something? bzr send --no-patch --output=- works
[00:13] <Leonidas> bzr send --no-bundle --output=- does not.
[00:14] <Leonidas> bzr send --output=- does work and produces both patch & bundle.
[00:16] <spiv> Leonidas: I'm guessing "bzr send --no-bundle" is failing due to a lack of a public location for your branch.
[00:16] <spiv> Leonidas: if you just want a diff, you're better off using "bzr diff" directly, as james_w suggested.
[00:17] <Leonidas> spiv: right, it fails because there is no public location. But I don't see why it does not work like bzr send just without the bundle. I could use sed, though ;)
[00:18] <spiv> Leonidas: bzr send tries fairly hard to make sure that all the history is available to the recipient, either in the included bundle, or in a publically accessible branch if there is no bundle.
[00:18] <Leonidas> ah, that explains a lot!
[00:18] <poolie> lifeless: no
[00:19] <spiv> i.e. bzr send is designed as a way to send merge directives for branches, not as a way to generate diffs.  Generating diffs is what "bzr diff" is for :)
[00:19] <Leonidas> spiv: ok, bzr diff -r ancestor:... works properly. Fine.
[00:20] <Leonidas> Thanks, also to james_w
[00:20] <Leonidas> I wonder what happens if I merge trunk :)
[00:24] <Leonidas> ok, works. Fine
[00:37] <igc> lifeless: I'm planning to tweak stacked branches today
[00:37] <igc> 1. move branch-location into branch.conf
[00:37] <igc> 2. rename shallow options and messages to stacked
[00:37] <igc> 3. ????
[00:37] <igc> lifeless: is that ok?
[00:51] <poolie> igc, is the name really just branch-location? it needs a less ambiguous name...
[00:53] <igc> poolie: no. I was being lazy because I knew that lifeless knew what I meant
[00:53] <poolie> ok :)
[01:12] <abentley> jelmer: around?
[01:13] <jelmer> abentley, hi
[01:13] <jelmer> igc: 4. profit ? ;-)
[01:13] <abentley> jelmer: Can I ask some questions about samba?
[01:13] <jelmer> abentley: sure
[01:15] <Peng> jelmer: How stable is bzr-svn's 0.4 branch at the moment?
[01:15] <jelmer> Peng: stable
[01:15] <Peng> jelmer: So it's okay to use instead of 0.4.10?
[01:15] <abentley> jelmer: The main question is, is Samba suitable for sharing to linux clients?  I.e. can it preserve users, modes, etc?
[01:15] <jelmer> Peng, at the moment, yes
[01:16] <abentley> I've only used it when the primary clients were win32.
[01:16] <Peng> jelmer: Are you planning to break it before the next release? :P
[01:16] <jelmer> abentley: Yes, when you're using a recent version of Samba and CIFS VFS (mount -t cifs rather than mount -t smbfs)
[01:16] <jelmer> Peng: no plans :-) but not guarantees either..
[01:17] <abentley> jelmer: cool, thanks.
[01:17] <jelmer> abentley: It's more POSIX compliant than NFS3 and even more compliant than NFS4 in a lot of cases
[01:17] <Peng> Maybe I'll keep using 0.4.10 as long as it works with bzr.dev. If it still does.
[01:18] <abentley> jelmer: great.
[01:19] <Peng> Yeah, it does.
[01:20] <jelmer> Peng: 0.4.10 is broken with bzr.dev (push for example)
[01:21] <Peng> Oh.
[01:21] <Peng> Broken as in traceback or corruption?
[01:25] <jelmer> traceback
[01:25] <jelmer> corruption never happens because of mismatching versions
[01:58] <lifeless> poolie: found the plugin ? :P
[01:59] <lifeless> abentley: is branch.conf meant to be human edited or bzr edited?
[02:00] <abentley> lifeless: Yes.
[02:00] <lifeless> hmm
[02:00] <abentley> Same as bazaar.conf.
[02:01] <lifeless> what settings from it are copied on clone/sprout?
[02:02] <abentley> I can't think of any values that are copied.
[02:02] <lifeless> ok
[02:02] <lifeless> igc: go ahead
[02:03] <abentley> lifeless: It contains values like parent location, push location, bind location.
[02:03] <igc> lifeless: thanks
[02:04] <igc> lifeless: summary email on its way now too fwiw
[02:09] <lifeless> igc: thanks
[02:10] <lifeless> poolie: call?
[02:21] <mwhudson> beuno: are you still up?
[02:22] <ricardokirkner> hi everyone. I just wanted to know. Is olive-gtk currently the best available option for a gui interface to bzr? Or are there any better options? (I would prefer gtk over qt, but it' s entirely a matter of (visual) taste)
[02:22] <ricardokirkner> what I was looking for is some app that makes viewing change history easy (something like trac, but as a client app, instead of requiring a webserver)
[02:25] <beuno> mwhudson, yeap
[02:25] <mwhudson> beuno: cool
[02:25] <mwhudson> beuno: so my understanding, roughly speaking is that you have done four things to loggerhead recently:
[02:25] <mwhudson> 1) remove the use of deprecated methods
[02:25] <mwhudson> 2) switched to using zpts
[02:26] <mwhudson> 3) some ajax-y stuff for revision views
[02:26] <mwhudson> 4) use cleaner urls
[02:26] <mwhudson> beuno: would that be a fair summary?
[02:28] <beuno> mwhudson, generally, yes. Although 3) required generating a new controller from scratch for diff, and changing how the revision view is generated
[02:28] <mwhudson> ok
[02:28] <mwhudson> so what i would _like_ is to have one branch for each of these things :)
[02:29] <mwhudson> (they don't all have to be brances off trunk, i'd expect the branch for 3) to be a branch off that for 2), for example)
[02:29] <beuno> ah, good, was about to say that  :)
[02:29] <beuno> and, well, 4) off 2) also, since it's mostly templating work
[02:29] <mwhudson> sure
[02:30] <beuno> ok, I can do that, now, where could I find a good VCS to help me with that...
[02:30] <mwhudson> heh heh
[02:31] <mwhudson> beuno: i'd like to review the branches for 1 and 2 today if i can
[02:32] <beuno> mwhudson, oh, sure. I'll get right on it.   1) would be with KID than?
[02:32] <beuno> *then
[02:32] <mwhudson> beuno: yeah, i think so, the changes are entirely independent of the templating stuff
[02:32] <mwhudson> and this branch is more urgent
[02:33] <beuno> yes, I see where you're going. I'll push em to LP and ping you
[02:33] <mwhudson> thanks a lot
[02:34] <mwhudson> you could even send merge requests to the bazaar list :)
[02:35] <beuno> sure, whatever is better. Will BB get confused if I send with [MERGE]?
[02:37] <mwhudson> yeah, i guess [loggerhead/MERGE]
[02:41] <mwhudson> hmm, is there anyway of running bzr viz in a repository?
[02:41] <mwhudson> (i.e. with multiple heads)
[02:45] <mwhudson> beuno: any idea how long this is going to take?  i.e. a few minutes, an hour, tomorrow?
[02:45] <mwhudson> beuno: don't want to pressure, just want to know
[02:45] <beuno> mwhudson, I'll send 1) in a few minutes
[02:46] <mwhudson> cool
[02:46] <beuno> and 2) by the end of the day
[02:46] <beuno> as I see it, 3) and 4) stack up on top of 1) and 2)
[02:48] <fullermd> You can run viz on multiple branches...
[02:48] <mwhudson> fullermd: you can?
[02:49] <mwhudson> beuno: isn't it rather late for you already? :)
[02:49] <mwhudson> beuno: but sounds good
[02:49]  * mwhudson heads out to buy some chocolate to fuel the review
[02:49] <beuno> mwhudson, I've seemed to moved to new zeland time zone these past weeks  :)
[02:49] <mwhudson> beuno: heh
[02:50] <fullermd> Yah, just hand it a couple on the command line.
[02:50] <fullermd> (I haven't really used it, but I've done it)
[02:51] <mwhudson> fullermd: maybe my bzr-gtk is too old, it doesn't work for me
[02:52] <fullermd> NEWS says it was on 0.94.0
[02:52] <mwhudson> 0.93.0
[02:52] <mwhudson> oh well
[02:54] <lifeless> beuno: glad you like it
[02:56] <beuno> lifeless, I may even attempt to get it working within loggerhead, when I run into some free time
[02:57] <beuno> a pre-alpha version of it will be *way* better than what there is today  :)
[02:59] <lifeless> :P
[02:59] <lifeless> surely not ?
[03:00] <beuno> mwhudson, we sould really disable full text indexing by default
[03:01] <beuno> it makes my core2duo 1.5gb of ram cry for a good hour on bzr.dev
[03:01] <lifeless> holy crap
[03:01] <lifeless> are you sure it only indexes the commit messages?
[03:01] <beuno> I promise  :)
[03:01] <lifeless> how the hell can you spend more than a few seconds indexing bzr.dev's commit messages.
[03:02] <lifeless> I reckon you are missing a lock_read() or something similarly inane
[03:02] <beuno> I'd rather invest time in getting it to work with something new (bzr-search, for example) than fixing the horrid current sqlite thingie
[03:03] <lifeless> k
[03:03] <lifeless> (I'm sure the underpinnings are not that different though)
[03:03] <lifeless> poolie: bzrlib.tests.test_lockdir.TestLockDir.test_35_wait_lock_changing is failing sporadically for me. I mention this because I thought it was fixed?
[03:05] <mwhudson> lifeless: i think i already explained that loggerhead's text indexer is worse than you can possibly imagine, didn't i?
[03:05] <mwhudson> i wasn't kidding
[03:07]  * igc lunch
[03:07] <beuno> mwhudson, patch for 1) sent off to the list
[03:08] <lifeless> mwhudson: I thought my imagination had more power
[03:09] <beuno> mwhudson, I'm off for ~2 hours, and I'll be back to send 2) with 1) merged into it, and other tweaks it needs to work properly
[03:10] <mwhudson> beuno: ok, have fun
[03:11] <beuno> lifeless, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/launchpad%40pqm.canonical.com-20080418101647-2k1lv1l0edudd191?file_id=textindex.py-20061219035715-norgqx0pl0hxdax8-1
[03:11] <beuno> for your amusement  :)
[03:15] <beuno> mwhudson, oh, and I just remembered, not sure what that list is for, but I also tried genshi as a templating engine, which failed miserably  :)
[03:16] <mwhudson> beuno: right, i'm not expecting to merge that one :)
[03:16] <fbond> jelmer: thanks
[03:16]  * beuno is off
[03:18] <lifeless> beuno: bye
[03:21] <lifeless> holy cow
[03:21] <lifeless> thats scary shit
[03:22] <lifeless> I mean, might want to tweak the term generator in bzr-search to combine robert's -> roberts rather than robert's -> robert, s
[03:22] <lifeless> but thats stemming which I punted on
[03:37] <synic> is there an IRC bot out there that'll watch bzr repos for changes?
[03:39] <lifeless> I believe so
[04:11] <mwhudson> so bookmarks and lp: urls don't really get on
[04:13] <bob2> yay for stacking
[04:29] <poolie> lifeless: re that test - i have a patch that addresses it but there was some nontrivial review pushback, i need to revisit it
[04:30] <poolie> uh
[04:30] <poolie> i tried doing an incremental patch towards it, introducing a different error for "waiting for lock timed out" from "lock is not available at this instant"
[04:30] <poolie> which i think will make those tests clearer and not timing dependent
[04:30] <poolie> but the increment was not compelling by itself
[04:44] <lifeless> poolie: k
[05:18] <beuno> back
[05:18] <beuno> mwhudson_, so, 2) then?
[05:20] <mwhudson_> beuno: yes please :)
[05:21] <beuno> on it
[05:35] <jml> hey guys
[05:35] <jml> when someone deletes a directory in bazaar and the directory has pyc files, I get conflicst
[05:35] <lifeless> yes
[05:36] <lifeless> known issue, no good answer so far
[05:40] <jml> lifeless: ok. cool.
[05:42] <lifeless> (you need a way to separate 'my-bank-details.txt' which I ignored so it wouldn't be added from 'foo.pyc' wchich I ignored so it would not be added
[05:43] <bob2> need to somehow consider the former to be...precious ;)
[06:00] <lifeless> or the latter to be junk
[06:01] <lifeless> but this has complexity impact
[06:12] <beuno> mwhudson_, do you want the 2) patch relative to 1) or trunk?
[06:12] <mwhudson_> relative to 1) please
[06:13] <mwhudson_> beuno: i
[06:13] <beuno> coming up
[06:13] <mwhudson_> 'm not going to be working for much longer today, btw
[06:13] <mwhudson_> i'll look at it first thing tomorrow
[06:13] <beuno> oh, but it's only 3k lines...  :p
[06:14] <mwhudson_> :)
[06:14] <mwhudson> i know, i'm lame
[06:18] <beuno> mwhudson, sent
[06:19] <beuno> I'll prepare the other 2 tomorrow
[06:37] <poolie> beuno, hi
[06:37] <beuno> hey there poolie
[06:41] <poolie> beuno: what a circus :-}
[06:42] <beuno> poolie, heh, the past weeks have been pretty active  :)
[07:02] <lifeless> abentley: lol, I have this image of bb running around going 'I'm freaking out mAAAAAAN'
[07:03] <beuno> hahha, I was just thinking that. With ian's patch in it's hand
[07:03] <abentley> lifeless: hehe
[07:33] <fdv> Hi. Anybody know what 'KnitCorrupt: Knit <bzrlib.knit._PackAccess object at 0x870fc6c> corrupt: incorrect number of lines 221 != 152 for version {svn-v3-single1-dHJ1bmsvbWFpbg..:6226825f-cf0a-0410-9073-f4040cba8958:trunk%2Fmain:116353}' means?
[07:37] <beuno> I'm off to bed. G'night everyone
[07:40] <igc> night beuno
[07:42] <lifeless> fdv: my first thought would be a symlink with newlines in it in the source svn repo
[07:43] <fdv> lifeless: ah
[07:43] <lifeless> because I *think* bzr-svn generates its own knit hunks or something like that
[07:43] <fdv> that revision had broken symlinks, but I tried removing those nodes
[07:43] <lifeless> jelmer: ^ any thoughts
[07:44] <fdv> what are knit hunks, really?
[07:46] <spiv> fdv: records containing the lines added in a revision, basically.
[07:47] <fdv> ok..
[07:47] <spiv> Usually just the new lines, and a record of the lines removed.  Sometimes a full copy of a file is stored rather than just a delta, depending on various conditions.
[07:47] <fdv> right
[07:48] <spiv> Basically, low-level guts :)
[07:48] <fdv> I removed all the nodes containing these symlink edits from the dump file and repopulated the repo
[07:48] <fdv> and then tried pulling it again
[07:48] <abentley> igc: Do you have a clear idea what you need to do to generate a mergeable directive?
[07:49] <lifeless> fdv: did you clear the output repository?
[07:49] <lifeless> fdv: or remove the corrupt revisions copied into it?
[07:49] <fdv> lifeless: absolutely :)
[07:49] <igc> abentley: use bzr.dev as the submit_branch
[07:49] <fdv> lifeless: I couldn't remove the whole revisions
[07:49] <fdv> only the nodes affected
[07:50] <igc> abentley: I don't get hope to get the right preview diff though ...
[07:50] <abentley> igc: And you can use -r to specify the cherrypick you want
[07:50] <igc> so -rancestor:../foo.bar?
[07:50] <lifeless> igc: bzr send -r thread:..-1
[07:50] <lifeless> igc: you should never need to touch -rancestor with send and a loom
[07:50] <igc> lifeless: I've exported the loom
[07:51] <lifeless> igc: oh, don't
[07:51] <lifeless> igc: :)
[07:51] <lifeless> igc: I send all my patches for loom-branches direct from the loom
[07:51] <igc> lifeless: I didn't know better and smart people told me to :-)
[07:51] <lifeless> AIUI export-loom exists solely for use with launchpads internal review system which is not loom aware
[07:52] <lifeless> BB doesn't have the same flaws
[07:52] <abentley> lifeless: Not true, also for dealing with PQM
[07:52] <lifeless> abentley: oh, I guess. I do all my merges via an integration branch, so it never occured to me
[07:52] <lifeless> abentley: (bzr pull $source --overwrite && push --overwrite && pqm-submit -m '...')
[07:54] <abentley> igc: Anyhow, are you able to get a reasonable preview diff?
[07:54] <igc> just trying now
[07:57] <igc> abentley: in the case of StackableBranch, not by using -rancestor:../Development1 :-(
[07:58] <igc> I guess the preview is the least important bit
[07:58] <igc> but it annoys people reviewing in the mailer
[07:58] <abentley> igc: The preview reflects the merge you are requesting.
[07:58] <abentley> If it's wrong, your request is wrong.
[07:59] <igc> abentley: the preview contains the right changes vs bzr.dev
[07:59] <igc> but it's more than I wanted in the preview because it includes the changes from 'threads' below
[07:59] <lifeless> igc: honestly, do the BB submissions direct from the loom
[08:00] <lifeless> igc: with 'bzr send -r thread:..-1' from within each thread.
[08:00] <lifeless> igc: it will JustWork
[08:00] <lifeless> (I mean, this is the sort of scut work that loom is _meant_ to manage for you)
[08:00]  * abentley has send -r thread: aliased as tsend
[08:01] <igc> lifeless: understood. Why the ..-1 ?
[08:01] <lifeless> exactly
[08:01] <lifeless> current tip
[08:01] <abentley> igc: a -r spec generally specifies the tip.
[08:02] <lifeless> igc: you want from the thread below (thread:) to the last commit (-1). But giving send one revision says 'from bzr.dev to that revision)
[08:02] <abentley> So -r thread: specifies the tip to be the tip of the previous thread, which is wrong.
[08:02] <igc> ok
[08:02] <abentley> You can probably specify "-r thread:.." but I haven't tried that.
[08:03] <igc> I try sending from the loom now
[08:05] <abentley> Alternatively, you can specify the revision-ids from your previous submissions.  i.e. "bzr send -r revid:ian.clatworthy<EMAIL_ADDRESS>../bzr.dev"
[08:05] <gour> will loom become part of bzr?
[08:05] <lifeless> gour: do you mean 'will it be part of the tarball' ?
[08:06] <lifeless> gour: if so, probably, we plan to roll popular plugins into the release tarballs.
[08:06] <gour> lifeless: yes. otoh, 'loom' is not listed at http://bazaar-vcs.org/BzrPlugins or i'm blind
[08:08] <fdv> lifeless: wrt. the knit error, could the revision be cached or already (half way) applied somehow, so that I don't get it from the new repo I set up, but still from the old one (which is broken)?
[08:08] <lifeless> fdv: yes
[08:08] <fdv> ah
[08:08] <lifeless> fdv: I would try importing to a fresh ('bzr init --rich-root-packs') tree
[08:09] <fdv> crap
[08:09] <fdv> that's three more days :p
[08:09] <lifeless> well
[08:09] <fdv> but if that's what it takes.. :)
[08:09] <lifeless> you have corrupt content in your target repo
[08:09] <lifeless> removing knit references is not the simplest thing to explain
[08:09] <fdv> I can't roll it back somehow?
[08:09] <fdv> that's all right
[08:09] <fdv> if it's the only feasible solution, I'll start from scratch
[08:10] <lifeless> we dont have an automated UI for removing single revisions at the moment
[08:10] <fdv> I think I have a corner case here :)
[08:10] <lifeless> oh, there is need for it
[08:10] <lifeless> it needs someone to write a ui for it using the low level primitives
[08:11] <fdv> I see
[08:11] <fdv> are there some docs anywhere? :)
[08:11] <lifeless> if you have a pack repository, pydoc bzrlib.repofmt.pack_repo
[08:12] <lifeless> (for a pack repo its basically 'copy everything to a new pack except hwat you want to remove, then discard the old packges')
[08:12] <abentley> igc: I'm off to bed.  If in doubt, run a test against a local bzr.dev that doesn't use the same shared repo.
[08:12] <igc> ok
[08:12] <lifeless> for a knit repo its 'remove low level index entries' by doing the same on a per file-id basis
[08:13] <gour> svn folks released svn-1.5rc10 :-/ good luck to those living with such software
[08:13] <fdv> lifeless: ok, I'll try to have a look. Don't have too high hopes, thouhg :)
[08:14] <gour> ...requiring 10rcs
[08:16] <lifeless> fdv: don't stress about it :P
[08:16] <fdv> no, but it'd be interesting to have a look
[08:28] <vila> beuno: test a little, code a little :) I don't think you need to duplicate tests for a --dry-run option. TDD helps in *reducing* code duplication after all.  Some blackbox tests should be enough.
[08:28] <lifeless> later all, dinner time
[08:33] <igc> ok, I think I've stopped BB freaking out now. Let's hope so.
[08:41] <igc> night all
[08:41] <gour> night
[08:44] <poolie> cheerio igc
[08:44] <poolie> 1.6b2 is out
[08:55] <toyto1> hello guys, does bzr can be integrated with trac?
[09:01] <toyto1> guys is launchpad.net seems to be like trac?
[09:08] <Peng> toyto1: There's a bzr-trac thingy, but I don't think it's 100%.
[09:08] <Peng> toyto1: And yeah, Launchpad has some similarities to Trac. No wiki though.
[09:10] <gour> seeing that trac-0.11 is still no out...hmm
[09:11] <poolie> night all
[09:13] <gour> toyto1: have you seen http://www.redmine.org/ ?
[09:13] <toyto1> Peng: ah i see:)
[09:13] <toyto1> gour: what's that? let me check
[09:14] <toyto1> Peng: I didn't find how-to their with bzr-trac for integrating :(
[09:14] <gour> toyto1: it's what trac-2.0 will maybe become. it's RoR app, but still
[09:16] <toyto1> gour: so you mean is that redmine is more advance than trac as of now?
[09:16] <gour> toyto1: yep, more support for SCM, multi-project etc. however, we choose roundup (http://roundup.sourceforge.net/) - no need for wiki
[09:22] <toyto1> gour: I see thanks for the info :)
[09:22] <gour> ;)
[09:32] <mtaylor> help!
[09:32] <mtaylor> bzr: ERROR: Revision {foo@bar-20080606164431-373v96de5ba508yi} not present in "revisions.kndx".
[09:32] <weigon_> ... at a bzr branch ...
[09:37] <james_w> mtaylor: https://bugs.edge.launchpad.net/bzr/+bug/232270
[09:37] <mtaylor> james_w: ah
[09:37] <james_w> are you using a smart protocol for whatever operation you are doing?
[09:38] <mtaylor> for that one.
[09:38] <mtaylor> it's possible someone used sftp or something though
[09:38] <weigon_> james_w: it is all bzr+ssh://
[09:39] <weigon_> james_w: I have a 2nd tree that is a bit more up-to-date that has that rev-id and I can pull nicely into that tree
[09:40] <weigon_> only if I use a tree that is "before" that rev-id the branch/pull/log/... all fail
[09:40] <james_w> if you use sftp:// it should work.
[09:41] <weigon_> james_w: it does
[09:41] <weigon_> and interestingly a $ bzr log --show-ids sftp:// shows me the {foo@bar-20080606164431-373v96de5ba508yi}
[09:41] <james_w> hang on, are you two working together on this?
[09:41] <weigon_> james_w: yep :)
[09:42] <james_w> ah :-)
[09:42] <james_w> ok, it's some problem with the smart server, I've updated the bug report about it, you can subscribe if you wish to follow the progress.
[09:43] <james_w> a full traceback of the error would be very useful, you can find one in your ~/.bzr.log.
[09:43] <james_w> you can edit out the details, but the traceback would be really helpful.
[09:43] <mtaylor> so, there still isn't a pack-based format that you can upgrade to from dirstate-with-subtrees ?
[09:44] <james_w> you should be able to upgrade to --rich-root-pack if you don't actually have any subtrees I believe.
[09:45] <weigon_> james_w: http://pastie.org/212084
[09:45] <mtaylor> james_w: we don't _think_ we are using any (at least, we aren't on purpose)
[09:45] <weigon_> this is the one for bzr log failing
[09:46] <mtaylor> james_w: but upgrade --rich-root-pack still b0rks
[09:46] <james_w> weigon_: thanks. That's a different error from the "bzr branch" error, could you possibly provide that one as well, it would be great to have as much information as possible.
[09:47] <weigon_> sure
[09:47] <james_w> mtaylor: is it an error about this problematic revision, or something unrelated?
[09:47] <mtaylor> james_w: something unrelated - I was trying upgrading to packs to see if that would help ... but now I'm just fixed on the fact that I _can't)
[09:48] <james_w> heh :-)
[09:48] <james_w> sounds like it would be worth a separate error report then.
[09:49] <mtaylor> yay! two bugs in one swipe!
[09:49] <weigon_> james_w: http://pastie.org/212087
[09:50] <james_w> thanks team.
[09:50] <james_w> I'll put those in the bug report if you don't mind, as we don't have good info there yet
[09:52] <weigon_> shall I add it so you have a reference for more info ?
[09:53] <james_w> I think there may be enough there to know what is going on. I'm no expert in this area though.
[09:53] <weigon_> k
[09:53] <james_w> there's also a public branch there that is reported to exhibit the problem, so it can always be reproduced by the developer.
[09:53] <james_w> thanks for your help.
[09:54] <weigon_> the sftp:// idea is good enough for now
[09:54] <weigon_> thanks
[09:57] <weigon_> james_w: the story goes on with $ bzr merge ... let me paste it
[09:59] <weigon_> james_w: http://pastie.org/212089
[10:01] <james_w> ok, do you understand what the error message is saying?
[10:11] <weigon_> james_w: it tries to find the common ancestor where the two trees are related and can't find it
[10:12] <james_w> yup, are these two trees supposed to be related?
[10:12] <weigon_> this is the same tree that has the other problems :)
[10:12] <weigon_> they are related just a few revs before the unknown rev-id
[10:13] <weigon_> I assume that this is just a side-effect, as bzr thinks it can't find one of the rev-ids along the way and jumps out
[10:22] <awilkins> gour: The SVN team have always been cautious about version numbers ; I remember how long it took them to get to 1.0
[11:13] <blaudden> Hi, I'm getting extensive merge conflicts when merging two trees(383 conflicts). It feels like it select's a very old base. The manual hints about specifying a specific base to use. But I can't figure out how to do that. Any ideas?
[11:16] <blaudden> Have tried to remerge with "bzr remerge --weave <conflicted files>" and that will bring the number of conflicts down, but at the same time some changes will be lost and it's not possible to use "bzr extmerge" after that since ther is no .BASE, .OTHER and .THIS anymore.
[11:56] <spiv> blaudden: try --lca instead of --weave maybe
[11:56] <spiv> blaudden: I'm not sure what you mean by "some changes will be lost"
[11:57] <blaudden> spiv: yes, I tried --lca also
[11:59] <blaudden> spiv: When running the binary it wil crash and I find one place where the merge has removed two lines instead of conflict them. That makes me a little scared and I start to think about other places being merged that way but that doesn't cause an immediate crash.
[12:03] <fredreichbier> when i use bzr with http+ftp, does that create special traffic or abuse the sever?^^
[12:08] <spiv> blaudden: that's always a risk with an automatic merge tool
[12:09] <blaudden> spiv: :)
[12:09] <spiv> blaudden: just because one branch adds a line here and another removes a line there, in non-overlapping parts of the code, doesn't mean there isn't a semantic conflict.
[12:10] <spiv> blaudden: a trivial example is a branch that adds an extra parameter to a function, and updates all the callsites to pass the new parameter.  If you have a branch that adds another call to that function, then merge the first branch in, you probably won't get an automatic conflict.
[12:10] <spiv> blaudden: but the code won't work
[12:11] <spiv> blaudden: so you ought to run the test suite and/or review the diff and/or do some other QA to check that the result is sane.
[12:12] <blaudden> spiv: yes, that example seems resonable
[12:12] <Peng> fredreichbier: Do you mean ftp or http, or some ungodly hybrid of the two? ;P
[12:12] <spiv> fredreichbier: not sure what you mean by "special" traffic.  It is just regular ftp/http, it doesn't do anything crazy.
[12:13] <spiv> You can abuse the server with regular traffic if you have enough of it, though ;)
[12:13] <Peng> fredreichbier: http mostly uses Range requests, which can confuse Squid. It also might make quite a lot of requests in a short amount of time, especially with a knit repo.
[12:14] <blaudden> spiv: In this example it's someone who changed part of the line, and in addition the order of that line and the line above has changed place in one of the branches.
[12:14] <fredreichbier> Peng: spiv: i mean http-pulling and ftp-pushing. thanks your your answer ;)
[12:15] <Peng> fredreichbier: You should use bzr+ssh or at least sftp. ftp sucks. It's not encrypted.
[12:15] <fredreichbier> Peng: i need access to the server to use bzr+ssh, and i don't have ,)
[12:15] <spiv> blaudden: please feel free to file a bug with that example if you think bzr ought to do better there, btw.
[12:15] <Peng> fredreichbier: What do you mean?
[12:16] <spiv> blaudden: our merges are generally very good, but there's always room for improvment
[12:16] <blaudden> spiv: ok, I'll see if I can make something reproducible...
[12:17] <fredreichbier> Peng: i thought i have to set up a bzr server (`bzr serve`?) on my server to use bzr+ssh, don't i?
[12:17] <spiv> fredreichbier: you just need bzr installed on the remote side
[12:17] <Peng> fredreichbier: For bzr+ssh, you need to have ssh access (duh), with bzr installed and in the PATH.
[12:18] <Peng> fredreichbier: bzr+ssh simply sshes in and runs "bzr serve --inet --directory=/".
[12:18] <Peng> fredreichbier: (Err, the process doesn't stay around like a normal "bzr serve". --inet causes it to close when you're done.)
[12:19] <spiv> Peng: (it also passes --allow-writes)
[12:19] <Peng> spiv: Oh, right.
[12:20] <fredreichbier> thanks Peng ;) I have a shared hoster without ssh access, that's the problem.
[12:20] <matkor> Hi ! What are options to make partial revert of file ?
[12:21] <matkor> I see that sb deleted too much changing few lines ...
[12:21] <Peng> fredreichbier: Um. You just have FTP? Hopefully not telnet..
[12:21] <Odd_Bloke> matkor: 'bzr shelve' in the bzrtools plugin might help.
[12:22] <Peng> fredreichbier: You should tell your host that it's the 21st century now.
[12:22] <matkor> Odd_Bloke: tnx checking ...
[12:23] <spiv> matkor: you could also try "bzr cat -r 1234 FILE > FILE.older" then "meld FILE.older FILE"
[12:23] <spiv> (where 1234 is the revision number)
[12:24] <spiv> (Also depends a bit on what you mean by "revert" I guess...)
[12:24] <sabdfl> spiv: thanks and congrats on the results of your landings in 1.6 - network performance is transformed here
[12:24] <spiv> sabdfl: excellent!  There's more to come.
[12:27] <sabdfl> pull is much faster - i'm close to the server in question so performance has never been an issue, but the change is noticeable nonetheless
[12:32] <fredreichbier> Odd_Bloke: :-) thanks
[12:55] <lifeless> sabdfl: thats great news
[12:57] <fredreichbier> uh. i did a wrong highlight :/
[13:42] <sabdfl> lifeless: yes, i bet it's really noticeable from .au!
[14:03] <sven_> hi! i have a problem where 'bzr merge --weave' resolves more than it should. in branch_1, i permute line 5 and 6. In branch_2, i replace line 5 by line 5.1 . 'bzr merge --weave' does not give a conflict; instead it outputs line 5.1, line 6, and line 5, in that order.
[14:04] <sven_> i would prefer to get a conflict. it is very dangerous to resolve like this without any human seeing it...
[14:08] <sven_> what is your position on this? does it look like a bug? shall i create a bug report?
[14:13] <spiv> sven_: off the top of my head I suspect that's working as intended.  To the merge algorithm a changed line looks like a delete and an add, so it would think both sides deleted the line (so they agree, no conflict), and then they both add some lines.
[14:14] <spiv> sven_: still worth a bug report, though.  It would be good to make the merge better than it already is.
[14:14] <blaudden> spiv: thanks! sven_ is trying to help me figure out what could be the problems we experience
[14:14] <sven_> spiv, thanks. yes, i suspected it was something like that. i'll file a bug
[14:14] <blaudden> spiv: how recomended is it wo use --weave ?
[14:15] <mtaylor> blaudden: still working on the ugly merge?
[14:15] <blaudden> blaudden: after having done it 20 times I start to learn :)
[14:15] <blaudden> mtaylor: ^
[14:15] <mtaylor> hehe
[14:16] <mtaylor> we should give the bzr guys the two branches as the are now as a worlds-worst-merge test case :)
[14:16] <blaudden> mtaylor: ok, I'll check it in....
[14:16] <mtaylor> hehe
[14:16] <mpt> Is there a quick way of asking bzr "Show me a diff of branch X compared to what branch Y would look like if branch Z was merged into it", without making a temporary branch that merges Z into Y?
[14:16] <radix> bzr merge --preview, maybe?
[14:16] <blaudden> bzr merge --preview ?
[14:17] <radix> It really only makes sense for two branches though
[14:17] <radix> like, "show me a diff of what branch X would look like if branch Y were merged into it"
[14:19] <mpt> hmm
[14:19] <spiv> mpt: You could get a very rough approximation with interdiff, I guess.
[14:21] <spiv> mpt: someone could probably write a plugin that does that operation for you without a temporary branch (although making it not simply hold the full temporary branch in memory would non-trivial)...
[14:21] <spiv> (but possible, I think)
[14:22] <mpt> meh, I'll just make the temporary branch :-)
[14:24] <spiv> mpt: yeah, I think that's the pragmatic answer :)
[14:24] <spiv> sven_: hmm, I cannot reproduce your bad merge
[14:25] <spiv> sven_: That is, I get a conflict on those lines.
[14:25] <sven_> spiv, i'm using 1.3.1. trying with development version...
[14:25] <sven_> spiv, did you use --weave?
[14:26] <spiv> sven_: I did.  And tried with --lca, too.
[14:26] <spiv> sven_: with bzr1.3.1
[14:26] <spiv> sven_: http://pastebin.com/m5efc4c3
[14:27] <spiv> sven_: (I get the same result with bzr 1.6b2 FWIW)
[14:27] <blaudden> spiv: nice way to reproduce
[14:28] <spiv> blaudden: it was about as literal an interpretation of your scenario as I could think of :)
[14:28] <blaudden> spiv: ok, we'll come up with something worse soon...
[14:29] <spiv> blaudden: :)
[14:31] <sven_> spiv, i reproduced it with this: http://pastebin.com/m48d554f9
[14:31] <sven_> spiv, by 'permute', i meant change the order of the lines without modifying the contents...
[14:32] <spiv> sven_: Oh I see
[14:33] <spiv> sven_: right, I can see why it does that
[14:34] <sven_> spiv, ok, why? :-)
[14:36] <spiv> sven_: IIUC it correctly, because in branch_1 it sees a line removed between lines 4 & 6, and a line added after 6.  In branch 2 it sees that same line removed between 4 & 6, and a new one added in the same place.
[14:37] <sven_> spiv, right.
[14:37] <spiv> sven_: So the removal is done by both sides, which is not considered a conflict (both sides took an identical action), so the only differences are adding two lines.  The two lines are added in different, i.e. non-conflicting, places.
[14:38] <spiv> And there's no ambiguity about where to insert those lines (the lines adjacent to the insertions didn't change).  So it doesn't consider it a conflict.
[14:38] <sven_> spiv, that makes sense from an algorithmic point of view. but still i think it is dangerous to merge this automatically.
[14:38] <spiv> sven_: all automatic merges are dangerous
[14:39] <Odd_Bloke> Danger, Will Robinson!
[14:40] <spiv> Many merge algorithms will tend conflict on this sort of change, because they will consider both sides doing the exact same thing as a conflict, so the parallel removals would cause a conflict here.  (Although typically a hard to understand one, conflicts involving removed lines always look confusing because the conflicting bit isn't visible).
[14:42] <spiv> We generally consider that aspect to be a feature though (instead of a confusing conflict, you get a merge with what both sides tried to do anyway), it's almost always what you want in our experience so far.  Maybe it'd be worth adding a --cautious or something, though
[14:42] <spiv> sven_: but there's nothing magic about line-based merging algorithms that can guarantee the result makes sense.
[14:43] <sven_> spiv, of course not.
[14:43] <sven_> spiv, but 'bzr merge' gives a conflict on these lines. however, we cannot use that since we have a criss-cross merge which results in 383 conflicts. otoh, we cannot use 'bzr merge --weave' if it does not give a conflict in this case...
[14:43] <spiv> Even when there's clearly no overlap in the lines touched you can have semantic conflicts.  You can't rely on the automated merge tool to give you something that makes sense.
[14:43] <sven_> spiv, i'm no merge algorithm expert, but could it be possible to give conflict if concurrent changes are "close" to each other (where "close" is a configurable number of lines)?
[14:44] <spiv> sven_: closeness doesn't matter
[14:44] <spiv> sven_: you can have incompatible changes in different files
[14:45] <spiv> sven_: i.e. one branch changes a function definition in one file to take a new parameter, another branch adds a new caller of that function using the old signature in a file the first branch doesn't touch.
[14:46] <spiv> sven_: any line-based merge will think there's no conflict there, as the changes aren't even in the same files.  But the result is broken and needs conflict resolution.
[14:49] <spiv> sven_: Anyway, it might be possible to make --weave/--lca more cautious so that it gives a conflict in that case (without making it so conflict-prone that it's as bad as --merge3).  So do file a bug, we want the tool to DWIM as much as possible.
[14:50] <sven_> spiv, ok, i'll file a bug
[14:50] <sven_> spiv, thanks for your help!
[14:50] <spiv> sven_: but it can never be perfect, unless you can supply it with an external merge tool that understands code rather than just lines of text :)
[14:50] <sven_> spiv, of course :-)
[14:52] <spiv> sven_: another option is that maybe we could make merge report warnings when it's assuming that identical changes by both sides don't conflict, or similar, so humans have hints about what's perhaps most likely to need checking.
[14:53] <spiv> Although really it may as well just generate a conflict in that case...
[14:54] <spiv> sven_, blaudden: finally, even though --lca doesn't produce .BASE file (which unfortunately breaks extmerge, which is a bug in extmerge I think), you could still invoke something like meld manually with the THIS and OTHER file.
[14:54] <blaudden> spiv: oh really. that seems nice
[14:55] <blaudden> spiv: is that that same with --weave?
[14:55] <spiv> It's not as helpful as when there's a BASE file, but I'm fairly sure meld can still help when there's just two sides.
[14:56] <spiv> blaudden: right.  --lca is basically always at least as good as --weave, btw.
[14:57] <spiv> (there's an obscure edge case it flat out can't handle yet which is why it isn't a total replacement, but in practice you might as well use --lca rather than --weave)
[14:57] <spiv> --lca is likely to become the default merge method in future.
[14:58] <blaudden> spiv: so you suggest that I try with "merge --lca" or just "remerge --lca" ?
[14:58] <blaudden> we should fix extmerge ...
[14:59] <pickscrape> I sent a patch through to the extmerge author a while back but it seems to have been ignored :(
[14:59] <pickscrape> (not for this problem, for something else)
[14:59] <blaudden> pickscrape: maybe it ws a problem with merging? :-)
[14:59] <pickscrape> :)
[15:00] <pickscrape> It was to give the use the option of which merge tool to use if he doesn't have one configured
[15:00] <pickscrape> Instead of the current hard-coded check order
[15:00] <spiv> pickscrape: that sounds useful.  Is your branch/patch on launchpad somewhere?
[15:01] <mpt> jam, thanks for all your help yesterday. After the reconcile (which finished overnight) the branch worked fine.
[15:01] <spiv> mpt: ah, glad to hear your problem is finally sorted out
[15:01] <pickscrape> It's not... Would I need a new project for that, or can I just upload it to my own area without attaching it to any project?
[15:01] <jam> mpt: good, though you probably shouldn't have needed to wait for the full repository reconcile, unfortunately
[15:01] <jam> the branch fix takes like 2sec
[15:02] <spiv> pickscrape: there's already a bzr-extmerge project on launchpad
[15:02] <pickscrape> Oh there is?
[15:02] <pickscrape> Am I able to just randomly register a new branch and push to it on that project?
[15:02] <spiv> pickscrape: you can just do "bzr push lp:///~USERNAME/bzr-extmerge/my-branch".  Or just file a bug and attach a patch :)
[15:03] <pickscrape> Ah right... I'll give that a go :)
[15:03] <spiv> Er, "lp:~USERNAME/bzr-extmerge/my-branch" would be fine, actually.  Not sure why I put the /// in there...
[15:04] <pickscrape> spiv: lp:~pickscrape/bzr-extmerge/choose-mergetool
[15:05] <spiv> pickscrape: thanks!
[15:10] <mpt> spiv, well, it's fixed in *that* branch. :-) There's another branch that's pretty much hosed because I tried to fix it by copying in an old copy of .bzr, when one of the merges I'd done since then was merging mainline
[15:10] <mpt> So now there's dozens of unknown files in the tree, some of which should be there, and some of which shouldn't
[15:10] <lifeless> mpt: erm, wtf. let bzr manage .bzr, you manage your working tree
[15:11] <mpt> yeah, I know that now
[15:11] <lifeless> mpt: why was it not obvious (how can we prevent other users doing the same thing)
[15:13] <mpt> lifeless, because that's what someone told me to do for the same problem last week
[15:14] <lifeless> who?
[15:15]  * pickscrape just used the launchpad "Propose for merging" feature for the first time.
[15:53] <jam> lifeless: when you have a broken dirstate (from a couple of older bugs) you can do "bzr co --lightweight" and then copy it back over
[15:53] <jam> it was the only recovery tool that we had
[15:53] <jam> I don't remember the specific problems
[16:58] <sven_> spiv, blaudden, i reported https://bugs.launchpad.net/bzr/+bug/238895
[16:58] <sven_> right
[17:27] <whitelynx> i'm using Bazaar to manage several projects with multiple users, and I'm running into an issue; when someone pushes a new branch to our repository, the permissions are set so that nobody else can write to it, and I have to go manually fix permissions so others can push to it. Is there any way to set a umask or something in the Bazaar configuration?
[17:28] <whitelynx> Also, I had to make everyone part of the same group and have them all default to that group to make the pushed branches have the correct group; however, this means I can't use multiple groups to manage permissions for different projects because whenever someone pushes, it always pushes as their default group
[18:11] <blaudden> sven_: I updatede your report with the result we get.
[19:09] <fredreichbier> if i try to push over sftp, i get an Permision Error with ".bzr/README.tmp.1213121278.758560896.7992.40354623", but it creates the branch directory. what can i do?
[19:15] <fdv> lifeless: I've been looking at this issue with the KnitCorrupt error I talked about earlier. Isn't what I want essentially 'unpull'?
[19:19] <fdv> lifeless: And couldn't this be accomplished somehow by a pull --overwrite with an appropriate revision range?
[19:41] <MvG> Is Jan Hudec present here?
[21:32] <tethridge> please excuse me for asking again, but does anyone know of a project similar to bzr-svn for clear case?
[21:32] <tethridge> Somebody told me that they had heard that somebody was using it internally at work, but they didn't know who.
[21:33] <tethridge> I've been asking through different times of the day in the hopes that somebody would know something.
[21:37] <mwhudson> tethridge: the most knowledgeable people are probably going to appear in 1-2 hours
[21:38] <tethridge> mwhudson, I'll try again then.  Do you have some usernames that I should look for?
[21:47] <beuno> tethridge, actually, you might even get a better response from mailing to the list
[21:47] <beuno> morning mwhudson
[21:47] <tethridge> good idea
[21:50] <abentley> mwhudson: I wouldn't say that exactly.
[21:50] <tethridge> I'm going to try both
[21:50] <abentley> jam and I are pretty knowledgeable.
[21:51] <abentley> It's just that idling here isn't what I'm paid for.
[21:52] <tethridge> abentley, know anything about a clear case plugin?  :-)
[21:52] <tethridge> oh, and you get paid?
[21:52] <abentley> tethridge: No, I haven't heard of any such thing.
[21:52] <tethridge> I'm getting screwed
[21:52] <abentley> tethridge: I work on the bazaar-launchpad team.
[21:53] <tethridge> ah
[21:53] <tethridge> just kidding
[21:53] <abentley> I'm not too up on the proprietary stuff.  What is ClearCase again?
[21:54] <abentley> i.e. are you looking for an IDE plugin or an import/export plugin?
[21:57] <matkor> Hm. Why when I try bzr push lp:~matkor/wicd/experimental-matkor I get bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ematkor/wicd/experimental-matkor/.bzr/repository/lock): Transport operation not possible: http does not support mkdir ? Why bzr tries to use http ?
[21:58] <jelmer> matkor: the launchpad plugin uses http if you haven't logged in
[21:58] <jelmer> matkor: try "
[21:58] <jelmer> bzr lp-login"
[21:58] <jelmer> or something
[22:00] <matkor> jelmer: I see .. thanks a lot !
[22:37] <mwhudson> oh man, i have some mailing list posts to write, it seems!
[22:44] <mwhudson> beuno: simpletal looks interesting
[22:45] <beuno> mwhudson, more than pylons + mako?
[22:45] <mwhudson> beuno: well, i dunno
[22:45] <mwhudson> as i said, i kind of hate non-tree templating
[22:45] <mwhudson> but if you're the one doing the work ... :)
[22:46] <mwhudson> beuno: what does pylons use for the http part?
[22:47] <mwhudson> (where turbogears uses cherrypy)
[22:47]  * beuno looks
[22:49] <beuno> mwhudson, it seems to use wsgi
[22:50] <mwhudson> uhh
[22:50] <mwhudson> is that actually an answer to the question?
[22:50] <mwhudson> i guess it is
[22:50] <beuno> well, yes and no  :)
[22:50] <beuno> "paste"
[22:50] <mwhudson> i guess it means you can plug in ~whatever http server you like
[22:51] <beuno> By default Pylons uses paste's httpserver
[22:51] <mwhudson> which would be good because cherrypy makes the baby jesus cry
[22:51] <beuno> "You could stick to it or use something different, say one from CherryPy 3.0"
[22:51] <mwhudson> cherrypy 3 is ok, afaict
[22:51] <beuno> so if you still feel like you need pain on a daily basis, we can stick with it  :p
[22:52] <beuno> the cool thing is that pylons has kid/genshi too
[22:52] <mwhudson> well
[22:52] <mwhudson> i am still skeptical that loggerhead benefits from _anything_ that's in the django/turbogears/pylons/zope category
[22:53] <mwhudson> really SimpleHTTPServer + some templating engine should be enough
[22:53] <mwhudson> (for the plugin version, not what we do on lp)
[22:53] <beuno> yeah, SimpleHTTPServer would be the best way to go
[22:54] <mwhudson> i guess we may want slightly more sophistication, because we do want to set http headers occasionally
[22:54] <mwhudson> so maybe wsgi would be an appropriate interface to aim for
[22:56] <beuno> mwhudson, I believe the dependency issue for ZPT is enough reason to look into other options sooner than later. What do you think?
[22:57] <mwhudson> beuno: i think if simpletal can work, then that's a small enough dependency
[22:57] <beuno> mwhudson, I'll check and see what changes have to be made
[22:58] <mwhudson> beuno: *i* already have too many half-finished not-really-sure-if-it's-a-good-idea loggerhead branches around
[22:58] <mwhudson> beuno: i don't want you to start collecting them too :)
[22:58] <beuno> in fact, I'll do it now, while I wait for lifeless to wake up and I can complain about bzr-search
[22:58] <beuno> heh
[22:58] <beuno> ok, so you want the other 2 patches first  :)
[22:59] <mwhudson> well, let's see about simpletal
[22:59] <beuno> the ZPT thing just itches too much, at least to move it into trunk
[22:59] <mwhudson> on first blush, it seems like the changes required would be fairly minor
[23:00] <beuno> ok, so I'll take a shot at simpletal now, and, if it's simple enough, I'll re-send the last patch with simpletal, and the other 2
[23:00] <beuno> seem ok?
[23:00] <mwhudson> i will give turbogears some credit, it nicely encourages loose coupling
[23:00] <mwhudson> beuno: +1
[23:01] <mwhudson> if nothing else, i think refactoring from the zpt templates to something else might be easier than refactoring the kid templates
[23:01] <mwhudson> because i think i cleaned up the templates a bit when i rewrote them
[23:01] <beuno> absolutely, I've been doing all my work based on your zpt branch
[23:02] <beuno> kid is a bit icky, but it may be the cleanup too
[23:02] <beuno> either way, there may be some portions of the zpt patch you may want to look at, the non-template bits
[23:03] <mwhudson> phone brb
[23:11] <beuno> ah, lifeless, finally  :)   good morning
[23:20] <jelmer> hmm, post-push hooks don't appear to be working when creating a new branch
[23:25] <mwhudson> beuno: ok, back
[23:26] <beuno> mwhudson, I can't find a clear way to use simpletal with TG...  :/
[23:27] <beuno> documentation on simpletal is a bit...  "lacky"
[23:27] <mwhudson> well, i guess you need to hackerize the turbozpt package that zpt-templating includes
[23:29] <beuno> I can't get TG to use simpletal at all
[23:29] <beuno> and google isn't really being helpful
[23:29] <mwhudson> let me have a go
[23:29] <beuno> many people saying they want to move to, but none that actually did
[23:30] <mwhudson> i see
[23:32] <beuno> argh, simpletal is only available for 2.4...
[23:32] <beuno> packaged in Ubuntu at least
[23:33] <mwhudson> ?
[23:33] <mwhudson> mwh@grond:~/canonical/repos/loggerhead/trunk$ python2.5 -c 'import simpletal'
[23:33] <mwhudson> mwh@grond:~/canonical/repos/loggerhead/trunk$
[23:33] <beuno> ah, no, ignore me
[23:33] <beuno> I really have to do a fresh install
[23:34] <beuno> anyway, there doesn't seem to be integration into TG, or am I missing something?
[23:34] <mwhudson> no, there probably isn't
[23:34] <mwhudson> but that's ok, we can write it
[23:36] <beuno> is it still worth it if we have to?
[23:36] <mwhudson> i really don't think it will take very long
[23:36] <tethridge> anybody heard of a clearcase plugin similar to bzr-svn?
[23:36] <tethridge> last time I'm asking
[23:36] <tethridge> :-)
[23:36] <jelmer> tethridge: I don't think there is one
[23:37] <tethridge> I was told that supposedly somebody was working on one for internal use at their company
[23:37] <tethridge> don't know who though
[23:37] <beuno> mwhudson, alright, I'm not very familiar with that area, but I'll give it a try
[23:37] <mwhudson> beuno: let me try first :)
[23:38] <beuno> yay!  :)
[23:38] <mwhudson> beuno: is the latest version of the zpt branch on launchpad somewhere?
[23:38] <bob2> tethridge: maybe someone on the list will know
[23:38] <tethridge> I'm going to try that
[23:39] <beuno> mwhudson, I have 3 zpt branches. 1) is that patch I sent to the list, which I can upload if you want. 2) is zpt+ajax+cleanups, 3) is list patch + cleaner URLs
[23:40] <mwhudson> beuno: ok, i'll use the bundle
[23:41] <mwhudson> bundles are awesome