User1: actually, that's not quite it, I actually deleteed those files and created new files as symlinks so they don't have a bad history.
User1: The only files that are messed up are images.
User1: other symlinks are fine.
User1: I recently changed all images including symlinks by adding a svn property svn:mime-type and committed.
User1: When I realized I also modified symlinks, I then droped that property from all symlinks and checked them in.
User1: so all image symlinks now have a history of add, followed by propset, and now propdel.  Other symlinks only have a history of add.
User1: No symlinks have their svn:special modified.
User2: who does bzr-builddeb?
User2: I'm having a weird issue with it and an interaction with pdebuild
User2: some files in the diff (specifically ones in debian/source/include-binaries aren't making it in to the tree when I use pdebuild ... but when I use --builder='debuild' it does the right thing
User3: User2 james_w
User2: User3 thanks
User2: User6 ^^ :)
User2: User6 if you are so inclined, you can reproduce by grabbing lp:~drizzle-developers/pkg-drizzle/trunk and then running bzr bd --builder='pdebuild' ... it will churn for a while and then fail on the information_schema test
User4: Good morning.
User5: User2 *sounds* like the problem is more likely pbuilder than bzr-builddeb
User5: Try reproducing it without bzr-builddeb in the picture?
User2: User5 I haven't ... I'll try that next - although usually bzr bd is the one assembling everything for me, so I'll have to spend a few moments making sure I'm doing the same thing
User6: User2 please file a bug
User6: I'll look at it, but can't right now, and don't want to forget
User2: User6 ok. will do
User2: User6 filed. thanks! (I'm just using normal debuild for now, so I've got a workaround and stuff)
User6: great, thanks
User7: Can anyone answer a bzr vs. git question? Is there anything similar to git pull --rebase in bzr? I made some changes to my tree, and there were upstream changes. Can I pull them in and have the log be as it should have been had I been up to date in the first place?
User8: Not in one command anyway.
User9: User7 bzr has the slight tendency to regard that as a non-goal
User9: generally by having 'log' behave a bit differently and having commands like bzr missing
User7: mwhudson, so bzr says just merge and deal with the merge commits?
User9: yeah
User7: eh, ok
User10: User7 The bzr-rewrite plugin provides the functionality that you seek, but it's discouraged.
User7: wgrant, yeah, I'll just accept the merge commit. I've just gotten used to the git model while working on Banshee.
User11: hi all !
 * fullermd pdavis@example.com.
User11: \o_
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | bzr 2.2-final has gone gold, build those installers
User12: hello
User12: I'm trying to understand how I can fit a bzr shared repo structure on a hudson build structure
User11: User12 create it a level above the or at the 'workspace' directory
User11: User12 make sure to issue 'bzr reconfigure --use-shared' in the existing job directories after creating the repo
User12: ok, I have an existing bzr chckout, are you saying its possible to convert it to a shared instance?
User11: User12 yes
User12: nice!
User11: User12 create the shared repo *above* your checkout (where exactly depends on your setup and how wide you want to share) with 'bzr init-repo .'
User11: User12 then, *in* your working trees (where there is a '.bzr' directory) do: 'bzr reconfigure --use-shared'
User11: User12 alternatively delete all your checkouts after creating the repo
User11: User12 hudson should re-recreate them and bzr will then find the shared repo and use it
User12: the bzr server is very slow in this case, so id rather reuse the checkout if at all possible
User12: in this case the structure looks like this: /var/lib/hudson/jobs/emacs-trunk/workspace/
User12: /var/lib/hudson/jobs/emacs-imagemagick/workspace/
User11: User12 then create the shared repo at /var/lib/hudson/jobs/emacs-trunk
User11: err, oh, in this case, you may even want: /var/lib/hudson/jobs
User12: but the sibling is emacs-imagick?
User12: yes, but will bzr notice when the shared repo is not the immediate parent?
User11: you should issue 'bzr reconfigure --use-shared' in all workspaces
User11: User12 yes, any level up
User12: hmmm
User12: good!
User11: User12 if you have other bzr branches below /var/lib/hudson/jobs, it's up to you to leave them as standalone branches or reconfigure them to also use the shared repo
User12: ok
User12: the imagemagick dir is a failed  tandalone bzr checkout
User11: User12 if you want to create standalone branches under a shared repo, use 'bzr branch --standalone'
User12: ok
User11: User12 failed ? How ? Why ?
User12: well I tried to initialize it from the savannah bzr repo for emacs from the imagemagick branch, using the hudson bzr plugin. I got a python exception
User11: User12 and the exception was related to what ?
User12: I can maybe paste the trace somewhere
User11: !paste
User13: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
User12: http://paste.ubuntu.com/483316/
User11: User12 worth filing a bug
User11: User12 you may also want to upgrade to 2.2final
User12: yes, thats why I dodnt file yet :)
User12: I'm atm trying to see if theres new rpms for fedora yet
User11: User12 anyway, once you have the shared repo set up, you may *deleted* the checkout under /var/lib/hudson/jobs/emacs-imagemagick/workspace/ and let hudson re-recreate it (it should use the shared repo and shouldn't need to download a lot)
User12: thanks
User11: s/*deleted*/*delete*/
User12: great!
User4: User11 hah, I just found one reason why 'bzr status' was taking 25s for that gcc-linaro dev: https://bugs.edge.launchpad.net/ecryptfs/+bug/613873
User13: Launchpad bug 613873 in eCryptfs "stat mtime on encrypted fs doesn't match between calls (affected: 1, heat: 11)" [Medium,Confirmed]
User11: User4 urgh
User11: User4 I thought we rounded the mtime ? Or is it on windows only ?
User4: User11 hmm!
User4: Oh, heh:
User4: Oh, hmm.
User8: Oh hah, oh hey, oh huh.
User4: User8 harumph!
User8: That's not 3 letters long!
User4: User11 I was going to suggest that maybe rounding of x.11 vs x.99 might account for it, but at a glance we truncate to an int towards zero.
User11: and the int contains the mtime in what resolution ?
User4: User11 seconds
User11: wow
User4: User11 you've ruined my beautiful theory :(
User8: How cruel   :(
User11: User4 not sure about that, in the bug you point there is a difference > 0.5 seconds, so it can still apply
User4: User11 but only in the sub-second part of the value
User4: User11 if we always truncate the time towards zero, and we do, then I think we discard exactly the bits that might be wrong.
User11: User4 the bug example starts a 11:14:40.000000000, nothing says it can't start at 11:14:40.5 and still get a adjustment
User11: User4 then the first stat can say 11:14:40 and the second 11:14:41
User4: Not on my reading of the bug.
User11: User4 right, a strict reading invalidates your theory but I still think it's worth subscribing to the bug and ask lool if he can reproduce then bug when not using ecryptfs
User4: Judging from the comments, it appears that ecryptfs isn't reliably conveying the sub-second part of mtime.  There's nothing there that suggests to me that the whole seconds part will ever be wrong.
User11: User4 right, but nothing either to disprove it
User4: This sounds like essentially the same bug the whole linux kernel itself had a few years ago.
User11: User4 and one bug in this area says to me that there may be others too...
User4: (Individual filesystems started to support subsecond mtimes etc, but the in-memory inode cache only held whole seconds, so you got different answers from lstat depending on if the data came from disk or cache)
User4: User11 I certainly agree with the "there may be other bugs" theory :)
 * spiv updates the bug
User11: User4 the bug report itself is a gem...
User11: User4 gentle nudge to the pp, I've put many wip mps back the review queue (and as such addressed your request about looking at the wip queue :-)
User12: now I get an exception while converting to shared format
User12: http://paste.ubuntu.com/483334/
User12: I cant seem to find 2.2 final rpm:s for fedora 13
User12: any suggestions?
User14: is there any way to check the version of bzr that the remote smart server is using?
User8: There's a ping plugin that shows it...
User4: User14 install lp:bzr-ping, then 'bzr ping URL'
User14: User4 ta
User14: User8 thanks too
User15: bzr-svn seems to be rather easier to cope with than git-svn ....
User11: User12 sorry, didn't see your msg earlier
User11: User12 that sounds like a corrupted repo :-/ cd into your .bzr/repository/packs and issue 'md5sum *.pack'
User11: User12 the md5 sums should match the file names
User16: hey
User16: in which section of NEWS should I put the mention of deprecation of parameters passed to function?
User12: User11 ok Thanks
User12: I'm beginning to suspect my machine isnt quite feeling well
User11: User12 most of the time reported corruptions are due to hardware failures or really rude shutdowns
User11: hey bialix
User16: bonjour vila!
User11: User16 could be 'Compatibility breaks' or 'New Features' or 'Improvments', it depends
User11: User16 there is also 'API changes'
User11: User16 reviewers will whine if needed anyway ;)
User16: API changes for now seems appropriate for me
User16: hmm, but poolie put deprecation news into Compatibility breaks. poolie knows better!
User17: I could use some help with a broken branch :-(
User17: getting crash reports
User11: User17 !paste ?
User11: !paste
User13: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
User18: Where can I find a non-handwavy documentation on what --reprocess does?
 * fullermd is not aware of one.
User18: I had a look at bialix kftp plugin, for cached ftp, and thought about using a disk-backed cache instead of a dict.
User18: I don't *really* need it, but I thought it would be a Good Idea.
User18: I woud like to use a temporary anydbm for that. So I would like to know when the transport is done, so I can delete the cache.
User18: But it seems that Transport has no notion of "close()", allowing to release resources.
User18: So, how can I know I when can delete the disk cache? A hook maybe?
User18: (preferrably, something not involving __del__)
User19: What does "rich root" mean?
User11: User18 the question may be *when* to you want to invalidate a cache entry ? IIRC bialix plugin is mainly targeted at .pack files which by definition never need to be invalidated...
User11: s/to you/do you/
User18: User19 that the root has a file-id. That's needed at least by bzr-svn, and will be needed for nested trees in the upcoming bzr 2.3.
User11: User18 the 2a format is already rich-root aware and the default
User19: ah, as in the root directory has the same stuff that a subdir has?
User18: User11 not only pack files, but indexes, any stuff, ftp is not particularly latency-efficient.
User11: User18 indexes are as immutable as their respective pack file
User18: User11 also, the question is "when can I delete the cache, because I don't care to keep it across invocations, and I don't want to waste disk space."
User18: User11 so, you're saying that .pack, .cix, .iix, .rix, .six, .tix files are all write-once?
User11: User18 there is no '.close()' for transports, there is a '.disconnect()' in a proposed patch, but I don't think it will work for you
User11: User18 given that md5sum xxx.pack == xxx, yes
User18: Well, that's something. At least there are no invalidation semantics to worry about.
User11: User18 in that case .disconnect() can more or less do the trick unless errors occur and we need to reconnect :-/
User11: User18 otherwise... that's atexit or __del__ or ... hooks for all high-level operations. None of which is especially appealing, but that's ftp...
User11: the lack of a proper readv implementation for ftp doesn't fit well with the pack idea
User18: I guess I can be happy enough with an infinitely persistent cache in ~/.cache/bazaar
 * fullermd will be very happy the day FTP dies the death it should have freakin' died last millennium...
User11: User18 except some pack files will be deleted from the server when a repack occur...
User20: is there any documentation on how to setup PQM? I tried checking the admin guide and even tried looking on the trunk /doc/en/admin-guide doc directory, but PQM is still empty. I'd have no problem documenting it if I knew how to use it :( If not documentation exists, can someone point me in the right direction on how to go about learning about it?
User20: ... if no documentation exists* ...
User18: User11 ack that... thinking of it, the right approach might just be atexit(), because of the "single process" limitation of anydbm.
User18: and ~/.cache/bazaar is the right place anyway because of encrypted home considerations.
User18: thanks, I now have a solution that makes me happy
User11: User18 but why do you want to use anydbm when a transport is associated with a single directory where each path is unique ?
User18: User11 out of laziness, because the kftp code uses a dict, and anydbm does too.
User11: User18 that's a good reason :)
User18: User20 offering beer, ham and eggs to lifeless would probably be a move in the right direction :-)
User20: User18 I'll offer my first born if that's what it takes [note, I'd have to create a first born first ;)]. But I'd be willing to offer to write official documentation if he just helps me understand it over the course of the next month or so. I've got some time. I'll hit him up on stuff. In the mean time I'll just get a branch and poke around.
User18: User20 last time I checked, lifeless was not interested in eating babies anymore, being on a diet and stuff...
User8: Eh, you just need to stay away from the legs.  The wings are pretty lean.
User20: User18 ah, that's too bad. I'd seriously send him a case of whatever beer he wanted though ;). I'll ping him when I have some questions. I don't even know quite where to start yet
User18: User8 that's interesting, I would be interested in eating cherub wings.
User8: Everybody is.  That's why they're so rare, see.
User20: I've found that if you cook them in baby oil you get a very nice distinct flavor.
User8: Better texture if you coat them with baby powder first.
User18: User8 what do you use to make the batter with baby powder?
User15: cornflour
User15: baby powder is mineral in origin and only suitable for dusting
User18: User15 I'm sure it's fine for cooking cherubs
User15: I'm told rice flour makes a nice light crispy tempura better
User15: Although I suspect a nice sticky teriyaki glaze may be better
User16: hi
User16: what does "readv" mean?
User16: hi jam
User21: User16 Transport.readv() look in bzrlib/transport/__init__.py
User21: FTPTransport *should* provide a custom one, but it relies on the base "get + seek + read" behavior
User11: User16 I think about it as read-variable, you give it a list of (offset, size) to read from a file
User16: jam, err, I wonder to know what actually readv stands? read vectors?
User11: yeah, vector is even better
User18: I think it mean "read vectorized"
User11: User16 thanks :)
User16: User18 thanks
User18: http://www.opengroup.org/onlinepubs/009695399/functions/readv.html
User16: User21 re Ftp: as I can see from SFTP implementation I should implement _readv
User22: one thing I miss from loom with pipeline is the way 'bzr st' would tell me which thread of the loom I was using.
User21: User22 I use my shell for that
User22: meh.
User21: User22 specifically, in each checkout I have it show me the branch name
User22: ahh.
User22: I rarely use 'switch', so that works less well for me.
User21: User22 I have a C program that works pretty well: https://code.edge.launchpad.net/~jameinel/+junk/my_nick
User22: User21 thanks.
User21: You need to adapt the Makefile a bit for Linux vs Windows
User21: that way you don't pay the import bzrlib overhead just to run 'ls' :)
User21: PS1="\[\e]0;\h \w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w$(/home/jameinel/bin/my_nick.exe)\[\e[0m\]\n\$"
User15: jam, If you're using powershell you could write the nick thing as ps script
User15: Shouldn't have too much overhead since you already loaded powershell to run powershell
User21: User15 except I don't ever run powershell :)
User15: User21 Fair enough, are you using cygwin bash?
User21: yes
User15: I just can't imagine anyone using CMD.exe for more than 10 minutes
User15: Although I suppose cygwin uses cmd.exe as it's terminal
User18: nope, it uses it's own terminal emulator
User18: that's considerably less sucky than cmd.exe, not that is saying much
User15: ddaa, That's odd, because when I open cygwin, I get cmd.exe appearing in my process list :-)
User18: really? I had this impression
User8: Usimg cmd.exe does tend to leave an impression.  Head-shaped.  On the desk.
User15: I think cmd.exe is probably a terminal but the usual shell it runs is bobbins
User8: Or vice versa, depending on the relative quality of your furniture and calcium in your diet...
User15: I have an animated gif of that
User15: Even powershell runs in what is essentially the same terminal
User23: cmd.exe is the commandline interpreter
User23: it's what command.com used to be
User22: How do I test code that uses SMTPConnection?
User15: Make a mock SMTP server?
User15: Or even a mock SMTPConnection
User22: Yeah, that's roughly what I'm doing now.
User22: Was hoping bzrlib might have one
User22: but grep doesn't seem to reveal any.
User15: User learning to use cmd.exe and DOS batch script after using bash : http://imagebin.ca/view/E2RHNegX.html
User8: Yeah, I've seen that used as a forum avatar.
User15: I wonder if it will work as a Skype avatar...
 * fullermd . o O ( bash?  People actually use that? ) O o .
User15: fullermd, Are you one of those dirty .... Korn shell users?
User8: Oh, heck no.  I'm a sparkly clean C shell user   8-}
User23: User8 Cshell? Oh dear
 * Kinnison disassociates himself from fullermd
User8: It's too late.  You're marked.
User21: jml, User15 class StubSMTPFactory(object):
User21: in bzrlib/tests/test_smtp_connection.py
 * awilkins looks at the C Shell page on Wiki and likes it
User15: Marked... and spreading the infection
User22: jam, thanks. I saw that, but it's stubbing at a level below the one I care about.
User11: C shell... I feel 20 years younger :-)
User8: As if you were bourne again?
User8: Wait.  That's backward...
User11: It's too late.  You're marked.
User8: Aiee!  Unclean!  Unclean!
User8: If you could port testtools/subunit, we could run the test suite   ;)
User8: No particularly good idea.  Probably.
User8: I know vila has it locally installed in his testing VM; he'd know if there was anything nontrivial about getting it working.
User8: No, they're not plugins, they're regular python libs.
User11: C-S: well done !
User11: C-S: from the release tarball ?
User11: C-S: credits.pickle ?
User11: C-S: yeah, one command to generate it... let me find it back
User8: So, you cuked it?  ;)
User11: C-S: : That's not what is called "taking credit" :-D
User8: There's a certain joy in looking at a pristine upstream tarball...  then slapping a brute force hack over it to get the port to build.
 * fullermd looks pointedly at the apport stuff in bzr...
User11: C-S: I know, whoever created the tarball forgot about it
User11: There is a wiki page I can't find back describing the release process
User11: C-S: yet, http://wiki.bazaar.canonical.com/bzr-gtk mention FreeBSD and how to install it...
User11: C-S: hehe, you added that :)
User11: C-S: here we go: http://wiki.bazaar.canonical.com/bzr-gtk/releasing
User11: 3. Update the credits pickle file by running python ./setup.py build_credits
User11: C-S: ok, just mentioning in case your patch broke something
User8: Oh, if it does, we'll just blame it on upstream   8-}
User11: C-S: as fullermd said, bringing testtools and subunit would be great
User11: testtools is pure python, subunit includes a python implementation so may be a bit harder
User11: testtools is pure python, subunit includes a python implementation (of the subunit protocol) so may be a bit harder
User11: C-S: I run them from sources as I often need the trunk version
User11: C-S: testtools is required as it provides some more stuff than the python unittest module
User11: C-S: subunit... I don't remember if it's strictly required or not, but it helps streaming the test suite results and I need that for running under hudson control
User11: C-S: in short: none of them are required to *use* bzr, but help a lot to *test* bzr
User8: subunit was required for --parallel back before testtools was pdavis@example.com.
User11: C-S: yes, the best way to check is to run 'bzr selftest'
User24: User11 couple of questions on my test cleanup merge proposal branch if you're still around
User24: you mentioned you get 2000 tests which complain about leaking even with the testtools change, can I have that list?
User24: also, what change to bb.test_log using addCleanup would deal with the cycle? because I'm not seeing it.
User8: C-S: You probably want that to by devel/py-testtools...
User8: That's a different problem.  That's paramiko puking on up-to-date pycrypto.
User8: I "solved" that by just dumping paramiko off my system   :|
User8: Can't today.  It's way late (in my head).  I'm just fiddling with some relatively mindless stuff before I fall over.
User6: User2 hey, interesting problem you've found here
User6: I've reproduced the failure locally now
User6: User2 just to confirm http://paste.ubuntu.com/483616/ is the test failure you were referring to?
User6: looks like it from the log that you provided
User6: the source package contains that file in the debian.tar.gz, which indicates to me that debian/source/include-binaries isn't the cause
User6: are you sure that it's not just something like that test giving different output in a chroot?
User25: hello
User26: is there any way of getting bzr-svn to save the authentication credentials?
User2: User6 yes. that is it
User2: User6 it would be _very_ unlikely for that to generate different results in a chroot, but I suppose that anything is possible
User2: User6 should I try spinning up a chroot and checking manually?
User6: User2 I'm doing that if you can help me verify
User6: User2 firstly, installing diff doesn't seem to change the output :-)
User2: User6 well that's a good step :)
User2: btw - I really hate that test case - the binary null that's in it just causes no end of headaches
User6: no, I mean that it still complains that it can't run "diff" :-)
User2: ah. heh
User2: I should file a bug about that...
User2: or just replace the test running system - but I digress
User6: that's always the solution
User6: User2 is DATA_DICTIONARY supposed to be 39 or 40 in the package?
User6: 40 it seems
User2: User6 oh - sorry - I was distracted spinning up a chroot :)
User6: so it looks to me as though it is correct in the source package, but is unpacked incorrectly
User2: weird
User6: though I'm not overly familiar with the v3 format
User2: me either - still learning it myself
User6: and I can't unpack the source package on lucid apparentl
User2: wow. that's fantastic
User6: so the source package that is created by pdebuild outside the chroot is different from the one that it creates in the chroot just as it starts building
User6: no, that's not true
User9: does "Exception AttributeError: "'SmartSSHClientMedium' object has no attribute '_ssh_connection'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://pdavis@example.com/)> ignored" ring any bells for anyone?
User24: yes.
User24: it rings the "can't write __del__ methods properly" bell.
User9: oh right
User9: the real error is
User9: bzrlib.global_state.cleanups.add_cleanup(self.flush_all)
User9: AttributeError: 'NoneType' object has no attribute 'cleanups'
User24: that one I haven't run into.
User9: ah strange
User9: so if (a) you open a branch over bzr+ssh (b) you haven't called bzrlib.initialize() (c) you have hpss in debug_flags
User9: then you'll get that error
User24: initialize is an ever-growing pain.
User24: just give in and always call it.
User9: funnily enough
User9: i think i started the chain of events that led to it being added
User9: because this script that's now failing
User9: would blow up if you didn't install a ui factory
User27: User26 hi
 * jelmer waves
bzr
Ubuntu IRC