| sttng359 | 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. | 00:05 |
|---|---|---|
| sttng359 | The only files that are messed up are images. | 00:05 |
| sttng359 | other symlinks are fine. | 00:06 |
| sttng359 | I recently changed all images including symlinks by adding a svn property svn:mime-type and committed. | 00:06 |
| sttng359 | When I realized I also modified symlinks, I then droped that property from all symlinks and checked them in. | 00:07 |
| sttng359 | so all image symlinks now have a history of add, followed by propset, and now propdel. Other symlinks only have a history of add. | 00:08 |
| sttng359 | No symlinks have their svn:special modified. | 00:09 |
| mtaylor | who does bzr-builddeb? | 00:34 |
| mtaylor | I'm having a weird issue with it and an interaction with pdebuild | 00:34 |
| mtaylor | 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 | 00:36 |
| lifeless | mtaylor: james_w | 00:37 |
| mtaylor | lifeless: thanks | 00:38 |
| mtaylor | james_w: ^^ :) | 00:38 |
| mtaylor | james_w: 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 | 00:39 |
| spiv | Good morning. | 01:06 |
| maxb | mtaylor: *sounds* like the problem is more likely pbuilder than bzr-builddeb | 01:09 |
| maxb | Try reproducing it without bzr-builddeb in the picture? | 01:09 |
| mtaylor | maxb: 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 | 01:16 |
| james_w | mtaylor: please file a bug | 02:21 |
| james_w | I'll look at it, but can't right now, and don't want to forget | 02:21 |
| mtaylor | james_w: ok. will do | 02:23 |
| mtaylor | james_w: filed. thanks! (I'm just using normal debuild for now, so I've got a workaround and stuff) | 02:29 |
| james_w | great, thanks | 02:29 |
| lamalex | 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? | 04:33 |
| fullermd | Not in one command anyway. | 04:38 |
| mwhudson | lamalex: bzr has the slight tendency to regard that as a non-goal | 04:39 |
| cody-somerville | I think there is a plugin that allows you to rebasing like that | 04:39 |
| mwhudson | generally by having 'log' behave a bit differently and having commands like bzr missing | 04:40 |
| lamalex | mwhudson, so bzr says just merge and deal with the merge commits? | 04:40 |
| mwhudson | yeah | 04:40 |
| lamalex | eh, ok | 04:41 |
| wgrant | lamalex: The bzr-rewrite plugin provides the functionality that you seek, but it's discouraged. | 05:42 |
| lamalex | wgrant, yeah, I'll just accept the merge commit. I've just gotten used to the git model while working on Banshee. | 06:03 |
| vila | hi all ! | 07:12 |
| * fullermd waves at vila. | 07:14 | |
| vila | \o_ | 07:17 |
| === 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 | ||
| jave | hello | 08:32 |
| jave | I'm trying to understand how I can fit a bzr shared repo structure on a hudson build structure | 08:33 |
| vila | jave: create it a level above the or at the 'workspace' directory | 08:36 |
| vila | jave: make sure to issue 'bzr reconfigure --use-shared' in the existing job directories after creating the repo | 08:38 |
| jave | ok, I have an existing bzr chckout, are you saying its possible to convert it to a shared instance? | 08:41 |
| vila | jave: yes | 08:41 |
| jave | nice! | 08:41 |
| vila | jave: create the shared repo *above* your checkout (where exactly depends on your setup and how wide you want to share) with 'bzr init-repo .' | 08:42 |
| vila | jave: then, *in* your working trees (where there is a '.bzr' directory) do: 'bzr reconfigure --use-shared' | 08:42 |
| vila | jave: alternatively delete all your checkouts after creating the repo | 08:43 |
| vila | jave: hudson should re-recreate them and bzr will then find the shared repo and use it | 08:43 |
| jave | the bzr server is very slow in this case, so id rather reuse the checkout if at all possible | 08:43 |
| jave | in this case the structure looks like this: /var/lib/hudson/jobs/emacs-trunk/workspace/ | 08:44 |
| jave | /var/lib/hudson/jobs/emacs-imagemagick/workspace/ | 08:44 |
| vila | jave: then create the shared repo at /var/lib/hudson/jobs/emacs-trunk | 08:44 |
| vila | err, oh, in this case, you may even want: /var/lib/hudson/jobs | 08:45 |
| jave | but the sibling is emacs-imagick? | 08:45 |
| jave | yes, but will bzr notice when the shared repo is not the immediate parent? | 08:45 |
| vila | you should issue 'bzr reconfigure --use-shared' in all workspaces | 08:45 |
| vila | jave: yes, any level up | 08:45 |
| jave | hmmm | 08:45 |
| jave | good! | 08:45 |
| vila | jave: 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 | 08:46 |
| jave | ok | 08:46 |
| jave | the imagemagick dir is a failed tandalone bzr checkout | 08:47 |
| vila | jave: if you want to create standalone branches under a shared repo, use 'bzr branch --standalone' | 08:47 |
| jave | ok | 08:47 |
| vila | jave: failed ? How ? Why ? | 08:48 |
| jave | 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 | 08:49 |
| vila | jave: and the exception was related to what ? | 08:50 |
| jave | I can maybe paste the trace somewhere | 08:50 |
| vila | !paste | 08:50 |
| ubot5 | 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. | 08:50 |
| jave | http://paste.ubuntu.com/483316/ | 08:51 |
| vila | jave: worth filing a bug | 08:53 |
| vila | jave: you may also want to upgrade to 2.2final | 08:53 |
| jave | yes, thats why I dodnt file yet :) | 08:54 |
| jave | I'm atm trying to see if theres new rpms for fedora yet | 08:54 |
| vila | jave: 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) | 08:55 |
| jave | thanks | 08:55 |
| vila | s/*deleted*/*delete*/ | 08:55 |
| jave | great! | 08:55 |
| spiv | vila: 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 | 08:57 |
| ubot5 | Launchpad bug 613873 in eCryptfs "stat mtime on encrypted fs doesn't match between calls (affected: 1, heat: 11)" [Medium,Confirmed] | 08:57 |
| vila | spiv: urgh | 08:58 |
| vila | spiv: I thought we rounded the mtime ? Or is it on windows only ? | 08:59 |
| spiv | vila: hmm! | 09:00 |
| spiv | Oh, heh: | 09:01 |
| spiv | Oh, hmm. | 09:01 |
| fullermd | Oh hah, oh hey, oh huh. | 09:02 |
| spiv | fullermd: harumph! | 09:03 |
| fullermd | That's not 3 letters long! | 09:03 |
| spiv | vila: 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. | 09:04 |
| vila | and the int contains the mtime in what resolution ? | 09:05 |
| spiv | vila: seconds | 09:07 |
| vila | wow | 09:07 |
| spiv | vila: you've ruined my beautiful theory :( | 09:08 |
| fullermd | How cruel :( | 09:08 |
| vila | spiv: not sure about that, in the bug you point there is a difference > 0.5 seconds, so it can still apply | 09:11 |
| spiv | vila: but only in the sub-second part of the value | 09:12 |
| spiv | vila: if we always truncate the time towards zero, and we do, then I think we discard exactly the bits that might be wrong. | 09:13 |
| vila | spiv: 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 | 09:13 |
| vila | spiv: then the first stat can say 11:14:40 and the second 11:14:41 | 09:13 |
| spiv | Not on my reading of the bug. | 09:13 |
| vila | spiv: 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 | 09:15 |
| spiv | 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. | 09:15 |
| vila | spiv: right, but nothing either to disprove it | 09:15 |
| spiv | This sounds like essentially the same bug the whole linux kernel itself had a few years ago. | 09:15 |
| vila | spiv: and one bug in this area says to me that there may be others too... | 09:16 |
| spiv | (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) | 09:17 |
| spiv | vila: I certainly agree with the "there may be other bugs" theory :) | 09:17 |
| * spiv updates the bug | 09:24 | |
| vila | spiv: the bug report itself is a gem... | 09:25 |
| vila | spiv: 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 :-) | 09:42 |
| jave | now I get an exception while converting to shared format | 09:49 |
| jave | http://paste.ubuntu.com/483334/ | 09:49 |
| jave | I cant seem to find 2.2 final rpm:s for fedora 13 | 09:49 |
| jave | any suggestions? | 09:49 |
| thumper | is there any way to check the version of bzr that the remote smart server is using? | 10:12 |
| fullermd | There's a ping plugin that shows it... | 10:14 |
| spiv | thumper: install lp:bzr-ping, then 'bzr ping URL' | 10:25 |
| thumper | spiv: ta | 10:27 |
| thumper | fullermd: thanks too | 10:27 |
| === Guest17053 is now known as jelmer | ||
| awilkins | bzr-svn seems to be rather easier to cope with than git-svn .... | 10:38 |
| vila | jave: sorry, didn't see your msg earlier | 10:46 |
| vila | jave: that sounds like a corrupted repo :-/ cd into your .bzr/repository/packs and issue 'md5sum *.pack' | 10:48 |
| vila | jave: the md5 sums should match the file names | 10:48 |
| === jelmer is now known as Guest61071 | ||
| === Guest61071 is now known as jelmer | ||
| bialix | hey | 11:09 |
| bialix | in which section of NEWS should I put the mention of deprecation of parameters passed to function? | 11:09 |
| jave | vila: ok Thanks | 11:12 |
| jave | I'm beginning to suspect my machine isnt quite feeling well | 11:12 |
| vila | jave: most of the time reported corruptions are due to hardware failures or really rude shutdowns | 11:13 |
| vila | hey bialix | 11:13 |
| bialix | bonjour vila! | 11:14 |
| vila | bialix: could be 'Compatibility breaks' or 'New Features' or 'Improvments', it depends | 11:14 |
| vila | bialix: there is also 'API changes' | 11:14 |
| vila | bialix: reviewers will whine if needed anyway ;) | 11:15 |
| bialix | API changes for now seems appropriate for me | 11:15 |
| bialix | hmm, but poolie put deprecation news into Compatibility breaks. poolie knows better! | 11:18 |
| bigkevmcd | I could use some help with a broken branch :-( | 11:46 |
| bigkevmcd | getting crash reports | 11:47 |
| vila | bigkevmcd: !paste ? | 12:01 |
| vila | !paste | 12:01 |
| ubot5 | 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. | 12:01 |
| ddaa | Where can I find a non-handwavy documentation on what --reprocess does? | 13:16 |
| * fullermd is not aware of one. | 13:17 | |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| ddaa | I had a look at bialix kftp plugin, for cached ftp, and thought about using a disk-backed cache instead of a dict. | 14:35 |
| ddaa | I don't *really* need it, but I thought it would be a Good Idea. | 14:35 |
| ddaa | 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. | 14:36 |
| ddaa | But it seems that Transport has no notion of "close()", allowing to release resources. | 14:37 |
| ddaa | So, how can I know I when can delete the disk cache? A hook maybe? | 14:38 |
| ddaa | (preferrably, something not involving __del__) | 14:41 |
| shentino | What does "rich root" mean? | 14:47 |
| vila | ddaa: 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... | 14:47 |
| vila | s/to you/do you/ | 14:47 |
| ddaa | shentino: 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. | 14:48 |
| vila | ddaa: the 2a format is already rich-root aware and the default | 14:48 |
| shentino | ah, as in the root directory has the same stuff that a subdir has? | 14:48 |
| ddaa | vila: not only pack files, but indexes, any stuff, ftp is not particularly latency-efficient. | 14:49 |
| vila | ddaa: indexes are as immutable as their respective pack file | 14:49 |
| ddaa | vila: 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." | 14:50 |
| ddaa | vila: so, you're saying that .pack, .cix, .iix, .rix, .six, .tix files are all write-once? | 14:51 |
| vila | ddaa: there is no '.close()' for transports, there is a '.disconnect()' in a proposed patch, but I don't think it will work for you | 14:51 |
| vila | ddaa: given that md5sum xxx.pack == xxx, yes | 14:51 |
| ddaa | Well, that's something. At least there are no invalidation semantics to worry about. | 14:53 |
| vila | ddaa: in that case .disconnect() can more or less do the trick unless errors occur and we need to reconnect :-/ | 14:54 |
| vila | ddaa: otherwise... that's atexit or __del__ or ... hooks for all high-level operations. None of which is especially appealing, but that's ftp... | 14:56 |
| vila | the lack of a proper readv implementation for ftp doesn't fit well with the pack idea | 14:56 |
| ddaa | I guess I can be happy enough with an infinitely persistent cache in ~/.cache/bazaar | 14:57 |
| * fullermd will be very happy the day FTP dies the death it should have freakin' died last millennium... | 14:58 | |
| vila | ddaa: except some pack files will be deleted from the server when a repack occur... | 14:58 |
| rubbs | 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? | 14:58 |
| rubbs | ... if no documentation exists* ... | 14:59 |
| === zyga is now known as zyga-us-visa-stu | ||
| ddaa | vila: ack that... thinking of it, the right approach might just be atexit(), because of the "single process" limitation of anydbm. | 15:00 |
| ddaa | and ~/.cache/bazaar is the right place anyway because of encrypted home considerations. | 15:00 |
| ddaa | thanks, I now have a solution that makes me happy | 15:01 |
| vila | ddaa: but why do you want to use anydbm when a transport is associated with a single directory where each path is unique ? | 15:01 |
| ddaa | vila: out of laziness, because the kftp code uses a dict, and anydbm does too. | 15:02 |
| vila | ddaa: that's a good reason :) | 15:02 |
| === jelmer_ is now known as Guest3182 | ||
| === Guest3182 is now known as jelmer | ||
| ddaa | rubbs: offering beer, ham and eggs to lifeless would probably be a move in the right direction :-) | 15:04 |
| rubbs | ddaa: 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. | 15:05 |
| ddaa | rubbs: last time I checked, lifeless was not interested in eating babies anymore, being on a diet and stuff... | 15:06 |
| fullermd | Eh, you just need to stay away from the legs. The wings are pretty lean. | 15:07 |
| rubbs | ddaa: 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 | 15:07 |
| ddaa | fullermd: that's interesting, I would be interested in eating cherub wings. | 15:09 |
| fullermd | Everybody is. That's why they're so rare, see. | 15:09 |
| rubbs | I've found that if you cook them in baby oil you get a very nice distinct flavor. | 15:11 |
| fullermd | Better texture if you coat them with baby powder first. | 15:13 |
| === jelmer is now known as Guest48768 | ||
| ddaa | fullermd: what do you use to make the batter with baby powder? | 15:17 |
| awilkins | cornflour | 15:17 |
| awilkins | baby powder is mineral in origin and only suitable for dusting | 15:18 |
| ddaa | awilkins: I'm sure it's fine for cooking cherubs | 15:18 |
| awilkins | I'm told rice flour makes a nice light crispy tempura better | 15:18 |
| awilkins | Although I suspect a nice sticky teriyaki glaze may be better | 15:19 |
| bialix | hi | 15:31 |
| bialix | what does "readv" mean? | 15:33 |
| bialix | hi jam | 15:33 |
| jam | bialix: Transport.readv() look in bzrlib/transport/__init__.py | 15:33 |
| jam | FTPTransport *should* provide a custom one, but it relies on the base "get + seek + read" behavior | 15:34 |
| vila | bialix: I think about it as read-variable, you give it a list of (offset, size) to read from a file | 15:34 |
| bialix | jam, err, I wonder to know what actually readv stands? read vectors? | 15:35 |
| vila | yeah, vector is even better | 15:35 |
| ddaa | I think it mean "read vectorized" | 15:35 |
| vila | bialix: thanks :) | 15:35 |
| bialix | ddaa: thanks | 15:35 |
| ddaa | http://www.opengroup.org/onlinepubs/009695399/functions/readv.html | 15:36 |
| bialix | jam: re Ftp: as I can see from SFTP implementation I should implement _readv | 15:36 |
| === Guest48768 is now known as jelmer | ||
| jml | one thing I miss from loom with pipeline is the way 'bzr st' would tell me which thread of the loom I was using. | 15:46 |
| jam | jml: I use my shell for that | 15:47 |
| jml | meh. | 15:47 |
| jam | jml: specifically, in each checkout I have it show me the branch name | 15:47 |
| jml | ahh. | 15:48 |
| jml | I rarely use 'switch', so that works less well for me. | 15:48 |
| jam | jml: I have a C program that works pretty well: https://code.edge.launchpad.net/~jameinel/+junk/my_nick | 15:48 |
| jml | jam: thanks. | 15:48 |
| jam | You need to adapt the Makefile a bit for Linux vs Windows | 15:48 |
| jam | that way you don't pay the import bzrlib overhead just to run 'ls' :) | 15:48 |
| jam | PS1="\[\e]0;\h \w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w$(/home/jameinel/bin/my_nick.exe)\[\e[0m\]\n\$" | 15:50 |
| awilkins | jam, If you're using powershell you could write the nick thing as ps script | 16:03 |
| awilkins | Shouldn't have too much overhead since you already loaded powershell to run powershell | 16:03 |
| jam | awilkins: except I don't ever run powershell :) | 16:04 |
| awilkins | jam: Fair enough, are you using cygwin bash? | 16:04 |
| jam | yes | 16:04 |
| awilkins | I just can't imagine anyone using CMD.exe for more than 10 minutes | 16:05 |
| awilkins | Although I suppose cygwin uses cmd.exe as it's terminal | 16:05 |
| ddaa | nope, it uses it's own terminal emulator | 16:06 |
| ddaa | that's considerably less sucky than cmd.exe, not that is saying much | 16:06 |
| awilkins | ddaa, That's odd, because when I open cygwin, I get cmd.exe appearing in my process list :-) | 16:07 |
| ddaa | really? I had this impression | 16:07 |
| fullermd | Usimg cmd.exe does tend to leave an impression. Head-shaped. On the desk. | 16:08 |
| awilkins | I think cmd.exe is probably a terminal but the usual shell it runs is bobbins | 16:08 |
| fullermd | Or vice versa, depending on the relative quality of your furniture and calcium in your diet... | 16:08 |
| awilkins | I have an animated gif of that | 16:08 |
| awilkins | Even powershell runs in what is essentially the same terminal | 16:09 |
| Kinnison | cmd.exe is the commandline interpreter | 16:13 |
| Kinnison | it's what command.com used to be | 16:13 |
| jml | How do I test code that uses SMTPConnection? | 16:13 |
| awilkins | Make a mock SMTP server? | 16:14 |
| awilkins | Or even a mock SMTPConnection | 16:14 |
| jml | Yeah, that's roughly what I'm doing now. | 16:15 |
| jml | Was hoping bzrlib might have one | 16:15 |
| jml | but grep doesn't seem to reveal any. | 16:15 |
| awilkins | User learning to use cmd.exe and DOS batch script after using bash : http://imagebin.ca/view/E2RHNegX.html | 16:16 |
| fullermd | Yeah, I've seen that used as a forum avatar. | 16:17 |
| awilkins | I wonder if it will work as a Skype avatar... | 16:17 |
| * fullermd . o O ( bash? People actually use that? ) O o . | 16:17 | |
| awilkins | fullermd, Are you one of those dirty .... Korn shell users? | 16:18 |
| fullermd | Oh, heck no. I'm a sparkly clean C shell user 8-} | 16:18 |
| Kinnison | fullermd: Cshell? Oh dear | 16:19 |
| * Kinnison disassociates himself from fullermd | 16:19 | |
| === zyga-us-visa-stu is now known as zyga | ||
| fullermd | It's too late. You're marked. | 16:20 |
| jam | jml, awilkins: class StubSMTPFactory(object): | 16:21 |
| jam | in bzrlib/tests/test_smtp_connection.py | 16:21 |
| * awilkins looks at the C Shell page on Wiki and likes it | 16:21 | |
| awilkins | Marked... and spreading the infection | 16:21 |
| jml | jam, thanks. I saw that, but it's stubbing at a level below the one I care about. | 16:22 |
| vila | C shell... I feel 20 years younger :-) | 16:33 |
| fullermd | As if you were bourne again? | 16:34 |
| fullermd | Wait. That's backward... | 16:34 |
| vila | It's too late. You're marked. | 16:34 |
| fullermd | Aiee! Unclean! Unclean! | 16:34 |
| C-S | Good news for all FreeBSD users: more and more ports are available. See: http://www.freshports.org/search.php?query=bzr&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive | 16:49 |
| C-S | For all remaining plugin users: if you want me to port your plugin, publish a release file on launchpad. | 16:50 |
| fullermd | If you could port testtools/subunit, we could run the test suite ;) | 16:51 |
| C-S | where do I find that? | 16:52 |
| C-S | launchpad? | 16:52 |
| fullermd | No particularly good idea. Probably. | 16:52 |
| C-S | I don't understand. Aren't these normal plugins? | 16:53 |
| fullermd | I know vila has it locally installed in his testing VM; he'd know if there was anything nontrivial about getting it working. | 16:53 |
| fullermd | No, they're not plugins, they're regular python libs. | 16:53 |
| C-S | I see. | 16:53 |
| C-S | I'll have a look what I can do. | 16:54 |
| C-S | By the way. There is a stupid bug in bzr-gtk: a file is missing. | 16:54 |
| vila | C-S: well done ! | 16:54 |
| C-S | vila: thanks vila | 16:55 |
| vila | C-S: from the release tarball ? | 16:55 |
| C-S | vila: bzr-gtk? Yes from the release tarball. I had to patch setup.py | 16:55 |
| vila | C-S: credits.pickle ? | 16:55 |
| C-S | vila: exactly... | 16:55 |
| C-S | vila: I patched it away :-) | 16:55 |
| C-S | vila: and it still works... | 16:55 |
| vila | C-S: yeah, one command to generate it... let me find it back | 16:56 |
| fullermd | So, you cuked it? ;) | 16:56 |
| C-S | vila: here is my patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/bzr-gtk/files/patch-setup.py?rev=1.1;content-type=text%2Fplain | 16:56 |
| C-S | fullermd: it was really necessary, because bzr was already updated on freebsd and the old bzr-gtk did not work anymore... | 16:57 |
| vila | C-S: : That's not what is called "taking credit" :-D | 16:57 |
| C-S | vila: I agree :-) I'd be happy if the file was still there... | 16:58 |
| C-S | vila: by the way, this bug also seems to bother other maintainers: os x, debian etc. | 16:59 |
| fullermd | 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. | 16:59 |
| * fullermd looks pointedly at the apport stuff in bzr... | 16:59 | |
| vila | C-S: I know, whoever created the tarball forgot about it | 16:59 |
| C-S | vila: don't worry about it. I am looking forward to the next release... | 17:00 |
| vila | There is a wiki page I can't find back describing the release process | 17:00 |
| vila | C-S: yet, http://wiki.bazaar.canonical.com/bzr-gtk mention FreeBSD and how to install it... | 17:00 |
| C-S | fullermd: bzr-gtk is an exception. All other ports work smoothly. The Makefile just installs the things in the right place. | 17:00 |
| vila | C-S: hehe, you added that :) | 17:00 |
| C-S | vila: right :-) | 17:01 |
| vila | C-S: here we go: http://wiki.bazaar.canonical.com/bzr-gtk/releasing | 17:03 |
| vila | 3. Update the credits pickle file by running python ./setup.py build_credits | 17:03 |
| C-S | vila: perfect, although I'll leave this task to others. I am fully occupied bringing bzr stuff and other stuff to FreeBSD... | 17:04 |
| vila | C-S: ok, just mentioning in case your patch broke something | 17:04 |
| fullermd | Oh, if it does, we'll just blame it on upstream 8-} | 17:04 |
| vila | C-S: as fullermd said, bringing testtools and subunit would be great | 17:04 |
| C-S | vila: ah, thanks a lot. I am sure there will soon be a new release of bzr-gtk | 17:05 |
| C-S | fullermd: of course :-) | 17:05 |
| vila | testtools is pure python, subunit includes a python implementation so may be a bit harder | 17:05 |
| C-S | vila: I'll see what I can do. | 17:06 |
| vila | testtools is pure python, subunit includes a python implementation (of the subunit protocol) so may be a bit harder | 17:06 |
| vila | C-S: I run them from sources as I often need the trunk version | 17:06 |
| C-S | vila: so what do these two tools do exactly? | 17:06 |
| vila | C-S: testtools is required as it provides some more stuff than the python unittest module | 17:07 |
| vila | 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 | 17:08 |
| vila | C-S: in short: none of them are required to *use* bzr, but help a lot to *test* bzr | 17:08 |
| C-S | vila: ok. thanks for that explanation | 17:09 |
| fullermd | subunit was required for --parallel back before testtools was used at all. | 17:10 |
| C-S | so testtools is more important? | 17:10 |
| vila | C-S: yes, the best way to check is to run 'bzr selftest' | 17:12 |
| C-S | vila: I see. | 17:13 |
| C-S | thanks | 17:13 |
| === beuno is now known as beuno-lunch | ||
| === Ursinha is now known as Ursinha-lunch | ||
| mgz | vila: couple of questions on my test cleanup merge proposal branch if you're still around | 18:15 |
| mgz | you mentioned you get 2000 tests which complain about leaking even with the testtools change, can I have that list? | 18:16 |
| mgz | also, what change to bb.test_log using addCleanup would deal with the cycle? because I'm not seeing it. | 18:16 |
| C-S | vila: I just commited the FreeBSD port for testtools. Hope it gets accepted soon. | 18:19 |
| === beuno-lunch is now known as beuno | ||
| === Ursinha-lunch is now known as Ursinha | ||
| fullermd | C-S: You probably want that to by devel/py-testtools... | 18:40 |
| C-S | fullermd: I agree, wrote it in the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/149967 | 18:52 |
| C-S | fullermd: anyway. there seems to be some modules missing still... | 18:52 |
| C-S | fullermd: bzr selftest yields: /usr/local/lib/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken | 18:53 |
| C-S | RandomPool_DeprecationWarning) | 18:53 |
| C-S | bzr: ERROR: No module named layout.test_custom | 18:53 |
| C-S | You may need to install this Python library separately. | 18:53 |
| fullermd | That's a different problem. That's paramiko puking on up-to-date pycrypto. | 18:58 |
| fullermd | I "solved" that by just dumping paramiko off my system :| | 18:58 |
| C-S | fullermd: ok. Can you try the port? Please tell me if it works for you. | 19:14 |
| fullermd | Can't today. It's way late (in my head). I'm just fiddling with some relatively mindless stuff before I fall over. | 19:16 |
| james_w | mtaylor: hey, interesting problem you've found here | 21:09 |
| james_w | I've reproduced the failure locally now | 21:10 |
| james_w | mtaylor: just to confirm http://paste.ubuntu.com/483616/ is the test failure you were referring to? | 21:12 |
| james_w | looks like it from the log that you provided | 21:12 |
| james_w | the source package contains that file in the debian.tar.gz, which indicates to me that debian/source/include-binaries isn't the cause | 21:18 |
| james_w | are you sure that it's not just something like that test giving different output in a chroot? | 21:18 |
| === scott_aubrey_uk_ is now known as scott_aubrey_uk | ||
| amogorkon | hello | 21:30 |
| cbz | is there any way of getting bzr-svn to save the authentication credentials? | 22:01 |
| mtaylor | james_w: yes. that is it | 22:41 |
| mtaylor | james_w: it would be _very_ unlikely for that to generate different results in a chroot, but I suppose that anything is possible | 22:42 |
| mtaylor | james_w: should I try spinning up a chroot and checking manually? | 22:42 |
| james_w | mtaylor: I'm doing that if you can help me verify | 22:43 |
| james_w | mtaylor: firstly, installing diff doesn't seem to change the output :-) | 22:43 |
| mtaylor | james_w: well that's a good step :) | 22:44 |
| mtaylor | btw - I really hate that test case - the binary null that's in it just causes no end of headaches | 22:44 |
| james_w | no, I mean that it still complains that it can't run "diff" :-) | 22:44 |
| mtaylor | ah. heh | 22:45 |
| mtaylor | I should file a bug about that... | 22:45 |
| mtaylor | or just replace the test running system - but I digress | 22:45 |
| james_w | that's always the solution | 22:46 |
| james_w | mtaylor: is DATA_DICTIONARY supposed to be 39 or 40 in the package? | 22:50 |
| james_w | 40 it seems | 22:53 |
| mtaylor | james_w: oh - sorry - I was distracted spinning up a chroot :) | 22:54 |
| james_w | so it looks to me as though it is correct in the source package, but is unpacked incorrectly | 22:54 |
| mtaylor | weird | 22:55 |
| james_w | though I'm not overly familiar with the v3 format | 22:55 |
| mtaylor | me either - still learning it myself | 22:55 |
| james_w | and I can't unpack the source package on lucid apparentl | 22:56 |
| mtaylor | wow. that's fantastic | 22:56 |
| james_w | 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 | 22:58 |
| james_w | no, that's not true | 23:01 |
| === Ursinha is now known as Ursinha-afk | ||
| mwhudson | does "Exception AttributeError: "'SmartSSHClientMedium' object has no attribute '_ssh_connection'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://mwhudson@bazaar.launchpad.net/)> ignored" ring any bells for anyone? | 23:10 |
| mgz | yes. | 23:15 |
| mgz | it rings the "can't write __del__ methods properly" bell. | 23:16 |
| mwhudson | oh right | 23:17 |
| mwhudson | the real error is | 23:18 |
| mwhudson | bzrlib.global_state.cleanups.add_cleanup(self.flush_all) | 23:18 |
| mwhudson | AttributeError: 'NoneType' object has no attribute 'cleanups' | 23:18 |
| mgz | that one I haven't run into. | 23:20 |
| mwhudson | ah strange | 23:26 |
| mwhudson | so if (a) you open a branch over bzr+ssh (b) you haven't called bzrlib.initialize() (c) you have hpss in debug_flags | 23:26 |
| mwhudson | then you'll get that error | 23:26 |
| mgz | initialize is an ever-growing pain. | 23:28 |
| mgz | just give in and always call it. | 23:29 |
| mwhudson | funnily enough | 23:29 |
| mwhudson | i think i started the chain of events that led to it being added | 23:29 |
| mwhudson | because this script that's now failing | 23:29 |
| mwhudson | would blow up if you didn't install a ui factory | 23:29 |
| Guest83593 | cbz: hi | 23:52 |
| === Guest83593 is now known as jelmer | ||
| * jelmer waves | 23:52 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!