[00:06] <thumper> james_w: ping
[00:06] <james_w> hi hi
[00:42] <lifeless> meep
[00:43] <lifeless> something very odd:
[00:43] <jam> lifeless: I just set you an update about iter_interesting... did it make sense?
[00:43] <lifeless> g$ bzr info lp:~mordred/libcpuinfo/add-bindings
[00:43] <lifeless> bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "lp-49592784:///~mordred/libcpuinfo/add-bindings"')
[00:43] <lifeless> but merging from http://b.l.n. works
[00:44] <lifeless> if someone could reproduce that would be great
[00:45] <jam> lifeless: 'bzr info lp:...' works here
[00:46] <jam> I do see:
[00:46] <jam>   public branch: http://bazaar.launchpad.net/%7Emordred/libcpuinfo/add-bindings
[00:46] <jam>   parent branch: lp-hosted:///%7Elibcpuinfo-developers/libcpuinfo/trunk/
[00:46] <jam>      stacked on: /~libcpuinfo-developers/libcpuinfo/trunk
[00:46] <jam> the 'lp-hosted' specifically looks weird
[00:46] <lifeless> jam: its plausible
[00:47] <lifeless> jam: the parent branch won't be followed though
[00:47] <lifeless> jam: are you lp-login'd?
[00:47] <jam> lifeless: yes
[00:47] <lifeless> [its plausible] - the iter_interesting
[00:47] <jam> lifeless: I figured
[00:47] <Peng_> I just tried "bzr info" over lp: (logged in). I mostly concur with jam, except I saw a shared repo line, not a public branch line.
[00:47] <lifeless> yes, interesting things cannot be in *any* uninsteresting page
[00:48] <jam> lifeless: "bzr info http://b.l.n" works, too
[00:48] <lifeless> http:// works for me
[00:48] <mwhudson> i see the same as lifeless
[00:48] <lifeless> mwhudson: great.
[00:48] <mwhudson> i bet the difference here is that lifeless and i have branch super powers
[00:48] <mwhudson> and are seeing the hosted area
[00:48] <lifeless> https://code.edge.launchpad.net/~mordred/libcpuinfo/add-bindings
[00:49] <lifeless> it looks like it is a hosted branch
[00:49] <mwhudson> and well
[00:50] <mwhudson> there's no repository there
[00:50] <mwhudson> lifeless: https://pastebin.canonical.com/18971/
[00:50] <lifeless> ?!
[00:50] <lifeless> I'll ask monty when he returns
[00:52] <jam> mwhudson: so you're saying that it didn't mirror the broken repo to the public side
[00:52] <jam> and thus non-super people like me and Peng see everything as ok
[00:52] <mwhudson> jam: i am not intepreting anything!
[00:52] <mwhudson> jam: but yes, that seems likely
[00:52] <mwhudson> there's probably an oops from the puller somewhere
[00:53] <jam> lifeless: could be in the middle of an upgrade?
[00:53] <lifeless> he asked me to look at it; I don't think he'd have done that just before starting an upgrade
[00:54] <jam> lifeless: unless he was asking you why it was broken :)
[00:56] <poolie> jam, want to resume?
[00:57] <jam> poolie: yes, though my wife is away, so I'm watching my son
[00:57] <lifeless> jam: no, he asked me to review it
[00:57] <jam> phone would probably work better
[01:17] <igc> morning
[01:19] <lifeless> jam: so, let me know when you're stopping working on the bug and I'll pick up from there
[01:20] <jam> lifeless: I'm done
[01:22] <lifeless> kk
[01:42] <jelmer> rocky: that's not specific to bzr-svn, deleting tags doesn't propagate inside of bzr in general
[01:43] <rocky> jelmer: so there's no way to delete a tag?
[01:44] <jelmer> rocky: push --overwrite might delete a tag
[01:44] <jelmer> IIRC
[01:45] <Peng_> Yeah, I think so.
[01:48] <mwhudson> damn loggerhead's way of making you fix a bunch of bugs at once!
[01:48] <lifeless> because it has so many?
[01:50] <mwhudson> yes
[01:54] <mwhudson> still, it's only 250 lines
[01:54] <mwhudson> Peng_: want to review a branch? :)
[01:54] <Peng_> mwhudson: Sure.
[01:54] <Peng_> mwhudson: I'll probably wind up saying "it seems ok to me, but you should really ask beuno", though. :P
[01:55] <mwhudson> yeah
[01:59] <Peng_> mwhudson: no-transport-sharing?
[01:59] <Peng_> mwhudson: I think you have the logic backwards in check_serveable.
[01:59] <mwhudson> Peng_: yeah
[01:59] <mwhudson> oh yes
[02:00] <mwhudson> writing up a merge proposal now
[02:01] <Peng_> If a thread exits, will its threading.local stuff automatically get cleaned up?
[02:02] <mwhudson> not sure
[02:02] <mwhudson> probably not
[02:03] <Peng_> Leaking a transport every 100 requests (by default) wouldn't be very nice/
[02:06] <lifeless> uhm
[02:06] <lifeless> I'd expect threading.local to get dereferenced
[02:07] <lifeless> otherwise its a huge bug in python :)
[02:07] <Peng_> Haha.
[02:07] <lifeless> check the module source if you need to
[02:08] <Peng_> I did once. I wasn't curious enough at the time to try to understand it. :P
[02:08] <Peng_> And I only checked the Python version, not the C version that actually gets used on most platforms.
[02:11] <lifeless> so there is a wrapper around each thread
[02:11] <lifeless> I'd expect the wrapper to have a list of threading.local instances, and tell them all at thread exit
[02:12] <Peng_> _threading_local.py uses attributes on threading.current_thread() to store the thread-local data, so it'd probably be okay?
[02:13] <mwhudson> the data is stored in the threadstate it seems
[02:13] <mwhudson> so it will die with the thread
[02:13] <mwhudson> (in the c implementation)
[02:14] <Peng_> Wait, what broke HTTP serving was the stupid readonly+ decorator? Ouch.
[02:14] <mwhudson> Peng_: yes
[02:15] <mwhudson> Peng_: hey, you know what are really really great?
[02:15] <Peng_> Cupcakes!
[02:15] <mwhudson> i was going to say tests, but you're also right
[02:15] <mwhudson> i guess docstrings are nice too
[02:16] <Peng_> What's even better are interns to get you cupcakes, docstrings and unit tests.
[02:22] <jml> I would like a cupcake.
[02:29] <lifeless> Peng_: I did suggest not doing readonly+ :P
[02:29] <Peng_> lifeless: :(
[02:29] <lifeless> Peng_: actually no. I suggested not requiring it :)
[02:46] <mwhudson> Peng_: LocationConfig doesn't open a transport afaict
[02:46] <mwhudson> it looks up locations by url in the ~/.bazaar/locations.conf file
[02:47] <Peng_> mwhudson: Oh, OK.
[02:47] <Peng_> mwhudson: ...If locations.conf is broken, will it explode, and do we care?
[02:47] <mwhudson> Peng_: so will everything else though?
[02:48] <mwhudson> i'm not sure i care very much
[02:48] <Peng_> Heh, probably. I'm OK with that, then. :)
[02:54] <mwhudson> uh
[02:54] <mwhudson> the date on this launchpad bugmail is highly unbelievable
[02:55] <mwhudson> (i.e. it's in the future)
[02:55] <Peng_> Oh? Which one?
[02:55] <mwhudson> Peng_: when you assigned the 'serve over http is broken' to me
[02:56] <Peng_> I got "Date: Thu, 25 Jun 2009 01:36:37 -0000", which is correct.
[02:56] <mwhudson> Date: Thu, 25 Jun 2009 02:36:38 -0000
[02:56] <Peng_> Wow.
[02:56] <RenatoSilva> Is BzrEclipse compatible with Eclipse Galileo?
[02:56] <Peng_> Hello, Daylight Saving Time. Meet Launchpad.
[02:57] <mwhudson> Peng_: i'm a little bit scared as to how this is possible :)
[02:57] <mwhudson> Peng_: which machine was yours sent from?
[02:57] <Peng_> mwhudson: If you're receiving bugmail from the future, you could file bugs before people get the chance to and steal the credit!
[02:57] <mwhudson> mine was 'potassium' it seems
[02:58] <Peng_> From what, the Recieved headers?
[02:59] <Peng_> loganberry -> adelie (IIRC) -> my mail server.
[02:59] <Peng_> Notably, both were BST (GMT+1)
[02:59] <mwhudson> ok, mine was a very different path
[02:59] <mwhudson> which is good, i guess
[02:59] <Peng_> Might've been Adelaide or something. I can't remember, and my mail client is swapping.
[02:59] <Peng_> Oh, adelie.
[03:00] <Peng_> mwhudson: Oh, the message-id is indeed potassium.
 ?
[03:00] <mwhudson> i guess the launchpad user's TZ is set wrong on that machine or something
[03:00] <Peng_> Message-Id<EMAIL_ADDRESS>[03:01] <mwhudson> huh
[03:01] <mwhudson> i have no idea how this code works :)
[03:01]  * mwhudson emails the sysadmins
[03:03]  * Peng_ brushes his teeth.
[03:03] <Peng_> brb
[03:09] <lifeless> abentley: is there a bug open for the fetch errors you're experiencing?
[03:11] <abentley> lifeless: I don't know.
[03:35] <abentley> lifeless: You know that this was discussed in the canonical-bazaar thread "Ongoing problems with inconsistent revisions in Launchpad trunk", right?
[03:36] <Peng_> "canonical-bazaar"?
[03:39] <abentley> Peng: The canonical employees' list for discussions related to bazaar.
[03:39]  * Peng_ feels left out. :P
[03:40] <abentley> Peng_: It doesn't get a lot of traffic.
[03:40] <fullermd> Peng_: Why?  Obviously being on the list makes you have problems   ;)
[03:40] <Peng_> Heh.
[03:40] <abentley> fullermd: No, only people with problems are allowed on the list :-)
[03:41]  * fullermd quickly hides his invitation.
[04:59] <lifeless> abentley: I've re-read the thread; it didn't seem to talk about the proposed solution
[04:59] <lifeless> abentley: I agree that this is an important thing to correct
[05:05] <abentley> lifeless: Yeah, it mostly covers the investigation of the situation.  I thought that was what you were looking for.
[05:06] <lifeless> abentley: I want a backtrace I think; I want to make reconcile faster, but I need to make sure it will still catch these bits of data
[05:07] <lifeless> the new KnownGraph thing may be an easy-grasp item to make reconcile _much_ faster.
[05:08] <abentley> lifeless: backtrace is in the first message.
[05:08] <lifeless> abentley: ah cool.
[05:08] <lifeless> I'll turn it into a bug
[05:08] <abentley> lifeless: My problem repository is at devpad:/home/abentley/branches
[05:57] <poolie> lifeless: see you soon
[05:59] <lifeless> yeehaw
[06:51] <jml> spiv, I want to hook into the smart server so that I logged an OOPS on unexpected errors
[06:51] <jml> spiv, where's the best place to hook in?
[06:53] <jml> at the moment, I'm considering monkeypatching log_exception_quitely
[06:53] <jml> quietly.
[06:57] <ree> hi All! I pushed a branch to a different location (on launchpad) and it became stacked for some reason. Is there any way to make it non-stacked? I would not like it to depend on the old location
[06:58] <ree> I find no --nostacked option.... how is stacking prohibited?
[07:02] <lifeless> ree: there isn't a command line way to do it at the moment
[07:02] <lifeless> ree: I don't understand the issue though?
[07:03] <ree> ok, so is it a problem if it's stacked? The launchpad ui says it's stacked on the old location. What if the old location is removed? I would like to keep the new branch location independent from the old one
[07:04] <ree> lifeless, ^
[07:04] <lifeless> ree: well, lp won't let you remove the series branch
[07:05] <lifeless> ree: as its used by other branches to stack on - not just branches of your own; anyone pushing to that project
[07:05] <ree> the trunk was under my own username, and I want to move it to under a group, so I can share access
[07:06] <ree> I thought in bzr the full branch history is stored in every repo... now this seems to be not like this with stacking. I also would like to find the way in general, to make a repo unstacked
[07:07] <ree> is there a way to "flatten out" a repo? Remove all stacking and get all history be local?
[07:08] <ree> lifeless, ^
[07:09] <spiv> jml: yes, that's probably the best option at the moment.
[07:10] <spiv> jml: In the background I've recently started thinking about how to do that better, but for now hooking into where log_exception_quietly goes is the simplest route I can think of.
[07:23] <jml> spiv, thanks.
[07:23] <jml> spiv, why doesn't bzr use log.exception for that?
[07:24] <jml> (I'm guessing performance, but it's worth asking)
[07:26] <spiv> jml: you mean logging.exception?  Not sure for this particular case.
[07:27] <spiv> I personally wouldn't expect log_exception_quietly to be performance-sensitive... if you're calling it, something has gone wrong, so speed isn't a massive concern.
[07:28] <jml> spiv, trace._bzr_logger.exception is what I mean in particular.
[07:29] <jml> hmm. I guess that's a simple patch to try out.
[07:37] <lifeless> ree: local branches on your pc will be not be stacked
[07:37] <lifeless> ree: for server side branches, stacking is a *huge* space saver
[07:37] <lifeless> ree: and you should be able to move the branch to a shared branch without problems; if you have any we can recover via the python API
[07:38] <lifeless> ree: (just ask a question on answers.launchpad.net/launchpad-code, if noone here or in #launchpad is around/able to help immediately)
[07:38] <lifeless> jml: do you mean logging.exception ?
[07:38] <lifeless> jml: because logging was a huge performance suck for us, IIRC
[07:38] <ree> lifeless, thanks! I have to go now, I'll experiment around.
[07:40] <jml> lifeless, logging is being used for note & error, just not log_exception_quietly
[07:41] <lifeless> jml: hmm, not sure then.
[07:42] <lifeless> jml: I do recall us having performance issues tied into using logging for multiple levels of output
[07:42] <jml> lifeless, I can easily believe that. :)
[07:43] <jml> lifeless, but as spiv says, I wouldn't expect log_exception_quietly to be particularly performance-sensitive.
[07:43] <jml> what'd be the best way of evaluating the performance impact?
[07:46] <lifeless> test? :P
[07:47] <lifeless> I'm struggling to think of a scenario where we'd be logging high volumes of exceptions though
[07:47] <spiv> Yeah, me too.
[07:47] <lifeless> as we stop what we're doing when we choose to log exceptions
[07:48] <spiv> I'd think any case where we're logging high volumes of exceptions that the right answer would be "stop doing that" rather than make it fast.
[07:48] <spiv> I'd expect the highest-volume producer of bzrlib exceptions is probably Launchpad :)
[07:49] <jml> :D
[08:34] <poolie> spiv, hi, still around? how did you go on network deltas?
[08:36] <jml> lifeless, just double checking: bug 365615 is fixed in trunk, should be CPd to Launchpad and should (not 'must') go into 1.16.1...
[08:37] <jml> bug 390563 still needs to be fixed (there's a cheap-but-slow fix and an expensive-but-performant fix), it has to go into 1.16.1 and be CPd to Launchpad
[08:38] <lifeless> jml: 365615 yes
[08:38] <lifeless> 390563 is in progress
[08:39] <lifeless> no fixes completed yet; have code for a candidate in front of me now
[08:39] <jml> lifeless, sweet.
[08:41] <jml> any other bugs that I need to be watching, either as RM or as LP/Bazaar person?
[08:41]  * jml looks over the Critical bug  list
[08:43] <jml> I obviously don't know how to use "Target to release"
[08:48] <lifeless> jml: yes, but let me get this done first
[08:48] <jml> lifeless, no worries.
[08:52] <kfogel> poolie: you explained to me once why Bazaar trunk itself is not on 1.16, but I can't remember the answer.  What was it?
[08:53] <kfogel> poolie: (a mere hint might be enough :-) )
[08:54] <asabil> bialix: ping ?
[09:03] <lifeless> kfogel: because wee've moved on?
[09:03] <lifeless> kfogel: we don't release from trunk
[09:04] <kfogel> lifeless: not sure I understand.  IIRC, if I branch Bazaar's bleeding-edge development trunk, the branch will not be in 2a, but in something older.  Is that still right?
[09:04] <lifeless> kfogel: oh, that isn't what you asked
[09:04] <kfogel> lifeless: sorry
[09:04] <lifeless> kfogel: two reasons; one we know its broken at the moment.
[09:04] <kfogel> *nod*
[09:04] <lifeless> we're trying to fix it
[09:04] <lifeless> secondly, we knew it was broken, and were trying to fix it
[09:04] <kfogel> lifeless: :-)
[09:05] <lifeless> the check and reconcile steps make the upgrade process very traumatic
[09:05] <lifeless> and at the moment, without LOSA's to help, migrating would be fraught with risk
[09:05] <kfogel> lifeless: thanks
[09:05] <kfogel> lifeless: I do think dogfooding is important at some point, but obviously not when there are known problems.
[09:06] <lifeless> there is another aspect which is that its hard for distros to track trunk until there is a version out there that they can use to pull trunk
[09:06] <lifeless> so I'm not at all convinced that dogfooding *trunk* in canididate formats makes sense
[09:06] <kfogel> lifeless: why would we want distros to track trunk?
[09:06] <lifeless> kfogel: daily builds
[09:06] <lifeless> or even release builds
[09:06] <lifeless> what I want is bzr to get to a rich root format ASAP
[09:06] <kfogel> lifeless: (2a is rich-root, right?)
[09:07] <lifeless> then we can dogfood 2a as developers without trunk changing to 2a
[09:07] <kfogel> ah
[09:07] <lifeless> and once we've got a clean bill of health as developers, then its much lower risk to change trunk
[09:07] <kfogel> sure
[09:07] <kfogel> okay, bedtime for me.  Thanks for the explanation, lifeless.
[09:07] <lifeless> the rich root transition is really painful, as most trapdoors are
[09:07] <lifeless> hey, how is the mysql test going?
[09:08] <kfogel> lifeless: still going.  ~/.bzr.log last touched 8 min ago
[09:08] <lifeless> cpu burning up?
[09:15] <kfogel> lifeless: yes, it looks like my process eats all available cpu
[09:15] <lifeless> good
[09:15] <lifeless> its busy
[09:16] <bialix> asabil: pong
[09:18] <asabil> bialix: I just checked bzr explorer, and it looks great ! thanks
[09:19] <bialix> asabil: kudos for igc!
[09:19] <bialix> it looks easy, but I agree -- it's great GUI
[09:20] <asabil> bialix: yes, but you are also the guy implementing it, am I wrong ?
[09:20] <bialix> I'm padavan here, and igc is master
[09:20] <bialix> I'm mostly working on qbzr
[09:21] <asabil> bialix: I see :)
[09:22] <bialix> it's so cool to see how fast bzr explorer growing into usable tool. mostly because we already have mature enough pieces in bzr-gtk and qbzr
[09:22] <asabil> bialix: I would like to suggest you take a look at the accurev ui
[09:23] <asabil> I have never used it myself, but it got some really awesome drag and drop features
[09:23] <asabil> you can basically drag and drop revisions between branches to merge/cherry pick
[09:23] <bialix> oh, I see
[09:23] <asabil> and that's something I would love to see integrated in qbzr's qlog and bzr explorer
[09:23] <bialix> it's related to qlog (from qbzr then)
[09:24] <bialix> you also need to ping garyvdm with this idea
[09:24] <asabil> http://www.accurev.com/virtualbooth/2min-demo/2min-demo.html
[09:24]  * bialix looks
[09:24] <asabil> :)
[09:27] <asabil> it does more than version control, but there are some good ideas that could be used in the bzr gui world I think
[09:30] <bialix> hmmmmmm
[09:30] <bialix> why they're dragging offshore team back and forth?
[09:30] <bialix> what's the point?
[09:30] <bialix> looks interesting, but I don't understand something
[09:31] <bialix> anyway thanks, I'll send the link in qbzr ml so other people (garyvdm) can see it too
[09:31] <asabil> bialix: to allocate resources
[09:32] <bialix> allocate resources?
[09:32] <asabil> bialix: from what I understood, accurev does version control + bug tracking + resources management
[09:32] <bialix> and it supposed to be distributed?
[09:33] <asabil> bialix: I am not sure, never used it myself as I said earlier
[09:33] <bialix> ok
[09:33] <asabil> but basically they are dragging a Team on top of a Stream (branch) to say that "this is the team now working on this branch"
[09:34] <bialix> hm
[09:34] <bialix> I see the point
[09:35] <bialix> asabil, btw here is our ideas qbout qbzr gui http://groups.google.com/group/qbzr/browse_thread/thread/68987a67f323e287#
[09:36] <bialix> feel free to comment
[09:36] <bialix> the main problem with bzr is main bzr idea: one branch = one dir
[09:36] <asabil> will check it out, thanks
[09:36] <asabil> yep, I agree :/
[09:36] <bialix> so you have to either work inside shared repo to get all branches
[09:36] <bialix> or create virtual project structure
[09:37] <bialix> though I think defining projects (including remote branches like in git) could be very powerful
[09:37] <bialix> I'm not sure how such project could be shared between several devs though
[09:38] <bialix> future colocated branches won't fix all rough edges
[09:38] <bialix> I think idea of registering remote branches in git is the right idea
[09:38] <bialix> although it's mostly local thing IIUC
[09:39] <asabil> yep
[09:39] <asabil> but I think each model has its flaws
[09:39] <bialix> as usual :-)
[09:45] <bialix> igc: ping
[09:45] <igc> hi bialix
[09:46] <bialix> hi, is there possible to pass current branch as argument to some commands?
[09:46] <bialix> in explorer
[09:47] <igc> bialix: yes
[09:47] <igc> bialix: see lib/app-suite-qbzr.ini in rev 113
[09:47] <bialix>     "add":      "bzr qadd --ui-mode %(selected)s",
[09:48] <bialix> that is?
[09:48] <igc> bialix: we haven't populated the context with "current selection" information yet, but the command definitions support it when we do
[09:49] <igc> bialix: %(root)s is the current branch
[09:49] <igc> that bit is working now
[09:49] <igc> bialix: got to go, sorry
[09:49] <bialix> ok
[09:49] <igc> very hungry and dinner is ready :-)
[09:49]  * igc dinner
[09:50] <bialix> bon appetit
[10:04] <poolie> night
[10:50] <lifeless> EOD()
[11:43] <mzz> I was wondering if putting unrelated projects into the same shared repository is good, bad or neutral?
[11:44] <mzz> I currently have most stuff in a single ~/bzr shared repo and am doing some belated digital spring cleaning, was wondering if I should change that
[11:45] <lifeless> neutral
[11:47] <vxnick_afk> mzz: I only ever put related projects within the same shared repo
[11:48] <vxnick> related branches, even
[11:51] <ddaa> lifeless: If I understood correctly, at some point it was bad, if one project was large (e.g. launchpad) because the index bloat impacted performance with the branches of small projects.
[11:51] <mzz> also it makes it a bit hard to rm -rf a project
[11:51] <mzz> so I think I'm changing away from it
[11:51] <ddaa> But 1. maybe I misunderstood, or 2. maybe it's fixed now with some newer non-default repo format.
[11:52] <lifeless> ddaa: bzr runs out of steam with 16K projects
[11:52] <lifeless> (all of ubuntu)
[11:53] <lifeless> but other than that its really just total things to index, not project count; the steam issue on 16K projects is simply the total file-version count
[11:53] <lifeless> and B+Tree indices are much more robust than the flat file indices were
[11:55] <ddaa> I do not understand what you mean by the "16k projects" limit. I take your other reply as meaning "yes, index bloat can be an issue with the default repo format, but it's fixed with repo format >= 1.9".
[11:56] <lifeless> I put all of ubuntu into a single repo
[11:56] <lifeless> as 16K 1-commit long branches
[11:56] <lifeless> it uses a lot of memory to work with everything at once
[11:56] <lifeless> but you can commit to individual branches very quickly and successfully
[11:57] <ddaa> lifeless: with which repo format?
[11:57] <lifeless> 1.9+
[11:57] <lifeless> I think
[11:57] <lifeless> pack-0.92 was worse
[11:58] <ddaa> Thanks. Sorry about being this insistent, but I think it's important to be very clear about what performance benefits from non-default repo formats.
[11:58] <lifeless> 1.9 memory caps the cache for indices
[11:59] <lifeless> speeds up locating data by 100x factor (200:1 rather than 2:1 fan out)
[11:59] <lifeless> 2a delivers similar changes to the inventory layer
[12:00] <ddaa> So, how are you going to market 2.0? Came with something better than "bzr, it's not slow anymore!"?
[12:00] <lifeless> no idea :)
[12:02] <ddaa> My 2¢, postpone 2.0 until you have a marketing angle.
[12:03] <ddaa> 2.0 is largely (not only, but largely) a marketing op, so better to fire that particular bullet when you have a good target.
[12:03] <lifeless> its mainly about fixing the rich root problem once and for all
[12:03] <lifeless> marketing is a small component
[12:03] <lifeless> 2.0's default format will be rich root; there will be no new formats added in 2.0 that are not rich root
[12:04] <ddaa> Oh. I thought it was more important to make the public reconsider its perception that "git and hg are so much faster than bzr".
[12:05] <lifeless> the way to do that is to be fast
[12:05] <ddaa> Which has proven disastrous for adoption.
[12:05] <lifeless> have you tried 2a out?
[12:06] <ddaa> Nope. Not interested in testing it before release. Bzr has been mostly fast enough for me since knitpacks.
[12:06] <lifeless> 2a is supported - its a released format
[12:06] <lifeless> it becomes default in 2.0
[12:06] <lifeless> I encourage you to migrate to rich roots as soon as you can; it will mean you can test 2a more easily if you want to
[12:06] <ddaa> Oh right, it must have been just released.
[12:07] <lifeless> 18th June :)
[12:07] <ddaa> I set up repos for my current project just a couple of weeks ago. It was not out yet.
[12:07] <ddaa> BTW, I did have a performance problem.
[12:08] <lifeless> 1.16.1 will fix a key bug with 2a btw
[12:08] <lifeless> thats due out in the next dayish
[12:08] <ddaa> Specifically, initial push to as unpopulated repo through bzr+shh was MUCH slower than it should have been (with 1.9 repos).
[12:08] <lifeless> not a dataloss bug, just annoying
[12:08] <lifeless> big history?
[12:08] <lifeless> and what bzr version ?
[12:09] <ddaa> History ~1000 revs. Bzr from ppa as of one month ago.
[12:09] <ddaa> Import from hg using fast-import.
[12:09] <lifeless> ok
[12:10] <lifeless> its odd that that would be slow
[12:10] <ddaa> It was not as much slow as stalling.
[12:10] <lifeless> if you care to a) try with bzr 1.16 at both ends and b) if it is still slow, run with 'bzr -Dhpss' and file a bug with the .bzr.log contents for it
[12:10] <ddaa> At minutes at a time.
[12:11] <ddaa> Sure. I'll do that today.
[12:11] <lifeless> lan or internet?
[12:11] <ddaa> internet, but should be fast
[12:11] <lifeless> we had a hard-to-diagnose problem with the python trials
[12:11] <ddaa> i.e. remote host is a hosted server on the same ISP as my workstation.
[12:11] <lifeless> similar sounding symptoms
[12:12] <ddaa> I'd be happy to provide diagnostic.
[12:12] <lifeless> cool
[12:12] <lifeless> thanks
[12:12] <asabil> is it normal that bzr status takes 26sec to complete with a clean working tree ?
[12:13] <lifeless> asabil: it has to sha1sum the files the first time
[12:13] <lifeless> asabil: it should be near instant after that
[12:13] <asabil> lifeless: what is the 1st time ?
[12:13] <lifeless> asabil: after checkout, after manually copying the tree (destroys the stat cache)
[12:14] <asabil> right, it gets down to 1.1 seconds after that
[12:14] <lifeless> asabil: the other possibility is that your tree was cold and you're actually measuring the time to page in the dentries and inodes for the tree (and if its really cold, bzr is likely not in cache as well - thats a good 15-20 seconds there, because python *sucks* at loading many modules)
[12:15] <ddaa> also, if the tree has many files, it can take a while for the system to read directory entries into the cache. Cold-cache perf occurs e.g. after reboots or long periods not working on those files.
[12:15] <ddaa> (lifeless just said the same thing with more jargon)
[12:15] <asabil> lifeless: also I had a really weird issue with bzr-svn and the --development-6-rich-root format
[12:15] <vxnick> davidstrauss: ping
[12:15] <davidstrauss> vxnick: pong
[12:15] <asabil> I checked webkit over http, and it did result in an 11GB repository
[12:15] <vxnick> davidstrauss: did you package the fixed 1.16 installer?
[12:16]  * ddaa goes afk for an hour
[12:16] <asabil> it went down to 800MB after running bzr pack
[12:16] <davidstrauss> vxnick: I haven't done anything since that venerable night
[12:16] <lifeless> asabil: hmm, shoulda gone smaller.
[12:16] <vxnick> davidstrauss: fair enough :)
[12:16] <davidstrauss> vxnick: It wasn't clear from the mailing list who was doing what
[12:16] <vxnick> davidstrauss: ah, ok
[12:16] <asabil> lifeless: the 11GB is not good in the 1st place I think
[12:18] <lifeless> anyhow, its bug https://bugs.edge.launchpad.net/bzr/+bug/376748
[12:18] <lifeless> bzr-svn needs to change as well
[12:18] <asabil> lifeless: it wasn't a conversion
[12:18] <asabil> it was a fresh checkout
[12:18] <lifeless> asabil: svn->bzr - thats a conversion
[12:18] <asabil> ah oki
[12:19] <asabil> thanks
[12:19] <lifeless> so what happens is
[12:20] <lifeless> bzr-svn copies some data
[12:21] <asabil> yes ?
[12:21] <lifeless> because of a couple of things, its not compressed beyond zlib
[12:21] <lifeless> then, when it hits a threshold (5000 commits I think), it commits the transaction, and repeats
[12:22] <lifeless> bzr's core causes an autopack when a certain number of transactions have occured
[12:22] <lifeless> probably bzr-svn needs some tuning to work better with 2a
[12:22] <lifeless> and it definitely needs to start doing the incremental autopack at the end of the fetch process as well
[12:22] <asabil> I see
[12:30] <lifeless> `night all
[12:32] <asabil> night, and thanks for the explanation
[13:26] <Peng_> You mean the pack_hint stuff? bzr-svn and bzr-git do that now.
[15:02] <jrwren> I'm getting very strange behavior, bzr 1.16 on win32 installed via the setup program. nslookup resolves my host, an internal dns name, but bzr says "failed to lookup <hostname>:4155: getaddrinfo failed"
[15:06] <james_w> it shouldn't be adding the port to the lookup should it?
[15:07] <james_w> how many colons do you have in the host/user/password part of the URI?
[15:08] <jrwren> none.
[15:08] <jrwren> its connecting to a bzr://host/path
[15:08] <jrwren> an instance of bzr --serve running
[15:08] <jrwren> it appears to be python getaddrinfo is different from windows nslookup.
[15:09] <jrwren> ah!  maybe a python bug.
[15:09] <jrwren> my win7 network interfaces were in bridge mode.
[15:09] <jrwren> I had both interfaces up and connected to the same network.
[15:10] <jrwren> when I took down an interface, it worked again.
[15:14] <jam>  morning vila
[15:14] <jam> morning #bzr
[15:14] <james_w> morning jam
[15:15]  * vila waves and wonders how jam manage to pop up at the precise second I was clicking on ja1 to check :-)
[15:15] <jam> vila:  magic
[15:16] <vila> jam: Aren't you scared that my magic allows me to summon you with my mouse ?
[15:17] <vila> :D
[15:17] <jam> meh, such is life
[15:17] <jam> Being summoned at the whim of a Frenchman is just part of the mystery of the world
[15:19] <awilkins> Ca va
[15:20] <awilkins> And C'est la vie
[15:20]  * vila should stop magic, too much of it today anyway
[15:20] <awilkins> Speaking of mouse magic, I've discovered Synergy and I' love it
[15:20] <vila> awilkins: you forgot: 'Et pour la ptite dame ce sera quoi ?'
[15:21] <vila> awilkins: yup, synergy rocks, despite some incompatibilities with virtualbox
[15:21] <awilkins> Ma Francais est tres merde
[15:22] <vila> awilkins: You certainly meant: "Mon francais n'est pas tres bon" :-D
[15:22] <awilkins> Ah, yes, I just called myself a girl
[15:23] <awilkins> No wonder they're obsessed with sex, it suffuses their language (ok, ok, that's gender)
[15:23] <vila> awilkins: nope, I'm a boy, yet, I can say: "Ma voiture est en panne" (my car is broken)
[15:23] <vila> awilkins: German is even worse, there is also neutral ;-)
[15:23] <awilkins> So "french" is mle
[15:23] <awilkins> I thought it was that way round
[15:24] <awilkins> I only studied it until I was 15
[15:24] <Tak> yeah, I wonder why so many of the romance languages dropped the neuter gender from latin
[15:24] <awilkins> Wasn't romantic enough   <ducks>
[15:25]  * Tak cry
[15:27] <awilkins> verterok: I hate Eclipse sometimes
[15:27] <awilkins> "No repository found containing ...."   WHY IS THE SOFTWARE IN THE LIST IF YOU CAN'T SEE ITT!!!!1
[15:27] <awilkins> Ahem.
[15:27]  * awilkins calms down a bit
[15:28] <verterok> awilkins: you'r not alone
[15:34] <jrwren> is there a way to spec a revno saying "last time this file changed"?
[15:35] <jrwren> i want to bzr diff MyFile, I know it changed recently, but I don't know if its -2, -3, -4...
[15:35] <jrwren> is there a way to say "-1 for this file" ?
[15:36] <vila> jrwren: no, but annotate will show you all revisions the modify you file
[15:36] <jrwren> ah!  right!
[15:36] <jrwren> ty.
[15:36] <vila> jrwren: no, but annotate will show you all revisions the modified your file
[15:36] <vila> gee, typos all over the place
[15:37] <vila> s/the/that/ even or something
[15:37] <awilkins> You can log a file
[15:37] <awilkins> bzr qlog <file> and bzr log <file> work just fine
[15:37] <jrwren> annotate doesn't work in this case because I'm looking for a deleted line.
[15:37] <jrwren> yes, I was trying to avoid log then diff
[15:38] <vila> jrwren: try qannotate
[15:38] <vila> one more typo "-(
[15:38] <jrwren> i'm on win32 :(
[15:38] <awilkins> qannotate works on win32
[15:38] <vila> qannotate from the qbzr plugin
[15:38] <jrwren> whoa!  awesome!
[15:39] <awilkins> If you installed the .exe it's arleady instlled
[15:41] <jrwren> thanks, that helps a lot
[15:44] <james_w> chk seems to have changed the rules about the revprops you can supply
[15:44] <james_w> I have to supply unicode values now, and I thought I had to supply non-unicode with old formats
[15:45] <james_w> was I wrong before?
[15:53] <awilkins> Oh, I found a circumstance in 1.16 on windows where it just drops dead, something happening inside groupcompress_pyx.pyd
[15:54] <awilkins> Alas, no stack track, because it just drops a minidump
[15:55] <awilkins> Would that actually be any use to any bzr developers?
[15:59] <rockstar> jam, who designed the plugin model for bazaar?
[15:59] <vila> awilkins: did you check you .bzr.log ?
[15:59] <vila> awilkins: did you check your .bzr.log ?
[15:59] <awilkins> vila: yes
[15:59] <jam> rockstar: I wrote the original code
[16:00] <jam> james_w: Revision property *values* were *always* Unicode
[16:00] <jam> we may have not asserted that in the past
[16:00] <jam> but they were meant to be
[16:00] <jam> and the decoder would always turn them into Unicode
[16:00] <awilkins> vila: It doesn't write a stack dump to the log. I suppose a debug-on log would be ok
[16:00] <james_w> jam: ok, thanks
[16:00] <jam> awilkins: a copy of the *data* you were using would be helpful
[16:00] <jam> if that is possible
[16:01] <jam> awilkins: and you can rm groupcompress_pyx.pyd and you should then get a stacktrace
[16:01] <rockstar> jam, so, if I wanted to, say, steal the plugin loading code, where would I need to look?
[16:01] <jam> Though I recommend *moving* it away
[16:01] <jam> rockstar: bzrlib/plugin.py
[16:01] <vila> rockstar: groupcompress is not a plugin anymore
[16:01] <jam> mv groupcompress_pyx.pyd groupcompress_pyx.old.pyd
[16:01] <rockstar> jam, okay.
[16:02] <jam> rockstar: different threads :)
[16:02] <jam> awilkins: We have a pure-python fallback that will be in library.zip
[16:02] <rockstar> vila, ?
[16:02] <jam> So we should recover just fine from the .pyd going missing
[16:02] <awilkins> jam: Alas, the data is rather large
[16:02] <jam> awilkins: my guess is an out-of-memory error or something weird like that
[16:02] <jam> awilkins: but again, the pure-python is more "segfault" tolerant
[16:02] <awilkins> jam: That was my guess too ; it's also a bzr-svn branch
[16:03] <jam> so try that and see if it gives anything interesting
[16:03] <vila> rockstar: err, sorry, misread your first message, forget me
[16:03] <awilkins> jam: Ok, I'll have to tinker with library.zip
[16:03] <jam> awilkins: you shouldn't have to tinker with library.zip
[16:03] <awilkins> jam: Can you just unpack it and delete the zip
[16:03] <jam> I was just saying where the python code is
[16:03] <awilkins> Ah, yes
[16:03] <awilkins> so just rename it to pyd_off ?
[16:04] <jam> awilkins: yep
[16:04] <rockstar> vila, c'est bon
[16:04] <jam> vila: any chance you could look at https://code.edge.launchpad.net/~jameinel/bzr/bug-390563/+merge/7889
[16:04] <jam> It should unblock the launchpad devs
[16:04] <jam> so I'd like to get it merged in
[16:04] <jam> and probably end up cherrypicking it to 1.16.1
[16:04] <jam> Then I need to look at a more complete fix
[16:04] <jam> abentley: https://code.edge.launchpad.net/~jameinel/bzr/bug-390563/+merge/7889
[16:05] <jam> That is the branch Robert & I put together
[16:05] <jam> which probably fixes your issue about texts getting fetched that have already been fetched.
[16:09] <abentley> jam: That approach isn't as robust as simply skipping duplicates when inserting records.  For example, the target repository may have text versions that cannot be predicted from its inventory data.
[16:09] <jam> abentley: I think erroring is the right approach if you have data that is inconsistent with what we want to insert that "cannot be predicted from the inventory data"
[16:10]  * vila can't parse robust == ignoring errors
[16:10] <abentley> jam: I disagree.
[16:11] <jam> abentley: if you have something that isn't referenecd
[16:11] <jam> which then *disagrees* with data that *is* referenced
[16:11] <jam> then you have something very strange going on
[16:11] <jam> and it would be better to error than to warn
[16:11] <jam> warning == do nothing
[16:12] <jam> (most people ignore warnings)
[16:12] <abentley> jam: Erroring makes it harder to fix such situations.  It also requires the code that determines what to send to be bug-free.
[16:13] <jam> abentley: having different content be "acceptible" means that broken repositories are never "found"
[16:13] <abentley> jam: Since you acknowledge that your code isn't bug-free, I'm not happy with such a solution.
[16:13] <jam> abentley: code is never bug free
[16:13] <jam> I would rather have it fail
[16:13] <jam> than silently propagate corruption
[16:13] <vila> corrupted data are harder to fix and diagnose than corrupted code
[16:14] <abentley> jam: I didn't say we should do it silently.
[16:14] <jam> abentley: a warning won't generate a bug report
[16:14] <jam> nor push us to fix the code
[16:15] <abentley> jam: It's not silent.  Users who care about corruption will notice and do something about it.    Everyone wins.
[16:15] <jam> cprov: I think the "crimson-and-clover" branch was yours, right? I've confirmed that lp:~jameinel/bzr/bug-390563 on the server side allows me to branch your stacked branch.
[16:15] <jam> beuno: ^^
[16:15] <jam> abentley: I honestly doubt it.
[16:15] <jam> Simple warnings get ignored
[16:16] <abentley> jam: Also, your patch means that a bzr 1.16 server will break a newer client.
[16:16] <jam> abentley: nope
[16:16] <abentley> jam: Doesn't the server decide what to send?
[16:16] <jam> abentley: so an older server will send more data than necessary to a client
[16:17] <jam> no breakage
[16:17] <jam> an older server will *break* just as it is breaking today
[16:17] <jam> when you push minimal data
[16:17] <jam> but then fetch more data than that
[16:17] <jam> client determines what data to push
[16:17] <jam> server determines what data to pull
[16:17] <abentley> jam: Right.  I don't want it to break the way it breaks today.
[16:17] <jam> aka, source determines data
[16:17] <jam> abentley: and upgrading the *server* to this patch will fix it
[16:17] <abentley> jam: I encountered this bug when pulling, not when pushing.
[16:18] <jam> abentley: to give details
[16:18] <jam> when pushing up 1 rev
[16:18] <jam> we pushed up the minimal data
[16:18] <jam> when fetching 10 revs
[16:18] <jam> we suddenly started fetching more data than the minimal set
[16:18] <jam> so doing "bzr push; bzr commit; bzr push" would send a minimal amount of data to the server
[16:18] <jam> and then doing "bzr pull" would break
[16:18] <jam> (for someone that didn't have the data)
[16:19] <jam> if you did "bzr commit; bzr commit; bzr push"
[16:19] <jam> everyone would be happy
[16:19] <jam> the server would have "more data than necessary"
[16:19] <jam> but that doesn't *break* things
[16:19] <abentley> jam: As I said earlier, this approach is not robust.  I'm not happy with it.
[16:19] <jam> abentley: having the same text twice in a repository with identical details does not harm anything
[16:20] <jam> attempting to insert it with *different* details does
[16:20] <jam> I'm against not aborting under that circumstance
[16:20] <abentley> jam: It does no harm if you don't insert it.
[16:20] <jam> abentley: Except if *you're* the one that is wrong
[16:20] <jam> and the only way to find that out
[16:20] <jam> is to fetch someone else who is actually right
[16:21] <abentley> But you're damaging the case where I'm the one who is actually right.
[16:22] <jam> unlike the justice system, I'd rather presume guilty than innocent
[16:23] <jam> I realize this has blocked LP devs for a couple of days
[16:23] <jam> and that is certainly annoying
[16:23] <jam> I'd rather block some people and get a fix
[16:23] <jam> than not block, and have the problem spread
[16:24] <abentley> jam: It is not reasonable to prevent people from pulling good data from a server, just because the server also happens to have bad data.
[16:24] <abentley> It makes it much harder for us to fix the data.
[16:25] <abentley> And this won't detect most forms of bad data.  It will only detect it in edge cases.
[16:27] <abentley> In fact, it won't even detect bad that we are inserting.  It will only detect potentially bad data that we *aren't* inserting.
[16:28] <abentley> I'm all for improving consistency, but this is not contributing to that cause significantly.
[16:28] <vila> jam: I was looking at Robert's branch already,  I approved yours
[16:34] <mxpxpod> is there a way to register a directory type with the directory service and have certain urls initialize a shared repository with multiple branches in it?
[16:49] <abentley> jam: I also don't understand why you think my fix would cause the corruption to spread.  Your fix would cause us to silently ignore the bad data, while my fix makes us warn about it.
[16:50] <jam> abentley: my fix is not specifically proposed for your work, though I think it will get you to where you want to be
[16:51] <jam> the problem is cases where we should be fetching things  and they turn out to be inconsistent
[16:51] <jam> yours will still only warn
[16:55] <abentley> The problem is that I don't trust bzr to figure out what things we should be fetching.  Especially if I don't have control over the copy of bzr determining what to fetch.  That code is complex and you've already said it still needs work.
[18:35] <vxnick> is it best to use 'bzr bundle' or 'bzr send' for saving patches?
[18:35] <vxnick> creating*
[18:36] <dash> i think the main difference is that 'send' mails it
[18:37] <vxnick> I can't get either to output the patch info in the output file - I don't know what I'm missing
[18:37]  * Tak always use bzr diff
[18:37] <vxnick> I've tried "bzr bundle -o changes.diff" and "bzr bundle -r-1 -o changes.diff"
[18:38] <vxnick> so something like "bzr diff -r-1 > changes.diff" ?
[18:38] <LarstiQ> vxnick: bzr send
[18:38] <fullermd> You want 'send -o$FILE'
[18:39] <fullermd> bundle is deprecated since about 2 weeks after dirt was invented.
[18:39] <dash> why doesn't it say anything about that then
[18:39] <vxnick> ah I didn't know that
[18:39] <LarstiQ> vxnick: and you might want to supply the submit branch
[18:40] <LarstiQ> dash: bundle is a hidden command
[18:40] <fullermd> It maybe should.  It's been taken out of the 'commands' list since...  I don't even know.
[18:40] <fullermd> 0.11 maybe, something in that era.
[18:40] <vxnick> LarstiQ: there isn't a public branch
[18:40] <LarstiQ> vxnick: send needs to know which revisions to include
[18:41] <vxnick> LarstiQ: I'm using "-r -1" for that
[18:41] <vxnick> assuming that'll do the last rev
[18:42] <LarstiQ> vxnick: not exactly
[18:43] <vxnick> "bzr send -r -2.. -o changes.diff" works
[18:43] <fullermd> And note 'submit branch' != 'public branch'.
[18:43] <vxnick> fullermd: yeah I'm aware of that bit
[18:43] <LarstiQ> vxnick: say you have a branch that is 2 revisions behind, if you made a merge directive with just the last revision, it wouldn't be able to apply that in the 2-behind branch
[18:43] <fullermd> And if that works, it probably means it already has a submit branch, so you don't need the -r at all (unless you're intending a cherrypick).
[18:44] <vxnick> ok, so assume I've branched someone's code - if I want to create a patch with my changes in it since their last update, what would I use for the revision argument?
[18:45] <LarstiQ> vxnick: nothing
[18:45] <LarstiQ> vxnick: just `bzr send`
[18:45] <fullermd> You wouldn't need any.  send checks the submit branch (which default to what you branched from), and includes everything that isn't in it already.
[18:45] <vxnick> ah, thanks :)
[18:45] <LarstiQ> vxnick: now, if your last couple of revisions were bogus, but you wanted to send the rest, you would do `bzr send -r -4`
[18:45] <LarstiQ> which means, everything up to -4 that the submit branch doesn't have
[18:46] <vxnick> gotcha
[18:46]  * LarstiQ goes for dinner
[18:46] <vxnick> thanks for your help guys
[18:46] <LarstiQ> vxnick: np
[18:51] <glyph> "DoS attack"?
[18:51] <glyph> whoops
[18:51] <glyph> I was responding to something twenty hours ago on a different channel :)
[19:02] <alf> Hello, I was wondering if there is a preferred way to handle feature branches in very large (disk-space wise) trees. Creating lots of feature branches creates lots of large trees which can be a problem. Any thoughts?
[19:09] <FibeRichio> Is it possible to integrate the "bzr-push-and-update"-plugin to Turtoise Bazaar on Windows? Or do I have to use the commandline for that?
[19:10] <beuno> alf, because of the working tree, or the revision information?
[19:11] <alf> beuno: the working tree
[19:11] <beuno> alf, you can use bzr switch\
[19:16] <alf> beuno: thanks, I am reading about it now in the user guide
[19:38] <jskulski> is this possible: bzr branching from a checkout of svn?
[19:39] <LarstiQ> jskulski: if you have bzr-svn installed, yes
[19:41] <jskulski> LarstiQ:: so when you bzr push you modify the files in teh checkout (which will sit and wait to be committed manually?)
[19:43] <kirkland> i'm in a local bzr branch, and i want to change the location it pushes to when i just type "bzr push"
[19:43] <kirkland> how do i change the stuff cached and reported in 'bzr info' ?
[19:43] <vxnick> kirkland: bzr push --remember <new location>
[19:43] <kirkland> vxnick: rocking, thanks.
[19:43] <LarstiQ> jskulski: no, it will push to the svn server then
[19:43] <LarstiQ> jskulski: (and update the checkout)
[19:44] <LarstiQ> jskulski: you need not touch the svn checkout anymore after you branch from it though
[19:44] <jskulski> LarstiQ:: ok, so for bzr-svn, the workflow requiires svn commit access
[19:45] <LarstiQ> jskulski: how so? (and what workflow?)
[19:45] <jskulski> is that correct?
[19:45] <LarstiQ> jskulski: you don't need to have svn commit access to use bzr-svn, no
[19:45] <LarstiQ> jskulski: you need it to write back to the svn repo though
[19:45] <jskulski> LarstiQ:: yeah
[19:45] <jskulski> LarstiQ:: ok thanks for your help
[19:45] <LarstiQ> jskulski: and pushing to a checkout implies pushing to it's master, both in bzr and svn
[19:46] <jskulski> right on
[19:46] <jskulski> seriously this channel is rocking, consistently helpful and friendly advice to a newb.
[19:46] <jskulski> thanks!
[19:46] <LarstiQ> jskulski: but it's fine to just branch from svn, develop, publish, and let someone else bother with pushing back into svn. It's what I do ;)
[19:46] <LarstiQ> jskulski: thanks :)
[19:46] <jskulski> LarstiQ:: oo that is what i'm waiting for
[19:47] <jskulski> err looking for
[20:05] <jskulski> hey again, I am trying to bzr branch file:///var/www/project where /var/www/project is a svn checkout of an external repository and I keep getting a segementation fault.
[20:06] <jskulski> i have bzr-svn installed
[20:06] <jskulski> and i've done this process berfore with local svn repositories
[20:08] <LarstiQ> jskulski: which version of bzr, bzr-svn (and possibly subvertpy) does this happen with?
[20:09] <jskulski> bzr 1.5
[20:10] <jskulski> 1.5.1
[20:10] <jskulski> 0.4.10-2
[20:10] <jskulski> sorry 0.4.10-2 is bzr-svn
[20:14] <schmoonior> so I was doing a bzr add when my Mac had the equivalent of a BSOD (not related to bzr) and now when I run bzr status I get: bzr: ERROR: The dirstate file (DirState(u'/Users/drew/Documents/working/.bzr/checkout/dirstate')) appears to be corrupt: failed to find trailing NULL (\0). Trailing garbage: '\n'
[20:14] <schmoonior> any suggestions?
[20:14] <jskulski> subversion is also 1.5, but not sure what the external reposiotry version is
[20:15] <Peng_> schmoonior: If you don't mind losing some of the working tree's uncommitted meta data (e.g. bzr adds), and aren't using a lightweight checkout, getting rid of .bzr/checkout and running "bzr co" is probably easiest.
[20:16] <Peng_> schmoonior: Note: if it opens a black hole and destroys the planet, it's not my fault. :)
[20:16] <schmoonior> fortunately I'm not at LHC ;)
[20:16] <schmoonior> if I do the bzr co, it won't mess with any of the uncommitted changes in files?
[20:18] <Peng_> schmoonior: I don't know. I'd be surprised if it *destroyed* anything, but it might rename stuff to backup files or generate conflicts or something.
[20:18] <Peng_> schmoonior: Again, black holes, not my fault, etc.
[20:18] <schmoonior> ok, I might just make a simple copy of my tree before I do anything
[20:18] <SamB> schmoonior: was just about to suggest that myself ;-)
[20:19] <Peng_> Yeah, backups are good. :)
[20:19] <schmoonior> thanks guys, I will let you know how it goes
[20:33] <LarstiQ> jskulski: sorry, I didn't get highlighted so didn't get drwan back here
[20:33] <LarstiQ> jskulski: bzr-svn 0.4 is a dead end, preferably use 0.6.x or if not that then at least 0.5.x
[20:34] <kfogel> anyone: if you had to point people to just one page to say what brisbane-core is all about, what page would it be?  http://jam-bazaar.blogspot.com/2009/03/brisbane-core.html ?
[20:34] <LarstiQ> jskulski: I can't promise all bugs will be fixed in newer versions, but many have
[20:34] <LarstiQ> kfogel: if one page, then yes that one
[20:34] <kfogel> LarstiQ: thanks
[20:35] <LarstiQ> jskulski: are you on suse by chance?
[20:49] <jskulski> LarstiQ:: sorry stepped out, i will look into updating. We are debian 5
[20:50] <schmoonior> Peng_ and SamB: it appears to work.    Thanks again
[20:51] <LarstiQ> jskulski: ah good, I run Lenny myself too
[21:15] <SamB> jelmer: if I do a "bzr svn-import" with a destination repository that contains a branch of my own in addition to the branches imported from SVN, is my branch in any danger?
[21:27] <synic> is there an easy way to serve bzr via http with access control?
[21:28] <dash> sure
[21:28] <dash> use any http server with access control :)
[21:29] <synic> I see.  Just the regular Auth in apache would work?  What about limiting writes to some users and read to others?
[21:31] <SamB> bazaar supports commit-by-PUT now?
[21:32] <synic> anyone?
[21:32] <dash> synic: i don't remember if you can push to a bzr branch via http
[21:32] <LarstiQ> SamB: with smartserver enabled, or with webdav
[21:33] <dash> but yes, just regular auth will work.
[21:33] <synic> I'm trying to find the best way to serve a bzr repo to windows users with access control
[21:33] <synic> ssh doesn't really work because lol windows
[21:33] <LarstiQ> windows can do ssh
[21:33] <LarstiQ> synic: bzr has support for putty/pageant
[21:34] <synic> oh, pageant?  Sweet, this will work then
[21:35] <synic> LarstiQ: is there a doc on that?  I'd like to use ssh keys
[21:36] <LarstiQ> synic: userguide perhaps, but if pageant is in your PATH, it should just work?
[21:36] <LarstiQ> synic: and yes, with keys :)
[21:45] <synic> LarstiQ: do you have to tell bzr to use pageant?
[21:47] <lifeless> jelmer: bug 376748, just checking - you call the partial pack function?
[21:48] <LarstiQ> synic: should not be needed. But in case you also have openssh on windows (which it will prefer) you can use BZR_SSH=plink
[21:48] <synic> mk
[21:53] <LarstiQ> synic: but afaik all you should need is to have PATH set up
[21:53] <synic> yeah, it's working now.  Thanks :)
[21:54] <LarstiQ> cool :)
[22:01] <synic> one more question, is there a way to "bzr push" in tortoise bzr?
[22:04] <synic> it's got pull, update, commit, add, delete.  No push?
[22:06] <LarstiQ> synic: called 'publish' maybe?
[22:06]  * LarstiQ is not well versed in windows/Tortoise :/
[22:06] <synic> yeah, no publish
[22:06] <synic> I'm not very good with windows either
[22:07] <synic> I'm probably missing something obvious
[22:16] <jam> lifeless: ping
[22:16] <lifeless> hi
[22:16] <lifeless> timing :P I wass just about to go grab food
[22:17] <jam> Sorry I was away, my wireless on my laptop dies every now and then
[22:17] <jam> so I just hacked hidden without it for a while
[22:17] <jam> lifeless: so you may want to look at lp:~jameinel/bzr/1.17-chk-multilevel
[22:17] <lifeless> thats cool
[22:17] <lifeless> so
[22:18] <jam> I'm pushing it now
[22:18] <jam> anyway, it is an attempt at using the same heapq strategy
[22:18] <jam> for iter_interesting_nodes
[22:18] <lifeless> I was wondering why you remove any uninteresting nodes
[22:18] <jam> any?
[22:18] <jam> so that you don't have to walk the entire uninteresting set
[22:18] <jam> the way the code was structured
[22:19] <jam> it made sure to get the 'largest possible uninteresting' set
[22:19] <jam> and then filtered the interesting nodes as it read the rest in
[22:21] <lifeless> well
[22:21] <lifeless> let me rephrase
[22:21] <lifeless> 'I wasn't awake'
[22:22] <lifeless> clearly an interesting tree may have uninteresting nodes, so you have to trim from both sides
[22:22] <lifeless> so, all good
[22:22] <lifeless> let me know when its pushed, and I'll give it a review
[22:23] <lifeless> I wanted to ask you about abentley's skip-dupes; reading scrollback it looks to me like you have similar concerns to what I expressed about the first version of the patch
[22:23] <jam> lifeless: the basic fix I wrote, and you managed to write tests for has been landed in bzr.dev
[22:23] <jam> as it at least fixes the common cases we are running into
[22:24] <jam> lp:~jameinel/bzr/1.17-chk-multilevel is a pretty major rewrite
[22:24] <jam> and it is going to be a while before I'm specifically ready to land it
[22:24] <jam> It currently reads nodes 1-at-a-time
[22:24] <jam> which isn't appropriate for what we are doing
[22:24] <jam> (especiallly yielding *keys* one-at-a-time)
[22:24] <lifeless> heh yes
[22:25] <lifeless> I think the crisis is over, I'm helping[nagging?] mwhudson to land the common case fix
[22:26] <jam> lifeless: generally, I think the check we have is better than a simple warning. I could be convinced that it isn't the perfect time to be doing the check, and that we should have better ways of handling it.
[22:26] <jam> like having a "reconcile my repo with this repo over here"
[22:27] <jam> and "I know you don't like it, but stop getting in my way" flag.
[22:28] <lifeless> jam: Could you do me a favour, and review aarons new version; I don't like being the only bad guy :)
[22:28] <abentley> lifeless: Dude, I did what you asked.
[22:29] <lifeless> abentley: you did, but the basic concern I expressed is still there
[22:29] <lifeless> which is fundamental
[22:29] <lifeless> the trace version has no performance issues - and thats great
[22:29] <lifeless> if its conceptually ok to do this, then it passes muster
[22:29] <abentley> lifeless: You expressed concern about it being silent.  It's not silent.
[22:31] <lifeless> abentley: your revised version is massively better than the first one. I'm ecstatic on that basis.
[22:33] <lifeless> I think one of the concerns I have that I haven't adequately expressed so far is this:
[22:33] <lifeless> for revisions is really serious to have this wrong
[22:33] <lifeless> for texts it affects annotate and log
[22:34] <lifeless> so I'm going to ask you to do one smallish further change, which is to note whether we care in a particular GCVF  object, and then I'll be happy
[22:35] <SamB> have what wrong?
[22:36] <abentley> lifeless: for revisions, it would be a pretty big bug to miscalculate what revisions to send.
[22:36] <jam> abentley: it would be an even bigger bug to have different ancestries
[22:37] <abentley> jam: I'm not sure that's even true.
[22:37] <SamB> sending the wrong revisions doesn't sound like it ought to do any permanent damage to *me*
[22:37] <jam> for the same revision to have different parents...
[22:37] <jam> SamB: sending revisions you don't need, or duplicates with what you already have doesn't seem like a problem, as long as they are identical
[22:37] <SamB> corrupting the revisions sent is indeed *bad*
[22:38] <lifeless> abentley: it would; and this was an inarticulated concern, which is why you couldn't fix it ;)
[22:38] <SamB> jam: exactly
[22:38] <lifeless> abentley: now I've figured it out, its possible to fix it.
[22:38] <lifeless> abentley: I've proposed one way in the merge
[22:38] <SamB> jam: not sending what you do need is a problem but presumably the other end will catch it
[22:38] <lifeless> abentley: other ways are likely possible, and if you have one please propose it. Though what I'm proposing is pretty lightweight.
[22:39] <jam> and at least in our "theoretical" prototypes, we have discussed sending extra data in exchange for not having to query to determine what you do/don't have
[22:39] <abentley> lifeless: I will update my branch as you requested.  I think my fix is appropriate for CPing into Launchpad, because it lets us reconcile trunk.
[22:40] <SamB> jam: like the way git defaults to behaving?
[22:40] <lifeless> abentley: as long as we deploy the full version rapidly thereafter I'm fine with that
[22:40] <lifeless> abentley: I would be concerned about running with trace-for-revisions for extended periods
[22:40] <lifeless> SamB: that isn't what git does
[22:41] <lifeless> abentley: sorry for giving your a runaround here; it wasn't intentional.
[22:41] <lifeless> s/your/you/
[22:41] <abentley> lifeless: Okay.
[22:42] <SamB> lifeless: well, it doesn't involve going down the list and asking the recieving end "do you have this? do you have this?"
[22:42] <abentley> lifeless: I will try to set up a cron job to run "bzr check" on trunk.
[22:42] <lifeless> SamB: it does
[22:42] <lifeless> abentley: I think thats a good precaution.
[22:43] <SamB> lifeless: git-to-git? no...
[22:43] <lifeless> SamB: yes
[22:43] <lifeless> SamB: it has a bidirectional stream where both sides say 'I have X\nI have Y\n'...
[22:44] <lifeless> SamB: and that goes on until the sender knows precisely what the reciever doesn't have, when it stops sending 'I have' messages, goes and creates a pack on the fly and transmits it.
[22:44] <SamB> well, it doesn't go and then ask you what blobs you have ...
[22:44] <lifeless> SamB: neither does bzr
[22:44] <lifeless> SamB: it walks the commits and tree content to determine what blobs to send; bzr does similar.
[22:45] <SamB> ... which can be annoying if you're rewriting ancestry ;-P
[22:45] <lifeless> so yes, the same blob will be sent if you rebased or similar the only refs that had it
[22:45] <lifeless> and bzr will do the same in the same situation
[22:46] <lifeless> what jam is talking about is quite different
[22:46] <SamB> so, what approximation do you mean ?
[22:46] <lifeless> its about *deliberately* cutting the calculation for 'what the receiver has' short (either at the revision level, or doing less work analysing the commits), and just sending what we have on disk
[22:47] <lifeless> e.g. send the entire compression group, rather than the 3 texts from within it that the receiver needs
[22:47] <SamB> oh, you mean the sender deciding "screw this, I'm just sending the pack"?
[22:48] <lifeless> for instance, yes.
[22:52] <lifeless> jam: I really must eat now, bbs
[22:52] <jam> lifeless: eat hearty
[22:52] <lifeless> 87.1kg today
[22:52] <lifeless> slowly slowly
[22:52] <jam> that is a lot of food to eat
[22:52] <jam> and it isn't even 8am there
[22:53] <jam> lifeless: you should slow down indeed :)
[22:53] <lifeless> jam: !
[22:53] <lifeless> bbs
[23:24] <thewrath> hey all i have linux commands i need to run
[23:25] <thewrath> can i run bzr diff commands
[23:29] <lifeless> what do you mean?
[23:29] <thewrath> is there a such thing as bzr diff
[23:30] <thewrath> want to run something liek this svn diff -r 36:69 URLgoesHere | grep "^+" | grep -v "^+++" | wc -l
[23:31] <thewrath> but im using bzr
[23:31] <lifeless> yes there is
[23:33] <thewrath> pefecto
[23:33] <thewrath> i need the url like this  hold on
[23:33] <thewrath> https://code.launchpad.net/~mikesats-coders/mikesats/stableversion
[23:34] <thewrath> what would the url be for that
[23:35] <thewrath> would it be bzr diff -r 4:5 lp:mikesats | grep "^+" | grep -v "^+++" | wc -l  ?
[23:35] <lifeless> bzr diff -r 4..5 lp:mikesats
[23:35] <lamalex> does anyone know the name of the project for code hosting on lp?
[23:35] <lamalex> whooops
[23:35] <lamalex> meant to join #launchpad
[23:35] <lifeless> lamalex: launchpad-code
[23:35] <thewrath> lifeless but i want the number of added lines
[23:35] <thewrath> that is where the greps come in handy
[23:36] <lamalex> lifeless: thanks
[23:36] <lifeless> thewrath: sure, so use them
[23:36] <thewrath> is that supposed to be 4.5 or 4:5 lifeliess
[23:36] <lifeless> 4..5
[23:36] <thewrath> that is how bzr does it?
[23:36] <lifeless> yes
[23:36] <thewrath> bzr diff -r 4..5 lp:mikesats | grep "^+" | grep -v "^+++" | wc -l  ?
[23:37] <lifeless> yes
[23:50] <thewrath> lifeless: u still around
[23:50] <lifeless> thewrath: sure
[23:50] <thewrath> i get  a dont know how to handle ssh connection
[23:50] <thewrath> please set bzr_ssh enviroemnt variable
[23:51] <lifeless> thewrath: are you on windows?
[23:51] <thewrath> yes sir
[23:51] <thewrath> i have pageant key list running with my key
[23:51] <lifeless> ok
[23:51] <thewrath> how do i correct the error
[23:51] <lifeless> uhm, I'm not really fluent about using bzr on windows
[23:51] <lifeless> how did you install bzr?
[23:53] <thewrath> normal windows install
[23:53] <lifeless> we have a couple of different installers; can you be more precise? was it a .exe? or the python installer or?
[23:54] <lifeless> jam: are you still around? ^
[23:54] <thewrath> exe
[23:54] <thewrath> i think its sometihng to dow ith cygwin but not sure
[23:54] <lifeless> thewrath: its meant to detect pageant automatically I thought
[23:56] <thewrath> yea
[23:56] <thewrath> it is
[23:56] <thewrath> damn it
[23:59] <lifeless> so you could try
[23:59] <lifeless> set BZR_SSH=paramiko
[23:59] <lifeless> then run your bzr commands


[13:46]  * thorwil reads _MMA_s Stepping down from Ubuntu Studio mail
[13:46] <_MMA_> yep
[13:47] <thorwil> _MMA_: the CAD job continuous?
[13:48] <_MMA_> Looks like it will be. I'll be designing on Autodesk's "Inventor".
[13:48] <thorwil> that's a bit like solidworks, right?
[13:49] <_MMA_> I'm unsure. I've never used Solidworks.
[13:50] <thorwil> parametric solid modeling with parts in assemblies, buidling a tree
[13:50] <_MMA_> Ahh... Then yes.
[13:51] <thorwil> had a love-hate relationship with that one. so incredibly powerful and clever, but some things that i thought should work didn't and it's a very windowsy application
[13:54] <_MMA_> Yeah. I'd love it to be a linux app. Some of the Autodesk stuff is. I think its mostly stuff they bought. This company lets me use linux where I can though. ie: I do some things that arent CAD. Like developing a manual. Im doing that all on Ubuntu.
[13:54] <thorwil> cool


[07:02] <dholbach> hey hey
[07:21] <davidcalle> o/
[07:27] <dholbach> salut davidcalle
[07:32] <Mister_Q> hey everyone o/
[07:37] <tsimonq2> o/ dholbach, davidcalle, Mister_Q, how are you all? :)
[07:38] <dholbach> good good :-)
[07:38] <dholbach> how about you all?
[07:38] <davidcalle> Good, thanks!
[07:39] <Mister_Q> tsimonq2 good :) Listening to Casey West about pivotal cloud right now :) how are you ?
[07:39] <tsimonq2> well I'm at someone else's house using crouton on a Chromebook with generic LXDE and no mouse, but otherwise, I'm good :)
[07:46] <dholbach> relocating to the office, bbiab
[08:18] <svij> morning!
[08:23] <Mister_Q> svij o/
[08:25] <Kilos> hi dholbach svij and other peeps
[08:26] <dholbach> hi Kilos
[08:37] <tsimonq2> o/ Kilos and svij :)
[08:37] <Kilos> hi tsimonq2
[13:20] <dholbach> davidcalle, so it's us for the Q&A today?
[13:20] <davidcalle> Yup \o/
[13:20] <dholbach> let's set things up already :)
[13:20] <dholbach> I'll set up the event and update ubuntuonair
[13:21] <davidcalle> <3
[13:22] <dholbach> hum, where do I do this in the "new G+ interface"?
[13:22] <dholbach> where did they hide hangouts on air?
[13:23] <dpm> svij, I might be a few minutes late for the call. mhall119, would you mind sharing the sponsors list and templates with svij while I'm not on the call?
[13:23] <dholbach> what a nightmare
[13:23]  * dpm still goes retro and uses the old G+ interface
[13:24] <dholbach> yeah
[13:25] <davidcalle> dholbach: https://plus.google.com/hangouts/onair
[13:25] <dholbach> ah, you need to get the special URL from somewhere :)
[13:26] <dholbach> was it hidden under the "Pay $50 to continue" button in the fifth level of navigation somewhere?
[13:26] <dholbach> sorry, I'm sure I just didn't see it earlier :)
[13:27] <davidcalle> dholbach: I have an account still using the old interface :)
[13:28] <dholbach> I see, Ubuntu Community team = a bunch of retro people :)
[13:28] <dholbach> ok, uonair updated
[13:29] <svij> dpm: ok
[13:29] <dpm> sorry, wrapping up a couple of things for the snappy sprint next week
[13:30] <svij> no worries
[14:14] <Mister_Q> dpm sorry again that I was late for the ubucon meeting. I was at a cloud event and literally stepped out the car and joined the hangout
[14:49] <dpm> Mister_Q, no worries, we could clearly see that :)
[14:49] <dpm> thanks for making the effort in participating
[14:50] <Mister_Q> dpm I dont know how bad the video quality was :D Will add the links for the updated google docs to trello board later
[14:54] <dpm> thanks
[16:04] <dholbach> have a good one everyone!
[16:50] <hggdh> all: I opened https://bugs.launchpad.net/ubuntu-codeofconduct/+bug/1602344
[16:50] <hggdh> comments are welcome.
[16:53] <Mister_Q> Did we came to a conclusion at the last uos? There was a session about that iirc
[18:57] <mhall119> Mister_Q: the conclusion was to add some text, but not necessarily agreement on the text itself
[18:57] <mhall119> there's an MP attached to the above bug report with proposed text
[20:15] <hggdh> Mister_Q: also, some more pointers to definitions, etc so that it gets more complete


[08:14] <desrt> happy thursday!
[08:53] <ricotz> damn, I was hoping it is friday
[09:01] <Laney> morning
[09:03] <davmor2> Morning all
[09:05] <seb128> hey desrt ricotz Laney davmor2
[09:05] <desrt> seb!
[09:05] <desrt> Laney!  davmor2!
[09:05] <desrt> is everyone just on UK time now, or what?
[09:06] <seb128> I usually start around 7:30 european and deal with the night backlog, emails etc until ~9
[09:06] <seb128> then get something to eat/coffee and come back to work&IRC when u.k joins
[09:07] <davmor2> seb128: that's only cause you want to look busy when the boss joins right ;)
[09:07] <seb128> because greetings on IRC is busy work right? :p
[09:08] <davmor2> seb128: maybe not busy but important :D
[09:08] <seb128> also what boss?
[09:08] <seb128> willcooke still didn't say hey :p
[09:08] <seb128> some extra minutes to slack before pretending to be at work!
[09:09] <davmor2> seb128: that's it just take it easy till the real work kicks in :D
[09:09] <willcooke> o/ OTP
[09:10] <davmor2> seb128: you ever notice how these managers always have an excuse
[09:11] <Laney> hey davmor2 seb128 desrt
[09:11] <desrt> willcooke: i hope your phone is tasty!
[11:36] <Laney> willcooke: default wallpaper reminder ping reminder ping (& contest?)
[11:47] <willcooke> Laney, thanks.  Spoke to Marcus this morning about it actually :)
[11:47] <willcooke> Laney, (but only because c_yphermox reminded me yesterday)
[11:48] <Laney> win
[12:07] <davmor2> willcooke: you didn't read my zesty testing report that listed it too then :P
[12:07] <willcooke> davmor2, seriously - it's top of my list, I'm going to get to it this afternoon :)
[12:07]  * willcooke <- not even lying
[12:08] <davmor2> willcooke: I think the biggest issues I hit once I reproduced on hardware and was able to give devs access to are now on the fix :)
[12:09] <willcooke> thanks davmor2
[12:10] <davmor2> Laney: did you say you wanted the zeitgeist landing in today if so I can give that a quick test and see if it is working on the latest image?
[12:15] <Laney> davmor2: it is there, works for me http://people.canonical.com/~laney/weird-things/apps.png but feel free to check
[12:15] <davmor2> Laney: nice thanks
[12:38] <davmor2> Yay I see dead people.....oh wrong script......I see apps in scopes and all sorts on the live session let's do an install and test it there too \o/
 jbicha, can you build gtk3 without mir on s390x?
 and hence without content-hub, ubuntu-app-launch, mir.
 xnox: yes, but I'd like the Desktop team to approve that
 jbicha, i'm sure they don't support mir on s390x =)
 xnox: could you reask in #ubuntu-desktop?
[13:13] <xnox> seb128, ^^^
[13:13] <xnox> bregma, ^^^
[13:16] <Laney> ted_g said he thought that ual would be done this week.
[13:16] <seb128> what Laney said
[13:37] <bregma> xnox, I confirm we don't support Mir on s390x because finding one of them mainframes with the appropriate graphics acceleration hardware is challenging at best
[13:46] <Sweet5hark> hardware refresh ordered ;)
[13:48] <Sweet5hark> (lenovo germany dropped their prices by 10%, hard to resist that -- and yes, I know quite well, there might be new models out at MWC today still. I dont care ;) )
[14:32] <xnox> Laney, i am all for u-a-l systemd-only port we need it everywhere.
[14:32] <xnox> but as per above, we really don't need mir enabled gtk3 on s390x
[14:33] <Laney> We don't need arch-specific hacks in the source either
[14:33] <Laney> Plenty of hacks for upstart/s390x all over the archive already
[14:34] <xnox> true
[14:36] <Laney> I just think it has the stench of technical debt and if we can use this to leverage a fix then we should
[14:36]  * Laney whispers (obviously we wouldn't want to release like this ...)
[14:51] <willcooke> Sweet5hark, link?
[14:51] <willcooke> Sweet5hark, this is relevant to my interests
[14:53] <Sweet5hark> willcooke: e.g. http://shop.lenovo.com/de/de/laptops/thinkpad/t-series/t460s/
[14:54] <Sweet5hark> willcooke: I hope lenovo does not do some location based redirect crap.
[14:54] <didrocks> no, I can see "Wie konfiguriert" :)
[14:54] <willcooke> and a docking station for it too \o/
[14:54] <Sweet5hark> willcooke: see this "eCoupon: LASTCHANCE" stuff giving some 150 -200 EUR discount.
[14:55] <willcooke> Still got a few months to wait
[14:57]  * Sweet5hark decided to go with an i5 instead of an i7. I will see how that works out. If I need compile power for a sprint or something I will add a NUC with a good i7 or a Ryzen later.
[14:59] <Sweet5hark> thus: for a simple 2 day conference -- less than 2 kg notebook. for a sprint, have the NUC checked in and have a proper CPU and something that can actually push away the heat. (my current i7 is fast for 5 minutes, then it is throttled b/c of heat. I dont imagine a 14" thingie to be better at getting rid of heat)
[15:10] <Laney> wohohoh
[15:10]  * Laney forgot to eat food
[15:15] <seb128> Laney, no worry, dinner is at the corner now
[15:28] <davmor2> yay apps I tell you \o/
[15:28] <davmor2> willcooke, Trevinho, Laney: looks like the patch worked \o/
[15:28] <Trevinho> yay
[15:29] <jbicha> thoughts on bug 1669138 ?
[15:30] <seb128> jbicha, it's only a game so I would +1 changing the platform config
[16:23]  * Laney patches davmor2
[16:25] <davmor2> Laney: great now I can break more things.....didn't think that one through entirely now did we :P
[17:37] <Laney> might get to ride my bike in non complete darkness during the week
[17:37] <Laney> praise be
[17:40] <Laney> dunno though, have had to put the light on
[17:42] <davmor2> Laney: Wait till March 21st
[17:42] <Laney> stay indoors until then?
[17:42] <Laney> that's fine
[17:42] <Laney> just ship me some climbing holds
[17:43] <davmor2> Laney: no just don't go riding a bike without lights till then, and even then I'd put lights on it and turn them on
[17:43] <Laney> O_O
[17:44] <davmor2> Laney: it's just safer
[17:46] <Laney> haha
[17:46] <Laney> thanks for the safety tips
[17:46] <Laney> i'd never thought about using lights!
[17:49]  * Laney cancels the daily 10 kilos of carrots
[18:06] <Laney> night!
[19:02] <willcooke> night all


[07:16] <mlankhorst> yay more stack accepted
[07:28] <mlankhorst> shall I put up a raring version now?
[07:29] <tjaalton> of?
[07:29] <mlankhorst> the renamed stack
[07:29] <tjaalton> ah
[07:29] <tjaalton> not much point yet, since nothing has changed :)
[07:30] <mlankhorst> testing mechanics
[07:30] <tjaalton> in that case go ahead
[07:31] <mlankhorst> looks like 1.14 x release will be boring, ah well, I like boring :-)
[07:32] <tjaalton> so no impedance layer?
[07:35] <tjaalton> <IP_ADDRESS>2, I'll merge that
[07:35] <mlankhorst> ah was going to do that myself
[07:35] <tjaalton> feel free :)
[07:36]  * mlankhorst was reading ml first to see if he missed some announce
[07:36] <tjaalton> it got tagged, didn't see the announcement
[07:36] <tjaalton> yet
[07:39] <ricotz> tjaalton, mlankhorst, hi
[07:39] <ricotz> tjaalton, are you going to update git for 1.13.1rc2 right away?
[07:40] <tjaalton> ricotz: probably
[07:41] <ricotz> tjaalton, i want to push it to edgers, but i guess there wont be much packaging change
[07:41] <ricotz> so might be not worth to wait
[08:03] <mlankhorst> I was waking up
[08:03] <mlankhorst> I don't expect much packaging change, if any
[08:05] <mlankhorst> oh some packages dropped ofc
[08:05] <mlankhorst> s/packages/patches/
[08:08] <mlankhorst> tjaalton: did you push xorg-server to raring previously?
[08:09] <tjaalton> mlankhorst: not sure
[08:09] <tjaalton> not the rc1 at least
[08:09] <mlankhorst> ah k
[08:10] <tjaalton> 2:1.13.0-0ubuntu8 yes
[08:13] <mlankhorst> yeah just saw unreleased rc1, was wondering if an error or not :-)
[08:19] <tjaalton> kinda forgot to upload it
[08:19] <tjaalton> but now we have rc2! :)
[08:21] <mlankhorst> I'm even doing a testbuild on an environment that's almost similar
[08:21] <mlankhorst> :P
[08:22]  * mlankhorst still on precise, using the renamed packages to satisfy depends
[08:24] <mlankhorst> blegh fails on my libGL from blob, good enough I suppose..
[08:31] <mlankhorst> ricotz: uploaded the new xorg-server, enjoy!
[08:32] <ricotz> mlankhorst, oh, thanks, i already pushed it to edgers too though
[08:32] <mlankhorst> one packaging change, ABI_VIDEODRV_VERSION bump
[08:33] <ricotz> yeah, this already happened with rc1


[15:23] <kacee> Hi, I've got a question about setting up a Debian server on EC2. I'm new to EC2 but I know the basic and I've worked with S3.
[15:24] <kacee> I would like to setup a EC2 instance that runs Zope (python webserver). But I'm not sure how to setup a server that stays persistent (so I can stop it). I would like to know what is the best know solution.
[15:25] <kacee> Do I have to create a EBS that is mounted as a root partition on Debian. Or is it possible to just copy an existing AMI and some sort of update procedure when things change on the system (like installed packages or configuration in /etc).


[12:08] <floam> has anyone here gotten a serial ata plextor drive to work with via chipsets? I've got a bugzilla bug proceeding as normally but I'm curious if it's actually supposed to work at all in dapper
[12:08] <floam> s/drive/dvd drive/
[01:26] <qwert1> hi
[03:16] <desrt> psusi; i found a fix for the fglrx problems if you're interested
[03:17] <desrt> linked to in 20587.  please test and share your results in that bug.
[03:25] <hub> hey desrt
[03:25] <desrt> hello hubert
[03:25] <desrt> Xgl is fun :)
[03:26] <desrt> nice + fast but has some odd errors with transparency
[03:29] <hub> desrt: the closed development from SuSE?
[03:30] <desrt> ?
[03:30] <hub> desrt: s/SuSE/Novell/
[03:31] <desrt> i'm confused
[03:31] <desrt> xgl is a fdoism, not a novellism
[03:31] <hub> ah
[03:31] <desrt> http://www.freedesktop.org/wiki/Software/Xgl
[03:31] <desrt> this one
[03:32] <hub> because there have a been some sort of disagreement
[03:32] <hub> desrt: hold, I'll give you some links
[03:32] <desrt> ya.  i have no idea what's going on either
[03:32] <hub> http://aseigo.blogspot.com/2005/12/bit-more-on-xgl.html
[03:32] <desrt> between xegl, xgl, in-kernel gl support, xrender, cairo, glitz, ...
[03:32] <desrt> so many different bits of the picture and nobody seems to know how they are going to fit together
[03:33] <hub> desrt: in short Novell hired a few Xgl hackers and decided to work behind closed doors, making the other people working on this on thei own
[03:33] <desrt> weird
[03:33] <desrt> i'm gonna read a bit.  hold on.
[03:33] <hub> desrt: and KDE hackers like Aaron Seigo started ranting and raving about that
[03:34] <hub> desrt: look at the recent desktop_architect list
[03:34] <hub> a bit like Gtk MacOS X
[03:37] <desrt> so
[03:37] <desrt> novell is trying to keep this all to themselves for (i guess) 2 reasons
[03:38] <desrt> 1) they maintain complete control over it throughout its incubation period and when they release it to the world it will be mature enough that nobody will really have any chance to influence it
[03:38] <desrt> 2) they'll get to have it integrated into NLD first and everyone else will lag a release cycle or two
[03:40] <desrt> this makes a lot of sense
[03:46] <hub> crap
[03:46] <hub> network manager does not react to my wireless card
[03:46] <hub> the PCCard one
[03:46] <hub> not the atheros shite
[03:48] <desrt> heh.  google for 'desktop_architects list' gets linus
[03:48] <hub> same list
[03:48] <hub> @osdl
[03:48] <desrt> nod.
[03:48] <desrt> i'm there
[03:48] <desrt> this is very high traffic
[03:48] <hub> not lately
[03:49] <hub> it has been for a few days
[03:49] <hub> with Linus troll
[03:52] <desrt> you saw nat's reply?
[03:52] <hub> sure I did
[03:53] <hub> I'm subscribed to the list
[03:53] <desrt> the way he presents it it's more like someone went off and worked on their own and is in the process of getting his changes ready to merge
[03:53] <hub> my boss even asked my why I didn't post using my work address
[03:54] <Burglaptop> hub: you work for Xandros now?
[03:54] <hub> yeah
[03:54] <hub> that the only job I got an offer for
[03:54] <hub> that's why I moved
[03:54] <Burglaptop> what do you do there?'
[03:54] <desrt> it's because everyone else heard you're french
[03:55] <hub> Burglaptop: software developer
[03:55] <hub> on their proprietary server product
[03:55] <desrt> that seems like a strange fit
[03:55] <hub> in Qt
[03:56] <desrt> even more strange :)
[03:56] <hub> desrt: well, could be worse. I could write C# on Windows
[03:56] <Burglaptop> true. I sell a FC4 based product
[03:56] <hub> at least it is a Linux job
[03:56] <Burglaptop> hub: feel the same way
[03:57] <hub> that's why I installed Ubuntu on my laptop :-)
[03:57] <hub> :-)
[03:57] <hub> (I paid for it)
[05:47] <psusi> desrt, which fglrx problem?
[06:08] <desrt> psusi; were you not the person in here about a week ago annoying the hell out of everyone about how your videocard wasn't working? :p
[06:10] <psusi> hehe... daniels told me it could be done without ATI's damned drivers using the mesa ones instead ;)
[06:12] <psusi> right now I'm working on getting hal and gnome-volume-manager to auto mount a packet write mode cdrw correctly... finally managed to mess with the hal config files to get the drive to auto mount read/write, but now I can't figure out why it doesn't show up on the desktop
[06:12] <psusi> even though it is mounted under /media
[06:47] <MasterTsunami> is there supposed to be a bittorrent tracker running by default in dapper?
[06:48] <crimsun> probably something overlooked, though it does only listen on localhost
[06:48] <MasterTsunami> yeah that i noticed as well
[06:48] <MasterTsunami> still, i would think most users would want a client only, and not the tracker
[06:48] <MasterTsunami> perhaps i should file a bug?
[06:49] <Burglaptop> MasterTsunami: raise it on ubuntu-devel mailing list
[06:49] <psusi> I swear I've seen that brought up before... maybe it was on the dapper forums not the mailing list...
[06:50] <MasterTsunami> i wouldnt have noticed it had i not restarted my laptop and saw "Shutting down bittorrentTracker"
[06:50] <MasterTsunami> and then my eyes went O_O
[06:54] <MasterTsunami> i have to say though, xorg7 is fasssst :D
[06:54] <Burglaptop> MasterTsunami: are you going to post to ubuntu devel or should I?
[06:55] <MasterTsunami> In the forums?
[06:55] <psusi> xorg7 likes to hard lock when I /etc/init.d/gdm restart
[06:56] <MasterTsunami> I'll post Burglaptop ;D
[06:56] <Burglaptop> MasterTsunami: cheers, ok
[06:58] <MasterTsunami> fglrx is kinda funky with xorg7 too; doesn't like to shutdown :/
[06:58] <psusi> also it seems that xorg7 thinks that the forward/back ( far left/far right ) buttons on microsoft intellimice are mouse buttons 8 and 9 instead of 6 and 7... few others complaining about it on the forums
[06:59] <MasterTsunami> well, i've never gotten the mouse numbering; there just seems to be too much variance by distribution, mouse, etc.
[06:59] <psusi> I don't get why it would change from release to release
[06:59] <psusi> the thing only HAS 7 buttons... even says so in xorg.conf... so why on earth does xorg think I'm pressing buttons 8 and 9?  heh
[07:02] <MasterTsunami> lol
[07:02] <psusi> oh well, a little xmodmap trickery fixes it...
[07:04] <Burglaptop> psusi: you filed a bug?  Should I mention an annoying bug in Dapper here, or just register it?
[07:58] <Burglaptop> method: just file it
[07:58] <method> Burglaptop, will do.
[07:58] <Burglaptop> method: unless you think it needs a great deal of dicussion regarding the solution
[07:59] <method> No, I thought it might be trivial.
[07:59] <method> But annoying.
[10:41] <Treenaks> jdub: http://muttscomics.com/art/images/daily/121305.gif
[11:02] <tuhl> as far I have seen dbus migration is completed
[11:02] <tuhl> when will we get the new gnome packages?
[02:24] <zakame> evening devs :)
[03:25] <tepsipakki> how come there is no libnspr4_1.7.12-1ubuntu2 for i386, only for amd64?
[03:25] <tepsipakki> mozilla isn't installable because of this (dapper)
[03:26] <zakame> hm, 'coz it's not built yet? lemme check the buildLogs
[03:26] <tepsipakki> it's old..
[03:27] <tepsipakki> amd64-version built a month ago ;)
[03:28] <zakame> hm other reasons then ;)
[05:02] <tuhl> hi - when will we see the new dbus 0.6 GNOME packages?
[05:03] <jsgotangco> its being done
[05:04] <ogra_ibook> already there
[05:08] <tuhl> ok thanks
[05:47] <tuhl> after an update to the latest package in depper my applicaiotn menu does not contain any entries
[05:47] <ogra> killall gam_server
[05:48] <tuhl> it only blinks very short with displaying all entries and contains no entry after taht
[05:49] <ogra> tuhl, try the above command
[05:49] <tuhl> ogra: now it works
[05:50] <tuhl> what is the reason for that? wrong starting order?
[05:50] <tuhl> gnome-power manager crashes aswell
[05:50] <ogra> nope, its a bug in gamin
[05:51] <ogra> will be fixed eventually during dapper development
[05:51] <ogra> the fun of a devel release :)
[05:51] <tuhl> what about gnome-power-manager?
[05:51] <Lathiat> might be a dbus thing?
[05:52] <Lathiat> hrm no 0.6 yet, maybe not
[05:52] <tuhl> cupsd does not start anymore aswell
[05:53] <ogra> g-p-m is running flawlwee on my amd64 lappie and the ibook i have ... whats your issue ?
[05:53] <tuhl> The Application "gnome-power-manager" has quit unexpectedly.
[05:54] <Lathiat> try starting it on a konsole and see what kind of messages it spits out
[05:55] <ogra> or start it in a termial if you dont use the k prefixed apps :P
[05:55] <tuhl>  gnome-power-manager
[05:55] <tuhl> /usr/bin/gnome-power-manager(5836): libnotify: Error connecting to session bus: Unable to determine the address of the message bus
[05:55] <tuhl> ** ERROR **: Cannot initialise libnotify!
[05:55] <tuhl> aborting...
[05:56] <ogra> your libinotify is outdated or your g-p-m binary isnt up to date ...
[05:56] <Lathiat> ogra: hahaha
[05:56] <Lathiat> i said konsole without thinking about it
[05:56] <Lathiat> signs im truely lost ;p
[05:56] <ogra> heh
[05:57] <ogra> tuhl, it should work fine with all apps up to date, look whats outdated
[05:58] <tuhl> g-p-m is 0.1.2-2
[05:59] <tuhl> libnotofy 0.2.2-1ubuntu1
[06:00] <tuhl> no further updates available vi snaptic
[06:00] <tuhl> synaptic
[06:04] <tuhl> ogra: any ideas?
[06:04] <ogra> not really
[06:05] <ogra> as i said, its all running fine here
[06:05] <tuhl> what might be wrong with cupssys?
[06:51] <Robot101> meh
[06:52] <Robot101> I got udev from breezy, it made me devices in /dev/dvb/ once
[06:52] <Robot101> s/breezy/dapper/
[06:52] <Robot101> now it only makes the /dev/dvb0.dvr0 ones
[07:00] <sivang> hi Robot101
[07:01] <Robot101> hola
[07:02] <sivang> Robot101: Hola! :-) Can I ask you something on #dbus?
[07:02] <Robot101> sure
[08:40] <zyga> evening :)
[08:44] <sivang> evening zyga
[08:50] <floam> BenC: should I bother reporting my unsuccess with sata_via's ATAPI support upstream?
[09:20] <BenC> floam: yeah
[09:37] <floam> BenC: ok
[09:37] <floam> I was sort of hoping it was something Ubuntu was doing wrong, but it seems not so now
[09:38] <floam> googling shows people on SuSE, Gentoo with the same thing on sata_via
[11:27] <\sh> Burgwork: no problem with wine
[11:27] <\sh> brb


[00:02] <doko> slangasek, accepted libverto, do you want to delay promotion? otoh krb5 won't be built with it
[00:40] <slangasek> doko: I have no reason for or against delaying promotion
[00:40] <infinity> slangasek: If we only have one "port" at this point, I'd argue that we should move both armhf and powerpc (for the britney stuff), and do away with the distinction.
[00:40] <infinity> slangasek: But yeah, maybe waiting on libreoffice to not vomit all over the report would be nice.
[00:41] <slangasek> well, even if powerpc is the only port, if there *is* a difference in who's responsible for it I think the distinction ought to be kept
[00:41] <slangasek> especially since powerpc is also seemingly never at 0
[00:42] <infinity> slangasek: ppc was at zero until very recently, to be fair.
[00:42] <slangasek> ah
[00:42] <infinity> slangasek: And, I dunno.  Having it alone on another report leads to it being ignored.  It's a bit of a catch-22.
[00:42] <infinity> "Oh look, no one fixes problems with it, let's hide them, so no one notices there are problems to fix."
[00:42]  * infinity shrugs.
[00:43] <slangasek> well, I don't feel strongly either way
[00:43] <infinity> This has nothing to do, of course, with the mirroring distinction, or the "official support" tag in LP, just for the britney reports, I think it's not worth the separation.
[00:43] <slangasek> the plusoners may have more relevant opinions here
[00:44] <infinity> I think it made more sense when -ports was more than half the arches we had.
[00:44] <infinity> Now it's.. One.
[00:44] <doko> slangasek, either the third buildd appears or we should drop powerpc. could you escalate the ticket?
[00:44] <infinity> (And we list it on, say, the ftbfs reports and most of our home-grown archive reports)
[00:45] <slangasek> doko: what ticket is this?
[00:46] <doko> slangasek, infinity knows the number, I need to search ...
[00:47] <infinity> 48569
[00:48] <slangasek> ta
[00:48] <slangasek> I won't necessarily escalate it before I know what else is in lamont's queue ahead of it, however
[00:53] <doko> slangasek, and here is bug #907126 to reduce the build load as well
[00:53] <ubot4> Launchpad bug 907126 in launchpad "allow exclusion of powerpc builds from PPA's (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/907126
[00:55] <infinity> That's only for non-virt anyway.
[00:55] <infinity> Which people are meant to be careful with.
[00:55] <infinity> (In theory)
[00:55] <doko> practice beats theory
[00:55] <infinity> Heh.
[00:56] <infinity> Still, the third machine would make things fine.
[00:56] <infinity> Given that PPC always catches up, just sometimes get a bit backlogged.
[00:56] <infinity> One more box should make it happy.
[00:56] <infinity> And once I finish the livefs-in-soyuz thing, we get sulfur as an lp-buildd too.
[00:56] <doko> yes, but it does have an impact on workflow. and things like linaro-overlays have priority on the buildds
[00:57] <infinity> I might also cut build time when I'm rooting around in lp-buildd too.
[00:57] <lamont> slangasek: that ticket needs stakeholder escalation if you want it anytime soon... 'twas #460 in the queue earlier today (and it's not just lamont's queue, thanks)
[00:58] <infinity> We always meant to do something with the "uninstalling build-deps failed" return code from sbuild, but we never did.  So, given that no one cares anyway, we may as well skip the uninstall step.
[00:58] <infinity> Which shaves a ton of time off every build.
[01:00] <doko> slangasek, still see libev in component-mismatches
[01:01] <slangasek> doko: I don't - reload?
[01:01] <doko> ohh, not anymore. libverto promoted
[01:03] <doko> have to get used to the 30min intervals
[01:07]  * doko watches Riddell's kde mess