| thumper | morning spiv, jam, igc ;-) | 00:12 |
|---|---|---|
| === mw is now known as mw|out | ||
| mwhudson | boo merge --uncommitted doesn't work over ssh | 00:53 |
| mwhudson | i'm not surprised, though | 00:54 |
| lifeless | heh | 00:56 |
| === emgent is now known as bakunin | ||
| === bakunin is now known as emgent | ||
| poolie | beuno: hi | 01:45 |
| poolie | igc: ping | 01:46 |
| igc | hi poolie | 01:47 |
| lifeless | spiv: I think we should talk abot get_data_stream | 01:47 |
| poolie | tim just forwarded me the patch to fix https://bugs.edge.launchpad.net/launchpad/+bug/181157 | 01:47 |
| ubotu | Launchpad bug 181157 in launchpad "Product series should have a status (like distro series)" [Medium,Confirmed] | 01:47 |
| spiv | lifeless: ok | 01:47 |
| lifeless | spiv: I think I know where a bunch of problems are comng from | 01:47 |
| poolie | can you look at that quickly and tell me either any other values you think should be allowed, or anything else that comes to mind | 01:47 |
| igc | poolie: sure | 01:47 |
| lifeless | spiv: voice or irc? | 01:48 |
| spiv | lifeless: whichever suits you best | 01:48 |
| poolie | hello spiv, lifeless | 01:48 |
| spiv | I'm happy either way. | 01:48 |
| lifeless | ringing you | 01:48 |
| lifeless | ok, false alarm; its not the cause of the bugs we're seeing | 02:01 |
| lifeless | hi poolie | 02:01 |
| poolie | igc: can you please just look at that quickly now, i want to reply to tim | 02:02 |
| igc | commenting on the bug right now | 02:02 |
| poolie | oh cool, thankyou | 02:02 |
| igc | poolie: done | 02:04 |
| igc | I think we want one more status now - Pending Release (or Frozen to mirror the distro name) | 02:04 |
| igc | "Future" or Experimental might be good as well but I'd leave it out until we explicitly need it | 02:05 |
| igc | i.e. some project asks for it | 02:05 |
| beuno | poolie, hey | 02:19 |
| poolie | hi beuno | 02:22 |
| poolie | igc, hm | 02:22 |
| poolie | so this is like a subcategory of active development? | 02:22 |
| poolie | oh i see | 02:22 |
| poolie | so 1.4 would be in that state now, and 1.5 would be active development? | 02:22 |
| beuno | poolie, just got home, so I'll be on and off while I run errands. Do you want to talk now or would it be better for you later on? | 02:26 |
| igc | poolie: that's right | 02:33 |
| Kamping_Kaiser | hi all. is there a list of what environment variables/bazaar.conf options are available? | 02:53 |
| Kamping_Kaiser | also, is last push path remembered like last merge path? (eg per repository?) | 02:55 |
| spiv | Kamping_Kaiser: bzr help env-variables | 02:55 |
| spiv | Kamping_Kaiser: bzr help configuration | 02:55 |
| Kamping_Kaiser | spiv, ok, thanks | 02:55 |
| spiv | Kamping_Kaiser: (also at http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#configuration-settings and http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#environment-variables) | 02:56 |
| spiv | Kamping_Kaiser: the first time you push, it remembers the path. You can overwrite the remembered path by passing "--remember" to push. | 02:56 |
| Kamping_Kaiser | spiv, sounds the same. thanks again :) | 02:57 |
| spiv | Not a problem | 02:57 |
| Kamping_Kaiser | of the two help outputs i assume configuration is authoritive? it lists items env-variables doesnt | 02:59 |
| spiv | Hmm, that's a bug. | 03:02 |
| spiv | But afaik, all the items in the 'configuration' help topic do exist. | 03:02 |
| Kamping_Kaiser | BZR_PROGRESS_BAR BZR_SIGQUIT_PDB BZR_PDB are listed in config but not env-var | 03:04 |
| Kamping_Kaiser | bzr1.3, btw. | 03:05 |
| Kamping_Kaiser | they both give quite different output it seems | 03:06 |
| Kamping_Kaiser | "DEFAULT" isnt the only header currently supported by bzr is it? (ALIASES works too?) | 03:10 |
| spiv | Kamping_Kaiser: you mean sections in the bazaar.conf? | 03:16 |
| Kamping_Kaiser | spiv, yeah. | 03:16 |
| * jml frowns | 03:19 | |
| jml | ubuntu is telling me that I can't upgrade bzr without removing bzrtools | 03:20 |
| spiv | Kamping_Kaiser: sounds like a bug in the docs. | 03:20 |
| jml | this seems to happen a lot. | 03:20 |
| Kamping_Kaiser | spiv, ok :( | 03:20 |
| lifeless | jml: its a ppa feature | 03:23 |
| jml | lifeless: I'm sceptical. | 03:24 |
| RAOF | Yeah; when is a 1.4-compatible bzrtools/bzr-svn likely to be uploaded there? | 03:24 |
| spiv | Kamping_Kaiser: I've sent a quick patch to fix it to the list | 03:24 |
| spiv | Kamping_Kaiser: thanks for letting us know | 03:24 |
| spiv | jml: "feature" | 03:25 |
| lifeless | jml: what happens is that the bzr < current upload is immediately removed | 03:25 |
| lifeless | jml: hilarity then ensues | 03:25 |
| jml | and there's no workaround? | 03:27 |
| Kamping_Kaiser | spiv, NP. i was worried you were going to tell me to write the patch myself ;) | 03:27 |
| spiv | Kamping_Kaiser: you can if you really want to ;) | 03:27 |
| RAOF | jml: You can just not upgrade bzr. | 03:27 |
| Kamping_Kaiser | spiv, i really dont. *grin*. | 03:28 |
| jml | RAOF: this a bit of a pain. | 03:29 |
| RAOF | The current bzrtools depends on bzr < 1.4~. The PPA contains bzr 1.4rc1, and 1.4rc > 1.4~ | 03:29 |
| RAOF | jml: Does current bzrtools work on 1.4? If it does, you probably have the permissions to upload a bzrtools to the PPA with relaxed dependencies. If not, we're preventing you from accidentally breaking bzrtools. | 03:30 |
| lifeless | RAOF: bzrtools is version locked | 03:32 |
| lifeless | RAOF: apt can resolve conflicts better if 1.3 is kept in the archive | 03:32 |
| abentley | RAOF: Not to mention the fact that even if started at the same time, bzrtools 1.4 and bzr1.4 are unlikely to enter the archive at the same time. | 03:33 |
| lifeless | abentley: in fact they can't | 03:33 |
| lifeless | abentley: as there is a build sequence constraint | 03:34 |
| abentley | Okay, *very* unlikely :-) | 03:34 |
| RAOF | Maybe I'm spoilt by aptitude. That handles this case just fine. | 03:34 |
| lifeless | :P | 03:34 |
| abentley | It handles the case where bzrtools requires bzr 1.3 and only bzr 1.4 is available? | 03:35 |
| RAOF | abentley: But bzr 1.3.1~rc1 *is* available. | 03:35 |
| lifeless | abentley: it offers different resolutions | 03:35 |
| lifeless | RAOF: not in the ppa its not | 03:35 |
| RAOF | Just not from the PPA. | 03:35 |
| RAOF | But that's not jml's problem. | 03:35 |
| lifeless | jml: what release are you on, and do you have backports enabled? | 03:36 |
| jml | lifeless: hardy. | 03:36 |
| jml | lifeless: not sure how to check for backports. | 03:36 |
| RAOF | Does'nt matter, there aren't any yet. | 03:36 |
| lifeless | RAOF: would for gutsy :P | 03:37 |
| lifeless | jml: for reference grep backports in /etc/apt/sources.list | 03:37 |
| RAOF | lifeless: Yeah, but I know he's on Hardy :) | 03:37 |
| lifeless | poolie: ping; removing deprecated methods question on the list; would like a reply :P | 03:45 |
| jdobrien | Im working on a bug Mentored by LastiQ who is in bed...could anyone help for a WorkingTree4 question? | 04:09 |
| jdobrien | sorry..LarstiQ Wouter | 04:09 |
| lifeless | sure | 04:10 |
| jdobrien | I am working on adding a switch which will output relative paths ../path/to/file/filename.py instead of the stripped out paths from bzr stat (and the like) | 04:11 |
| jdobrien | unfortunately, (as far as i can see) at the point the stripped out paths are output, there is no indication (like a global varable) where the working path is | 04:12 |
| jdobrien | aka WorkingTree4.basedir | 04:12 |
| jdobrien | fyi, this is a learning project for me...been doing c,c++ for 15 year...python for 15 days | 04:13 |
| jdobrien | this is the 'bug' https://bugs.launchpad.net/bzr/+bug/30159 | 04:17 |
| ubotu | Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] | 04:17 |
| jdobrien | yeah IMO...there may be to many side-effects changing the default behaviour | 04:18 |
| jdobrien | but i was thinking "bzr status --relative" would probably work | 04:19 |
| jdobrien | simple change if i know the basedir when in delta.py | 04:20 |
| lifeless | jdobrien: look at status.py | 04:28 |
| jdobrien | yeah | 04:28 |
| lifeless | jdobrien: iter_changes outputs paths from the root fo the tree | 04:28 |
| jdobrien | problem is, it strips out the basedir | 04:29 |
| lifeless | yes, thats the correct internal representation | 04:30 |
| lifeless | I think you want to do the change at output time only | 04:30 |
| jdobrien | yeah | 04:30 |
| lifeless | so in ChangeReporter | 04:30 |
| lifeless | and the Delta class for old-style status | 04:30 |
| jdobrien | k, which still brings me to the question...is the basedir in a global setting so i could calculate the relative path base on cwd? | 04:31 |
| jdobrien | it's not passed into change reporter...i could always get it again | 04:32 |
| lifeless | I would add a method on Delta to set the cwd | 04:33 |
| lifeless | and a parameter to ChangeReporter I think | 04:33 |
| lifeless | no there is no global, because in general it doesn't exist | 04:34 |
| jdobrien | oh crap | 04:34 |
| lifeless | on windows for instance its not per-thread | 04:34 |
| lifeless | on most unixes its per-thread | 04:34 |
| jdobrien | i missed it...it's passed into show_tree_status | 04:34 |
| jdobrien | <---------------idiot | 04:34 |
| lifeless | but when used as a library cwd is not ours to fool with | 04:34 |
| lifeless | wt is passed in, but not cwd | 04:35 |
| lifeless | the paths are already relative to wt | 04:35 |
| jdobrien | in this instance, wouldn't it be safe to get get the actual path (wt.basedir + path) and calc relative path based on cwd | 04:37 |
| jdobrien | on output only | 04:38 |
| lifeless | you need to pass the path to normalise against in though | 04:38 |
| jdobrien | yes | 04:38 |
| lifeless | as in, getcwd() isn't something library code should be calling | 04:38 |
| jdobrien | no | 04:38 |
| lifeless | to get the abspath, use wt.abspath(relpath) | 04:39 |
| jdobrien | thanks | 04:40 |
| jdobrien | not sure how this would work/break if basedir was not a physical dir | 04:41 |
| lifeless | :P | 04:41 |
| jdobrien | thanks for the help | 04:41 |
| jdobrien | bill this hour to wouter | 04:42 |
| lifeless | bug 218023 | 04:42 |
| ubotu | Launchpad bug 218023 in pqm "Use textwrap.dedent to make multiline strings more readable" [Undecided,New] https://launchpad.net/bugs/218023 | 04:42 |
| lifeless | yay tests pass | 04:51 |
| jdobrien | time for a beer | 04:52 |
| lifeless | maybe in the evening :P | 04:55 |
| jdobrien | 11:55 here USA FL | 04:55 |
| lifeless | ITYm 2355 :P | 04:56 |
| lifeless | 1355 here | 04:56 |
| lifeless | time for /wave | 05:20 |
| lifeless | poolie: good progress, I have the output stuff ~= correct | 05:20 |
| lifeless | adapters tomorrow | 05:21 |
| jdobrien | thanks for the help | 05:21 |
| Kamping_Kaiser | can bzr count the lines in a diff? i have a command "$(bzr diff $1 2>/dev/null |wc -l)", and i'm wondering if |wc -l is strictly necesary | 07:07 |
| spiv | I usually use "bzr diff | diffstat" myself :) | 07:09 |
| bob2 | there's a "bzr diffstat" plugin, too, for the minimal typing saving | 07:10 |
| thumper | lifeless: it appears in 'bin/pqm' there is an expectation that --config must be set, but the code seems to indicate that it is to specify a non default config file | 07:11 |
| thumper | lifeless: aarrrggghhhh | 07:16 |
| thumper | lifeless: I found out why I thought that | 07:16 |
| * thumper wipes the unclean feeling away | 07:16 | |
| === doko_ is now known as doko | ||
| ubotu | New bug: #218068 in bzr-svn "Pushing to SVN, SubversionException: "File ... already exists"" [Undecided,New] https://launchpad.net/bugs/218068 | 08:45 |
| * igc dinner | 09:28 | |
| jimcooncat | are there any good tutorials out there for using bzr for website development? Google's failing me on this. | 09:47 |
| poolie | hm i'm not sure | 09:48 |
| poolie | people seem to do it a lot | 09:49 |
| jimcooncat | I'm not a dummy, but I can't wrap my head around how it works | 09:51 |
| jimcooncat | must be a gui tool I can use to walk me through it, should I get a gedit extension or something? | 09:52 |
| jimcooncat | bzr-gtk? | 09:54 |
| poolie | jimcooncat: can you please send mail with your questions to bazaar@lists.canonical.com and i'm sure someone will help you out | 10:07 |
| poolie | unfortunately i have to go in a sec | 10:08 |
| jimcooncat | thanks poolie | 10:08 |
| visit0r | hello is there a way to set a file to be treated as a binary? it seems bzr diff detects one of our pdf as text due to some ascii lines in the beginning of it. | 10:50 |
| ubotu | New bug: #218115 in bzr "corrupt: attempt to add line-delta non-delta knit" [Undecided,New] https://launchpad.net/bugs/218115 | 10:51 |
| quicksilver | visit0r: that's a really good question and I'm surprised I don't know the answer | 11:01 |
| Kamping_Kaiser | i seem to recall there was a flag to merge that allowed it to resolve conflicts better. i cant see that option looking at its help now - have i missed it or was it removed? | 11:03 |
| Stavros | hello | 11:10 |
| Stavros | how does bzr-svn work with bzr branches? | 11:10 |
| visit0r | quicksilver: ok, I'll open a bug | 11:19 |
| bob2 | Stavros: how do you mean? | 11:28 |
| Stavros | bob2: if i have many branches on my local disk, do i have to merge before committing back to svn? does it make svn branches? | 11:28 |
| ubotu | New bug: #218128 in bzr "some binary files detected as text: provide a way to flag files binary?" [Undecided,New] https://launchpad.net/bugs/218128 | 11:31 |
| bob2 | Stavros: you can push from a bzr-svn bzr branch to svn, yes | 11:32 |
| Stavros | yes, but how will this affect my other branches? | 11:34 |
| Stavros | will i need to pull to them again? | 11:34 |
| === mrevell is now known as mrevell-lunch | ||
| === Pilky_ is now known as Pilky | ||
| === mrevell-lunch is now known as mrevell | ||
| igc | night | 13:10 |
| === mw|out is now known as mw | ||
| jam | Kamping_Kaiser: there are a couple, --reprocess and --lca are the recommended ones | 13:56 |
| jam | (you can also use "bzr remerge --lca foo" to not have to redo the whole merge again) | 13:57 |
| jam | Kamping_Kaiser: --reprocess reduces the size of the 3-way conflict chunks by finding lines that are common to both sides | 13:57 |
| jam | --lca uses a different merge algorithm that usually does better when you have a criss-cross merge, or other more involved history. | 13:57 |
| Kamping_Kaiser | jam, then --reprocess is probably the one thats good for aliasing to merge | 13:58 |
| jam | Kamping_Kaiser: correct, I've often thought it should be default | 13:58 |
| jam | I think the only reason it wasn't is because it conflicts with --show-base | 13:58 |
| jam | (if you remove the common lines, then you don't have the context to show the base lines correctly.) | 13:58 |
| Kamping_Kaiser | bzr conflicts drive me crazy :( i prefer svns. if --reprocess makes it less anoying i'll be a verry happy person ;) | 13:58 |
| jam | Kamping_Kaiser: try it out and let me know. I think most systems use the "--reprocess" form by default | 13:59 |
| Kamping_Kaiser | jam, not sure when i'll face a conflict next ;) but i'll try to remember | 14:01 |
| Kamping_Kaiser | thanks for the help :) | 14:02 |
| ubotu | New bug: #218191 in bzr "paramiko.SSHException: Server connection dropped" [Undecided,New] https://launchpad.net/bugs/218191 | 14:30 |
| ubotu | New bug: #218206 in bzr "Pending-deletions error message" [Undecided,New] https://launchpad.net/bugs/218206 | 15:05 |
| === bigdo2 is now known as bigdog | ||
| guilhemb | jam: hi! I was reading your lines above about --reprocess and --lca; from them I guess that using --reprocess and --lca in the same "bzr merge" command does not make sense? | 15:15 |
| LeoNerd | So.. Suppose I wanted to make a "bzr sync" command which is like pull or push, whichever it finds is appropriate. Is there some example command plugin, or some doc somewhere that explains how to make a plugin? | 15:17 |
| jam | guilhemb: I'm not sure, but I think that the style of how --lca works means that there is no need to --reprocess | 15:17 |
| jam | You are welcome to try both | 15:18 |
| jam | I don't think it will break anything, just that --lca doesn't leave any lines to be reprocessed | 15:18 |
| guilhemb | jam: ok, thanks | 15:19 |
| === pmezard_ is now known as pmezard | ||
| abentley | jam, guilhemb: Yes, --lca implicitly does --reprocess. | 15:31 |
| guilhemb | abentley: thanks for the info | 15:31 |
| abentley | guilhemb: np | 15:33 |
| moquist | I'm working on a project with one other developer. We both work remotely on multiple laptops and move around a lot. I've run 'bzr init-repo ./' and 'bzr init' in the project directory on our ssh server, so we can both run 'bzr checkout sftp://ourserver/path/to/project/' to get a local checkout from which commits can be made to the central repo. | 15:38 |
| moquist | How can/should I create a centralized 'working' branch (not sure about my terminology) where I can commit broken code from machineA so I can 'bzr update' on machineB tomorrow and keep working, and then commit to our shared repository when my new feature is working correctly? | 15:39 |
| moquist | I think I've made progress here. I can checkout from the shared repository to my own centralized...Thing, create a branch of my centralized Thing on each of my dev systems, and 'bzr push sftp://server/Thing' from each centralized system. Then I can 'cd Thing; bzr update; bzr commit' on the server. | 15:52 |
| awilkins | moquist: You shouldn't need a commit after an update (unless you've changed the content) | 15:59 |
| LeoNerd | Scripting question... Given two branch objects, is there an easy way to tell if one is an ancestor of the other? | 16:29 |
| LeoNerd | I.e. if I should push/pull in one direction | 16:29 |
| jam | LeoNerd: well, 'bzr missing' I thought would give that info | 16:32 |
| jam | I think it might be slower than it needs to be ATM | 16:33 |
| jam | be back in a bit | 16:33 |
| LeoNerd | Yes.. sorry.. by "scripting", I mean "I'm writing a plugin" | 16:33 |
| LeoNerd | (to anyone else): I can tell if they're identical by comparing branch1.last_revision == branch2.last_revision | 16:33 |
| LeoNerd | I presume one is an ancestor of the other if one's last_revision appears somewhere in the history of the other? | 16:34 |
| sabdfl | is 1.3.1 due to go into hardy? | 16:36 |
| james_w | sabdfl: I thought it was already there | 16:37 |
| james_w | or it may have been that the single patch that went in to 1.3.1 was added to the hardy package. | 16:37 |
| james_w | ah, it's 1.3.1~rc1-0ubuntu1, and there were no code changes between the rc and final for 1.3.1 | 16:38 |
| sabdfl | james_w: can we fix the version number, then? | 16:40 |
| james_w | probably, I'll submit a patch for approval from the release team. | 16:41 |
| abentley | LeoNerd: Ancestry, not history in particular. | 16:46 |
| LeoNerd | Right.. | 16:46 |
| LeoNerd | Should I look for the code that implements the "bzr missing" command, perhaps? That sounds likely to be doing similar tests | 16:46 |
| abentley | Probably not. | 16:47 |
| abentley | If you just want to know whether one branch is the ancestor of the other, you can determine that cheaply. | 16:47 |
| abentley | I.e. with Graph.is_ancestor or Graph.heads | 16:47 |
| LeoNerd | Well, I'm writing a command that's basically missing => {push/pull/complain/nothing} | 16:54 |
| sabdfl | thanks james_w, please let me know the RM response and status | 16:59 |
| james_w | sure | 16:59 |
| === Mez is now known as fishfinder | ||
| === fishfinder is now known as Mez | ||
| LeoNerd | So... perhaps it's sufficient to see if either branch can map the other's head revision into a revno | 17:02 |
| LeoNerd | ? | 17:02 |
| LeoNerd | Since at least one is guaranteed to fail | 17:03 |
| james_w | LeoNerd: get the two tip revisions, compare them for equality => do nothing | 17:04 |
| james_w | a in b's revision_history() => pull | 17:05 |
| james_w | b in a's revision_history() => push | 17:05 |
| james_w | otherwise error | 17:05 |
| james_w | I think that should work | 17:05 |
| LeoNerd | Yes.. it was the being "in the history" that confused me | 17:05 |
| LeoNerd | I've already done the first equallity one | 17:05 |
| james_w | ah, no, sorry, that only looks at mainline revisions. | 17:06 |
| dato | but I don't think you can't pull if your head is not a mainline revision of your parent, no? | 17:07 |
| dato | s/can't/can/ | 17:07 |
| james_w | hi dato | 17:10 |
| james_w | if your parent merges from you, then the tip of your branch will be the right hand parent of the paren't branch's tip, and you would be able to pull wouldn't you? | 17:11 |
| beuno | abentley, thanks for the amazing response to the show-author-on-commit patch, I haven't responded as I'm working on it, but I really appreciate how thorough it was :) | 17:31 |
| * lamont considers campaigning for bzr 1.3.1 in hardy, wonders what the support level from this channel is | 18:00 | |
| lamont | rather, how much support for the campaign he can count on... | 18:00 |
| dato | lamont: see a bit of backlog above, between james_w and sabdfl | 18:01 |
| dato | james_w: I'm not sure anymore :) (sorry, I missed your line at the time) | 18:02 |
| lamont | james_w: if 1.3.1~rc1-0ubuntu1 == 1.3.1-1, I'd be happy to do the upload, assuming it's approved... | 18:03 |
| LeoNerd | http://paste.leonerd.org.uk/?show=2184 <== my "bzr sync" command plugin. Anyone any comments? | 18:04 |
| james_w | lamont: the diff is trivial, I'm testing now, and then I'll seek permission from the release team | 18:06 |
| james_w | lamont: thanks for the offer though, I may well take you up on that if it gets approved | 18:06 |
| lamont | james_w: no worries - it's blocking some testing that I'm doing, since them machines in question have bzr_1.3.1-1~$mumble installed | 18:07 |
| lamont | and the end result is a very annoyed and failing do-release-upgrade | 18:07 |
| dato | james_w: ah, right, it does that thingy of making your last commit not-mainline | 18:08 |
| lamont | james_w: my technique is to just upload and then explain why. :-) | 18:08 |
| james_w | lamont: oh yeah, I'd forgotten everything was frozen so that was possible | 18:09 |
| lamont | :-D | 18:09 |
| james_w | lamont: this upload would be 1.3.1-0ubuntu1, would that solve your problem? | 18:09 |
| lamont | is this an upload to debian, or to ubuntu? | 18:09 |
| lamont | no. | 18:09 |
| dato | hm | 18:09 |
| lamont | >>1.3.1-1~CAT.6.06 | 18:10 |
| dato | I guess I could upload to debian | 18:10 |
| james_w | I was going for Ubuntu, but we could upload to Debian and sync | 18:10 |
| dato | I didn't, because 1.4~rc1 was around the corner | 18:10 |
| lamont | hrm... | 18:10 |
| james_w | dato: if you've got the time, that would be great. | 18:10 |
| lamont | dato: are you the normal uploader to debian? | 18:10 |
| dato | but rc1 turned out unsuitable for upload, so I ended up uploading none | 18:10 |
| dato | lamont: yes | 18:10 |
| lamont | sync is pain these days... | 18:10 |
| lamont | how about 1.3.1-1 to debian, and 1.3.1-1build1 to ubuntu and lots of handwavy bits about why 'build' is correct | 18:11 |
| james_w | we could fake-sync, or -1build1 one it | 18:11 |
| lamont | ^5 | 18:11 |
| lamont | fakesync would be bad. | 18:11 |
| lamont | but we want the orig.tar.gz files to be the same both places | 18:11 |
| james_w | yeah, that would work, it may make the release team think about it a bit more though. | 18:11 |
| james_w | true | 18:11 |
| lamont | nah - I'm happy to deal with release team... they're used to my craziness | 18:12 |
| james_w | :-) | 18:12 |
| james_w | lamont: are we best to just subscribe the release team to the bug and then deal with the actual upload when we have the ACK? | 18:13 |
| dato | oh | 18:14 |
| james_w | I can provide the upstream diff that we want to incorporate. | 18:14 |
| dato | first bzr upload with python 2.5 | 18:14 |
| dato | not that it really matters | 18:14 |
| james_w | dato: it's been 2.5 on Ubuntu for a while, so it should be fine. | 18:14 |
| lamont | is there abug? | 18:14 |
| lamont | if we just upload 1.3.1-1build1 to hardy, we don't need a bug | 18:14 |
| james_w | a non very eloquent one: bug 218257 | 18:14 |
| ubotu | Launchpad bug 218257 in bzr "Update bzr package to a non-release-candiate version number" [Undecided,New] https://launchpad.net/bugs/218257 | 18:14 |
| james_w | I was going to expand on it when I had the patch. | 18:15 |
| james_w | this would be my first upload-new-upstream-version-to-main-during-final-freeze upload, so I'm still feeling my way around | 18:15 |
| lamont | that works. the other big decision-fork is that if the bits are in debian within the next 45 min or so, there's a very good chance they'll make today's dinstall run, if not -> tomorrow. to sync them, it's best if the mirrors have had a chance to do their thing | 18:16 |
| lamont | if we just upload to hardy, then it's click-to-approve for the release manager | 18:16 |
| dato | lamont: it'll be <45min | 18:16 |
| dato | wow, what's all this crap pycentral now spits | 18:17 |
| lamont | dato: it doesn't spit it, it excretes it | 18:18 |
| lamont | james_w: if we know that the same .orig.tar.gz will be used by both uploads, then we can actually upload ubuntu ahead of debian if we want, and I can get back to testing,... :-) | 18:19 |
| james_w | dato: is that the "diff" stuff? | 18:19 |
| dato | ye | 18:19 |
| dato | s | 18:20 |
| james_w | it looks like debugging output to me | 18:20 |
| lamont | in the ideal world, we want dato's package for debian, with about 5 lines of change in changelog (for -1build1) and an upload... | 18:20 |
| lamont | james_w: are you core-dev, or who does your ubuntu uploads? | 18:20 |
| james_w | yep | 18:20 |
| lamont | ah, cool | 18:20 |
| james_w | we need to sync first though? | 18:20 |
| lamont | not if we're really really really diff from 1.3.1-1 in only the changelog | 18:20 |
| james_w | ah, no, I'm not core-dev, it was your previous statement I was agreeing with | 18:20 |
| lamont | ok. /me is happy to sponsor... so when you/dato are happy with 1.3.1-1 for debian, if I could have a copy of it, I'll smack it into hardy | 18:21 |
| james_w | I'm testing 1.3.1 now, so when dato's got the package I should have finished testing | 18:23 |
| lamont | \o/ | 18:24 |
| dato | good lord | 18:32 |
| dato | my wireless here sucks | 18:32 |
| dato | uploaded nevertheless | 18:34 |
| james_w | dato: thanks. | 18:37 |
| lamont | dato: got a pointer to your bits? | 18:37 |
| dato | yes, http://people.debian.org/~adeodato/tmp/2008-04-16/bzr/ | 18:38 |
| james_w | :-) | 18:38 |
| james_w | lamont: it's passed a selftest here, and stood up to a few minutes use | 18:38 |
| james_w | unfortunately I don't have any real work to do in bzr at the moment, so I can't test that. | 18:38 |
| lamont | james_w: that's more than my testing before I deploy...:0) | 18:39 |
| james_w | :-) | 18:40 |
| james_w | lamont: would you like me to do anything with the bug, or is it superfluous now that we have you to prod the release team? | 18:41 |
| lamont | oh. whichnumber? | 18:42 |
| james_w | 218257 | 18:44 |
| lamont | stupid wireless | 18:56 |
| lamont | james_w: the upload will close it | 18:56 |
| lamont | sigh. diff orig.tar.gz than the bazaar-vcs download page. | 18:57 |
| dato | uh | 18:58 |
| lamont | dato: or did you already upload? | 18:59 |
| dato | lamont: I used a pristine tarball | 18:59 |
| lamont | nfc what poolie used then | 18:59 |
| dato | https://launchpad.net/bzr/1.3/1.3.1/+download/bzr-1.3.1.tar.gz <-- link obtained from http://bazaar-vcs.org/Download | 18:59 |
| dato | lamont: err | 18:59 |
| lamont | hrm | 18:59 |
| dato | lamont: when james_w said 1.3.1~rc1-0buntu1 is 1.3.1-1 | 18:59 |
| lamont | no matter - I'll make sure your .dsc unpacks. | 18:59 |
| dato | he meant there were no code changes | 18:59 |
| dato | not that the tarball were identical | 18:59 |
| dato | poolie used the rc1 tarball, I guess :) | 19:00 |
| lamont | 5a2160e057d79288c186c42567aa0dc2 ../bzr_1.3.1.orig.tar.gz | 19:00 |
| lamont | he used _that_ one. :-) | 19:00 |
| dato | that's the one I uploaded | 19:00 |
| lamont | oh right | 19:01 |
| lamont | 2c560167aea6c8bde7cfaf7883d267dc ../../bzr_1.3.1.orig.tar.gz | 19:01 |
| james_w | yeah, sorry, there was a NEWS entry, and the version number was changed, but there were no changes to the meat of the code. | 19:01 |
| lamont | off by one error | 19:01 |
| lamont | testbuilding nwo | 19:04 |
| lamont | dh_python -pbzr | 19:08 |
| lamont | dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or dh_pycentral should do the work. You can remove dh_python from your rules file. | 19:08 |
| lamont | heh | 19:08 |
| dato | yay cdbs | 19:08 |
| lamont | in my mind cdbs is still filed under "slightly less evil than dbs;" | 19:09 |
| * lamont goes to talk to the nice folks in #ubuntu-release | 19:13 | |
| === mvo_ is now known as mvo | ||
| tolstoy | Folks, I'd like to try the fastimport plugin with the cvs2svn plugin, but there's no documentation on the options to use with cvs2svn. | 19:39 |
| === kiko-fud is now known as kiko | ||
| tolstoy | Do I output to a dumpfile? | 19:40 |
| tolstoy | I've seen this: includes an option now for the required output format. Python. But I don't know what that option is. | 19:40 |
| lamont | james_w: it'll get accepted post-RC :-( so fridayish sometime | 19:52 |
| tolstoy | cws2svn --dumpfile=app.dump ;; then cat app.dump | bzr fast-import - | 19:54 |
| tolstoy | Doesn't seem to work. | 19:54 |
| james_w | lamont: ok, thanks | 20:43 |
| james_w | tolstoy: does cvs2svn output in the fast-import format? | 20:44 |
| abentley | beuno: You're welcome. Hope it's helpful. | 20:46 |
| === kiko is now known as kiko-phone | ||
| === mw is now known as mw|food | ||
| trepca | hey | 21:10 |
| trepca | i have a project that consist of many small projects | 21:10 |
| trepca | how would i best organize it with bzr | 21:10 |
| trepca | in git there are superprojects | 21:11 |
| trepca | you can link to other repositories in them | 21:11 |
| trepca | wow, this channel is brimming with life :) | 21:16 |
| lifeless | trepca: sure is | 21:30 |
| james_w | trepca: bzr will have nested trees that are like subprojects, but they are not ready yet | 21:31 |
| james_w | hi lifeless | 21:31 |
| trepca | ok, thanks | 21:31 |
| trepca | i could create a huge repository as in SVN that would hold all those projects ... but that is probably not optimal for bzr ? | 21:32 |
| james_w | yeah, that's not great | 21:34 |
| tolstoy | james_w: Sorry, I was out to lunch! I don't know if it outputs in that format. No command-line switches suggest that it does. | 21:35 |
| tolstoy | james_w: But the docs at bazaar-vcs suggests that it does. | 21:35 |
| james_w | tolstoy: I don't think that it does | 21:36 |
| james_w | ah, maybe I'm wrong, have you got a pointer? | 21:36 |
| tolstoy | Hold on.... | 21:36 |
| tolstoy | http://bazaar-vcs.org/BzrFastImport/FrontEnds | 21:37 |
| tolstoy | I'm using the macport version, which might be the problem. | 21:37 |
| tolstoy | Hm. I'm using version 2.1.0, but there's a 2.1.1 available as a tarball on their website. | 21:39 |
| james_w | "includes an option now for the required output format" | 21:41 |
| tolstoy | Right. | 21:41 |
| james_w | "now" suggests it is new, so the new version may be needed | 21:41 |
| tolstoy | And that's all I can find on the subject. | 21:41 |
| === mw|food is now known as mw | ||
| tolstoy | Hm. I wonder if the Mac DMG install of BZR contains the bzr subversion plugin. | 21:45 |
| === kiko-phone is now known as kiko | ||
| trepca | i does not | 21:50 |
| trepca | it | 21:50 |
| tolstoy | Alas, no, it seems not to. | 21:50 |
| xxxYURAxxx | how to configure bzr-email to send emails? | 22:17 |
| lifeless | 'bzr help email' should contain enough info | 22:18 |
| xxxYURAxxx | thanks | 22:18 |
| ubotu | New bug: #218406 in bzr-gtk "olive-gtk.desktop lists incorrect categories" [Undecided,New] https://launchpad.net/bugs/218406 | 22:40 |
| LeoNerd | Hrm.. It seems I can ssh an alias in my .ssh/config, but I can't bzr push sftp:// it | 22:40 |
| LeoNerd | Can't bzr+ssh:// because the host doesn't have bzr installed | 22:40 |
| igc | morning | 22:56 |
| VSpike | I'm probably missing something obvious here but when I just did a bzr checkout, it created the last directory in the remote path. i.e. I did bzr checkout sftp://home/blah/bloo/main and it created ./main and filled it with stuff... other times, I'm sure the files have ended up just in the directory I run checkout. What causes the different behaviour? | 23:00 |
| lifeless | VSpike: the only time chekcout creates the files in '.' is when you use 'bzr checkout .' to create a tree on a treeless branch | 23:01 |
| lifeless | going for a walk to think about apis | 23:07 |
| VSpike | I keep getting the message No handlers could be found for logger "bzr" | 23:07 |
| james_w | VSpike: run "bzr --version", and it should say "Bazaar log file: " check that the path there is writeable by your user | 23:12 |
| VSpike | ahh.. spot on. I see the problem. I ran bzr with sudo the first time I used it | 23:14 |
| james_w | that's usually the problem, however the patch I wrote to detect it and explain it to the user was far from appetising. | 23:15 |
| * fullermd skips the obvious 'byte' puns. | 23:15 | |
| VSpike | james_w: thx | 23:16 |
| BasicOSX | Can you specify multiple email address on a post_commit_to ? | 23:20 |
| thumper | morning lifeless | 23:33 |
| thumper | lifeless: as you'll no doubt soon be aware, I've posted a branch for using optparse for PQM as part of the clean up for bug 218416 | 23:33 |
| ubotu | Launchpad bug 218416 in pqm "PQM has too much config in global scope" [Undecided,New] https://launchpad.net/bugs/218416 | 23:34 |
| LeoNerd | I asked earlier but didn't see any reply. I've written a push-or-pull command called "sync". Does anyone have any comment? ==> http://paste.leonerd.org.uk/?show=2184 | 23:34 |
| thumper | LeoNerd: I've not looked, but what happens if they are both different? | 23:34 |
| LeoNerd | It prints "Sorry, they diverged" and stops | 23:35 |
| LeoNerd | The intention is: If they're identical, it does nothing. If one is an ancestor of the other, it will push/pull in the right direction. Otherwise it complains. | 23:37 |
| abentley | LeoNerd: I still think your test is wrong. | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!