| poolie | hi lifeless, jelmer, maxb, spiv | 00:25 |
|---|---|---|
| poolie | urk, this scrollback looks bad | 00:25 |
| jelmer | g'morning poolie | 00:26 |
| fullermd | That'll teach you to scroll back. | 00:26 |
| poolie | maxb: thanks for the 2.2.2 upload | 00:26 |
| poolie | that was superbly quick | 00:26 |
| poolie | maxb, maybe we should take this back to the TB? | 00:27 |
| maxb | Well. The MRE was well reasoned. Running the testsuite makes sense. | 00:28 |
| maxb | It's just we can't, because of dependencies. | 00:28 |
| maxb | If we care (I'm not sure I do) about putting every micro release of bzr into the relevant ubuntu updates, then I think we need to sort out a MIR of python-testtools for natty | 00:29 |
| jelmer | I think we should. | 00:30 |
| poolie | i care about getting at least some bugfix releases into ubuntu | 00:31 |
| maxb | And for maverick, I think someone needs to have a discussion with the SRU team on whether they will consider allowing the testsuite to be run in a PPA to be "good enough" | 00:31 |
| spiv | testtools is a good library, I think having it in main in future makes senes. | 00:31 |
| spiv | sense, rather. | 00:31 |
| poolie | if we can't do that, perhaps either it's not worth doing them at all, or the SRU process is wrong in this case | 00:32 |
| poolie | > whether they will consider allowing the testsuite to be run in a PPA to be "good enough" | 00:32 |
| maxb | The SRU process is primarily built for cherrypicked backports of single fixes | 00:32 |
| poolie | that sounds like a good pragmatic approach | 00:32 |
| poolie | i know | 00:32 |
| poolie | however, i know mark's very keen on getting things just like this in to previous releases | 00:32 |
| poolie | if it's done in a very safe way of course | 00:33 |
| maxb | I've kicked off a test build in https://launchpad.net/~maxb/+archive/ppa | 00:35 |
| maxb | However, I personally don't have the energy/motivation to get involved with the MIR or SRU team discussions I conjectured above | 00:37 |
| jelmer | maxb: I'm going to send in a request to become a PerPackageUploader, I might look at the MIR. | 00:39 |
| poolie | i sent one too, but it apparently stalled because i didn't go to the irc meeting | 00:47 |
| poolie | jelmer, that would be great | 00:47 |
| poolie | maxb, i'll continue the SRU discussion | 00:47 |
| poolie | i wonder if sudo works :_) | 00:47 |
| fullermd | Didn't we have a discussion $YEARS ago about exit status on pull? | 01:16 |
| lifeless | yes | 01:16 |
| lifeless | i awas there | 01:16 |
| fullermd | I thought it went toward adding information. | 01:17 |
| maxb | As in, indication whether anything was actually pulled or not? | 01:20 |
| fullermd | Yah. | 01:20 |
| maxb | The problem with this is that there's no way you can change behaviour here without breaking people's shell scripts and causing wailing and gnashing of teeth | 01:21 |
| maxb | It seems like just checking the revno before and after would be better | 01:22 |
| fullermd | Well, it just broke my partly-written shell script :p | 01:22 |
| maxb | s/better/achieve the same without compatibility issues/ | 01:22 |
| lifeless | maxb: we have major/micro to permit improvements | 01:22 |
| maxb | Well, yes, 2.0 would have been the logical place to do such a thing | 01:23 |
| fullermd | Don't worry, we have a VCS. It's like a little time machine; we can just roll back to before 2.0... | 01:24 |
| poolie | we can change this in 2.3 | 02:12 |
| poolie | just describe it in news and whatsnew, make it as little disruption as possible, and do it | 02:12 |
| === ccxCZ- is now known as ccxCZ | ||
| lifeless | poolie: I'd love it if you could schedule https://bugs.launchpad.net/bzr/+bug/583667 for doing sometime fairly soon | 05:39 |
| ubot5 | Launchpad bug 583667 in Bazaar "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 1)" [High,Confirmed] | 05:39 |
| poolie | ooh | 05:41 |
| poolie | schedule it, or do it? | 05:41 |
| poolie | :-P | 05:41 |
| poolie | sounds pretty easy though | 05:41 |
| lifeless | poolie: if you're not doing it yourself, schedule. I'd love to see it done ;) | 05:42 |
| poolie | what's the actual problem? | 05:43 |
| poolie | just tidyness? | 05:44 |
| poolie | ah, the blog explains? | 05:44 |
| lifeless | we can't redirect API clients | 05:44 |
| lifeless | yes, it does | 05:44 |
| lifeless | we can't easily serve edge from the main cluster either | 05:44 |
| lifeless | due to a couple of issues | 05:45 |
| poolie | i trust you but i am surprised | 05:45 |
| lifeless | there is some machinery in zope | 05:46 |
| lifeless | but we're using a mangled implementation because we adopted so early | 05:46 |
| poolie | :/ | 05:47 |
| lifeless | gary is unsure that it would work, and sure that it would require effort | 05:47 |
| poolie | this kind of sucks because everybody who tried to write an api client has been told "use edge" | 05:47 |
| lifeless | that was, sadly, bad advice | 05:48 |
| lifeless | the wadl served from a domain has the domain embedded in it | 05:48 |
| poolie | of course it's great we're going to move away from using a separate url space for this | 05:48 |
| lifeless | so we can't just redirect in apache | 05:48 |
| poolie | we can't configure the main cluster to serve api.edge.l.n as well as api.l.n? | 05:49 |
| lifeless | no, see under zope machinery | 05:49 |
| lifeless | the objects that are published would be the same as for the main site | 05:50 |
| lifeless | but have to be on the site the request was received | 05:50 |
| lifeless | this fights some global state | 05:50 |
| poolie | ok | 05:51 |
| poolie | thanks for raising it then | 05:51 |
| poolie | and for the blog post | 05:51 |
| poolie | from the initial bug report against bzr, it was not at all obvious this would be urgent | 05:51 |
| lifeless | we're going to have to keep the cluster until we've got every user migrated, or near enough to every | 05:52 |
| lifeless | so I would say urgent | 05:52 |
| lifeless | but nice to do | 05:52 |
| lifeless | bzr would get better response by miving as well | 05:52 |
| poolie | my only reluctance is about updating very old series | 05:53 |
| poolie | cf recent threads about ceasing updates for 2.0 except for critical issues | 05:54 |
| poolie | it would be pretty unfortunate to have that break | 05:54 |
| lifeless | poolie: it would be unfortunate | 05:59 |
| lifeless | my /preference/ would be to get everything on lpnet (see for instance ng's query about edge this morning) | 05:59 |
| lifeless | but if thats particularly risky/problematic, staying on edge until you stop supporting 2.0 is fine. | 06:00 |
| poolie | i think if you kept it alive until at least the end of karmic (bzr 2.0.x) in april that would be ok | 06:00 |
| poolie | assuming nobody is still using hardy's original bzr | 06:00 |
| sqwishy | Is there a simple way to have a branch not store binary deltas? | 06:00 |
| poolie | what do you mean? | 06:01 |
| sqwishy | So when someone changes a binary file, it doesn't retain older versions of it. | 06:01 |
| sqwishy | :> | 06:01 |
| sqwishy | Basically, I have a project that will need potentially 10MB > binary resources that could be changed several timed. I'd like for them to be in the bzr repo with the code because then everything is in one place and can be updated easily. | 06:03 |
| poolie | sqwishy: sorry, no, we don't support that at the moment | 06:04 |
| poolie | i suggest you either | 06:04 |
| poolie | 1- put them in a bzr branch but from time to time kill its history and make a new branch | 06:04 |
| poolie | 2- download it by some other means like rsync | 06:04 |
| lifeless | poolie: right, the goal is to shrink with all due haste, not to be cavalier | 06:05 |
| sqwishy | Yeah, the project is in python so people don't run a build script to run the thing. There is no great place to put an automatic rsync fetchery thingy because scripts aren't run to build the app. | 06:06 |
| sqwishy | I might have to try and think of something clever. | 06:06 |
| poolie | spiv i'm going to finish up now | 06:20 |
| poolie | suggest you do too :) | 06:20 |
| spiv | poolie: Heh :) | 06:21 |
| spiv | Just finishing up writing some tests :) | 06:21 |
| vila | hi all ! | 07:36 |
| vila | maxb: ping | 07:37 |
| vila | maxb: I've seen your mail about the MRE | 07:37 |
| vila | So basically we need python-testtools. Getting it into main may be the best solution long term wise. | 07:38 |
| vila | Embedding a private version, while frowned upon in debian may be a workaround ? (I'm not holding my breath here :) but I think it's worth mentioning | 07:40 |
| vila | Now, where does it break precisely ? We are not releasing it, we need it to validate our code only, can't we find a way ? | 07:41 |
| * vila reboots | 07:50 | |
| loxs | I have 2 separate bazaar repositories. Is there some way to move a file from one to the other with all its history? | 11:01 |
| augdawg | when i try bzr branch, it always asks me for my password. i hav tried telling it to unlck the keychain, but it wont work. can anyone help? | 13:18 |
| jelmer | augdawg: Are you referring to the GNOME keychain? | 13:21 |
| jelmer | augdawg: bzr-gtk's keychain support will only use existing credentials, it won't add new ones. | 13:21 |
| augdawg_ | sorry jelmer, the wifi went offline briefly in my home. | 13:25 |
| jelmer | <jelmer> augdawg: Are you referring to the GNOME keychain? | 13:26 |
| jelmer | AfC ajmitch apw ahasenack augdawg | 13:26 |
| jelmer | augdawg: bzr-gtk's keychain support will only use existing credentials, it won't add new ones. | 13:26 |
| jelmer | Argh, xchat inserted the tab completion suggestions there. Sorry about the highlights :-( | 13:26 |
| augdawg_ | i mean that it wont let me tell it to unlock my keychain for branching stuff off launchpad | 13:28 |
| AfC | jelmer: nice one | 13:28 |
| jelmer | augdawg_: ah, this is for ssh? bzr just calls out to the main ssh binary to talk to Launchpad over bzr+ssh | 13:28 |
| augdawg_ | so what does this mean? | 13:29 |
| vila | augdawg: that means the problem is with your ssh setup, what does 'ssh-add -l' says ? | 13:38 |
| vila | augdawg: or rather, to start, what does 'ssh -v bazaar.launchpad.net' tells you ? | 13:39 |
| === jelmer_ is now known as jelmer | ||
| maxb | vila: Hi. Yes, we need python-testtools. For natty the answer is to get a Main Inclusion Report done and approved. | 15:06 |
| vila | maxb: hi ! | 15:06 |
| vila | So, *why* precisely do we need it ? | 15:06 |
| maxb | To run 'bzr selftest' | 15:07 |
| vila | ..and this must succeed without any piece external to main ? | 15:07 |
| maxb | Any build in the Ubuntu archive must obey the component dependency model | 15:07 |
| maxb | main only sees main. restricted sees main + itself. universe sees main + itself. multiverse sees everything | 15:08 |
| vila | and where did that fail ? I mean, we started running the tests some time ago | 15:09 |
| maxb | Yeah...... in PPAs. Enforcing this restriction is optional and usually disabled in PPAs | 15:09 |
| vila | ok, thanks for the clarification | 15:09 |
| vila | So indeed, that's bye bye MRE for maverick | 15:09 |
| vila | So, what's a 'Marin Inclusion Report' and who will do it ? python-testtools devs ? | 15:10 |
| vila | s/Marin/Main/ | 15:10 |
| maxb | A main inclusion report is a document justifying that a package is sufficently well maintained and will not put an undue burden on the Ubuntu Security Team if included in main | 15:12 |
| maxb | https://wiki.ubuntu.com/MainInclusionProcess | 15:13 |
| vila | great | 15:15 |
| vila | as for who should do that, I think the answer is: the bzr RM | 15:15 |
| vila | .. or he will never really learn how this works :D | 15:16 |
| vila | jml: ping | 15:18 |
| jml | hi | 15:19 |
| vila | jml: err, where are you these days ? May be in your ... oh no! Great ! | 15:19 |
| vila | jml: so, bzr has applied for Micro Release Exception with a pre-requisite of running the tests as part of the build | 15:20 |
| vila | jml: it turns out that python-testtools is not part of the main archive so we are blocked for maverick | 15:20 |
| vila | jml: What are your plans regarding inclusion of python-testtools in the main archive ? | 15:21 |
| jml | vila: none as yet. | 15:21 |
| jml | vila: whether we are in main or not doesn't matter much to me. | 15:21 |
| vila | jml: ok | 15:22 |
| === beuno is now known as beuno-lunch | ||
| cbz | is jelmer around? | 16:00 |
| jelmer | cbz: sortof | 16:02 |
| jelmer | cbz: Hi | 16:02 |
| cbz | hi jelmer - using bzr-svn on windows it complains that it cannot create something because it is a simlink, in the repository itself it appears to be a dirctory in which a bunch of external items are to be pulled in | 16:04 |
| jelmer | cbz: if you check out the repository using the "normal" svn client do you get a symlink? | 16:04 |
| cbz | no - svn creates a normal directory | 16:07 |
| cbz | actually no - it's created a file with a name inside | 16:09 |
| cbz | in one case | 16:09 |
| cbz | in the other case it created a directory | 16:09 |
| jelmer | cbz: is this a public repo? | 16:16 |
| cbz | no, unfortunately not | 16:16 |
| cbz | it looks like the directory that it bitches about is the one defined as a home for a bunch of svn:externals | 16:18 |
| jelmer | what exactly is the error message? | 16:18 |
| jelmer | cbz: ^ | 16:19 |
| cbz | bzr: ERROR: Unable to create symlink 'test/selenium/vendor' on this platform | 16:20 |
| cbz | thats for the file that svn creates as a file containing "link ../target/dir" | 16:20 |
| cbz | whichi presume is actually a symlink to a directory | 16:21 |
| jelmer | cbz: That file would be created as a symlink on unix by the svn client | 16:21 |
| cbz | yes | 16:21 |
| cbz | I get an identical error message for another directory which as far as i can tell is only referenced by svn:externals | 16:22 |
| cbz | svn will create the directory and populate it | 16:22 |
| cbz | bzr-svn throws an error message | 16:22 |
| jelmer | cbz: this is unrelated to bzr-svn, it's bug 81689 IIRC | 16:22 |
| ubot5 | Launchpad bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows (affected: 21, heat: 58)" [Medium,Confirmed] https://launchpad.net/bugs/81689 | 16:22 |
| cbz | The second issue does not appear to be symlink related | 16:23 |
| jelmer | what's the error you're getting? | 16:23 |
| jelmer | ah, it's identical - sorry | 16:24 |
| jelmer | can you check with "svn cat" what the contents of the problematic file are in that second case ? | 16:25 |
| jml | jelmer: btw, are you familiar with http://twistedmatrix.com/trac/wiki/BazaarMirror#CommittingaBazaarbranchtoaSubversionbranch | 16:29 |
| cbz | jelmer: svn says it's a directory (which it is). I think it doesn't exist in the repository, svn:externals just refers to it and so svn is able to create it | 16:31 |
| jelmer | jml: No, I wasn't aware of that. Thanks for the link | 16:31 |
| jelmer | cbz: bzr-svn ignores svn:externals at the moment | 16:31 |
| jml | jelmer: basically, it would be nice if there were fewer warnings about bzr/svn gotchas on that page | 16:32 |
| jelmer | cbz: There might be something strange going on there, such as svn checkout removing it because the svn:externals directory overwrites it. | 16:32 |
| kiko | jelmer, do you know why bzr diff -r submit: needs to hit the server? | 16:34 |
| jelmer | kiko: If the submit branch is a remote branch (it commonly is) it will need to check what the tip revision of the submit branch is. | 16:34 |
| jelmer | kiko: There are probably some other (less common) situations in which it can require remote access (if the local branch is a lightweight checkout, for example). | 16:37 |
| kiko | jelmer, is there a shortcut to ask bzr to give me the changes between my current tip and the tip of the remote branch as it was when I last pulled a revision | 16:39 |
| kiko | without hitting the server | 16:39 |
| jelmer | kiko: Not without manually keeping a local copy of the remote branch at the moment (or tagging the last remote revision, or something like that). | 16:42 |
| jelmer | kiko: When colocated branches land it should be a lot easier to do this sort of thing, much in the same way that git supports it ("remote refs") | 16:42 |
| kiko | right | 16:43 |
| jelmer | jml: the bzr metadata shouldn't really be an issue anymore. With a recent enough svn (>= 1.5) we no longer store the metadata in file properties. | 16:50 |
| jelmer | jml: I've considered printing a warning if we would end up writing to file properties | 16:50 |
| jml | jelmer: if we asked for confirmation, that would probably settle some fears in #twisted | 16:52 |
| jml | printing is a little chancy | 16:52 |
| jelmer | jml: bzr usually doesn't do interactive stuff (uncommit is the exception that confirms the rule). I guess we could require a configuration option though. | 16:53 |
| jml | jelmer: or warn, quit and say that you need to specify a particular option | 16:53 |
| jelmer | at this point repositories without custom revision property support should be really rare | 16:54 |
| jelmer | jml: That'd be reasonable. Care to file a bug ? :-) | 16:54 |
| jml | jelmer: sure, more than happy to. (once I finish dealing with my current silly self-imposed distraction) | 16:55 |
| === beuno-lunch is now known as beuno | ||
| fabio_kreusch | I have a bzr repository on format 2a, and I'm trying to do a split. So I do 'bzr split path', then ''bzr join --reference path' and 'bzr commit', and everything is fine. But after that, whenever I try to access the repository, I get this message: | 17:11 |
| fabio_kreusch | The method _generate_inventory is not supported on objects of type CHKInventoryRepository | 17:11 |
| fabio_kreusch | any thoughts? | 17:11 |
| kiko | sounds like a bug :) | 17:12 |
| fabio_kreusch | I have found on launchpad this https://bugs.launchpad.net/bzr/+bug/515947 | 17:12 |
| ubot5 | Launchpad bug 515947 in Bazaar "cannot commit in the containing tree which has by-reference joined trees [2a] (affected: 1, heat: 0)" [Low,Confirmed] | 17:12 |
| fabio_kreusch | yep | 17:12 |
| fabio_kreusch | that's the one | 17:12 |
| fabio_kreusch | but | 17:12 |
| fabio_kreusch | what should I do than? | 17:12 |
| fabio_kreusch | On that thread John Meinel says that --reference should not be compatible with 2a | 17:13 |
| fabio_kreusch | but what should I do than so that I'm able to split my repo? | 17:14 |
| maxb | Hrm | 17:54 |
| maxb | Looks like Gary accidentally marked lp:qbzr as not supporting bzrlib 2.3 | 17:55 |
| maxb | fabio_kreusch: I'm pretty sure --reference should be totally incompatible with 2a | 18:02 |
| maxb | Hence, you can use 'bzr split', but you can't use 'bzr join --reference' | 18:03 |
| fabio_kreusch | maxb: what I want to do is to have subtrees, can't I do that with 2a than? | 18:55 |
| jelmer | fabio_kreusch: no, 2a doesn't support nested trees. | 19:49 |
| lamont | bzr: ERROR: Unable to determine your name. <-- we did fix 2.3 so it doesn't consider that an error anymore, right? | 20:41 |
| jelmer | lamont: I haven't seen a fix for that yet. | 23:40 |
| lamont | gar | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!