[06:11] <GungaDin> if I've merged something (still haven't committed!!!)  and I'd like to reverse this operation and do a different merge, how can I do that?
[06:11] <bob2> revert
[06:12] <GungaDin> but hasn't the history been updated yet?
[06:12] <bob2> not until you commit
[06:14] <GungaDin> cool
[06:14] <GungaDin> thx
[06:16] <RAOF> bzr is all about not doing things you don't want to do. :)
[06:18] <fullermd> Where's the "no-taxes" plugin then?
[07:41] <vila> hi all !
[07:42]  * fullermd waves at vila.
[09:59] <masklinn> hello, is there a way to edit history in bazaar in order to fix a previous (broken, but not yet published) commit? In mercurial I'd use mq, qimport everything down to the faulty commit, qpop and edit my broken commit (or merge patches, whatever), in git I'm sure I'd find a way, but in bazaar I haven't found any paths so far. Loom is billed as an equivalent to MQ, but looks very complex, apparently modifies the repository format (is it still possible
[10:00] <masklinn> push to the regular, old format? Or for loom-less people to get non-loomed revisions as it is with hg mq?) and I haven't found any instruction on importing "normal" bzr revisions into looms and exporting them back in bazaar.
[10:02] <masklinn> So... is there anything I missed? How do you handle the case where you performed a broken commit and only realize it 5 commits later?
[10:03] <bob2> you can uncommit
[10:03] <beuno> or use bzr-rewrite
[10:03] <bob2> or you can branch from before the problem and manually commit new changes
[10:03] <bob2> or use bzr-rewrite
[10:03] <bob2> aka bzr rebase
[10:04] <Peng> masklinn: Mostly we just commit a fix. :P
[10:04] <masklinn> I don't want to uncommit, first uncommit is broken on my mac, second that means I have to manually store 5 different log messages in some kind of text file so I can re-commit later
[10:04] <masklinn> bzr-rewrite sounds interesting
[10:04] <masklinn> thanks
[10:04] <bob2> depends what broken means, too
[10:04] <masklinn> peng, I'd do that if the revisions were already published, but the history is still fully local so it's a waste to have broken revisions in there when I'm still in a position to amend them without anybody knowing
[10:05] <bob2> if it's "bug in the code", just fix it like Peng said
[10:05] <bob2> if it's nuclear launch codes, then put more effort in
[10:05] <Kinnison> Or you put up with the fact that you got a broken commit; fix the issue on head, and move on, having learned to be more careful in future :-)
[10:05] <vila> masklinn: if uncommit is broken on your mac (how so ?), please a file a bug
[10:05] <masklinn> vila: it locks up 9 times out of 10, no error message no nothing, and I have to C-c, break the lock, update and I lose all the changes in the tentatively uncommited commit
[10:06] <vila> masklinn: no messages even in .bzr.log ?
[10:06] <masklinn> vila: I don't know, I'll have to check next time it happens
[10:06] <masklinn> vila: never really wondered about the logfile
[10:06] <vila> masklinn: .bzr.log should still contain your old attemps, no need to wait :D
[10:07] <masklinn> vila: yeah but I tend to create and delete lots of clones, so I'm not sure I still have repositories where I did it. I tend to just avoid the operation these days
[10:09] <vila> masklinn: ok, then keep in mind that many people use uncommit on mac (myself included) and nobody ever report problems there, so presumably something is special in your config
[10:09] <masklinn> vila: i'm sure that's the case, which is why I specified it was broken on *my* machine, not in general ;)
[10:10] <vila> masklinn: if there is a bug, we want it to be fixed ;)
[10:10] <masklinn> yep, I'll check the log next time I forget myself and try an uncommit
[10:11] <j^> why does bzr use so much memory if i checkout an lp repository without account?
[10:11] <j^> i.e. bzr branch lp:bzr
[10:11] <j^> 595m 421m 2280 D  1.0 42.1   3:27.54 bzr
[10:14] <Peng> Yikes.
[10:21] <gerard_> hey
[10:42] <gerard_> jam: did you see the latest changes to my branch?
[10:42] <gerard_> I'm happy with it now :) ;)
[10:45] <masklinn> vila, where's the bzr log supposed to be?
[10:45] <bob2> ~/.
[10:46] <masklinn> oh, not in the repo root or .bzr?
[10:46] <vila> masklinn: 'bzr version' should tell you
[10:46] <vila> gerard_: jam in in Chicago, he's sleeping :D
[10:47] <fullermd> Yeah.  Nobody in this TZ would be awake at this hour; that would be crazy.
[10:47] <vila> j^: which bzr version are you using ? bzr-2.1 has fix a few related bugs
[10:48] <gerard_> vila: ah, hehe
[10:48] <vila> yeah no *average* body :D
[10:48] <vila> only people like cops, fire workers and the like, plus of course the bad guys...
[10:49] <vila> did I miss some category ? :D
[10:50] <fullermd> Well, I'm not a cop, I'm not a fire worker, I...   umm....
[10:50] <fullermd> Well, no, I guess that's all the categories   :p
[10:50] <vila> hehe
[10:51] <masklinn> vila, well there does't seem to be anything of note in the logs: http://pastebin.com/d7e2a0cf0
[10:51] <masklinn> Is there a way to turn the log's verbosity to 11 or something? I don't see anything in the docs
[10:52] <vila> masklinn: you meant C-c or you really did C-z ?
[10:53] <masklinn> I really did C-z, C-c didn't do anything, and neither did C-d
[10:53] <masklinn> The above revision(s) will be removed.
[10:53] <masklinn> Are you sure [y/N]? y
[10:53] <masklinn> ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^Z
[10:53] <masklinn> [1]+  Stopped                 bzr uncommit
[10:53] <vila> C-z suspend the process and put it in the background, you leave bzr no chance to clean up anything
[10:53] <masklinn> well to kill it I used a regular kill, not a kill -9
[10:54] <masklinn> so theoretically it should have given bzr the ability to do something, right?
[10:55] <vila> weird, what kind of setup are you using ? A bound branch ? The warning about the working tree out of date may be due to the break...
[10:55] <vila> masklinn: well, yes
[10:55] <masklinn> yeah the warning is due to the break, that's not an issue (the second command is mainly to show that there was nothing after the uncommit)
[10:55] <fullermd> Well, if ^C (with at least a few seconds) didn't interrupt it, it's stuck in the kernel somewhere, so it would never get a chance anyway.
[10:55] <masklinn> it's a standalone
[10:55] <vila> masklinn: what bzr version are you using ? (I'm pretty sure the recent ones always output that in the log)
[10:55] <masklinn> vila: it's a standalone tree
[10:56] <masklinn> 2.0.4 from macports
[10:56] <masklinn> Bazaar (bzr) 2.0.4
[10:56] <masklinn>   Python interpreter: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python 2.6.4
[10:56] <masklinn>   Python standard library: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
[10:56] <masklinn>   Platform: Darwin-10.2.0-i386-64bit
[10:56] <masklinn>   bzrlib: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/bzrlib
[10:56] <vila> !paste
[10:57] <vila> masklinn: where is your repo ? Local ? http ? bzr+ssh ?
[10:57] <vila> masklinn: mounted NFS ?
[10:57] <masklinn> local fs
[10:58] <masklinn> freshly cloned from another local repo
[10:58] <vila> masklinn: so you don't use shared repos ? (You should give it a try if you use many branches that share history)
[10:59] <masklinn> vila: I sometimes do, but I didn't on that project. And we have... issues with shared repos (the remote repositories are in a pretty old format, so things don't work out well when trying to push or push shared repos to lp)
[11:00] <Peng> ...Huh? How would shared repos make a difference there?
[11:00] <masklinn> you tell me
[11:01] <masklinn> bzr whines about incompatible repository formats
[11:01] <masklinn> and lp then tells me that the repo I just pushed is broken
[11:01] <Peng> It's notable that "bzr branch" uses the source branch's format by default, but the shared repo's format if you're in a shared repo (obviously), but it's not hard to keep that straight.
[11:01] <vila> Peng: I didn't way they were related, just mentioning them
[11:02] <Peng> vila: Err, sorry. I was just replying to masklinn, not you.
[11:02] <vila> Peng: no worries ;D
[11:03] <vila> masklinn: I agree with Peng, most probably you ran into bzr forcing the default format to be 2a
[11:03] <masklinn> Peng: yes, and the shared repo is created using 2a by default, and by the time i realized that I was basically hosed. And I'm not even clear on which format I should be using locally to keep things straight, as the repo names on the CLI and the ones given by error messages are basically unrelated
[11:03] <vila> masklinn: have a look at the upgrade guide: http://doc.bazaar.canonical.com/latest/en/upgrade-guide/index.html
[11:03] <masklinn> (I'm not even sure the remote repo's format is compatible with shared repositories)
[11:04] <vila> masklinn: I'd be suprised if you use a format that doesn't support shared repos
[11:04] <masklinn> vila: might be possible at some point, but the project is pretty big, and e.g. ubuntu 8.04 doesn't ship with 2.0, so for now it's not upgraded
[11:04] <Peng> It would have to be horrifically old, or broken, to not support shared repos. Besides, what matters is the local format.
[11:04] <vila> masklinn: ok, let's put that aside for now then
[11:04] <fullermd> I'd be well beyond surprised.  all-in-one formats are *OLD*.
[11:05] <vila> masklinn: how big is your working tree ?
[11:05] <masklinn> villa: the project/branch in question is https://code.launchpad.net/~openerp/openobject-addons/5.0 (warning: humongously huge)
[11:05] <masklinn> vila: .bzr is 93MB, total WC is 160MB
[11:05] <vila> masklinn: how many files ?
[11:06] <masklinn> vila: I fear my bzr-fu and terminal-fu are too weak to know, how can I check?
[11:06] <vila> I wonder if you may be missing some progress report and if bzr is actually taking longer than usual to finish the uncommit
[11:07] <vila> find . | ec -l
[11:07] <masklinn> vila: I don't think so, in the past I let it run 30mn+, never saw any progress
[11:07] <vila> find . | wc -l
[11:07] <Peng> Or "bzr inventory | wc -l".
[11:07] <vila> wow, 30mn is indeed far too long
[11:07] <masklinn> vila: find . reports 5722, bzr inventory reports 5689
[11:08] <vila> can you pastebin the output of 'brz info -v' ?
[11:08] <vila> masklinn: wow, 33 unknown files ? Or are there some *~n~ files ?
[11:08] <masklinn> vila, wouldn't those be the files in .bzr?
[11:09] <vila> masklinn: oh sure
[11:09] <Peng> Wow, the remote branch is rich-root-pack, so you actually could use 2a locally, though converting between them takes a couple seconds.
[11:09] <Peng> However, you can't *stack* between them, and that's probably what's freaking Launchpad out.
[11:09] <vila> bug 33 sounds a bit high, ha no, the repo is there
[11:09] <Peng> \o/
[11:09] <vila> grr *but* 33
[11:11] <vila> ubottu: your humour is thick
[11:11] <masklinn> vila: http://pastebin.com/d78ba2197
[11:11] <masklinn> apparently something is a bit broken after the uncommit
[11:12] <masklinn> running a bzr check
[11:12] <fullermd> That probably means the uncommit did its job on the branch, and failed trying to do stuff in the working tree.
[11:12] <fullermd> That's consistent with stat bleating about needing 'update' too.
[11:12]  * vila agrees with fullermd
[11:13] <masklinn> fullermd: I did an update after that, so the working tree should be in sync
[11:13] <vila> after what ?
[11:13] <fullermd> And doing stuff in the WT does OS locks last I checked, which is also the most likely place for uncommit to lock itself up inside the kernel.
[11:13] <masklinn> after it asked me to bzr update
[11:13] <masklinn> I bzr broke-lock and bzr updated
[11:13] <vila> yeah, so something was already broken there probably
[11:14] <vila> fullermd: OS locks are broken in OSX ? As much as in BSD ? :-D
[11:14] <masklinn> well the original repo I cloned from (the one without/before bzr uncommit) seems ok
[11:15] <Peng> Sure, working tree nonsense won't break the branch or repo.
[11:15] <Peng> Well, maybe, if you somehow commit something horribly wrong, but that's difficult.
[11:16] <vila> masklinn: side-note: since you already use a rich-root-aware format, migrating to 2a is easier
[11:17] <vila> Peng: like what ? If we can commit it we can uncommit it :D
[11:17] <masklinn> easier for me, but not easier for the project as a whole, and it doesn't solve lp freaking out everytime a bee flies near the window
[11:18] <vila> masklinn: easier compared to people using a non rich-root-aware format
[11:18] <Peng> Ideally, LP would be less dumb. I'm not sure whether it's supposed to be, too.
[11:18] <Peng> Yeah, the only issue you've got converting between rich-root-pack and 2a is stacking.
[11:18] <masklinn> Peng: ideally^2, lp would start by offering the same "clone" button github and bitbucket do
[11:18] <fullermd> Also, a pony.
[11:18] <masklinn> and then I'd know beforehand that Stuff Works
[11:18] <Peng> Well, and that pushing 2a up to LP is rude if not everyone using the project has a new enough version of bzr...
[11:19] <masklinn> yeah, i like ponies
[11:19] <masklinn> Peng: yep, though I think the stacked thing is creating enough pain right now that the "deciders" are looking at just migrating everything to 2a and telling users to install 2.x ppas
[11:20] <vila> masklinn: can you pastebin the relevant portion of .bzr.log leading to the traceback about bzr: ERROR: bzrlib.errors.NoSuchRevision: BzrBranch6('file:///Users/masklinn/projects/tiny/addons/stable-security-fix-2575/') has no revision<EMAIL_ADDRESS>[11:21] <vila> masklinn: migrating everything to 2a and telling users to install 2.x ppas is a good idea, you'll get smaller repos, faster bzr and the ability to bzr push stacked branches on LP, which in turn will allow you to push roughly size(changes) for new branches
[11:22] <masklinn> vila: yeah, but that requires users to install ppas on "older" ubuntus (and get lost if they're using non-ubuntu distros which don't ship 2.x, I guess) which isn't very nice to them
[11:23] <vila> masklinn: bzr-2.0 is being backported to older Ubuntu releases, this should happen RSN (tm)
[11:24] <fullermd> Just in time for 2.1 to be out, maybe  ;p
[11:24] <masklinn> villa: This should be the part of the log leading to the error: http://pastebin.com/m2e6f66be
[11:24] <masklinn> fullermd: talking about 2.1, does it change the repo format *again*?
[11:26] <jelmer> masklinn: only major versions (1.0, 2.0) change the default format
[11:26] <vila> masklinn: right, so it looks like your working tree is pointing to a revision that doesn't exist in the associated repo ? How weird
[11:26] <masklinn> vila: well that would be the uncommitted revision wouldn't it?
[11:26] <fullermd> uncommit doesn't remove the rev from the repo.
[11:26] <vila> masklinn: but it should still be in the repo
[11:27] <masklinn> oh
[11:27] <vila> masklinn: did you try something like 'bzr uncommit -r<unkown_revision>' ?
[11:27] <masklinn> nope
[11:27] <masklinn> just a plain "bzr uncommit"
[11:27] <vila> masklinn: did you try something like 'bzr uncommit -r<some_revision>' ?
[11:27] <vila> wow
[11:28] <masklinn> I'd done a bzr clone -r{something} before because I didn't want the top 2 revisions of the other repository (since I wanted to fix 2575)
[11:28] <masklinn> but uncommit was options-less
[11:30] <j^> vila: that was with 2.0.4 will try 2.1
[11:31] <vila> j^: make sure the extensions are compiled if you're running from source
[11:37] <vila> masklinn: and you had a valid working tree after your 'bzr branch' ?
[11:37] <masklinn> vila: I think so, but I can try brancing to some other repo and doing an info -v just in case
[11:38] <vila> masklinn: filing a bug with a reproducible scenario will be ideal
[11:39] <masklinn> well yeah but I doubt "reproducible 90% of the time on my own machine, never on others" would be reproducible enough ;)
[11:40] <vila> masklinn: that'd be a start towards making it 100% reproducible :) Then we'll can fix it !
[11:43] <masklinn> ok tried re-cloning the original branch (with the same parameters) to a new one, bzr info -v comes back with a clean bill of health, so it does quite seem like uncommit broke the thing. I'll try clearing my log and re-running the interesting commands
[11:45] <masklinn> and this time it worked... oh well (weird though, I get a warning about gtk, why is gtk involved in uncommit?)
[11:48] <fullermd> bzr-gtk hooks into it if it's installed.
[11:49] <masklinn> fullermd: ok, I'll kill bzr-gtk, the issues might come from that (macports's gtk seems to do nothing but crash on my machine, uncommit's issues might come from there, or the issues might be related)
[11:49] <masklinn> with a bit of luck, it'll unscrew uncommit
[11:57] <krisives> does anyone know how to use bzr-git ?
[11:57] <krisives> i cant find any kind of documentation
[11:58] <Kamping_Kaiser> bzr help git work?
[11:59] <manuee> hi everyone
[12:00] <manuee> drupal is considering moving (finaly) out of cvs, and pondering other vcs ... it'd b e nice if some of you could chip in http://groups.drupal.org/node/48818
[12:00] <manuee> i personaly would like us to use bzr, but not knowledgaeble enough to make a statement or to defend it against other options
[12:07] <krisives> `bzr help git` only gives me:
[12:07] <krisives> "A GIT branch and repository format implementation for bzr."
[12:08] <krisives> manuee: Good luck, I've noticed a lot of projects blindly hate bzr
[12:09] <krisives> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html is a good start, and the ultimate argument is simplicity, low barrier of entry, which they should obviously appreciate if they are switching from CVS
[12:12] <manuee> thanks krisives
[12:12] <krisives> and for a shameless plug: http://santiance.com/2010/01/how-to-synchronize-code-with-bazaar/
[13:17] <masklinn> Should documentary lacks of bzr (and extensions) be reported as bugs? Because it isn't exactly clear from its help topics that, in bzr rebase, `-r` can pretty much turn it into a transplant
[13:18] <masklinn> even though it seems to work ok
[13:26] <gerard_> masklinn: I'd say it's a bug
[13:35] <masklinn> ok, so I should open a bug on bzr-rebase on their lp page?
[14:25] <bialix> it seems today is holiday, so quiet here
[14:30] <rubbs> today is a holiday?
[14:30] <rubbs> hello bialix btw.
[14:30] <bialix> hello rubbs
[14:31] <bialix> maybe it was my imagination
[14:31] <bialix> so quiet here usually on weekends and holidays
[14:31] <rubbs> There is a lot of snow in the US. I don't know if that's part of it. Large parts of the East Coast here are without power.
[14:31] <rubbs> true
[14:39] <bialix> oh, that's not good
[14:39] <rubbs> yeah. I had to spend 45 minutes digging out my car this morning.
[14:40] <rubbs> made it to work though
[14:40] <bialix> hi jam, how's you dealing with snow?
[14:41] <jam> morning bialix, not really snowing here
[14:41] <bialix> rubbs: we have similar problems here
[14:41] <jam> I guess to the east and west of me is far worse than here
[14:41] <bialix> jam: morning, can you refresh my memory about 2.1 final date?
[14:41] <jam> this week
[14:41] <bialix> that's good
[14:41] <rubbs> jam you in Midwest?
[14:42] <jam> rubbs: yeah, just south of Chicago
[14:42] <rubbs> ah. cool. I have friends who live in Elgin (sp?). I was born in Paletine and lived in Aurora for a while
[14:48] <gerard_> jam: morning
[14:51] <bialix> jam: who is release manager for 2.1 final? poolie?
[14:51]  * bialix looking for summary of new changes in 2.1
[14:54] <bialix> rats, news entries for 2.0.x and 2.1.0by releases mixed
[14:54] <jam> bialix: I think I'm still the official 2.1 releaser
[14:54] <bialix> may I beg you to write soem summary on changes re 2.0?
[14:54] <bialix> *some
[14:55] <bialix> this will be first really big release
[14:55] <bialix> 6 months of work
[14:55] <jam> bialix: http://bazaarvcs.wordpress.com/2010/01/18/bazaar-2-1-2/
[14:57] <bialix> jam: thanks
[14:58]  * bialix hopes to see nested trees landed in 2.2
[15:00] <bialix> jam: fyi about qbzr 0.18.1: the tag for this release available in both lp:qbzr/0.18 and trunk. but I suspect you'd like to use lp:qbzr/0.18 for 2.1.x anyway
[15:00] <ronny> btw, what exactly is nested trees?
[15:00] <jam> bialix: well, it wasn't there when I tried doing the packaging earlier, but it doesn't really matter. As long as your tags can be found, I'll get them
[15:01] <bialix> ok
[15:07] <bialix> ronny: svn:externals, git submodules, hg subrepos
[15:11] <ronny> i see
[15:44] <mathrick> hi, what's the best / easiest way to install a post-commit hook in a single repo?
[15:45] <mathrick> I'd be happy to be able just to call a shell command, really, scp is all I need
[15:46] <rubbs> are you looking for just a mirroring system?
[15:47] <rubbs> if so, http://wiki.bazaar.canonical.com/BzrPlugins, under "Publishing" might be what your looking for. There are a few options there.
[15:47] <mathrick> right, but I need a single file, more or less
[15:48] <mathrick> the ones I've seen want to push the whole tree I believe
[15:48] <rubbs> ah, ok.
[15:49] <mathrick> so I guess what I need is to read some kind of config on the branch, but how'd I go about it?
[15:50] <mathrick> hmm
[15:50] <rubbs> not sure.
[15:50]  * mathrick reads automirror's source
[15:50] <rubbs> sorry I couldn't be more help :(
[15:50] <mathrick> nah, it's fine
[15:51] <bindjp> hi, was trying to get the bzr explorer to work in snow leopard and with no luck.  The installer looks like it doesn't install it
[15:52] <mathrick> bindjp: did you read the note on http://wiki.bazaar.canonical.com/MacOSXDownloads ?
[15:52] <mathrick> "he "Desktop" bundles include Bazaar Explorer and QBzr in addition to the contents of the "Core" bundles. It requires that you have the Qt framework installed. For Mac OS X 10.6 Snow Leopard, you must install the 64-bit Qt 4.6.1 framework."
[15:53] <bindjp> mathrick: yeah, I installed that
[15:53] <bindjp> mathrick: maybe there is a way to clean out the previous installs and start again?
[15:55] <mathrick> dunno really
[15:56] <bindjp> mathrick: I will see what I can find, thanks, just wondered if anybody ran into troubles too
[15:57] <mathrick> bindjp: yeah, I was making sure you didn't run into the most obvious issue. I don't really know anything past that, sorry
[16:16] <doctormo> I'm getting an odd error when I try and checkout lp:drawberry
[16:16] <doctormo> ErrorFromSmartServer: Error received from smart server: ('error', "'Inter1and2Helper' object has no attribute 'source_repo'")
[16:19] <james_w> bug 513432
[17:05] <mathrick> hmm, how do I get the pathname under which a WorkingTree lives?
[17:06] <vila> wt.basedir
[17:19] <bialix> rats, unicode error in unshelve --preview
[17:19] <bialix> rats rats rats
[17:22] <mathrick> vila: thanks
[18:01] <verterok> jelmer: hi! fwiw, I just tagged bzr-xmloutput 0.8.6 ;)
[18:27] <ahasenack> hey guys, bzr is throwing at me an internal error when trying to checkout a repository
[18:27] <ahasenack> http://ubuntu.pastebin.com/d717de539
[18:29] <rubbs> bug 513432
[18:29] <ahasenack> is this known? Should I go ahead and file a bug report?
[18:29] <ahasenack> ok
[18:30] <rubbs> looks like they're working on it
[18:30] <ahasenack> rubbs: thanks
[18:30] <rubbs> np
[18:32] <lamalex> is anyone here familiar with trac-bzr?
[18:39] <jelmer> verterok, hey
[18:39] <jelmer> verterok, awesome, I'll make sure it ends up in Debian/Ubuntu
[18:39] <verterok> jelmer: cool, thanks! :)
[18:52] <lamalex> I can't get it to display different branches
[19:34] <exs> hi guys. i have a question. i have a inited branche on locale space and want to upload the content to my webspace too. how i have to do this. the documentation irriteded my a little bit.
[19:37] <exs> the best way were. i devel on my local space. and then i have a upload command and after that bzr uploads the whole develcode at my webspace.
[19:38] <exs> and it would be greate if i could edit some commands executing before content will uploaded
[19:38] <rubbs> so, just to clarify, you want to be able to push just the working directory to a location? or do you want the whole history to go with it?
[19:39] <exs> only the actual revision
[19:39] <exs> no history needed
[19:40] <rubbs> ok, why would you ahve to use bzr? or do you want it do to that while commiting? I guess I'm asking why you couldn't just ftp or sftp or scp the directory to the webspace and not use bzr at all?
[19:40] <exs> because i used a wiki where other persons can change the code
[19:40] <rubbs> *not use bzr to upload at all* is what I ment
[19:41] <rubbs> so you want the web space to be versioned as well? so when another person changes it you can get that version?
[19:41] <exs> in additions its more comfortable when you are able to upload the whole content to the webspace while commiting
[19:41] <rubbs> I'm not quite understanding the set up.
[19:41] <exs> exectly
[19:42] <rubbs> just curious, doesn't the wiki have a version control built in?
[19:42] <exs> thats right, but its too hard to go hand by hand and look which files were edtied
[19:42] <rubbs> ah, ok.
[19:43] <exs> the wikipages are txtfiles. and this txtfiles i want to edit on my local space.
[19:44] <rubbs> well, there is a problem if someone changes it on the web by hand, you would have to modify the wiki to commit every change to bzr on the webserver.
[19:44] <exs> i thought bzr registrate every change automatically
[19:46] <exs> the wikisoftware is dokuwiki. it edit only textfiles saved on my webspace. other user can edit the wikipages too, so i need bzr to synchronize my local code with the code may edited by other users
[19:47] <rubbs> so how do you get the code from the webspace, do you just copy it over?
[19:47] <exs> yea
[19:47] <exs> i login with ftp
[19:47] <exs> then go to the dir where my files are saved and then copy to my local space
[19:48] <exs> can you german maybe?
[19:49] <rubbs> exs: sorry my german is REALLY bad. I wouldn't be able to understand you. It isn't your english that is the problem with me asking all the questions. It's just me needing to know how you work, so I can help you figure out how to make bzr work for you ;).
[19:51] <rubbs> bzr will understand what has changed automatically between the history you have and the working tree (your revision you work on) that's why you can use diff and the like
[19:52] <rubbs> but it will not automatically know if the directory on your webspace has changed.
[19:52] <exs> rubbs: the point is this. i have a bzr branch already where i code my programs. i want to publish the code on my webspace in a certain direcotry where wikiuser can edit the files. after certain time i want to syncronize both branches. maybe the user edited something new, and i added something new in the code and i want others to see it. the files i work on them are simply txtfiles. and dokuwiki just edit simply txtfiles. the whole wiki consists of txtfile
[19:53] <rubbs> Ok, got it. I think I can help, but I have to use the toilet.... I'll be right back.
[19:54] <exs> rubbs: ah now i understand what you mean :) yea that could make a problem. but my idea was that if something has changed so there are difference that bzr will show me this in the next commit and i solve the problem by hand or something like that
[19:54] <rubbs> exs: I think I still have an idea that will work, but I'll be right back.
[19:54] <exs> ok
[19:58] <rubbs> ok, back. Here's my idea:
[20:01] <rubbs> you could create a local branch and create a remote branch on your webspace. When changes happen on the wiki, the remote repo will keep track of them. then to get them to your local branch, you could run "bzr merge --uncommitted ftp://webspace/dir" That will pull all the changes on the webspace. Then you make your changes locally, then do a "bzr push --overwrite" That will put all the changes on your local to the remote.
[20:02] <rubbs> then you can use a plugin like "push and update" to make the working tree become updated.
[20:03] <rubbs> http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
[20:04] <jelmer> verterok, hi
[20:04] <verterok> jelmer: hey
[20:04] <rubbs> exs: http://doc.bazaar.canonical.com/bzr.2.0/en/user-reference/index.html#merge
[20:04] <jelmer> verterok, any chance you can upload a tarball as well?
[20:05] <rubbs> exs: hopefully that helps a little
[20:05] <verterok> jelmer: already uploaded :)
[20:05] <jelmer> verterok: oops
[20:05] <jelmer> verterok: ignore me then :-)
[20:05] <exs> why --uncomitted and --overwrite?
[20:05] <verterok> jelmer: but it's a 'bzr export' instead of a 'setup.py sdist'
[20:07] <rubbs> exs: when the wiki user makes a change, that will not be a part of the history yet (because it was never committed) so when you merge in the "uncommitted" changes, you are pulling all the changes on the webspace.
[20:07] <rubbs> exs: the more I think about it the more the --overwrite might not be necessary.
[20:10] <jelmer> verterok, uploaded
[20:10] <jelmer> verterok, thanks!
[20:10] <verterok> jelmer: awesome, thanks!
[20:56] <exs> rubbs: ok thx for help, but i could not try it now but i will try it later. can u answer me another question. what is the sense of repo-init? what exectly do this command?
[20:58] <rubbs> exs: init just makes one stand alone branch all that history is stored in that branch. init-repo will create a "shared" space for many branches. This allows you to save disk space when you have multiple branches with similar code. If you are only going to be using 1-2 branches at a time, it isn't that important.
[22:19] <lifeless> Is there a 'rhett trapmann' here?
[22:20] <jpds> lifeless: He's gone, long gone.
[22:21] <poolie> hello
[22:21] <lifeless> jpds: was he here at all?
[22:21] <lifeless> the account has been blacklisted (yay)
[22:21] <lifeless> hi poolie
[22:21] <jpds> lifeless: No, he just got banned from LP.
[22:21] <lifeless> but it was his second account anyway...
[22:21] <lifeless> so I expect a third pass until someone actually manages to sit down and explain things.
[22:24] <RAOF> I'm having trouble branching lp:launchpad-integration; bzr fails with bzrlib.errors.ErrorFromSmartServer.
[22:25] <RAOF> Full error is http://pastebin.ca/1790660 and http://pastebin.com/f1c08c1df
[22:36] <mwhudson> RAOF: are you branching from an old format branch into a 2a repo?
[22:36] <mwhudson> it's a server side bug though, must chase the SAs about getting that deployed
[22:36] <RAOF> Possibly.
[22:37] <RAOF> lp:launchpad-integration has Branch format: Packs 5, and I am branching into a 2a repo.
[22:37] <mwhudson> yeah
[22:38] <mwhudson> branch standalone first or something
[22:39] <RAOF> Or, it turns out, branch over http first.
[22:39] <RAOF> That worked.
[23:41] <exs> can someone say how to change the message in a commit?
[23:42] <bob2> you can't
[23:42] <LeoNerd> You can't. The revision is signed by a checksum.. that checksum is the identity of the revision. If you change the message, you change its identity, and have now broken it.
[23:42] <bob2> you can uncommit and recommit with a new message, if you like
[23:42] <LeoNerd> Well, not broken.. it's just now different
[23:42] <bob2> but that'll confuse anyone who has pulled from you


[14:25] <TJ-> Has anyone solved the Chicken-and-Egg situation of initially provisioning an on-premise infrastructure environment (e.g. Terraform, digitalrebar, kubernetes) ?
[16:21] <rbasak> TJ-: Canonical - with MAAS? https://ubuntu.com/kubernetes/install
[16:21] <rbasak> Or is that not what you mean?
[16:23] <TJ-> rbasak: no, not MAAS, but just trying to figure out the elegant way to bootstrap an orchestration system itself... its chicken-and-egg loop... got to install/configure various tools first but want them/their deployment/state to be captured in the tooling they provide :D
[16:24] <TJ-> in this case using terraform + digitalrebar (PXE deploy/config like Cobbler) and K8S (containers) ... but the chicken-and-egg seems to apply to all solutions :)
[16:26] <rbasak> I think the usual solution is to treat bare metal provisioning as entirely independent, presented as a separate abstraction layer.
[16:27] <rbasak> Eg. OpenStack.
[18:07] <koheleth> Hi, can I run a command as root to see the livepatch servers I am currently using?
[18:07] <koheleth> I am thinking they are all connected in someway.
[18:41] <OerHeks> sudo canonical-livepatch status
[18:52] <koheleth> OerHeks, thank you, that just for current server.
[18:54] <koheleth> Can I check my account of all servers with root on any particular server using livepatch?  That maybe asking too much yeah with regards to practicality and security!
[18:56]  * koheleth he says you fish poorly.
[19:24] <snickers> hi, is there a problem to set additional routes to dhcp interface in netplan?
[19:27] <snickers> I have this configuration https://pastebin.com/qkNjmgXW after netplan apply I don't see configured routes
[19:31] <koheleth> Contact your server people I would have thought
[19:31] <koheleth> They wont let it route anywhere
[19:32] <koheleth> what you after anyway?
[19:53] <koheleth> How do I stop a server using livepatch is it just a basic uninstall?
[19:57] <snickers> i can set this route via ip route add and it's work correctly
[20:02] <rbasak> koheleth: you should be able to just remove the livepatch snap and then reboot I think.


[00:58] <mrooney> okay, this might be something obvious I am missing, but how can I tell if a package is installed by default in Ubuntu? Say, http://packages.ubuntu.com/hardy/python-gtk2
[01:00] <james_w> mrooney: that's not easy as far as I know
[01:00] <james_w> there may be an easy way
[01:00] <james_w> either looking at the cd manifests or germinate output would do it
[01:00] <mrooney> oh I see, thanks james_w
[01:01] <james_w> however, that's not that easy
[01:01] <mrooney> I don't need to know in a general case, do you know for that specific one?
[01:01] <mrooney> I like our dueling conversations by the way :)
[01:02] <james_w> :-)
[01:02] <james_w> I don't know about that one
[01:02] <james_w> I would guess that it is
[01:02] <mrooney> yeah, I would think
[01:02] <mrooney> ubuntu loves both python and gtk
[01:02] <james_w> there are several things, e.g. jockey that are written in python and gtk that in the default install
[01:02] <james_w> exactly
[01:03] <bdmurray> doesn't task: ubuntu-desktop mean it is installed by default?
[01:03] <james_w> oh, that might well be it, yes
[01:06] <mrooney> okay, sounds good enough :)
[01:06] <mrooney> I was going to take up the task of making some small GUIs for some new things
[01:06] <mrooney> and wanted to do without pulling in another depend
[01:07] <james_w> cool
[01:07] <james_w> what sort of thing?
[01:07] <mrooney> specifically for the new encrypted private directory in Intrepid
[01:07] <mrooney> my preference is python-wxgtk2.8, I wish that was installed by default, but alas :)
[01:08] <james_w> that could be cool
[01:08] <james_w> I don't know if you've spoken to kirkland, but he's the one leading that effort, and he may be interested in your work
[01:09] <mrooney> yeah I have a pending wiki edit now :)
[01:11] <mrooney> okay, time to move some large objects!
[01:12] <bdrung> is here someone who has the right to mark a bug as wontfix?
[01:12] <nhandler> What bug bdrung ?
[01:12] <bdrung> bug #209209, #150405 and #201689. all packages was removed (xmms related)
[01:19] <nhandler> Done
[01:21] <bdrung> thanks
[01:27] <bdrung> nhandler: bug #95949 need wontfix too
[01:27] <bdrung> we should close all xmms related bugs, shouldn't we? xmms and all xmms-based tools were removed.
[01:35] <nhandler> Done
[01:38] <bdrung> nhandler: thanks
[02:23] <anakron> Hi mruiz1
[02:23] <anakron> !
[06:00] <nellery> Awsoonn, looks like ur /Organizing page got left behind with the moinmoin updates
[06:19] <nellery> is it a known issue that bugnumbers still generates the old moinmoin markup with --format=bugday ?
[06:21] <dholbach> good morning
[06:21] <dholbach> nellery: I guess it wasn't changed yet - best either you file a bug or publish a branch with the fix :-)
[06:22] <nellery> dholbach, ok thanks :)
[07:49] <tuxmaniac> can someone set the importance of bug 257508 to Wishlist?
[07:49] <tuxmaniac> please
[07:50] <nellery> tuxmaniac, done :)
[07:51] <tuxmaniac> nellery: thank you.
[07:52] <nellery> no problem
[08:31] <dholbach> hi thekorn - did you hear about bug 257516 before?
[08:32] <thekorn> dholbach, morgen Daniel
[08:32] <thekorn> let me check
[08:34] <dholbach> thekorn: seems it's fixed in bzr
[08:34] <thekorn> dholbach, this looks like a http connection error,
[08:34] <thekorn> so you can ealways reproduce it with the package version?
[08:35] <dholbach> thekorn: it looks very reproducible, yes
[08:35] <thekorn> hmm,
[08:38] <thekorn> I can reproduce it here right now, will have a closer look at it later today
[08:41] <dholbach> thanks a lot Markus
[09:22] <Ampelbein> Could someone please have a look at Bug 254390. I set it to invalid because i don't think it's an issue to be dealt with, but the user wants to have it reopened again. Thanks.
[09:34] <techno_freak> Ampelbein, the latest comments answers his questions :)
[09:45] <techno_freak> bug 257510 looks like a wishlist
[11:53] <bdrung> is here someone who has the right to mark a bug as wontfix, maybe nhandler?
[11:55] <bdrung> xmms was removed since hardy. can someone mark the bugs #205191, #198369, #158102, #153104, #144185, #129824, #127346, #123597, #117562, #116126, #109452, #107665, #106735, #84492, #78852, #76597, #64517, #62773, #56964, #37245, #16812, #869, #68087, #48181, #40467, #41311 as wontfix? I have already written a comment.
[13:28] <mrooney> bdrung: are those really wontfix? if the issue exists in Dapper/Feisty/Gutsy, those are still supported, so the bugs are valid I believe
[13:32] <hubuntu> I want to get started with 5-a-day and general bug triaging
[13:32] <bdrung> mrooney: if they should be fixed for dapper/feisty/gutsy they can be nominated for a release
[13:32] <mrooney> hubuntu: great! there are some great resources in the topic
[13:33] <mrooney> specifically the HelpingWithBugs link
[13:33] <hubuntu> let's me check
[13:34] <mrooney> bdrung: I really don't think standard behavior is to WontFix bugs just because they are fine in the current release, though I could be wrong.
[13:34] <Hobbsee> mrooney: well, will they ever get fixed?
[13:35] <Hobbsee> i don't remember either
[13:36] <mrooney> Hobbsee: sure, they could, I don't see why not, we fix bugs in dapper, feisty, and gutsy all the time
[13:36] <mrooney> granted because in this case the package was removed, that changes things
[13:36] <bdrung> mrooney: iirc the bug status is for the current release.
[13:37] <mrooney> you could be right, I don't have a great understanding of what to do in this case
[13:37] <mrooney> bdmurray could probably assist!
[13:38] <mrooney> persia or hggdh might also know :)
[13:43] <hubuntu> when I'm the process of triaging is it ok to ask here or is there any other channel for such things?
[13:45] <james_w> hubuntu: it's fine to ask in here, that's the point of the channel :-)
[13:46] <hubuntu> ok :)
[13:54] <hubuntu> there is a link in the https://wiki.ubuntu.com/Bugs/HowToTriage guide which do not work:
[13:54] <hubuntu> https://wiki.ubuntu.com/BugTrackingSystem which ends up in https://wiki.ubuntu.com/Malone?action=show&redirect=BugTrackingSystem
[13:59] <hggdh> mrroney, re fixing bugs on older releases -- it depends
[14:00] <hggdh> if it is a LTS release, and the fix can be backported, then it is possible it will be fixed
[14:00] <hggdh> if it is a security exposure, it will be fixed
[14:01] <hggdh> I will be right back (have to walk the dogs)
[14:31] <LimCore> so, anyone knows how to disable apparmored? in a way that actually works?
[14:31] <Hobbsee> i told you how to before.
[14:31] <LimCore> well, that unpolite guy kicked me, so I didnt read
[14:32] <Hobbsee> firstly, elkbuntu is not a guy.  secondly, you had ample time to read, as you responded twice afterwards.
[14:32] <LimCore> stop instead kill? it seems it worked
[14:33] <Hobbsee> see?  so you did read it.
[14:33] <Hobbsee> please stop lying.
[14:35] <LimCore> Hobbsee: I am not lying, I read log after I written that I didnt read it. Please stop accusing people of lying
[14:36]  * Hobbsee notes if you want to troll, like you've been doing in -offtopic for days, you can do it elsewhere, too.  That is your final warning - in any channel.
[14:36] <LimCore> is it a known problem - printing doesnt work recently - or not?  As it, does it affect all people?
[14:38] <Hobbsee> it worked last time i checked.  which was a while ago.
[14:40] <LimCore> only PDF fails
[15:08] <snap-l> May I have some feedback on bug 256729
[15:09] <snap-l> I reported this bug using apport and the bug reporting system, which gave a core-dump and what I thought was good information.
[15:09] <snap-l> The core dump was removed, and the bug marked "invalid", with a canned response.
[15:11] <Hobbsee> snap-l: useless stack trace, it looks like.  Beyond that, i don't know.
[15:11] <snap-l> I'm not sure where to go with this bug report. If the tools I'm given (and possibly our users) aren't good enough to lodge a bug report, how can we ever expect to get good reports from our users, and by extension, fix the issues?
[15:12] <snap-l> I know the issue is flash, and I know is likely a dead-end.
[15:12] <Hobbsee> snap-l: flash, by nature, is going to be one of the worse bug areas for this - afaik, there aren't many debug symbols, etc, or much debugging that goes on, due to the lack of source.
[15:13] <Hobbsee> ie, i wouldn't take it as a representative sample that the rest of the packages in ubuntu are like that, and that therefore, teh tools aren't good enough.
[15:13] <Hobbsee> (they may be, i don't know)
[15:13] <snap-l> Perhaps we can come up with a more friendly response for unsupported software like flash that isn't quite as off-putting as that one? :)
[15:14] <hggdh> snap-l, yes, please propose one
[15:17] <hggdh> snap-l, re bug 256729: this was an apport--generated bug. With the bad stack trace, there is not much we can do here. What you can do: (1) go to /var/crash, and remove the crash for firefox; (2) wait for it to happen again
[15:17] <hggdh> it will generate a new crash report, and a new proposal for a LP bug
[15:18] <snap-l> Like "thank you for your bug report. Your bug report appears to reference Adobe Flash. Adobe Flash currently does not provide useful debugging information that our developers can use to improve the software. Please conract Adobe for any support request relating to the Flash plugin.
[15:18] <Knightlust> wow
[15:18] <Knightlust> dito nako
[15:18] <Knightlust> ngek
[15:18] <Knightlust> iba nick
[15:18] <Knightlust> sowweee
[15:19] <Knightlust> initial to
[15:19] <Knightlust> panu ulit palit ng nick
[15:19] <jpds> !en
[15:26] <hggdh> what you can *also* do: make sure you have the debug packages for firefox, flash (what is available), etc
[15:27] <LimCore> https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/257603
[15:27] <hggdh> snap-l, this is not *completely* correct. Flash does not provide much in terms of debug data, true, but we should still try
[16:20] <Initial_M> ???
[16:21] <Initial_M> hi guys
[16:28] <bdmurray> Morning
[16:40] <hggdh> LimCore, did you try to run the program from a konsole?
[16:51] <pwnguin> wpa2 isn't working on my laptop
[16:51] <pwnguin> how can i figure out where the problem lies?
[17:16] <bdmurray> pedro_: do you remember that gnome-terminal bug from yesterday?
[17:17] <pedro_> bdmurray: yes the master one? bug 256769
[17:17] <bdmurray> the same thing just happened to me with terminator
[17:21] <pedro_> ah yes could be since it's a vte issue
[17:21] <bdmurray> great, I'm not safe anywhere
[17:21] <bdmurray> ;)
[17:22] <pedro_> haha sorry :-P
[17:23] <LimCore> hggdh: no.. which command should I try?
[17:23] <bdmurray> luckily screen will protect me!
[17:30] <hggdh> LimCore, first of all, how to you request a printout? Where are you, and what options you select? What version of KDE?
[18:17] <mattik> Why I haven't got permission to https://bugs.launchpad.net/bugs/131868
[18:18] <mattik> It said my bug is duplicate with it, but it's sure because I cannot check
[18:18] <mattik> is it sure
[18:18] <mattik> This is very old bug and I'm using Intrepid
[18:20] <pedro_> mattik: let me look at it
[18:22] <mattik> switch-user-applet if I remember right
[18:22] <mattik> It doesn't keep on in Intrepid
[18:26] <pedro_> mattik: i've re open it, thanks
[18:28] <mattik> pedro: thank you :) where is my bug report now? or do I need it?
[18:28] <LimCore> hggdh: it happens in KPDF viewer (it was working always before). Btw, from ghostview it prints fine (I use it uses other method?)
[18:28] <pedro_> mattik: in the same place (number)
[18:32] <mattik> pedro: thank you :). How could I report more about this. Do you need some tests?
[18:34] <pedro_> mattik: if you can give us some steps in order to reproduce the crash that would help a lot too, just put them on the report , thanks :-)
[18:34] <Ampelbein> Hi! Could someone please check on Bug 256629? Now that I've got enough information and done some research I found out that the specific WLan-Card (Intel® Wireless WiFi Link 5100 WLAN) is not supported under Kernel 2.6.24, but will be supported in 2.6.26. What is the correct status to set this bug to? Fix-Released?
[18:34] <mattik> ok, I log out and
[18:34] <mattik> log in again
[19:11] <bdmurray> nellery: I'm in the process of merging your patch.  Thanks!
[19:12] <nellery> bdmurray, no problem :)
[22:10] <calc> bdmurray: did the graphs stop updating?
[22:10] <calc> looks like they haven't updated in the last hour at least
[22:11] <calc> about 15min until the next run if its not broken
[22:11] <bdmurray> calc: yeah, I'm looking into it
[22:11] <calc> ok
[22:22] <Initial_M> hi
[22:38] <andre____> hmm. to which local dir does synaptic download the packages?
[22:39] <bdmurray>  /var/cache/apt/archives/
[22:40] <andre____> ah, thanks a lot!