[01:03] <thumper> davecheney: I'm looking at the peergrouper tests, but they now seem to pass when run individually, but fail when I run all juju tests
[01:03] <thumper> davecheney: I'm expecting it is impacted by load
[01:03] <thumper> davecheney: using your stress.sh script
[01:03] <thumper> but I'm needing something to stress either cpu or disk
[01:03] <thumper> do you have something?
[01:04] <thumper> wallyworld: we need to chat, re: simplestreams and lxd
[01:04] <wallyworld> "we need to talk"
[01:04] <wallyworld> i hate those 4 words
[01:05] <thumper> "please come to the office?"
[01:05] <wallyworld> thumper: did you want to talk now?
[01:05] <thumper> today
[01:05] <thumper> not necessarily now
[01:05] <wallyworld> thumper: ok, give me 15?
[01:05] <thumper> sure, np
[01:33] <wallyworld> thumper: talk now?
[01:33] <thumper> 1:1?
[02:28] <thumper> ugh
[02:28] <thumper> I have found the race in the peergrouper
[02:33] <davecheney> thumper: ??
[02:33] <davecheney> do tell
[02:34] <thumper> there are timing issues between the various go routines it starts up
[02:34] <davecheney> yup, so when you run go est ./...
[02:34] <davecheney> you have 4/8 other test jobs running at one time
[02:34] <davecheney> timing goes off
[02:34] <thumper> sometimes under heavy load, the peer grouper will attempt to determine the leader before it realises it has any machines
[02:35] <thumper> on successful runs, the machine watchers have fired before the other change
[02:35] <thumper> so it knows about the machines
[02:35] <thumper> on unsuccessful runs, it doesn't
[02:35] <thumper> so all the machines are "extra"
[02:35] <thumper> and have nil vote, so fail
[02:38] <thumper> I'm now attempting to work out the best place to sync the workers...
[02:38] <thumper> and best way how to...
[02:42] <thumper> uurrgghh
[02:42] <thumper> pretty sure that's a bit bollocks
[02:42] <thumper> davecheney: using a *machine as a key in a map?
[02:46] <davecheney> could be reasonable
[02:46] <davecheney> asumuing that nobody every creates a machine
[02:47] <davecheney> which could be a problem
[03:06] <thumper> shit
[03:06] <thumper> I can't work out how to sync these things
[03:06] <thumper> davecheney: got a few minutes?
[04:21] <davecheney> thumper: hey
[04:22] <davecheney> sorry, i was at the shops
[04:22] <davecheney> still there ?
[04:22] <thumper> yeah, but sent an email
[04:22] <thumper> I've given up on the peergrouper
[04:22] <thumper> it is a big pile of assumptions I don't understand
[04:22] <davecheney> \o/
[04:22] <davecheney> no
[04:22] <davecheney>  /o\
[04:23] <davecheney> i sounds like it needs more synchornisation
[04:23] <davecheney> if parts of the peergrouper assume something
[04:23] <thumper> I added what I thought would be enough
[04:23] <thumper> but no
[04:23] <davecheney> that needs to be replaced with expiliit coordination
[04:23] <thumper> yes, I agree with that last statement
[04:23] <davecheney> the worrying part is i think we can assume it will fail ~100% of the time in the field
[04:23] <davecheney> given it only just passes under controlled conditions
[04:24] <davecheney> this should proibably be a build blocker
[04:24] <thumper> the big problem as best as I can tell, is that it assumes that whenever the timer goes off for it to update itself, it assumes it knows the current state of the machines
[04:24] <thumper> which it does not
[04:24] <davecheney> wrooooong
[04:24] <davecheney> that's impossible
[04:24] <thumper> because those changes come in asyncronously
[04:25] <thumper> and it isn't querying
[04:25] <davecheney>  /me facepalm
[04:25] <thumper> I think that what it should do, is explicitly query all machines at the point of trying to decide
[04:25] <thumper> and not rely on just change notifications
[04:26] <davecheney> i think it's worse than that
[04:26] <davecheney> you cannot query a machine
[04:26] <davecheney> then do something with that information
[04:26] <davecheney> an unlimited amount of time can pass between statements
[04:26] <davecheney> any information you retrieve has to be assumed to be stale
[04:26] <thumper> well, in practice, it isn't infinite
[04:26] <davecheney> you have a distributed locking problem
[04:26] <thumper> but it certainly isn't zero
[04:27] <davecheney> s/infinite/unbounded
[04:27] <thumper> I think that for any point in time, it should ask for the current state of the machines it cares about, and use that consistent information to make the decision
[04:27] <thumper> to the best of its ability
[04:27] <thumper> rather than the inconsistent picture it currently has
[04:28] <thumper> but I have no more fucks to give
[04:29] <davecheney> is there a way to query the state of all machines atomically
[04:29] <davecheney> or is it N+1 style ?
[04:29] <thumper> yes, I belive there is an API call to get the machine info
[04:29] <thumper> if there isn't it is easy to add one
[04:30] <thumper> as atomically as mongo gives us
[04:30] <thumper> anyway
[04:30] <thumper> dirty reads and all that :)
[04:31] <davecheney> so, this is going to work 99% of the time
[04:31] <davecheney> except the time when it fails because everyuthing is going up and down like a yoyo
[04:31] <davecheney> in the 99% case, you don't need atomics or any of that jazz 'cos it's approximately steady state
[04:32] <davecheney> in the 1% case, when we _really_ need it towkr
[04:32] <davecheney> to work
[04:32] <davecheney> it's not going to
[04:32] <davecheney> at all
[04:32] <davecheney> this is a poor outcome
[04:33] <thumper> heh
[04:33]  * thumper nods
[04:35] <thumper> davecheney: the problem is, as I see it, that any server under load, as it probably will be at startup, the peergrouper will fail the first time through its loop, and get restarted
[04:35] <thumper> eventually it'll probably get settled
[04:35] <thumper> but geez
[04:35] <thumper> how not to do something
[04:37] <davecheney> yeah, that's what I was grasping at
[04:37] <davecheney> under steady state, it'll work just fine
[04:37] <davecheney> which is useless
[04:37] <davecheney> and under load, it'll freak out
[04:37] <davecheney> which is useless
[04:37] <davecheney> hmmm
[04:45]  * thumper is done
[04:45] <thumper> laters
[05:44] <wallyworld> axw_: if you have time at any point, could you take a look at http://reviews.vapour.ws/r/3046/ and http://reviews.vapour.ws/r/3104 for me? not urgent, just if/when you have some time
[05:45] <axw_> wallyworld: ok, probably not till later on
[05:45] <wallyworld> np, no rush
[05:45] <axw_> just wrapping up azure changes to support legacy
[05:45] <wallyworld> awesome, can definitely wait till after that
[08:24] <axw_> wallyworld: are you around?
[08:27] <axw_> wallyworld: never mind, self approving my merge of master into azure-arm-provider
[08:28] <axw_> mgz_: are you able to add "azure-arm-provider" as a feature branch to CI?
[08:29] <axw_> mgz_: or is it automatic...?
[08:38] <wallyworld> axw_: it's automatic, but unless yu ask, it won't get to the top of the queue
[08:38] <wallyworld> axw_: sory, was eating
[08:44] <axw_> wallyworld: thanks
[09:07] <axw_> wallyworld: FYI, PR to merge the azure-arm provider into the feature branch: https://github.com/juju/juju/pull/3701
[09:07] <axw_> wallyworld: warning, it's extremely large
[09:11] <wallyworld> axw_: ty, will look
[09:29] <mwhudson> oh, not that arm
[09:34] <frobware> dimitern, ping 1:1?
[09:34] <dimitern> frobware, hey, oops - omw
[10:00] <dimitern> voidspace, jam, fwereade, dooferlad, standup?
[10:00] <voidspace> omw
[10:31] <dimitern> jamespage, gnuoy, juju/os call?
[10:31] <jamespage> dimitern, 2 mins
[10:32] <dimitern> np
[11:15] <frobware> dimitern, I moved the openstack meeting to 16:30, but that may be too late for you.
[11:24] <dimitern> frobware, it's fine for me as scheduled
[11:24] <frobware> dimitern, thanks & appreciated
[11:31] <dimitern> voidspace, reviewed
[11:56] <frobware> dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/3102/
[11:56] <dimitern> frobware, looking
[12:07] <dimitern> frobware, btw updated http://reviews.vapour.ws/r/3088/ to fix the mac address issue with address-allocation enabled for kvm
[12:07] <dimitern> and tested it to work
[12:07] <frobware> dimitern, just saw it. checking my change against voidspace's change at the moment.
[12:11] <dimitern> frobware, hmm, so you decided to go for the full mile there - always using addresses instead of hostnames if possible, even in status
[12:12] <frobware> dimitern, if there's an address that is not resolvable you cannot connect to the machine.
[12:12] <dimitern> (rather than just for mongo peer host/ports)
[12:12] <frobware> dimitern, we're fixing the wrong bug, IMO. We need to fix maas.
[12:13] <frobware> dimitern, see the commit message for why you need to drop unresolvable names
[12:13] <dimitern> frobware, yeah, fair enough
[12:14] <dimitern> frobware, there is however a ResolveOrDropHostnames that does almost the same thing in hostport.go
[12:14] <frobware> dimitern, the trouble is that resolves
[12:15] <frobware> dimitern, let's chat instead. HO?
[12:15] <dimitern> frobware, ok, I'm joining the standup one
[12:53] <frobware> dimitern, voidspace, dooferlad: "maas-spaces" feature branch created
[12:53] <dimitern> frobware, awesome! let's get cranking :)
[12:58] <frobware> dimitern, T-3 weeks...
[13:06] <dimitern> frobware, yeah, it's not a lot, is it :/
[14:31] <mup> Bug #1514857 opened: cannot use version.Current (type version.Number) as type version.Binary <juju-core:Incomplete> <juju-core lxd-provider:Triaged> <https://launchpad.net/bugs/1514857>
[14:34] <mup> Bug #1514857 changed: cannot use version.Current (type version.Number) as type version.Binary <juju-core:Incomplete> <juju-core lxd-provider:Triaged> <https://launchpad.net/bugs/1514857>
[14:37] <mup> Bug #1514857 opened: cannot use version.Current (type version.Number) as type version.Binary <juju-core:Incomplete> <juju-core lxd-provider:Triaged> <https://launchpad.net/bugs/1514857>
[14:49] <dimitern> whaaaat?!
[14:49] <dimitern> damn...why did I spend almost a week fixing 1.24
[14:49] <dimitern> no 1.24.8 :(
[15:04] <voidspace> dimitern: yeah, shame
[15:04] <voidspace> dimitern: and there won't be a version of 1.24 with containers and "ignore-machine-addresses" working
[15:05] <dimitern> voidspace, if 1.24 dies quickly, that won't be a big deal :)
[15:05] <voidspace> dimitern: hopefully
[15:19] <mup> Bug #1502306 changed: cannot find package gopkg.in/yaml.v2 <blocker> <ci> <regression> <juju-core:Invalid> <juju-core lxd-provider:Fix Released> <https://launchpad.net/bugs/1502306>
[15:19] <mup> Bug #1514874 opened: Invalid entity name or password error, causes Juju to uninstall <sts> <juju-core:New> <https://launchpad.net/bugs/1514874>
[15:19] <mup> Bug #1514877 opened: Env not found immediately after bootstrap <blocker> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1514877>
[15:21] <katco> fwereade: hey ran into bug 1503039 last friday while writing a reactive charm. any reason not to set that env. variable all the time?
[15:21] <mup> Bug #1503039: JUJU_HOOK_NAME does not get set <charms> <docs> <hooks> <juju-core:Triaged> <https://launchpad.net/bugs/1503039>
[15:22] <mup> Bug #1514874 changed: Invalid entity name or password error, causes Juju to uninstall <sts> <juju-core:New> <https://launchpad.net/bugs/1514874>
[15:22] <mup> Bug #1514877 changed: Env not found immediately after bootstrap <blocker> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1514877>
[15:22] <mup> Bug #1502306 opened: cannot find package gopkg.in/yaml.v2 <blocker> <ci> <regression> <juju-core:Invalid> <juju-core lxd-provider:Fix Released> <https://launchpad.net/bugs/1502306>
[15:25] <mup> Bug #1502306 changed: cannot find package gopkg.in/yaml.v2 <blocker> <ci> <regression> <juju-core:Invalid> <juju-core lxd-provider:Fix Released> <https://launchpad.net/bugs/1502306>
[15:25] <mup> Bug #1514874 opened: Invalid entity name or password error, causes Juju to uninstall <sts> <juju-core:New> <https://launchpad.net/bugs/1514874>
[15:25] <mup> Bug #1514877 opened: Env not found immediately after bootstrap <blocker> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1514877>
[15:26] <fwereade> katco, nah, go ahead and set it always
[15:27] <fwereade> katco, it was originally just for debug-hooks, when you wouldn't know
[15:27] <fwereade> katco, and you *can* always look at argv[0]
[15:27] <fwereade> katco, but better just to be consistent across the board
[15:27] <katco> fwereade: kk ty just wanted to check
[15:28] <fwereade> katco, cheers
[15:28]  * fwereade gtg out, back maybe rather later
[15:28]  * katco waves
[15:31] <mup> Bug #1514874 changed: Invalid entity name or password error, causes Juju to uninstall <sts> <juju-core:New> <https://launchpad.net/bugs/1514874>
[15:31] <mup> Bug #1514877 changed: Env not found immediately after bootstrap <blocker> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1514877>
[15:31] <mup> Bug #1502306 opened: cannot find package gopkg.in/yaml.v2 <blocker> <ci> <regression> <juju-core:Invalid> <juju-core lxd-provider:Fix Released> <https://launchpad.net/bugs/1502306>
[15:33] <katco> ericsnow: did you use git mv for your cleanup patch?
[15:34] <ericsnow> katco: yep
[15:34] <ericsnow> katco: the GH diff is a little easier to follow
[15:34] <mup> Bug #1502306 changed: cannot find package gopkg.in/yaml.v2 <blocker> <ci> <regression> <juju-core:Invalid> <juju-core lxd-provider:Fix Released> <https://launchpad.net/bugs/1502306>
[15:34] <mup> Bug #1514874 opened: Invalid entity name or password error, causes Juju to uninstall <sts> <juju-core:New> <https://launchpad.net/bugs/1514874>
[15:34] <mup> Bug #1514877 opened: Env not found immediately after bootstrap <blocker> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1514877>
[15:34] <katco> ericsnow: i wish RB would detect that and show just the diffs instead of all green
[15:35] <ericsnow> katco: yep, me too
[15:35] <perrito666> ahh RB the source of most of our wishes :p
[15:38] <marcoceppi_> alexisb: is anyone working on this? https://bugs.launchpad.net/juju-core/+bug/1488139 will it actually make it to alpha2?
[15:38] <mup> Bug #1488139: juju should add nodes IPs to no-proxy list <network> <proxy> <juju-core:Triaged> <https://launchpad.net/bugs/1488139>
[15:38] <alexisb> cherylj, ^^^
[15:59] <voidspace> dimitern: ping
[16:00] <voidspace> dimitern: for "pick provider first" for addresses the upgrade step is AddPreferredAddressesToMachine
[16:00] <voidspace> dimitern: that's the same upgrade function used to add preferred addresses to machines in the first place
[16:00] <dooferlad> pro tip: if you uninstall maas, make sure that you get rid of maas-dhcp
[16:00] <voidspace> dimitern: 1.25 already calls this as an upgrade step, so I assert that the backport to 1.25 doesn't need to add a new upgrade step...
[16:00] <voidspace> dooferlad: :-)
[16:00] <dooferlad> two DHCP servers on the same network results in such fun :-(
[16:00] <voidspace> dooferlad: there are about seven billion maas packages
[16:01] <dooferlad> voidspace: indeed. I think it didn't get maas-dhcp when I uninstalled because by default it isn't installed with the maas metapackage
[16:19] <dimitern> voidspace, that sounds good
[16:33] <perrito666> well, in a whole new way of creepyness, google now adds the flight to your personal calendar when you get your plane tickets via email
[16:34] <perrito666> even though, the email was not the usual plain text reservation
[16:41] <marcoceppi_> we need help, our websocket connectino keeps dying during a deployment tanking charm testing for power8.
[16:41] <marcoceppi_> these are the last few lines of the log
[16:42] <marcoceppi_> http://paste.ubuntu.com/13216926/
[16:42] <marcoceppi_> INFO juju.rpc server.go:328 error closing codec: EOF
[16:42] <marcoceppi_> what does that mean^?
[16:48] <natefinch> marcoceppi_: I think in this case, EOF should be treated like "not an error"
[16:48] <natefinch> marcoceppi_: yeah, looking at the code, that just means it probably was already closed
[16:51] <marcoceppi_> well, we've been wrestling with this for a few days now, and we're suck in that every time after a few mins, the websocket abruptly closes and tanks the python websocket library, which kills python-jujuclient, which kills amulet
[16:51] <marcoceppi_> so we're unable to run charm tests on our power8 maas
[16:52] <marcoceppi_> I'm prepared to provide anyone willing to help logs or whatever else is needed. I've exhausted my troubleshooting
[16:54] <natefinch> alexisb: ^
[16:58] <alexisb> marcoceppi_, is this related to the bug you pointed at earlier?
[16:59] <marcoceppi_> alexisb: it's a machine running behind the great canonical firewall, we've got some things punched through and the rest we're using an http proxy. It seems this breakage always happens around the same time so we're removing as much of the proxy to test further
[17:00] <marcoceppi_> alexisb: long story short, not sure if this is related, we've manually no-proxy listed /everything/ for the environment so while that bug will help, it's not likely going to resolve whatever we're hitting
[17:07] <alexisb> so marcoceppi_ do you have a system we can triage?
[17:08] <marcoceppi_> alexisb: yes, but it's behind the vpn and some special grouping, though I may be able to get someone access if they aren't in that group
[17:08] <marcoceppi_> alexisb: ignore, yes we have a system to triage
[17:09] <alexisb> katco, can you get someone on your team to work w/ marcoceppi_ please
[17:09] <alexisb> marcoceppi_, we will need to make sure there is a bug open to track status
[17:10] <katco> alexisb: yep
[17:10] <alexisb> thanks
[17:10] <katco> marcoceppi_: is there already a bug for this?
[17:10] <marcoceppi_> alexisb: I'll file a bug though I'm not sure the problem name
[17:10] <marcoceppi_> we're not even able to diagnose the source of the problem
[17:11] <katco> marcoceppi_: that's ok, we can iterate on the title :)
[17:12] <marcoceppi_> katco: https://bugs.launchpad.net/juju-core/+bug/1514922
[17:12] <mup> Bug #1514922: Deploying to maas ppc64le with proxies kills websocket <juju-core:New> <https://launchpad.net/bugs/1514922>
[17:12] <katco> marcoceppi_: can you also update the bug with the details of what you've been discussing here, and any relevant logs?
[17:13] <katco> marcoceppi_: (ty for filing a bug)
[17:14] <rick_h__> urulama: frankban ^ did we see something with the websockets closing on us?
[17:14] <rick_h__> urulama: frankban please see if this souds familiar at all and with our 'ping' and such
[17:14] <urulama> looking
[17:15] <urulama> well, it was through apache ... not sure what is meant by proxy in the bug? apache reverseproxy?
[17:15] <marcoceppi_> katco: updated
[17:15] <katco> marcoceppi_: ty sir
[17:16] <frankban> rick_h__, urulama it does not look familiar
[17:16] <rick_h__> frankban: ok, thanks
[17:17] <marcoceppi_> fwiw, I can connect and deploy just fine to the environment, it's when we keep a persistent websocket connection open that it tanks after a few mins of websocketing, or whatever websockets do
[17:17] <marcoceppi_> this build script works without issue on all other testing substrates
[17:18] <katco> marcoceppi_: so it's *just* ppc?
[17:18] <marcoceppi_> katco: well it's the only maas we haver access to
[17:18] <marcoceppi_> it just so happens to be ppc64le
[17:18] <katco> marcoceppi_: gotcha... what do you mean when you say it works on all other testing substrates?
[17:19] <marcoceppi_> katco: gce, aws, openstack, etc
[17:19] <marcoceppi_> katco: this job runs all our other charm testing substrates, which are public clouds and local
[17:19] <katco> marcoceppi_: ah ok
[17:20] <natefinch> it's unfortunate that our only MAAS environment is also on a wacky architecture
[17:20] <marcoceppi_> well, it's not the only maas environment for testing, juju ci has a few they use. It's the only maas environ we have for charm testing and it's maas because no public cloud have power8 yet
[17:21] <natefinch> marcoceppi_: it's a shame it's the only MAAS environment *you* have for testing, then :)
[17:21] <marcoceppi_> hah, yes.
[17:25] <mup> Bug #1514922 opened: Deploying to maas ppc64le with proxies kills websocket <juju-core:New> <https://launchpad.net/bugs/1514922>
[17:44] <marcoceppi_> katco: this seems to be related to http-proxy juju environment stuff. We remove all but the apt-*-proxy keys and the websocket didn't die
[17:45] <katco> marcoceppi_: hm ok thanks that helps
[17:55] <mup> Bug #1514616 opened: juju stateserver does not obtain updates to availability zones <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1514616>
[17:59] <marcoceppi_> katco: it appears setting apt-http-proxy and other env variables does not do what is expected
[18:01] <marcoceppi_> hum
[18:01] <marcoceppi_> nvm
[18:08] <marcoceppi_> katco alexisb this isn't a priority for today, there are too many sharp sticks in our eyes to get a clear enough vision on this
[18:09] <marcoceppi_> for today anymore*
[18:09] <marcoceppi_> but it's very much a problem we will need fixed for 1.26
[18:09] <marcoceppi_> If getting on a hang out to explain this more helps, lmk
[18:24] <cmars> perrito666, can I get a review of http://reviews.vapour.ws/r/3041/ ? it's a bugfix for LP:#1511717 backported to 1.25
[18:24] <mup> Bug #1511717: Incompatible cookie format change <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cmars> <juju-core 1.25:In Progress by cmars> <juju-core 1.26:Fix Committed by cmars> <https://launchpad.net/bugs/1511717>
[18:31] <katco> marcoceppi_: just lmk when you get a better idea of what's going on
[18:32] <marcoceppi_> katco: we have no idea what's going on. We just know it's not getting resolved in 2 hours time
[18:34] <cherylj> ericsnow: ping?
[18:34] <ericsnow> cherylj: hey
[18:34] <cherylj> hey ericsnow :)  got a question for you about systemd
[18:34] <ericsnow> cherylj: sure
[18:35] <cherylj> ericsnow: was there a reason you linked the service files, rather than copying them over?  just out of curiosity
[18:36] <ericsnow> cherylj: was trying to stick just to the systemd API rather than copying any files
[18:36] <cherylj> ericsnow: okay, I was just wondering.  I've seen 2 bugs of people doing things we wouldn't expect that causes problems with just using links.
[18:37] <cherylj> I'm okay with making those special cases work around juju :)
[18:37] <ericsnow> cherylj: sounds good
[18:37] <cherylj> thanks!
[18:37] <ericsnow> cherylj: np :)
[18:55] <perrito666> cmars: sure you can
[18:55] <perrito666> sorry was afk for a moment
[18:58] <perrito666> cmars: shipit
[19:12] <cmars> perrito666, thanks!
[20:56] <natefinch> and.... master is blocked, dangit
[21:02] <natefinch> ericsnow, wwitzel3: can you guys review http://reviews.vapour.ws/r/3103/ real quick?  It's best to look at the PR (https://github.com/juju/juju/pull/3698) rather than reviewboard, because 99% of the code has already been reviewed, only a few small tweaks need to be reviewed (everything but the cherry-picked merge).
[21:04] <ericsnow> natefinch: looking
[21:06] <natefinch> I just made the worker into a singular worker and updated a test to check that.  The last commit is really just redoing work in the first commit, because I cherry-picked the merge afterward (a result of me doing things in the wrong order, but seemed like not worth the trouble to redo it in the right order)
[21:06] <ericsnow> natefinch: LGTM
[21:07] <natefinch> ericsnow: thanks :)
[21:37] <natefinch> katco, ericsnow: ug, looking at the failures on the lxd branch, I think it's just that some stuff changed out from underneath us... but when I rebase, I get 332 merge conflicts :/
[21:38] <ericsnow> natefinch: the patch I have up for review fixes most of those errors
[21:38] <ericsnow> natefinch: http://reviews.vapour.ws/r/3101/
[21:38] <katco> natefinch: we rebased off the last bless of master
[21:38] <katco> natefinch: i.e. we're intentionally behind master
[21:39] <natefinch> ahh
[21:43] <katco> ericsnow: the patch you have up fixes the things that cursed our branch?
[21:43] <ericsnow> katco: several of them
[21:44] <ericsnow> katco: oh
[21:44] <natefinch> the one I was looking at was this one: https://bugs.launchpad.net/juju-core/+bug/1514857
[21:44] <ericsnow> katco: not that cursed our branch
[21:44] <mup> Bug #1514857: cannot use version.Current (type version.Number) as type version.Binary <blocker> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core lxd-provider:Triaged> <https://launchpad.net/bugs/1514857>
[21:44] <ericsnow> katco: rather, the Wily test failures (which will curse our branch soon enough)
[21:45] <katco> ericsnow: ah ok. natefinch looks like you're still good to look at the curses
[21:45] <natefinch> katco: ok
[21:50] <natefinch> my problem is figuring out why there's a compile issue. Seems like we got half of a change or something
[21:54] <ericsnow> natefinch: looks like katco didn't use the merge bot :P
[21:55] <katco> ericsnow: i did not. is it causing problems?
[21:55] <ericsnow> katco: yeah, the merge broke some code
[21:55] <ericsnow> katco: the merge bot would have caught it
[21:57] <katco> ericsnow: oh oops :( sorry natefinch
[21:57] <katco> ericsnow: natefinch: the idea was to get a bless anyway, so skipped the bot. shouldn't have done that
[21:59] <natefinch> katco, ericsnow: http://reviews.vapour.ws/r/3110/
[22:00] <ericsnow> natefinch: LGTM
[22:01] <natefinch> I gotta run, it's time o'clock, as my 2 year old would say.   But I can land this later, or someone else can $$merge$$ as they wish
[22:02] <natefinch> everything compiles now.. . tehre's some maas timeouts, but I'm guessing those are spurious.
[22:02] <natefinch-afk> back later.  have a lot of work time left for today.
[22:20] <mup> Bug #1515016 opened: action argument with : space is incorrectly interpreted as json <juju-core:New> <https://launchpad.net/bugs/1515016>
[22:37] <katco> ericsnow: wwitzel3: natefinch-afk: please don't forget to update your bugs with status for the day
[22:37] <ericsnow> katco: will do
[22:38] <wwitzel3> katco: rgr
[23:15] <wallyworld> axw_: perrito666: give me a minute
[23:15] <anastasiamac> wallyworld: k


[02:54] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop amd64 [Focal 20.04.2] has been updated (20210204)
[10:00] <RikMills> santa_: looks ok now
[10:01] <cvtsi2sd> Hello, is there anyone who knows how the 56-kubuntu-noto.conf fontconfig settings file got into kubuntu-settings-desktop in first place? IOW, what problem it was meant to solve?
[10:02] <cvtsi2sd> Because it's causing considerable damage, especially on Firefox
[10:03] <cvtsi2sd> see https://askubuntu.com/q/1289600/208527, https://bugzilla.mozilla.org/show_bug.cgi?id=1645681, https://bugzilla.mozilla.org/show_bug.cgi?id=1481545, https://bugs.launchpad.net/ubuntu/+source/kubuntu-settings/+bug/1872800, https://bugs.launchpad.net/ubuntu/+source/kubuntu-settings/+bug/1872492
[10:05] <cvtsi2sd> I'm trying to draw attention to the issue, as unfortunately it's the classic problem where it's difficult to find/correlate information, because it isn't immediately obvious that "font rendering glitches in Firefox", "all-around uglyness on many fonts in UI" and "kubuntu-settings-desktop being installed" are immediately related
[10:21] <RikMills> !testers
[10:22] <RikMills> New spin of 20.04.2 :/
[12:07] <cvtsi2sd> hmm, from https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/kubuntu-settings/commit/desktop/etc/fonts/conf.avail/56-kubuntu-noto.conf?h=kubuntu_hirsute_archive&id=9ca4c58573bebf3d43634732bf56d06ed1737e48 it looks like RikMills is the man I'm looking for
[12:16] <RikMills> sadly no time to look. there are urgent release things at the moment
[12:17] <cvtsi2sd> given this breaks fonts for the last three releases IMO the prudent thing would be to just stop shipping the file immediately, and then maybe do a more thorough analysis; it's not like the rest of Ubuntu doesn't have fonts working without that file...
 (Photo, 1234x142) https://irc-attachments.kde.org/ruuGLl80/file_41260.jpg
 @DarinMiller not sure if the testers highlight on irc catches you on TG, so FYI ;)
[12:32] <mparillo> Darin: I paid attention to the restart time on the Encrypted Install, and I guess it was only a few seconds.
 oh, and kongress is now in hirsute. supports FOSDEM apparently
 https://kde.org/announcements/releases/2021-02-apps-update/
 apps 20.12.2 are building in proposed
[12:42] <mparillo> I'll take OEM next.
[12:59] <RikMills> mparillo: ty :)
[13:01] <BluesKaj> Howdy folks
 Testing the new spin now.  Live Boot and Entire disk  had no issues. And the long delay to remove media was gone (only 7 second wait).  Testing Manual Part.  next....
 I just encountered an installer "feature" that I have never noticed before:  The installer defaults to a guided resize  and auto selects a suggested hard drive.  Changing to use entire disk also changes the suggested hard drive.  I was not aware of this "feature" and though I initially verified the correct drive was  selected, I failed to re-verify after selecting the install to full drive. Thus,  I stomped on my Neon
[16:40] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop amd64 [Focal 20.04.2] has been marked as ready
 On a positive note, the 21.04 daily download is working great. :)
 @DarinMiller, Things are shaping up well :)


[15:09] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-clipman-plugin 1.6.2 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-clipman-plugin-1-6-2-released-tp60015.html (by Simon Steinbeiss)
[23:37] <Unit193> bluesabre: Oh, am I going for all releases?  Eg, new xfce4-taskmanager?


[00:00] <mwhudson> i'm thinking the linux kernel is probably a little ambitious for the moment...
[00:05] <RAOF> mwhudson: Banshee would work.  That's ~20Mb or so of git.  Or is that not medium enough?
[00:05] <mwhudson> RAOF: let's try it
[00:05] <mwhudson> RAOF: url me up?
[00:05] <RAOF> Also has the advantage that I know bzr-git successfully branches it.
[00:05] <RAOF> git://git.gnome.org/banshee
[00:06] <mwhudson> oh right, all the gnome imports
[00:06] <RAOF> There's _lots_ of them available :).  You don't want one of them?
[00:06] <RAOF> libdrm would be another one.
[00:07] <mwhudson> RAOF: no, i'd just forgotten
[00:09] <lifeless> mwhudson: linux should work well with dev6
[00:09] <mwhudson> lifeless: until --default-rich-root is dev6 or similar...
[00:09] <mwhudson> (actually i think it will import into 1.9-rich-root now)
[00:15] <lifeless> spiv: I'm a little worn on repeated 'cut a round trip off' day days
[00:15] <lifeless> spiv: I had wanted to pair today, but my desktop blew a sprocket on saturday
[00:15] <lifeless> spiv: so perhaps tomorrow?
[00:16] <spiv> lifeless: sure, tomorrow sounds good to me.
[00:16] <jonnydee1> hi :) I recently stumbled over the following bug and reported it: https://bugs.launchpad.net/bzr/+bug/370551  Is there a chance that a fix will make it in a 1.14 maintenance release, or in 1.15, at least?
[00:17] <jonnydee1> bazaar cannot handle files that were moved to unversioned directories. but this makes the auto-detect feature more or less useless (for me, at least)
[00:18] <lifeless> jonnydee1: thats a dupe actually
[00:18] <lifeless> jonnydee1: no, 1.14 won't get a fix; its not a regression. You can just 'bzr add' the new directory before you move files into it, to avoid the bug.
[00:20] <lifeless> bug 367628
[00:20] <lifeless> thats the root cause
[00:20] <jonnydee1> lifeless: I know I can add the directory. But I need auto-detection when I refactor code using an ide. and there it happens often enough that files are moved to newly created directories....
[00:20] <lifeless> jonnydee1: in your example you manually move a file to the unversioned dir first
[00:27] <jonnydee1> lifeless: and how do I recover from the stack trace if I occasionally got trapped by this bug? Will it suffice to 'bzr add' the unversioned directory, afterwards?
[00:27] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/367628 is the main bug for 'bzr mv foo unversioned/'
[00:27] <jonnydee1> The problem is that 'bzr st' does not work anymore, which makes it hard to figure out what directories are needed to be versioned...
[00:28] <jonnydee1> lifeless: ok, should I mark the other bug report as a duplicate?
[00:28] <lifeless> no
[00:28] <lifeless> it may be slightly different
[00:28] <lifeless> I'm going to note that in the bugs
[00:29] <lifeless> my browser just stopped working for a minute, doing that now
[00:29] <jonnydee1> ok, thank you, lifeless, for your help :)
[00:31] <lifeless> no problem
[00:34] <lifeless> poolie: http://igotgenes.blogspot.com/2009/04/how-symbolic-on-removing-symlinks-in.html
[00:35] <poolie> hm that's good i guess
[00:36] <poolie> wbn if somebody fixed the bugs though :)
[00:36] <pygi> lifeless, poolie : will be nice to see you at UDS :)
[00:39] <poolie> you too
[01:54] <mwhudson> spiv: wow, bug 250451 gets nastier and nastier
[01:54] <spiv> mwhudson: yeah
[01:54] <spiv> mwhudson: I suppose LP could monkeypatch sys.stdout to autocorrect that message ;)
[01:55] <mwhudson> spiv: we _should_ translate paths in some exceptions
[01:55] <mwhudson> but i don't think that will help here
[02:09] <rocky> ugh, how many times do i merge stuff from another branch, forget to commit, do a bunch of work, and realize now i have my merge changes all messed up with my new work
[02:09] <rocky> is there an easy way to fix that ? ^^
[02:12] <thumper> shelve?
[02:12] <rocky> i've done a bunch of work, shelve will take me all night :(
[02:13] <mwhudson> shelve, redo the merge, commit, unshelve
[02:13] <mwhudson> ?
[02:13] <rocky> oh you mean shelve everything ?
[02:18] <AfC> What's with the alternating '>' and '<' in the pretty display when communicating with a remote server?
[02:18] <spiv> AfC: traffic direction
[02:20] <mwhudson> rocky: right
[02:20] <mwhudson> rocky: you'll might have to fix some conflicts when you unmerge, but hopefully not too bad
[02:20] <mwhudson> s/unmerge/unshelve/
[02:22] <AfC> spiv: oh
[02:22] <AfC> Is there a way to turn off the progress bar and just have the textual information?
[02:23] <rocky> mwhudson: wow, conflicts are huge (like whole files)
[02:26] <spiv> AfC: not that I know of.
[02:27] <mwhudson> rocky: :(
[02:27] <rocky> actually it wasn't so bad
[02:27] <rocky> it was just one file like that and the fix was easy enough
[02:27] <rocky> so yeah i'm all set now. .. thanks mwhudson! :)
[02:28] <AfC> spiv: I recall we talked about that here a while back - I guess I need to file a bug for that.
[02:28] <mwhudson> rocky: np
[02:28] <rocky> mwhudson: although for what it's worth, after shelving my stuff i had to "revert" the bzr merge that wasn't being committed before i could start over
[02:29] <mwhudson> rocky: hm, that makes sense
[02:29]  * mwhudson wouldn't know how shelve interacts with pending merges, i guess it just ignores them
[02:30] <rocky> well, bzr doesn't know that something special has happened with shelve so bzr stat still shows the pending merge, just with no changes
[02:30] <rocky> and you can still commit the pending merge with no changes
[02:30] <rocky> but obviously you don't want to, so just rever it
[03:02] <exeoeoe> http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck
[03:11] <mwhudson> jelmer: are you going to be at uds?
[07:07] <vila> hi all
[08:04] <lifeless> signing off
[08:04] <lifeless> gnight
[08:08] <poolie> hello vila!
[08:09] <vila> good bight lifeless, hi poolie
[08:09] <vila> err night
[08:14] <poolie> vila, what are you working on next?
[08:14] <vila> bug #366107
[08:15] <vila> surprisingly, we can't handle servers which propose several auth schemes :-/
[08:16] <vila> then I'd like to refactor log tests and dig there, several bugs are hanging around since last Ian optimisations
[08:17] <vila> I'm also waiting for a review related to bug #355454 to finish fixing it
[08:22] <poolie> hm ok
[08:23] <poolie> 366107 sounds like a good thing to fix but i'm not so sure it's high priority
[08:23] <poolie> is it easy or already something you want to fix?
[08:24] <vila> poolie: should be easy once I enhance the related test servers and I'd like to fix it as not being able to handle server with multiple auth schemes is a bit embarassing :-}
[08:27] <poolie> ok
[08:27] <poolie> you probably know best
[08:28] <poolie> do you have an order of magnitude guess how long the log tests and fixes would take? like a week?
[08:30] <vila> surely less, it's first: refactoring existing ones that checks for particular revisions to avoid depend of the actual output format, then add new ones for the bugs I know of (mostly wrong selection of revisions)
[08:38] <vila> meh --coverage fails to recognize code run in threads :-/
[08:43] <spiv> vila: that's probably not too hard to fix
[08:43] <spiv> vila: add a call to threading.settrace in apply_coveraged in bzrlib/commands.py, probably
[08:47] <vila> spiv: works, great, thanks :)
[09:02] <mwhudson> vila: just in case you're curious, i'm adding support for multiple byte ranges to twisted's http server currently :)
[09:04] <vila> mwhudson: good, feel free to canibalize our http_server, there are some subtleties in parsing and validating the ranges requested
[09:05] <mwhudson> vila: no kidding
[09:05] <vila> :)
[09:07] <mwhudson> vila: twisted already had a pretty anal parser and handled the single-range case
[09:09] <vila> mwhudson: you may also want to have a look at lp:~vila/bzr/local-test-server for a quick way to validate your server against bzr
[09:57] <bialix> hi guys! anybody home?
[10:00] <bialix> I have a little question about English word "control" from "version control system". When you say "control" there you mean "management" or "check" or "watching"?
[10:02] <luks> I'd say management
[10:02] <bialix> hi luks
[10:02] <luks> hey
[10:02] <bialix> how are you?
[10:02] <luks> fine, thanks. you?
[10:02] <bialix> more or less
[10:03] <bialix> thanks for explanation
[10:03] <luks> well, that's just my opinion
[10:03] <bialix> my question raised because we have incorrect translation in Russian of this term
[10:03] <luks> and how I'd translate it to another language
[10:04] <bialix> I understand
[10:05] <bialix> translation in Russian is wrong because we have the word "control" here too, but it's false friend of translator
[10:05] <bialix> Russian control it's closer to "check"
[10:05] <luks> same here in slovak
[10:06] <bialix> :-)
[10:07] <bialix> I've started heavily using "daggy fixes" in my work
[10:07] <bialix> this very heavily influencing my style of work with VCS
[10:08] <luks> I don't think I could strictly follow that
[10:08] <luks> maybe for recent branches
[10:08] <luks> but definitely not for something old
[10:08] <bialix> well, in my case I need to maintain several branches in parallel, so it's work OK
[10:08] <bialix> and for old branches too
[10:08] <bialix> my mileage is different I suppose
[10:09] <luks> well, I'm a lazy person :)
[10:09] <bialix> me too, but daggy fixes make my life easier
[10:09] <bialix> because cherrypick in bzr sometimes painful
[10:10] <luks> the only feature I like in svn better
[10:10] <bialix> cherrypick?
[10:10] <luks> yep
[10:13] <bialix> IIUC this is inevitable downside of DAG-based systems
[10:14] <luks> exactly
[10:15] <jml> bialix: I'd say that the "control" part of VCS isn't terribly significant.
[10:15] <bialix> hi jml
[10:15] <bialix> jml: why not?
[10:15] <jml> bialix: "management" is close enough, I guess.
[10:16] <bialix> thanks
[10:16] <jml> bialix: but when I hear the phrase, I think "version $GENERIC_VERB $GENERIC_ABSTRACT_NOUN"
[10:16] <jml> version handler thing
[10:16] <bialix> :-)
[10:17] <bialix> ok, one more question: when you say "version" and "revision" -- what's difference?
[10:17] <bialix> VCS vs RCS
[10:17] <jml> not much.
[10:17] <jml> "version" has a connotation of "released version", I guess
[10:17] <bialix> version is more genric term?
[10:17] <jml> yeah.
[10:18] <jml> "revision" almost always refers to the result of a commit (in IT, anyway.)
[10:19] <bialix> I read "revision" as in "document revision"
[10:19] <jml> right, that's the broader sense
[10:19] <bialix> it's about editing the text, is not?
[10:19] <jml> a revision is what you get after you have revised something, usually a text.
[10:20] <bialix> i.e. when I fix some errors in the text?
[10:20] <jml> yeah.
[10:20] <bialix> or improve something?
[10:20] <bialix> thanks
[10:20] <bialix> the things much clearer now
[10:21] <bialix> it's so hard to translate VCS terms adequately
[10:21] <jml> I'll bet!
[10:21] <luks> doesn't russian have a commonly used equivalent?
[10:22] <bialix> that's the problem
[10:22] <bialix> we have some de0facto equivalent
[10:22] <bialix> de-facto
[10:22] <bialix> but sometimes they are represent svn-centric point of view
[10:22] <bialix> i.e. you have no pull/push in svn
[10:22] <davidstrauss> Revision is a bad term for VCS because it's colloquially used to mean a diff and the result of applying a diff.
[10:23] <luks> I think the the term applies to any vcs
[10:23] <bialix> davidstrauss: what will be better?
[10:23] <davidstrauss> bialix: commits should be called snapshots
[10:23] <luks> so if there were some manuals for csv or something, I'd use the term from there
[10:23] <luks> *cvs
[10:24] <davidstrauss> bialix: commits/revisions used to not be atomic, so you couldn't call them snapshots
[10:24] <bialix> luks: well, there is semi-official translation of svn
[10:24] <bialix> "svn book"
[10:24] <davidstrauss> bialix: but any modern vcs has atomic commits, so we ought to call them snapshots
[10:24] <luks> davidstrauss: but we don't :)
[10:24] <bialix> is not "commit" is the action
[10:25] <bialix> ?
[10:25] <bialix> but snapsot is the object
[10:25] <davidstrauss> bialix: See, that's another troublesome term
[10:25] <luks> depends, git uses it as the result of the action
[10:25] <davidstrauss> bialix: "Commit" can be the action of committing or the snapshot produced by committing
[10:25] <bialix> nice
[10:26] <davidstrauss> bialix: "Snapshot" is so unambiguous, I can even use it to define the confusing VCS terms.
[10:27] <bialix> I agree here
[10:27] <davidstrauss> bialix: It's a nice metaphor, too
[10:27] <luks> but it's not very translatable, I guess
[10:27] <davidstrauss> bialix: git could not call it a snapshot, though, because they have the staging area
[10:27] <luks> I can't think of a slovak translation for shapshot
[10:27] <bialix> for those who like photography?
[10:28] <davidstrauss> luks: What is the translation used for file system snapshotS?
[10:28] <bialix> for me snapshot is more about photo
[10:28] <luks> davidstrauss: I don't think there is one
[10:28] <davidstrauss> http://en.wikipedia.org/wiki/Snapshot_(computer_storage)
[10:28] <luks> we just use an expression to explain it
[10:29] <luks> can't think of a direct translation
[10:29] <davidstrauss> There are a few translations there in the inter-language links
[10:30] <luks> three words for russian :)
[10:30] <davidstrauss> It's pretty much impossible to find terms that work across languages. Computer terms are either metaphorical or made up
[10:30] <luks> so the same problem, I guess
[10:31] <luks> ah, no
[10:31] <davidstrauss> luks: I'm sure "commit
[10:31] <bialix> luks: in russian it's called "phot of file system"
[10:31] <davidstrauss> luks: I'm sure "commit" and "revision" are at least as bad
[10:31] <luks> davidstrauss: definitely
[10:31] <luks> I always laugh at the translation of commit in svn manuals
[10:31] <bialix> push is bad too
[10:31] <davidstrauss> luks: At least "snapshot" is unambiguous and tangible to English speakers
[10:32] <bialix> luks: in russian svn book "revision" called an "editing"
[10:33] <bialix> it's so crazy
[10:34] <bialix> davidstrauss: "git could not call it a snapshot, though, because they have the staging area" -- I disagree
[10:34] <bialix> their staging area is also "snapshotting"
[10:34] <davidstrauss> bialix: git isn't snapshotting anything
[10:34] <bialix> really?
[10:34] <davidstrauss> bialix: http://fourkitchens.com/blog/2009/02/03/importance-atomicity-or-why-git-staging-area-bad
[10:35] <bialix> looking into .git directory I see they're store actual state of the files
[10:35] <luks> davidstrauss: they are just applying a filter before they take the snapshot
[10:35] <davidstrauss> luks: no
[10:35] <luks> but I think it still is a shanpshot
[10:35] <davidstrauss> luks: nope
[10:35] <davidstrauss> luks: "Along these lines, one of the most atomicity-busting aspects of git’s staging area is that it doesn’t just mark code that needs to go into the next commit; it actually saves the hunk into the staging index. So, a developer could add code to the staging area, modify her working copy, and end up with a commit containing code that’s neither in her working copy nor in her stash."
[10:36] <davidstrauss> luks: Something can be in the git staging area but not in your working copy.
[10:36] <luks> hm, I didn't know that
[10:37] <davidstrauss> luks: It's uncommon for someone to stage a change, revert it, and then commit the staged change, but it's quite possible.
[10:37] <bialix> davidstrauss: roughly the same happens in interactive darcs commit
[10:37] <davidstrauss> luks: So, I think that violates the snapshot metaphor.
[10:37] <luks> davidstrauss: if you define it as a tree-level snapshot, yes
[10:38] <bialix> you mean the staging area is virtual, but real files are real?
[10:38] <davidstrauss> bialix: I mean a snapshot should be of your working tree
[10:38] <bialix> I understand
[10:38] <bialix> but...
[10:38] <luks> but the same thing applies to svn then
[10:38] <davidstrauss> bialix: A data structure that you stage changes into doesn't translate well to the snapshot metaphor
[10:38] <davidstrauss> luks: no
[10:39] <bialix> see! even in English you can use snapshot differently
[10:39] <davidstrauss> luks: svn allows selective commit, but the commit must be of files as they are in your working tree
[10:39] <luks> davidstrauss: they might be out of date
[10:39] <luks> davidstrauss: svn will automatically merge, if possible
[10:39] <davidstrauss> luks: svn requires you to update prior to commit if you're committing to changed files
[10:39] <luks> you can commit a revision that doesn't represent your working tree
[10:40] <luks> sure, but it doesn't have to be the modified files
[10:40] <luks> source code files usually depend on each other
[10:40] <davidstrauss> luks: if you mean "merge" different directories, then yes, svn sort of violates it. but the problem is more that svn doesn't distinguish between branches and directories.
[10:42] <davidstrauss> luks: svn takes snapshots from the directory you're in and below.
[10:42] <davidstrauss> anyway, it's way past my bedtime
[10:42] <davidstrauss> luks: I rag plenty on svn/git in that blog post, anyway
[10:43] <davidstrauss> luks: And I do bring up that very issue
[12:19] <Jemsquash> I think I'm missing something about bzr add.  I have a clearcase view where I do updates to. I have created a bzr repo here and I do an bzr move --auto, bzr add then I was hoping to do a commit. However I do a bzr status and it shows a lot of files and directories as unkown with a ?. I expected the bzr add to add these files. What am i missing?
[12:27] <lifeless> Jemsquash: have you done 'bzr init' at any point? if not I'd be expecting bzr mv and bzr add to be erroring
[12:27] <lifeless> Jemsquash: if they aren't erroring, perhaps you are invoking 'bzr add' in a strange way?
[12:28] <Jemsquash> I am just typing bzr add.
[12:28] <lifeless> what does it report?
[12:28] <Jemsquash> I have 3 revisions in the branch so it is definitely initialised.
[12:28] <Jemsquash> nothing.
[12:29] <Jemsquash> I do bzr add. The command completes with no response. I then do bzr status and it lists a load of files as unknown.
[12:30] <Jemsquash> I initially did an add and it seemed to add a bunch of files, but seemed to leave a whole lot out.
[12:30] <lifeless> would it be possible to pastebin?
[12:30] <lifeless> bzr st
[12:30] <lifeless> bzr add
[12:30] <lifeless> bzr st
[12:30] <lifeless> oh, actually
[12:30] <lifeless> I think I know
[12:30] <lifeless> if the things that are not getting added are all bzr trees themselves, that is why
[12:30] <lifeless> what does 'bzr info <somethingthatisn'tgettingadded>' report?
[12:31] <Jemsquash> I can't do it here, it was at work today and I don't have access to irc from there. Corporate firewalls :(
[12:31] <lifeless> I bet that the things you are adding are bzr trees,or perhaps svn or some other vcs that you have a bzr plugin for installed
[12:31] <Jemsquash> I'm a bit lost when you say that things not being added are all bzr trees themselves.
[12:32] <Jemsquash> Ok - perhaps.
[12:32] <Jemsquash> I'll have an investigation into looking for .svn folders or .cvs folders. It is a possibility although I will be surprised.
[12:32] <lifeless> to demo now
[12:32] <lifeless> cd /tmp
[12:32] <lifeless> bzr init foo
[12:32] <lifeless> cd foo
[12:33] <lifeless> bzr init bar
[12:33] <lifeless> bzr add
[12:33] <lifeless> bzr st
[12:33] <lifeless> you should see that bar hasn't been added
[12:33] <Jemsquash> yep. That sort of makes sense.
[12:33] <Jemsquash> Is that due to the shared repo containing branches etc?
[12:34] <lifeless> no, its because we haven't finished the nested trees support
[12:34] <Jemsquash> ah ok
[12:34] <lifeless> if it were to add bar, it would be versioning a link to bar, like a svn external
[12:35] <Jemsquash> I'm not sure I want to understand this concept of nested trees.
[12:35] <lifeless> heh
[12:36] <Jemsquash> it sounds scary :)
[12:36] <lifeless> its pretty straight forward; you have a bzr tree for a library or something that you want to embed in a larger tree
[12:37] <Jemsquash> so the tree in effect is a project with subprojects in a way.
[12:38] <lifeless> yes
[12:38] <Jemsquash> If you created a branch from a branch that contained a nested branch would it copy that nested branch with its revisions across too?
[12:39] <Jemsquash> I'm confusing myself with recursion when I reread my own post.
[12:41] <Jemsquash> I guess I'm asking what the relevance of the link is vs the actual full blown nested repository. The link is versioned not the nested repo.
[12:42] <Jemsquash> If I commit a change to the nested tree will it change the revno of the containing branch?
[12:43] <bialix> anybody knows approx timeframe for 1.15 release?
[12:45] <lifeless> the relevance is that you can continue working on the subproject separately [in an entirely different machine, without the parent project, for instance], then pull across into the subproject dir where you are nesting it
[12:45] <lifeless> if it was a new project, you've have to be doing merges, and it would be less conveninet
[12:45] <lifeless> bialix: sorry, not offhand
[12:45] <bialix> well, when UDS then?
[12:49] <Jemsquash> OK I think I understand. I would have to try it out to figure out how to use it. It sounds promising provided the overall project is structured correctly to cope with subprojects.
[12:53] <Jemsquash> Thanks for your suggestion on checking to see if the unadded files & directories are themselves under revision control.
[12:56] <bialix> UDS will be 25-29 May. So I suppose 1.15 will be before or after. right?
[12:57] <lifeless> bialix: I'm not exactly sure; I'd ask the list if you need to know
[12:57] <bialix> ok
[13:58] <phanatic> hi, i need to upgrade my branch to "rich-root-pack" to use split, right?
[14:05] <jelmer_> phanatic: yes
[14:05] <jelmer_> mwhudson: yes
[14:07] <phanatic> jelmer_: thanks. bzr upgrade --rich-root-packs should do the trick, right?
[14:09] <jelmer_> phanatic: if you're restricted to bzr <= 1.0, yes
[14:09] <jelmer_> phanatic: (1.9-rich-roots also exists, for example)
[14:10] <phanatic> jelmer_: any ideas why i get this: http://pastebin.com/d37856392 ?
[14:10] <jelmer_> phanatic: you must upgrade the repo, not the branch
[14:11] <phanatic> ah, thanks :)
[14:46] <Jemsquash> I'm trying to find an easy way of migrating from clearcase to bazaar. I've come across a tool that will migrate from clearcase to subversion. I could then import into bazaar from there. The tool that I found can be found at http://community.polarion.com/index.php?page=download&project=svnimporter Does anyone have any better suggestions in migrating to bazaar?
[16:22] <NfNitLoop> Jemsquash: I don't know about clearcase->svn, but svn->bzr is pretty easy.
[16:23] <NfNitLoop> The only thing I can think of is that you might lose some metadata in the clearcase->svn migration.
[16:23] <NfNitLoop> SVN doesn't do non-linear history.
[18:00] <limor> hi
[18:02] <limor> I have a question? any german people?
[18:23] <limor> the informations of an branch like history.. are they stored in the branch or in the repository folder?
[18:30] <Peng_> limor: The history is stored in the repository.
[18:31] <Peng_> limor: All .bzr/branch contains is some meta data and a pointer to the branch's tip revision, which can be used to reconstruct the history from the repository.
[18:37] <limor> ah ok so the branch .bzr folder only store the metadata an the .bzr in the repository filder stores the history where the branch points to
[18:51] <mrooney> I'm attempting to use loggerhead to view a remote svn branch, does anyone know if this should work?
[18:51] <mrooney> I am trying for example ./serve_branches svn+http://svnserver/repos/trunk
[18:53] <Peng_> mrooney: That's an interesting idea.
[18:53] <james_w> mrooney: does serve-branches load plugins?
[18:53] <Peng_> james_w: Yeah.
[18:53] <Peng_> It tells me "... is not a directory" though.
[18:54] <mrooney> do I need some switch to tell loggerhead it is a remote branch? maybe it has nothing to do with bzr-svn?
[18:57] <Peng_> From the file/class names, it seems filesystem-centric.
[18:57] <james_w> mrooney: serve-branches serves all branches under a directory, so that's probably not going to work
[18:58] <mrooney> oh darn and the repository doesn't work either
[18:59] <mrooney> I already have a full svn import of the repository, maybe I should add a commit hook to update it and then I can just use the local bzr thing
[18:59] <mrooney> although I bet it would be useful to others as well if it could work the aforementioned way
[18:59] <james_w> yep
[18:59] <james_w> loggerhead can do it fine
[19:00] <james_w> just serve-branches can't set it up in the right way it seems
[19:00] <james_w> is the other launch script still there?
[19:00] <james_w> start-loggerhead I think it was
[19:00] <james_w> or does serve-branches say anything about a config file in the source?
[19:00] <NEBAP> hi guys
[19:00] <beuno> no config file for serve-branches (yet)
[19:01] <mrooney> oh okay it works fine on my import
[19:01] <mrooney> but it doesn't have the fancy ajax expanding of changes or the unified diff / side by side toggle
[19:01] <mrooney> does LP have its own version or do I need trunk?
[19:01] <beuno> mrooney, trunk has those
[19:01] <mrooney> ah ok let me grab that
[19:01] <beuno> LP uses trunk
[19:01] <mrooney> fancy :)
[19:02] <beuno> we like cutting edges  :)
[19:03] <vxnick_> could I ask for your (collective) advise on something?
[19:03] <NEBAP> is it possible to use bazaar in the following way: I have a container folder which represents the complete project. Within this folder there are container subfolders representing a part (e. g. a DLL) of the project. Does bazaar recognise this project layout in the way that it knows that the subfolders are parts of the project container?
[19:03] <mrooney> hmm it looks the same to me
[19:03] <mrooney> I will take a look later
[19:04] <jelmer_> mrooney: I think I know
[19:04] <jelmer_> mrooney: loggerhead tries to store a cache in the branch
[19:04] <jelmer_> mrooney: and that might rely on local file access
[19:04] <jelmer_> beuno: ^
[19:05] <beuno> jelmer_, it does
[19:05] <beuno> well
[19:05] <beuno> not *in* the branch
[19:05] <beuno> in a /tmp dir
[19:05] <jelmer_> beuno: oh, ok
[19:05] <beuno> although, tbh, I don't know what it would do with remote branches
[19:05] <jelmer_> beuno: so that doesn't explain why ./serve-branches <svn-url> doesn't work
[19:06] <beuno> lifeless and I tried it on SVN branches locally, and it owrked
[19:06] <beuno> jelmer_, right. Other than "I have never tried that"  :)
[19:06] <beuno> it theory, it *should* work
[19:06] <vxnick_> what's the best way to deploy an app to a server with bzr? At the moment I'm using bzr-upload from my dev machine to the server itself, but I'm now wanting to centralise things so I can have a repository view on my project management system.
[19:07] <jelmer_> beuno: serve-branches:47 has a check that the specified path is a directory :-)
[19:07] <beuno> jelmer_, ah. There you go
[19:07] <beuno> because we do directory navigation
[19:07] <beuno> as well as branches
[19:08] <beuno> I guess we need a different path when it's already a branch
[19:08] <jelmer_> beuno: directory navigation could be done using Transport though
[19:08] <jelmer_> beuno: Transport.list_dir works on svn transports
[19:08] <beuno> jelmer_, interesting. May work better.
[19:08] <beuno> I guess that would be a bug
[19:09] <beuno> vxnick_, you could use push-and-update
[19:09] <beuno> and block .bzr dir from being served
[19:09] <vxnick_> beuno: thanks - does that push to the central server and then update the remote production server?
[19:09] <beuno> vxnick_, pushes and updates the working tree in the remote location
[19:09] <beuno> you need ssh
[19:10] <vxnick_> thanks, I'll take a look at its docs
[19:10] <beuno> welcome'
[19:10] <Peng_> Would using transports hurt Loggerhead's performance on local branches?
[19:11] <jelmer_> Peng_: it would have a very slight overhead
[19:12] <Peng_> BTW, Loggerhead does support remote branch references.
[19:12] <jelmer_> Peng_: not a noticable impact
[19:13] <Peng_> You can't pass a remote location to serve-branches, but if you have a branch reference locally, it works.
[19:13] <Peng_> Bit slow, though.
[19:19] <Peng_> beuno: It seems to build the caches correctly on remote branches.
[19:20] <jelmer_> bug 371787
[19:20] <Peng_> beuno: (Well, references, but that still loads the remtoe branch.)
[19:20] <beuno> ah
[19:20] <beuno> thanks herb
[19:20] <beuno> er
[19:20] <beuno> and jelmer_
[19:36] <mdz> I have a bzr repository which seems to fail to convert using bzr upgrade --1.9-rich-root
[19:36] <mdz> it runs for a very long time and never terminates
[19:50] <jelmer_> beuno, peng_: hmm, that was actually pretty easy
[19:50] <beuno> mdz, is .bzr.log helpful at all?
[19:51] <mdz> 66.413  Using fetch logic to copy between KnitPackRepository('file:///home/mdz/s
[19:51] <mdz> rc/.bzr/repository.backup/')(<RepositoryFormatKnitPack1>) and KnitPackRepository
[19:51] <mdz> ('file:///home/mdz/src/.bzr/repository/')(<RepositoryFormatKnitPack6RichRoot>)
[19:51] <mdz> 66.413  fetch up to rev {None}
[19:51] <mdz> 2654.157  Traceback (most recent call last):
[19:51] <mdz> [traceback from where I interrupted it]
[19:51] <mdz> so that's about 45 minutes with no indication of progress for most of it
[19:51] <beuno> mdz, if it's a big repo, I think it could actually take ages as it recompresses all it's deltas, etc
[19:52] <beuno> but it should be eating CPU like crazy
[19:52] <mdz> beuno: it did eat CPU, but the progress indicator didn't update
[19:52] <beuno> mdz, that's "normal"
[19:52] <beuno> how big is the repo?
[19:52] <beuno> I've heard big repos take up 18 hours in this kind of jump  :)
[19:53] <mdz> the repo is about 1.2G
[19:53] <Peng_> jelmer_: What was?
[19:53] <beuno> mdz, sounds normal then. Probably one of those things to do before you go to bed  :)
[19:55] <mdz> beuno: I will give it another try.  if it doesn't complete by this time tomorrow, I will renew my suspicions
[19:56] <jelmer_> Peng_: switching to transports
[19:56] <beuno> mdz, you should also be aware that all remote branches will need to be rich-root as well
[19:56] <beuno> or you won't be able to interact with them
[19:57] <mdz> beuno: that's what has actually triggered the upgrade for me; one of the branches I work with has converted and I could no longer branch from it
[19:58] <Peng_> jelmer_: Wait, did you actually do it, or just see how?
[19:58] <mdz> beuno: does this mean it's impossible to share a repository between branches unless they're all upgraded?
[19:58] <beuno> mdz, yes. It sucks.
[19:58] <mdz> beuno: or will upgrading the repository fetch massive amounts of data from remote branches?
[19:58] <mdz> hmm
[19:58] <beuno> mdz, they won't work if they aren't rich-root on the other end
[19:58] <beuno> but
[19:58] <mdz> sounds like I should quit using a repository
[19:58] <beuno> there's light at the end of the tunnel
[19:59] <beuno> 2.0 format will be rich-root
[19:59] <mdz> rather than spending days converting it
[19:59] <beuno> and there won't be any non-rich-root anymore
[19:59] <beuno> mdz, yeah, I keep them in shared repos between projects
[20:00] <vxnick_> is there anything like push-and-update but for commits?
[20:00] <beuno> vxnick_, well, checkouts accomplish that to some extent
[20:00] <beuno> but I don't know if push-and-update plugin works with it
[20:00] <vxnick_> beuno: I just want to avoid having to login to the production machine to update
[20:01] <jelmer_> Peng_: I actually fixed it
[20:01] <vxnick_> I want to do: local dev --> commit to central repo --> update remote production machine
[20:01] <Peng_> jelmer_: Oh, cool. :)
[20:01] <mdz> beuno: I just use one big repo for checking out everything
[20:01] <beuno> vxnick_, ah, two separate machines
[20:01] <vxnick_> beuno:  yup :)
[20:01] <beuno> mdz, yes, I used to do that. Had to move to per-project  :)
[20:02] <beuno> mdz, after 2.0, the madness should stop, and we can all finally be happy
[20:02] <beuno> vxnick_, I don't think there's anything in bzr that will let you do that
[20:02] <vxnick_> beuno: hmm. I think you're right but thought I'd ask
[20:02] <beuno> vxnick_, you can put together a plugin if you're good with python
[20:02] <beuno> vxnick_, or a cronjob  :)
[20:02] <vxnick_> beuno: I'm a complete noob :)
[20:03] <vxnick_> beuno: a cron is an option but it'd be nice to have it automated
[20:03] <mdz> beuno: if I just blow away my repo, will that break all of my local branches, or will they continue to work?
[20:03] <vxnick_> beuno: on second thoughts, it's probably best to manually run bzr update just in case there are any conflicts
[20:04] <beuno> mdz, break completely and loose all your data
[20:04] <mdz> beuno: sweet!
[20:04] <beuno> mdz, I'd recommend you branch from the repo for big branches so it's local and fast
[20:04] <mdz> so I guess I 1) make sure all my changes are pushed to LP, 2) blow away my repo, 3) re-download all my branches
[20:05] <beuno> and then bring in the rest remotely on a need-to-use basis
[20:05] <beuno> mdz, you can branch them locally instead, outside of the shared repo
[20:05] <mdz> beuno: oh, good idea
[20:06] <beuno> mdz, but then again, you're so close to the tubes, not sure it would make a dramatic difference
[20:06] <mdz> beuno: I'm at home, narrower tubes
[20:06] <beuno> right, avoid plumbing all together then
[20:08] <vxnick_> do you know of any bzr plugins to allow shell-type files to be run?
[20:08] <jelmer_> beuno, Peng_: how do I run the loggerhead testsuite?
[20:08] <beuno> jelmer_, nosetests
[20:08] <beuno> vxnick_, shell hooks. let me find some documentation for you..
[20:09] <jelmer_> beuno: is there some way to enter a debugger in case of tracebacks, like BZR_PDB=1 ?
[20:09] <vxnick_> beuno: thank you kindly :)
[20:09] <beuno> jelmer_, I... don't know   :)
[20:09] <jelmer_> beuno: thanks
[20:09] <vxnick_> beuno: I'm thinking that perhaps bzr upload would work if I called it from a shell script on the post_commit hook
[20:10] <vxnick_> from central server --> deployment server
[20:10] <mrooney> beuno: I checked out lp:loggerhead/trunk now and am running that, but I still don't see any of the new stuff LP has, do I need to do anything special?
[20:11] <beuno> mrooney, nope, you sould see all of it
[20:11]  * Peng_ has never run Loggerhead's test suite. Coughcough.
[20:12] <mrooney> beuno: hmph, I'm stuck then
[20:14] <beuno> vxnick, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks
[20:15] <beuno> http://bazaar-vcs.org/BzrHooks
[20:15] <vxnick> beuno:  cheers!
[20:15] <beuno> mrooney, did you install loggerhead from a package?
[20:15] <mrooney> beuno: no I checkout out lp:loggerhead/trunk and ran serve_branches
[20:16] <beuno> mrooney, do you didn't have it installed previously?
[20:16] <mrooney> beuno: well I had run 1.10 in the same way previously
[20:16] <beuno> mrooney, can you try getting lp:loggerhead instead?
[20:16] <mrooney> yeah that is what I originally used
[20:16] <mrooney> then I tried trunk and it looked the same
[20:17] <beuno> well, it's all there is  :)
[20:17] <mrooney> beuno: what is all there is?
[20:17] <beuno> mrooney, you don't have serve-branches in /usr/bin?
[20:17] <beuno> mrooney, lp:loggerhead
[20:18] <mrooney> beuno: nope I don't have it except in the 1.10 and trunk checkout
[20:26] <beuno> mrooney, so
[20:26] <beuno> you're doing:  bzr branch lp:loggerhead; cd loggerhead; ./serve-branches
[20:27] <mrooney> beuno: well, bzr co lp:loggerhead/trunk loggerhead-trunk; cd loggerhead-trunk; ./server-branches path
[20:28] <mrooney> well except for that typo in the last command
[20:30] <mrooney> is anyone able to attempt to reproduce it? as long as you have a local repository it should take about a minute
[20:30] <beuno> and when you hit localhost:8080
[20:30] <beuno> you get the old version?
[20:32] <mrooney> beuno: well I assume, I don't have the ajax expansions or side by side vs unified diff options
[20:32] <mrooney> if I kill the trunk process it stops working so I am fairly sure it is being served from the process I think it is
[20:34] <Peng_> Could it be importing the wrong "loggerhead" somehow? Does that even work anymore? I broke it for UserBranches, but I'm not sure about regular Branches.
[20:35] <mrooney> I would say it could have something to do with me first using the 1.10, but in retrospect I see lp:loggerhead goes to trunk anyway
[20:35] <mrooney> so I never actually had 1.10
[20:36] <mrooney> Peng_: do you have a repos to test with?
[20:37] <Peng_> mrooney: Test what?
[20:37] <mrooney> to see if someone else serving from trunk gets what I expect, the LP interface
[20:37] <mrooney> maybe they don't!
[20:56] <jelmer_> beuno, Peng_: loggerhead works on svn and git branches now :-)
[20:57] <beuno> jelmer_, you're unstoppable
[20:57] <beuno> have you files a merge proposal for the tweaks?
[20:57] <mrooney> jelmer_: so I can grab your branch and use a remote svn branch?
[20:57] <BasicOSX> just a /poke for input regarding 1.15rc1. My initial post had 1 follow-up and I've responded to that. Looking for general feel on the state of the code and bug fixes so a 1.15rc1 can be created.
[20:59] <jelmer_> mrooney: yeah, the last two branches I submitted for merging into loggerhead
[20:59] <jelmer_> mrooney: as well as the latest bzr-svn and subvertpy
[20:59] <jelmer_> beuno: and mercurial :-)
[20:59] <mrooney> ah okay I'll merge those locally
[20:59] <beuno> jelmer_, really?  bzr works with hg?
[21:00] <jelmer_> beuno: well enough for the history
[21:00] <jelmer_> beuno: I haven't tried looking at the diffs yet
[21:00] <beuno> amazing
[21:00] <jelmer_> mrooney: there's one caveat, you'll have to disable the caching in bzr-svn because loggerhead uses threads
[21:00] <beuno> jelmer_, if you point me at the MP, I'll review/merge
[21:00] <beuno> ah
[21:01] <beuno> Peng_ got to it  :)
[21:01] <beuno> he can merge
[21:01] <Peng_> beuno: OK.
[21:01] <jelmer_> beuno: https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179, https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179
[21:02] <jelmer_> I mean https://code.edge.launchpad.net/~jelmer/loggerhead/fix-nick/+merge/6180
[21:02] <Peng_> Huh, I haven't seen any code review emails. I'm still getting other LP mail...
[21:03] <LarstiQ> jelmer_: dude! asom!
[21:04] <Peng_> BTW: I don't want to review fix-nick, since I'm not qualified to comment on branch._get_nick.
[21:05] <Peng_> Ahh, here the emails are; they're just a bit late.
[21:06] <beuno> jelmer_, I had to change the nick bit so it didn't try and grab it remotely for checkouts
[21:06] <beuno> I think this will revert back to that behaviour?
[21:06] <beuno> or does the local=true prevent it?
[21:08] <jelmer_> beuno: local=True prevents it
[21:09] <beuno> jelmer_, thanks. Will merge it
[21:09] <Peng_> I could fix my review comments on transport and merge it. OK?
[21:10] <beuno> Peng_, go for it!
[21:10] <Peng_> OK.
[21:12] <jelmer_> Peng_: thanks!
[21:21] <mwhudson> jelmer_: what was i asking? :)
[21:21] <jelmer_> mwhudson: :-)
[21:21] <jelmer_> mwhudson: Where I would be at UDS
[21:21] <jelmer_> s/Where/Whether/
[21:21] <mwhudson> jelmer_: oh right
[21:21] <mwhudson> jelmer_: good!
[21:22] <jelmer_> mwhudson: more bzr-git issues to work on ?
[21:22] <beuno> jelmer_, you're going?
[21:22] <jelmer_> beuno: yep
[21:22] <beuno> yay
[21:22]  * beuno will be there
[21:22] <mwhudson> jelmer_: i can't quite remember why i was asking now :)
[21:22] <jelmer_> beuno: Cool :-)
[21:23] <beuno> Peng_, how about you?
[21:23] <mwhudson> jelmer_: testing git imports got stalled by having our staging code import machine stolen by IS
[21:23] <jelmer_> IS?
[21:24] <jelmer_> mwhudson: oh btw, I fixed another excessive memory usage issue in dulwich
[21:24] <mwhudson> information services
[21:25] <mwhudson> jelmer_: can i cope with the kernel yet? :)
[21:25] <beuno> aka, sysadmins
[21:25] <jelmer_> mwhudson: maybe
[21:25] <jelmer_> mwhudson: samba works pretty well now
[21:25] <mwhudson> jelmer_: cool
[21:25] <jelmer_> it's still a bit slow though, takes a couple of hours
[21:26] <mwhudson> jelmer_: importing into what?  --1.9-rich-root
[21:26] <mwhudson> jelmer_: hours!?! we have had cscvs imports take _days_
[21:26] <jelmer_> mwhudson: development6
[21:26] <mwhudson> o
[21:27] <mwhudson> k
[21:27] <jelmer_> mwhudson: the fact that creating an inventory in 1.9-rich-root is O(tree) makes it really slow
[21:28] <LarstiQ> slower than several hours you mean?
[21:28] <jelmer_> LarstiQ: yeah
[21:28] <jelmer_> you spent most of the time serializing and deserializing inventories
[21:28] <mwhudson> jelmer_: i can believe that
[21:28] <jelmer_> s/spent/spend/
[21:30] <Peng_> beuno: Me what?
[21:30] <beuno> Peng_, are you going to UDS?
[21:30] <Peng_> beuno: No.
[21:30] <Peng_> beuno & jelmer_: I merged the transport branch.
[21:30] <jelmer_> Peng_: Cool, thanks!
[21:31] <beuno> Peng_, you couldn't come?  or didn't get an offer to be sponsored?
[21:31] <jelmer_> mwhudson: what's the best way to get those OOo / samba branches updating again
[21:31] <jelmer_> mwhudson: ?
[21:31] <mwhudson> jelmer_: again?
[21:31] <Peng_> beuno: Um, let's say both. I don't even know anything about UDS.
[21:32] <jelmer_> mwhudson: Well, last time you asked tbm (?) to trigger an update
[21:32] <jelmer_> mwhudson: but doing it that way seems a bit labor-intensive :-)
[21:34] <beuno> Peng_, we should get you to one of them and hack  :)
[21:36] <mwhudson> jelmer_: spm
[21:36] <mwhudson> jelmer_: they've got stuck again?
[21:36] <Peng_> beuno: I dunno. I'm shy. And I dunno how useful I'd be. I still haven't done any major work. Plus I should've started eating dinner 20 minutes ago, and I'll go do that now. See you later, everyone. :) (Which is convenient for getting out of this conversation, but also true.)
[21:37] <beuno> Peng_, enjoy  :)
[21:39] <jelmer_> mwhudson: yeah
[21:39] <Peng_> Quick question: does transport.stat() follow symlinks?
[21:39] <jelmer_> mwhudson: but seem stuck even for smaller stuff, so it's impossible to use launchpad with reasonably large (>= 10k or something) development6 branches
[21:42] <mwhudson> jelmer_: two points i guess: 1) we should be able to make changes soon that allow us to up the timeout
[21:42] <mwhudson> 2) this means 15 minutes with no activity report -- that much be a bug somewhere
[21:42] <mwhudson> must
[21:43] <jelmer_> mwhudson: when does that timeout happen, during pull ?
[21:43] <mwhudson> jelmer_: yes
[21:44] <vxnick> what's the best way to move my repository including the ignored list?
[21:44] <mwhudson> jelmer_: also branch outside a shared repo is really slow for dev6, i guess this is an indication of the same problem
[21:44] <mwhudson> jelmer_: have you been having problems with mirrored branches too, or just hosted?
[21:45] <jelmer_> mwhudson: both
[21:45] <mwhudson> :(
[21:47] <LarstiQ> jelmer_: tbm is Martin Michlmayer :)
[21:47] <LarstiQ> vxnick: do you mean branch? Repositories don't have ignore lists.
[21:47] <vxnick> LarstiQ: sorry, that's correct
[21:48] <LarstiQ> vxnick: assuming the ignore list is nicely committed and everything, `bzr push` would be the operation of choice.
[21:48] <vxnick> LarstiQ: push doesn't move the files though does it, just the history?
[21:48] <jelmer_> LarstiQ: ahh
[21:48] <jelmer_> LarstiQ: Too many TLA's >-)
[21:49] <LarstiQ> jelmer_: there is only one tbm! ;)
[21:49] <LarstiQ> vxnick: the history is the important bit :)
[21:49] <LarstiQ> vxnick: a working tree can always be constructed if you have the history
[21:49] <LarstiQ> vxnick: where do you want to move it from, and whereto?
[21:49] <vxnick> LarstiQ: how so? I'm looking to shift the entire branch from my local machine to a remote server
[21:50] <LarstiQ> vxnick: does it even need a working tree then? Usually the answer is no.
[21:50] <vxnick> LarstiQ: but ideally I want to move the entire shared-repo
[21:51] <vxnick> LarstiQ: it does in this case as I want to have the files viewable through a system similar to trac
[21:51] <LarstiQ> vxnick: then you do not need a working tree.
[21:51] <LarstiQ> vxnick: the system like trac will provide it.
[21:51] <LarstiQ> vxnick: like, Loggerhead mwhudson, Peng_ and jelmer have been talking about.
[21:52] <vxnick> LarstiQ: thanks I'll have a read :)
[21:52] <LarstiQ> vxnick: for pushing an entire repo there is a repo-push plugin iirc (http://bazaar-vcs.org/BzrPlugins)
[21:52] <vxnick> LarstiQ: that looks ideal, many thanks!
[21:53] <LarstiQ> vxnick: np, let me know how it went
[21:53] <vxnick> will do
[21:54] <fullermd> q
[21:54]  * fullermd slaps his mouse.
[21:59] <vxnick> LarstiQ: worked a treat, thanks again :)
[22:00] <LarstiQ> vxnick: good :)
[22:08] <jfroy> jelmer: I just read a message you wrong on the mailing list where you mention push_merged_revisions. I'm not familiar with that setting, is it new?
[22:08] <jfroy> *you wrote
[22:13] <jelmer_> jfroy: no, it's been there for a while but never has been announced very publicly
[22:13] <jfroy> Am I guessing correctly that it pushes RHS revisions as separate svn commits when pushing a merge revision?
[22:14] <jfroy> *as separate svn revisions
[22:16] <jelmer_> jfroy: yes, onto a separate branch
[22:17] <jelmer_> or rather, separate branches
[22:17] <jfroy> I'm not sure I
[22:17] <jfroy> *I'm following completely.
[22:17] <jfroy> Are you saying it creates a new "branch" in svn?
[22:17] <jelmer_> jfroy: yes
[22:17] <jelmer_> and uses the bzr branch nick for the branch name in svn
[22:18] <jfroy> And I assume it guesses the bath based on its guess of the repository layout?
[22:18] <jelmer_> so if you did a commit in a bzr branch called "feature-a" and then merged it into trunk
[22:18] <jfroy> *the path
[22:18] <jelmer_> bzr-svn would push the commits in feature-a into branches/feature-a in subversion
[22:18] <jelmer_> and the merge commit onto trunk
[22:18] <jfroy> gotcha
[22:18] <jfroy> what happens if you pushed feature-a to svn yourself
[22:18] <jfroy> then merge feature-a into trunk (locally) and push trunk
[22:19] <jfroy> I assume, like any other bzr-svn push, that it will read the bzr-svn revprop and do the right thing?
[22:19] <jelmer_> jfroy: yes
[22:19] <jfroy> e.g. it will see it has no revisions to push, then move on to the merge revision in trunk
[22:19] <jfroy> I like it :)
[22:20] <jfroy> So where do I sign up for this goodness.
[22:20] <jfroy> bazaar.conf?
[22:21] <jelmer_> jfroy: yeah
[22:21] <jelmer_> or locations.conf / subversion.conf for individual repo's
[22:21] <jfroy> right, it's defined on BranchConfig which inherits from Config
[22:22] <jfroy> so it should pick up the usual behaviors of bzr's config machinery
[22:24] <jfroy> I think you should advertise it more.
[22:25] <jfroy> It's pretty nifty :p
[22:27] <jelmer_> I haven't used it much myself so it may still have some rough edges
[22:27] <jelmer_> I agree it's pretty nifty though :-)
[22:28] <jfroy> mmm
[22:28] <jfroy> Well if I hit any snags I'll file bugs, as usual.
[22:32] <jelmer_> thanks
[22:51] <flacoste> hi there
[22:51] <flacoste> i want to open a branch and look at the commit messages from a specific revision onward
[22:52] <flacoste> any pointers on how to use bzrlib to achieve this?
[22:52] <flacoste> i'm looking at log.py (but my head spins)
[22:52] <lifeless> moin
[22:53] <thumper> hmm...
[22:53] <mwhudson> log.py is pretty much brain-pain
[22:53] <thumper> merge sorted ?
[22:53] <flacoste> thumper: i don't know what this means
[22:53] <mwhudson> flacoste: all revisions, or just mainline?
[22:53] <thumper> flacoste: it wasn't for you :)
[22:53] <flacoste> just mainline
[22:53] <flacoste> lol
[22:53] <thumper> just mainline is easy
[22:53] <lifeless> flacoste: b = bzrlib.branch.Branch.open(url)
[22:53] <flacoste> yeah, i assumed so
[22:53] <lifeless> b.lock_read()
[22:54] <lifeless> revid = b.revno2revid(revno)
[22:54] <lifeless> for revid in b.iter_revision_history(revid):
[22:54] <lifeless>     print b.repository.revision(revid).message
[22:55] <lifeless> or ~ that anyhow
[22:55] <lifeless> iter_revisions or whatever its called is faster than getting inidividual revisions
[22:55] <flacoste> ok and this will return revision from revno and more recent?
[22:55] <flacoste> actually, excluding revno
[22:55] <flacoste> i assume
[22:56] <lifeless> oh, you want more recent
[22:56] <lifeless> iter_revision_history(b.last_revision)
[22:56] <lifeless> and then test for the exit point
[22:56] <flacoste> makes sense
[22:56] <flacoste> thanks a lot!
[22:57] <flacoste> how do i release the lock?
[22:57] <mwhudson> b.unlock()
[23:02] <ronny> LarstiQ: sup on the easy_install issues?
[23:02] <igc> morning
[23:04] <jelmer_> hi ian
[23:06] <flacoste> the only iter_ i find on branch is iter_merge_sorted_revisions
[23:11] <igc> hi jelmer_
[23:12] <thumper> igc: composite trees?
[23:12] <igc> thumper: back to reviewing them today
[23:12] <thumper> igc: cool
[23:12] <igc> thumper: sorry for the delay - just not well enough last week
[23:12] <thumper> ok
[23:15] <abentley> igc: IIRC, the big sticking point is the text filtering.
[23:15] <igc> abentley: hi. Right
[23:16] <igc> abentley: a parameter exists in the WT API but not the Tree one
[23:16] <abentley> igc: CompositeTree can contain RevisionTrees and WorkingTrees, but only the WorkingTree version supports text filtering.
[23:16] <abentley> igc: Why isn't that already causing problems?
[23:17] <igc> abentley: I'll think hard about it today. What problems would you expect?
[23:17] <abentley> igc: I would expect bzr cat -r -1 to raise an exception because an unknown parameter was passed into it.
[23:18] <abentley> igc: Where is text filtering actually used?
[23:18] <poolie> igc, i like your three/four wishes, but they're a bit big to be used there
[23:19] <poolie> by which i mean, i suppose, that "adoption blockers banished" could be just the only item on the roadmap for the whole duration of the project :)
[23:19] <poolie> but i suppose it's fine
[23:20] <igc> abentley: it's used implicitly most of the time
[23:20] <igc> abentley: and explicitly in some cases like cat and export
[23:22] <abentley> igc: So it defaults to True.  That's pretty gutsy.
[23:23] <igc> abentley: for WorkingTree's, it really needs to
[23:23] <igc> abentley: otherwise, every plugin needs to remember to switch it on
[23:23] <igc> and command
[23:24] <igc> abentley: IIRC, it used to live on the Tree API and default to True there too
[23:24] <abentley> igc: Not every plugin and command, just those that want the filtered form.
[23:24] <igc> abentley: but we backed out the change for .bzrrules, taking away historical storage of rules
[23:25] <abentley> igc: it's still a subtle enough behavior change that bugs it introduces might not be caught by our existing tests.
[23:26] <igc> abentley: in a sense, bzr has always used the internal form only
[23:27] <abentley> igc: I think that the parameter should exist on Tree, but should only affect Trees which have a filtered form.
[23:27] <igc> abentley: content filtering just means that what's in the tree is something else convenient for the user
[23:29] <igc> abentley: that sounds ok to me
[23:31] <igc> abentley: I'm pretty sure the text filtering issue was the only blocker wasn't it?
[23:31] <mwhudson> jelmer_: do you have a list of other branches that are failing to pull correctly?
[23:31] <abentley> igc: You gave me a tweak, and I upgraded it to resubmit because of that.
[23:32] <igc> abentley: I almost suggested last week that you land your change and we work together on the text filtering as a follow-up/known issue
[23:32] <jelmer_> mwhudson: lp:~jelmer/samba/trunk, lp:~jelmer/openoffice/trunk and lp:~jelmer/openoffice/hosted
[23:33] <igc> abentley: given how little the text filtering is currently used
[23:33] <jelmer_> mwhudson: beware of the last two though, they're both around 4.5Gb
[23:33] <igc> (and that's because we don't have branch-specific rules yet)
[23:33] <mwhudson> jelmer_: ah, the other two are mirrored branches
[23:34] <mwhudson> jelmer_: it's a bit crap that the openoffice/hosted got stuck again
[23:34] <mwhudson> jelmer_: did you push a lot of new revisions?
[23:34] <jelmer_> mwhudson: about 100k
[23:34] <abentley> igc: I'd be happy to do that.
[23:35] <mwhudson> jelmer_: ok, i guess that qualifies as a yes
[23:35] <jelmer_> mwhudson: :-)
[23:36] <igc> abentley: cool. Let's do that then because I don't think anything else I've seen in your patches so far will be affected
[23:37] <abentley> igc: I'm looking at the implementation of cmd_cat, and it doesn't pass filtered as a parameter to get_file_text.
[23:38] <igc> abentley: it's using the Tree API from memry, where that parameter doesn't exist
[23:38] <igc> abentley: RevisionTree API even
[23:39] <abentley> igc: It seems to be using revision trees everywhere, and in that case, it makes no sense to filter, because the file is already in the internal form.
[23:40] <igc> abentley: right, though the user can explicitly ask to see the output post-filtered
[23:40] <abentley> igc: Post filtered meaning the internal form?
[23:41] <igc> abentley: though, filtered then means "using configured filters", not historical filters
[23:41] <igc> abentley: the filtering can go 2 ways
[23:41] <igc> internal <-> external
[23:42] <igc> get_file_text() filters external -> internal
[23:42] <igc> abentley: in the case of cat, the filtering is the opposite way
[23:43] <abentley> igc: If "filtered" can mean two different states, do you think it would be clearer to refer to the desired state instead?
[23:44] <igc> abentley: perhaps
[23:44] <igc> abentley: the text at the top of bzrlib/filters/__init__.py might be of interest btw
[23:49] <abentley> igc: So this explains why no tests break even though CompositeTree doesn't support "filtered".  Nothing which uses CompositeTree is also providing that parameter.
[23:50] <lifeless> abentley: we're going to need CT everywhere right?
[23:50] <abentley> lifeless: No.
[23:50] <lifeless> where won't we?
[23:51] <lifeless> RevisionTree's for instance, shouldn't they be returned as CT's now?
[23:51] <igc> abentley: probably because nothing wants the external form, only the internal
[23:51] <Peng_> Possibly-dumb question: can branch references use relative paths?
[23:51] <lifeless> Peng_: not currently
[23:51] <mwhudson> Peng_: no
[23:51] <Peng_> Darn. Thanks.
[23:51] <abentley> lifeless: Most cases where we're writing to the tree, and cases where we handle nesting directly for read operations.
[23:51] <Peng_> That'd explain why I wasn't using a relative path already. :D
[23:51] <mwhudson> there was a thread about this on the bzr list semi-recently
[23:52] <lifeless> abentley: I'd have thought that e.g. 'bzr ls -R lp:twisted' should recurse.
[23:52] <abentley> lifeless: It probably should, but it's not on the list of commands I've committed to support.
[23:53] <lifeless> abentley: this comes back to my strong feeling we should be putting the support inside regular trees rather than an optional external construct which people need to remember to use
[23:55] <abentley> lifeless: I don't think that's practical.
[23:55] <lifeless> abentley: why not?
[23:58] <abentley> it makes everyone pay the cost of the feature, it makes recursion mandatory, it hides what's really going on, it makes the code trickier to debug.
[23:59] <abentley> It's an all-or-nothing sort of solution.  We need an incremental one.
[23:59] <abentley> If we can't start somewhere, we'll never get finished.