[19:22] <eerste> Trying to install edub 14.04.1 from dvd in Dutch. Installation stalled several times almost at the end with a CRON CMD ( cd / && run-parts --report)  /etc/cron.hourly ) Any idea to get it to finish?


[03:24] <_antant> well it's been quiet on here today
[10:29] <morgan> hey, anyone have any experience with IMDB scrapers etc.. imdb-tools is useless
[20:38] <kenni> Hi guys, have you decided (or looked into) if the MythTV 0.24 locale configuration will be supported in Mythbuntu 11.04? With the current use of a custom database on a clean Mythbuntu install, I suppose it will be too much work to get it done in time for the 11.04 release(?)
[20:53] <tgm4883> kenni, locale config?
[20:54] <kenni> tgm4883, bug #724693
[20:54] <Zinn> Bug 724693 in mythbuntu "New MythTV 0.24 locale auto configurations doesn't work with Mythbuntu 11.04" [Undecided, New] http://www.launchpad.net/bugs/724693
[20:55] <tgm4883> kenni, hmm, ok
[20:55] <tgm4883> kenni, what is it looking for in a clean DB?
[20:55] <tgm4883> superm1, ^
[20:58] <tgm4883> I see no reason that couldn't still make it into 11.04. Would seem like a bug to me that is isn't already there since the functionality already exists in 0.24
[21:00] <kenni> tgm4883, AFAIR it checks for a clean settings table
[21:01] <tgm4883> kenni, ok, are you able to check if just dropping that table makes it work. I'd have to check what we currently set in there
[21:01] <tgm4883> which wouldn't get checked until tonight
[21:05] <superm1> kenni, i think the proper solution is to pass that information to the database from during install
[21:05] <superm1> because we definitely need to have a prefilled database (at least somewhat) so that there isn't an error the backend isn't running on first boot
[21:11] <tgm4883> superm1, that seems logical to me, since that type of information is already gathered during install
[21:12] <superm1> hell if i'm gonna have time to help get it propagated though
[21:12] <Zinn> superm1: Please watch your language.
[21:14] <rhpot1991> tisk tisk superm1 :)
[21:15] <superm1> psh
[21:16] <tgm4883> well pulling it from the installer is going to be a feature
[21:16] <tgm4883> which would be 11.10
[21:18] <kenni> superm1, tgm4883: it seems like the language selection dialog is shown if the "Launguage" and "Country" field in the settings table are empty. But I haven't tested it, so I might be wrong, I just had a brief look at the code
[21:18] <kenni> Language
[21:20] <superm1> kenni, i wonder if there's a good way to have it pull up that dialog the first time and still pre fill the database
[21:20] <kenni> it will probably need some fitting to make it work in Mythbuntu
[21:20] <kenni> stuartm is the person to talk to about it, he wrote the feature
[21:23] <kenni> perhaps the feature needs to be altered a bit upstream, to make it compatible with distributions like Mythbuntu. At the moment the feature is written to specifically require a clean database.
[21:29] <superm1> well the other way to look at it is that a backend shouldn't require anything in the database to run
[21:29] <superm1> and then we could start with a clean database
[21:30] <superm1> but i think something has to happen upstream either way
[21:30] <kenni> unfortunately, I'll not have much (if any) time to play with MythTV/Mythbuntu for the next 1½ month. Otherwise I would gladly have helped with the testing...if it's just the two mentioned fields which need to be empty to bring up the dialog, you can probably pre-populate some of the other settings if needed. You then just need to beware when you startup mythtv-setup the first time, so the language dialog will be shown in the initial startup pha
[21:32] <kenni> superm1, why do you want to start the backend? Shouldn't you only start mythtv-setup on the initial bootup?
[21:32] <kenni> ...and then start the backend afterwards
[21:34] <superm1> kenni, well we don't currently start mythtv-setup on initial bootup
[21:34] <kenni> ok
[21:34] <superm1> and it requires some work to make that happen
[21:34] <superm1> at least in the proper fashion that it needs to
[21:34] <kenni> yep
[21:36] <kenni> what is the reasoning behind not starting mythtv-setup on initial bootup? I can't remember what Mythbuntu currently does - does it start the backend & the frontend on initial bootup?
[21:44] <superm1> yeah it starts the backend and frontend on initial bootup
[21:45] <superm1> mythtv-setup is a bit confusing, you dont want to boot up and immediately feel like you have to configure things
[21:45] <superm1> whereas if you start the frontend on first boot, you can go explore around etc
[21:47] <kenni> yeah, okay, but not much will work and it's a quite unsupported state to be in (with no tuners defined)
[21:48] <kenni> but I do see your point, realistically perhaps this is a 0.25/11.10/12.04 milestone
[21:48] <kenni> to await the setup rewrite
[22:06] <kenni> and we'll most likely also generate a lot of locale-files for 0.25 - currently only manually contributed locale configuration files exist in MythTV. Without much effort we can provide a baseline locale config (MythTV language, date format, etc.) for the most widespread locales.
[22:11] <superm1> kenni, exactly, 0.25 sounds a good time to do that


[00:06] <spiv> Good morning.
[00:11] <poolie> hi there spiv
[00:14] <spiv> The cold seems to have mostly subsided today, thankfully.
[00:14] <peitschie> poolie: do you know much about bzr reconcile behaviour?
[00:14] <poolie> that's great
[00:14] <poolie> peitschie: a bit, what do you want to know?
[00:16] <peitschie> poolie: i've been running into issues where the canonicalize-checks take around 20hrs to run over my repository at work
[00:16] <peitschie> i was trying to come up with some ways of speeding things up a bit
[00:16] <peitschie> i did notice that the process seems to be very heavily cpu bound... but it's only single-threaded
[00:18] <peitschie> as far as you know, does reconcile require sequential repair work (i.e., the next revision requires all previous revs to be fixed) or are chunks of it disconnected (i.e., multiple revs could be farmed out to be repaired by each core and then updates sequentialized back to the main thread)?
[00:21] <poolie> normally you should only need to run it to recover from a previous problem?
[00:21] <poolie> did someone or some program actually tell you to run it?
[00:21] <poolie> i think it probably could be parallelized
[00:34] <peitschie> poolie: at the moment I'm still trying to recover from https://bugs.launchpad.net/bzr/+bug/522637 and https://bugs.launchpad.net/bzr/+bug/485601
[00:35] <peitschie> poolie: I ran reconcile last weekend, but found someone checked in on monday without getting the "reconciled" repo... which broke things again
[00:35] <peitschie> poolie: because of the amount of time it takes to run things, I don't have a big enough space to really do a full reconcile during the week, as it takes a full day to do it :)
[00:36] <peitschie> it's one of the things I think is important to a corporate environment... any repair job needs to be able to happen over night
[00:36] <peitschie> because I know programmers a not infallible, and there is always a chance there will be another repo-breaking bug...
[00:37] <peitschie> i've been considering spending some time trying to speed up reconcile, so recovery from future bugs of this nature can be achieved during the working week without stopping all dev work during the day
[00:37] <poolie> :?
[00:37] <poolie> yuck
[00:37] <poolie> one good way to start might be to be able to select particular types of reconciliation to do
[00:38] <peitschie> yep... those were some of the other things i was going to look at
[00:38] <poolie> similarly for check for that matter
[00:39] <peitschie> i figured a lot of time is likely spent calculating sha's and similar tho as well... so if I can potentially just multi-thread *that* part slightly, I think there might be a reasonable gain to be made
[00:40] <peitschie> I started playing with some profiling last night to see, so I don't really have any clear ideas on it yet :)
[00:40] <peitschie> but just thought i'd ask in case you were aware of much around it :)
[00:42] <peitschie> the other thing i'm considering is how we might potentially be able to generate more useful debug information for the previously listed bugs as well
[00:42] <peitschie> in the case of both of those, they have proved exceedingly hard to track down and verify because of the requirement of having it occur on a publically available repo
[00:43] <peitschie> again... i have no real plans at this point... just pondering some things that would make my adoption here a little less risky a prospect
[00:44] <poolie> mm, again maybe having a task-specific check output some non-sensitive debug data would be good
[00:44] <poolie> it's a bit hard to predict ahead of time what would be useful
[00:44] <poolie> but it is possible
[00:44] <peitschie> i figured that there is always some things taht would be missed
[00:45] <peitschie> i'm wondering if perhaps dumping things like revision history, sha's, ancestry... i.e., mainly the repo and branch histories might be sufficient to get a head-start
[00:46] <peitschie> my thought is to try and work out what info would have helped track down the previously listed bugs... see how hard it is to produce... then potentially wrap that up in a command/tool of some sort (potentially even as part of check)
[00:46] <poolie> that would be good
[00:46] <peitschie> so even if we don't get everything next time, *hopefully* future issues like these (that seem to revolve a bit around shared repo => shared repo) might be a bit easier to track
[01:45] <dOxxx> Good evening.
[01:46] <dOxxx> Anybody here know about bzr-explorer internals?
[01:46] <poolie> hi there
[01:46] <dOxxx> In particular, the way it invokes qbzr commands?
[01:46] <poolie> not a lot, but what's up?
[01:46] <dOxxx> I'm working on my mergetools thing and it looks like explorer is using my system installed bzr to run qbzr commands instead of the dev version of bzr that I invoked explorer with.
[01:47] <dOxxx> So I get an ImportError because my qbzr references a module (mergetools) which doesn't exist in bzr 2.2.0
[01:48] <dOxxx> but which does exist in my dev bzr
[01:48] <poolie> hm, interesting
[01:48] <poolie> that sounds right
[01:48] <poolie> hi, spiv, so what are you up to today?
[01:48] <dOxxx> poolie: what sounds right? that it uses the system bzr to invoke qbzr?
[01:49] <poolie> i mean, that sounds like a correct diagnosis, but i agree it's a bug
[01:49] <poolie> it should use the matching version, i would say
[01:49] <dOxxx> poolie: http://paste.ubuntu.com/507655/ is the relevant section of bzr.log if you could double-check my diagnosis?
[01:51] <dOxxx> I'll be damned if I can think of how to search for this bug to see if it already is known :)
[01:55] <poolie> i don't recall hearing of it
[01:56] <poolie> dOxxx: i think there is a bzr symbol to find the right executable
[01:56] <poolie> because the tests do the same thing
[01:56] <poolie> i'd just file a new bug; we can always dedupe later
[01:56] <dOxxx> I thought I remembered some discussion about it on the bzr mailing list in the last month or two.
[01:56] <dOxxx> yeah I'm typing up the bug now
[01:56] <spiv> poolie: so far mainly catching up on a week's worth of email
[01:57] <poolie> oh, wow
[01:58] <poolie> it has been a while
[01:58] <poolie> good luck :)
[02:00] <poolie> dOxxx: if you want to talk about where the bug is or how to fix it just ask, otherwise i'll leave it with you
[02:01] <dOxxx> poolie: no I'm good, just writing it up. :)
[02:01] <spiv> Thanks :)
[02:34]  * spiv -> food
[03:16] <mkanat> Is there a plugin that will just run a particular external command before "commit"?
[03:20] <lifeless> sure there is a externals hook plugin
[03:20] <lifeless> or you can just trivially do a custom one yourself.
[03:31] <mkanat> lifeless: Yeah, I figured it would be trivial, I just wanted to know if it already existed.
[06:43] <poolie> spiv, what do you think we should do about news?
[06:43] <poolie> one news file per series?
[06:44] <spiv> I think so.
[06:49] <poolie> do you want to split it up then, while you're there?
[06:50] <spiv> I can do that, what's the exact path names you're after?
[06:50] <poolie> hm, possibly we should just move it into doc/en now, and perhaps just leave a pointer in news?
[06:50] <poolie> that would be similar to whatsnew
[06:50] <poolie> and everything else
[06:50] <poolie> s/in news/in NEWS in the root
[06:51] <poolie> whatever we do, we'll need to update the doc builds rules
[06:52] <spiv> Right.
[06:52] <spiv> It would be nice to have something fairly visible in the root.
[06:52] <spiv> But not nice to accumulate clutter for every historical release in the root.
[06:53] <spiv> I suppose we could have the current series in /NEWS, and everything else in doc/en/old-news/*, but that feels a bit weird.
[06:53] <poolie> istm just a pointer there would be ok
[06:53] <spiv> Ok, phew :)
[06:54] <spiv> I'll do that.
[07:05] <vila> hi all !
[07:05] <spiv> Hey vila!
[07:05] <vila> spiv: Welcome back !
[07:06] <vila> spiv: can I have paramiko package from your ppa for maverick with my pony ? Pretty please :)
[07:06] <vila> *a paramiko package
[07:10] <spiv> vila: hmm
[07:10] <spiv> vila: I'm not sure at a glance why my last attempt to do so failed: http://launchpadlibrarian.net/52203585/buildlog.txt.gz
[07:11] <spiv> (https://code.edge.launchpad.net/~spiv/+recipe/paramiko-test/+build/340)
[07:11] <vila> spiv: the point is that there is only one test failing on babune for the maverick slave
[07:11] <vila> ha, yeah, I forgot that, you mentioned it at the time though
[07:11] <vila> spiv: sudo build-my-package ?
[07:13] <vila> spiv: hmm, rather obscure... "they" did manage to build it for maverick so there should be a way...
[07:13] <spiv> I'll hit the button again and we'll see what happens.
[07:13] <vila> aptitude command not found ??
[07:13] <poolie> hello vila
[07:14] <vila> hey poolie, hopefully I'd feel better today :-/
[07:14] <poolie> and do you?
[07:14] <vila> well, so far, yes
[07:14] <vila> but yesterday and the day before I went down without notice :-/
[07:16] <fullermd> Maybe the universe is corrupted.  Look at the checksum?
[07:17] <vila> quantic checksums make my head hurt, bad idea
[07:18] <fullermd> Just pick a worldline where they don't.
[07:18]  * vila facepalms
[07:18] <vila> ouch
[07:18] <fullermd> Also, don't smack yourself.  It hurts less that way   8-}
[07:20] <spiv> vila: apparently it built and uploaded okay this time
[07:20] <vila> fullermd: you should have said so earlier
[07:20] <vila> spiv: yeah just noticed !
[07:21] <fullermd> Well, I did.  You just heard me later.  Speed of light and all that, y'know.
[07:24] <vila> fullermd: yeah sound travels slower than light around here
[07:25] <fullermd> Naturally.  Sound is heavy.  Light is...  well, you know.
[07:26] <vila> spiv: http://ppa.launchpad.net/spiv/packaging-test/ubuntu/dists/ not updated yet, I suppose I should wait a bit
[07:27]  * fullermd cranks up his sound to compensate.
[07:27] <fullermd> Luckily, nobody around minds if I do that at 0130   :p
[07:27] <vila> spiv: ha right, the details at https://code.edge.launchpad.net/~spiv/+archive/packaging-test/+packages shows that it's still pending publication
[07:28] <vila> fullermd: :)
[07:32] <fullermd> (on that topic, I wish Youtube would sort out their 34/18 formats, so that one was consistently the better, rather than random, or even more often, one having sucky audio and decent video, and the other being the other way around :|  )
[07:46] <mgz> hm, not sure whether to send this to the list or file a bug
[07:46] <mgz> vila: can I request a full babune run on windows of a branch?
[07:46] <vila> mgz: sure, just name it
[07:47] <mgz> http://float.endofinternet.org/bazaar/bzr/hack_get_transport
[07:48] <mgz> sorted out what from your leaks branch was causing me problems, but I'm not sure why it's not broken for other people, or the best way to fix it.
[07:50] <vila> mgz: hmm, looks like your bandwith will suffer :)
[07:50] <vila> mgz: push to lp next time ;)
[07:51] <mgz> it's a five line diff, how badly can bzr... oh, are you not stacking?
[07:52] <vila> mgz: nah, it's ok, I did branch it locally to look at it...
[07:53] <vila> mgz: err, this fix changes what exactly (in behaviour) ? It looks like you're working around some import aliasing bug here
[07:54] <mgz> ha, good guess. I'll post to the list.
[07:55] <vila> mgz: note that the current approach is hackish, we should define a hook triggered when a transport *connects*
[07:56] <mgz> that sounds like a good suggestion.
[07:56] <vila> mgz: running: http://babune.ladeuil.net:24842/job/selftest-subset-windows/8/
[07:57] <mgz> thanks!
[08:03] <mgz> okay, sent email.
[08:17] <poolie> mgz, nice mail
[08:17] <poolie> i thought there already was a way to disable laziness but imbw
[08:17] <poolie> that babune report is great!
[08:18] <mgz> to be fair on that front, by the time I realised it was lazy import causing issues not something else, I didn't need to test anything else
[08:18] <mgz> it was the getting to that point which was the hard bit :)
[08:19] <mgz> (so it may well be that I could have found a way to disable lazy import, if I'd thought to(
[08:20] <mgz> ))
[08:26] <mgz> poolie: can mgordan be added to the contrib agreement group? I landed his first branch already as I got cced.
[08:28] <poolie> will do
[08:28] <bialix> heya poolie, mgz
[08:28] <poolie> hi there
[08:44] <vila> mgz: you run finished: FAILED (failures=2, errors=3)
[08:45] <mgz> not bad for a hack, and 45 mins rather than 77 is the great bit :)
[08:47] <vila> mgz: I see to... what's the message... this test would have hang or something, right ?
[08:47] <vila> s/to/no/
[08:47] <bialix> bonjour vila
[08:48] <vila> which means the leak fixes were correct except they didn't catch some import aliases right ? (I confess I focused on the ones in tests...)
[08:48] <mgz> http://babune.ladeuil.net:24842/job/selftest-windows/190/ <- Took 1 hr 32 min on xp-32bits.local
[08:48] <vila> bialix: hey !
[08:48] <mgz> http://babune.ladeuil.net:24842/job/selftest-subset-windows/8/ <- Took 45 min on xp-32bits.local
[08:48] <vila> right, most probably the cause is that we don't wait for threads to finish anymore
[08:49] <mgz> basically yeah, complete for fix and all the "thread ('<IP_ADDRESS>', 2265) -> ('<IP_ADDRESS>', 2263) hung" goes away
[08:49] <vila> shudder
[08:49] <vila> care to comment on https://code.edge.launchpad.net/~vila/bzr/imports/+merge/36324 ?
[08:50] <mgz> no. :P
[08:50] <vila> I think I failed to convey some hard numbers about time spent to debug such obscure crazyness
[08:51] <vila> anyway, thanks for pointing out the obvious fix, but that's still a hack on top of a hack, so we should implement a hook
[08:52] <vila> I went out of steam on the subject at the time, may be we can pair on this ?
[08:53] <vila> mgz: A most probably related topic being the test suite still can't be run on OSX because some sockets are still leaking, I will try your branch there
[08:53] <poolie> vila can you try to help a bit with reviews/landings?
[08:53] <poolie> i realize i'm pp and i've done some but it's still queued
[08:53] <vila> poolie: yup
[08:53] <vila> poolie: I think it's fine that PP ask for help when needed
[08:55] <mgz> ^I agree merging namespaces can cause bugs like this, but it's also useful. I don't think we can coding style it away.
[08:55] <poolie> hm, i just did a parallel test and got ebadf again
[08:55] <vila> poolie: and I wonder if we should not *all* focus on getting the queue back into control, it's awesome to have so many contributions but it will collapse fast if we don't address them
[08:55] <vila> poolie: for an https one ?
[08:56] <poolie> vila, sftp actually, inside paramiko
[08:56] <mgz> I'll happily have a crack at fixing this the right way, especially if you're offering help/
[08:56] <poolie> running parallel=fork seems to be the only time my machine's fan spins all the way up :)
[08:56] <vila> hehe
[08:56] <poolie> it would probably be an even stronger effect on apple hardware
[08:56] <mgz> vila's the one most in need of reviewing I think, you'll need to press gang someone else as well :)
[08:56] <vila> poolie: sry I can't remember without a tracback, what's the failing test ?
[08:57] <poolie> i appreciate yours
[08:57] <spiv> I have a pselftest='selftest --parallel=fork' alias
[08:57] <vila> spiv: tss
[08:57] <vila> :)
[08:57] <poolie> vila, for the ebadf thing?
[08:57] <mgz> though neil's on a roll too.
[08:57] <vila> spiv: bzr alias tss="selftest --parallel=fork" :-D
[08:58] <vila> poolie: yup
[08:58] <spiv> Hopefully now I'm back from a week of leave + virus I'll be able to help with the queue too.
[08:58] <spiv> Help reduce it, rather than grow it, that is ;)
[08:58] <vila> mgz: and you've helped a lot too, thanks for that
[08:58]  * spiv -> dinner
[08:59] <mgz> I still need a lazr.restfulclient reviewer if anyone can dig one of those up.
[08:59] <vila> poolie: on a related note, we have an RT asking for an upgraded testtools on pqm that seem to be blocked by a desire to upgrade to lucid, I'm a bit lost about the whys here, can you summarize ?
[09:00] <poolie> https://bugs.edge.launchpad.net/bzr/+bug/656170
[09:00] <poolie> vila, sorry, i don't know many specifics
[09:00] <poolie> i know the GSAs are in the process of upgrading some boxes
[09:00] <poolie> suggest you ask in canonical is
[09:00] <vila> BIG RED FLASHING WARNING: lp read-only
[09:01] <poolie> no warning?
[09:01] <vila> poolie: ha, that one, but it doesn't make the test fail right ?
[09:01] <spiv> IIRC when I asked spm last week the RT wasn't blocked, merely some way down the queue?
[09:02] <vila> it's been announced, but I lost a bug report yesterday, so I'm warning others ;)
[09:03] <vila> poolie: I'll comment on the bug, but roughly, yes, it's a bad timing, but no it's really a bug
[09:05] <vila> poolie: the fix would be to catch the exception like we do for our threads, but this one is private to paramiko and injecting our class here can't be done cleanly, so it's way down my TODO list and I would even make the bug importance a wishlist, the test doesn't fail
[09:08] <spiv> vila: i.e. the bug is (partly?) in paramiko?
[09:12] <vila> spiv: hmmm, IMHO, the bug is partly in python: there should be a simpler way to handle exceptions in threads than redefining the Thread class
[09:12] <vila> spiv: and a way to kill a thread by throwing an exception too (and a pony)
[09:14] <vila> spiv: that won't give us a direct way to tell paramiko to ignore EBADF for its threads either though, but that will become easier
[09:15] <vila> the problem here is that we want to ignore this exception before stopping the thread but *not* when starting it
[09:19] <vila> mgz: so the idea for the hook is that we want to replace the hackish overideAttr with a hook that will do roughly the same thing: keep track of the transport and disconnect it when tearing down the test
[09:20] <spiv> vila: you don't need to subclass Thread
[09:20] <spiv> vila: you just need to wrap the function you pass as the target
[09:20] <vila> there is more than one way to do it :)
[09:21] <spiv> vila: unless you mean monkey-patching the threading.Thread globally to change the behaviour of *all* threads... which seems risky.
[09:21] <vila> spiv: the most convenient is to be able to say to a running thread: from now on, swallow these exceptions
[09:22] <spiv> I mean, it is a bit weird to me that the main thread has sys.excepthook, and the other threads don't.
[09:22] <spiv> Just because it's inconsistent.
[09:22] <spiv> (Or does sys.excepthook intercept unhandled exceptions from all threads...?)
[09:22] <vila> interesting approach...
[09:23] <spiv> (Nope, it doesn't.)
[09:23] <vila> too bad :-/
[09:24] <spiv> But anyway, in principle you don't need any special facility to deal with top-level exceptions.  You can already write "try: ...; except: top_level_exc_hander()" at the top-level of the code.
[09:25] <vila> spiv: for a third-party library ?
[09:25] <spiv> Well, how a 3rd-party library runs its threads is ideally its own business.
[09:26] <vila> hehe
[09:26] <spiv> It's like how you can't really add logging to a 3rd-party library from the outside
[09:27] <spiv> Either it already does that (and ideally allows you to have some control over where/how much it logs), or it doesn't and you need to get it fixed upstream.
[09:36] <vila> spiv: right, in this sense, yes, this could be seen as a paramiko bug, but given the time it takes for your fix about the wrong address families to be taken into account, I'm not holding my breath for something that impact only tests :-(
[09:38] <spiv> vila: well, being clear about the causes and deciding what to do about the problem given the circumstances are different issues.
[09:38] <spiv> vila: maybe there's a workaround we ought to do, but that doesn't magically make it not paramiko's fault :)
[09:41] <vila> well, paramiko rightly raises the EBADF exception, *we* want to be able to ignore it in *some* cases and even there, we change our mind *after* asking paramiko to start its thread
[09:41] <vila> that's the cause
[09:41] <vila> there is indeed more than one way to deal with it
[09:43] <vila> and like the other problems encountered with the leaks, the fact that we run the server and the client in the same process is something that hasn't been taken into account in the design
[09:44] <vila> it works better for paramiko than for SocketServer though
[09:45] <spiv> vila: the bug isn't that paramiko raises EBADF, it's that it spews it to stderr rather than giving the app a chance to know about it.
[09:46] <spiv> Probably the obvious thing for paramiko to do would be log the exception.
[09:46] <vila> spiv: well, if I was the paramiko author I could answer: hey, that's Thread that is spewing on stderr :-P
[09:46] <spiv> Seeing as it already uses the logging module.
[09:46] <spiv> Sure, that's the mechanism.
[09:46] <spiv> But that doesn't make "unconditional spew on stderr" the right behaviour for a library.
[09:47] <vila> and whatever happens in this thread is supposed to be conveyed to the user via the channel object (or whatever, don't remember the details)
[09:48] <spiv> (Especially given that in general paramiko takes a fair bit of care to use logging rather than unconfigurable spew on stderr)
[09:48] <vila> spiv: my suspicion is that reproducing this without running the server and the client in the same process is non trivial (if possible)
[09:49] <spiv> Sure, I'm not arguing about that point.
[09:50] <Glenjamin> do you know where abouts in the paramiko code it's printing directly to stderr?
[09:50] <spiv> (In fact, if robey had encountered it himself already I bet he'd have fixed it to be suppressed or logged, rather than let the Python threading bits spew it to stderr)
[09:51] <vila> Glenjamin: lol, nowhere in this specific case, it's a side effect of using a thread and having an uncaught exception bubbling up to the top level
[09:51] <Glenjamin> that sounds broken
[09:53] <Glenjamin> the thread's exception has nowhere to bubble up to, and can't kill the master process i guess?
[09:55] <spiv> It doesn't kill the main thread, no.
[09:55] <spiv> The Python VM just writes a traceback to stderr when an unhandled exception happens in a thread.
[09:56] <spiv> So if you don't want that, make sure you never have unhandled exceptions in your thread.
[09:56] <vila> well, that's my main grief against python threads, the interpreter takes a great care to handle them but the exception handling is left to the user, requiring him to be ready for it in the function given to the thread
[09:56] <spiv> Which isn't that hard, really.
[09:56] <Glenjamin> So the only fix is to wrap the thread contents in an except block
[09:56] <spiv> vila: I really don't see the difference with the main thread
[09:57] <vila> well, the exception in the thread is not propagated there for one
[09:57] <vila> so if you change your design to use threads your callers are suddenly doomed
[10:01] <spiv> Propagated where?
[10:01] <spiv> They have a separate call stack, that's kinda the point ;)
[10:06] <vila> I started a thread, I want a simple mean to know that something bad occurred
[10:07] <spiv> vila: you started the thread, so you can
[10:07] <spiv> vila: just pass in a function that reports that
[10:07] <vila> mgz: wooohhoooo, yeeeehaaa, test suite passes on OSX ! Pfew, my last attempt was depressing, I thought there was some more unknown leaks...
[10:08] <vila> spiv: that's not simple enough, see my previous point: callers have to care now
[10:08] <spiv> It's not hard to write a generic wrapper ("try: foo(); except: report_error()") to help you
[10:08] <mgz> vila: you're better than you thought you were :)
[10:09] <vila> mgz: yeah, something like that ;)
[10:09] <mgz> spiv: isn't the problem that it's not "you" it's paramiko, and we can't raise the maintainer currently anyway
[10:09] <spiv> So that your start thread call becomes Thread(target=err_wrapper, args=(func,)) rather than Thread(target=func)
[10:09] <spiv> Which isn't exactly onerous.
[10:09] <vila> spiv: and you also need to provide this to the caller which itself, etc
[10:09] <spiv> I mean, it would be nice to have it more convenient.
[10:10] <vila> exactly
[10:10] <spiv> Perhaps even have Thread.get_result that blocks (i.e. calls join), and then either returns the value the target func returned, or reraises the exception it terminated with.
[10:10] <spiv> (And in Twisted, you can use blockingCallFromThread for something like that)
[10:11] <mgz> ..or are we on testing now, not the EBADF bug?
[10:11]  * mgz went off to get food
[10:11] <spiv> But it's really not hard to roll your own :)
[10:11] <spiv> mgz: right, the problem is in paramiko, that's my point :)
[10:12] <vila> mgz: and I argue that paramiko can point the finger at python :)
[10:12] <vila> ThreadWithException was my answer for bzr :)
[10:12] <spiv> Eh, it can point the finger at python for making it merely simple, rather than trivially easy.
[10:13] <vila> ..where the exception is re-raised by join()
[10:13] <spiv> So pardon me if I don't consider that a great excuse :)
[10:15] <vila> spiv: well, if you require all thread users to implement such a mechanism, why not implementing it in thread ?
[10:16] <vila> spiv: the try/except/finally is not always enough, you also need a guarding event in most cases and this event should be set to ensure the caller is not blocked
[10:17] <hrw> hi
[10:18] <vila> mgz: to be precise, there are still 3 failures on OSX (plus some tweaks of LC_ALL) but at least it *completes*
[10:18] <vila> mgz: which is *huge* from my POV :)
[10:18] <spiv> vila: the standard library has many deficiencies
[10:18] <spiv> vila: this is just one of them :)
[10:19] <hrw> I have been trying to use git-bzr-ng plugin to get two way git<>bzr bridge so I will not have to learn bzr and can use git for it. clone works but push works only if there were no changes done. push with change ends with http://pastebin.com/XA8LJgVv reported.
[10:19] <hrw> can someone look at pastebin and comment?
[10:23] <hrw> it works when changes are pushed to new bzr branch but not when pushed to existing one
[10:25] <vila> hrw: by git-bzr-ng you mean bzr-git ?
[10:25] <hrw> no
[10:26] <vila> hrw: and you seem to be using bzr-fast-import...
[10:26] <hrw> http://github.com/termie/git-bzr-ng/
[10:26] <hrw> git-bzr-ng uses bzr-fast-import in backend
[10:26] <hrw> bzr-git is to get git repo in bzr. git-bzr-ng is to get bzr repo in git
[10:27] <vila> hrw: why don't you try to use bzr-git instead ? I never heard about git-bzr-ng so I'm not sure you get a lot of answers in *this* channel...
[10:27] <hrw> vila: http://marcin.juszkiewicz.com.pl/2010/10/06/bazaar-what-is-wrong-with-it/ summaries my feelings about bzr
[10:28] <hrw> vila: in short: I do not like bzr.
[10:28] <vila> hrw: I'm not discussing whether you like bzr or not, just trying to point you to the right place to get the right answers
[10:28] <hrw> sure
[10:29] <vila> but coming here saying that don't like what we do doesn't sound like the best start :) Welcome anyway
[10:31] <hrw> I know - just wanted to ask for help to understand where from error comes.
[10:33] <vila> the traceback tells it's from fast-import, try adding BZR_PDB=1 in front or your command and poke at parts and self_git_to_bzr_name for a start
[10:33] <hrw> thx, will check in few minutes
[10:34] <mgz> vila: to be clear, mac osx needs hack_get_transport to complete, or have you just not tried since your previous fixes?
[10:35] <vila> mgz: I tried with my fixes, the hack is needed, so the remaining leaks were caused by calls to the original get_transport, defeating the override
[10:36] <mgz> ha.
[10:36] <vila> mgz: I ran with the hack and a live open-files windows and I never seen such a clean run :)
[10:36] <mgz> yeah, we're getting there!
[10:37] <mgz> a bit more chipping away and we'll have a clean suite on all the platforms we try and support
[10:37] <vila> your hack ensures get_transport is properly overridden so it validates all the fixes, I just wished I thought about it myself ;)
[10:38] <vila> the bit I don't get though, is why this made such a huge difference between windows/OSX on one side and all the other on the other side...
[10:39] <mgz> I'm just answering poolie's question on the list, my understanding is it's how the different socket libraries work
[10:39] <vila> and no cheap joke about proprietary softwares leaking resources :)
[10:40] <vila> mgz: oooh, let's try it on FreeBSD
[10:40] <mgz> and naturally that the tests are written by people on nix, so when there are problems there it's fixed before it ever lands
[10:41] <vila> in the *socket* library...
[10:41] <mgz> windows at least has diverged rather from its start, not sure what osx uses.
[10:42] <mgz> but still worth seeing if we get a speed up on freebsd
[10:43] <txdv> awesume
[10:44] <txdv> git-bzr-ng - ill have to check it out
[10:44] <vila> mgz: yup, that's the idea
[10:45] <mgz> I want to know what the ng is for. Does it do time travel into the victorian age as well?
[10:46] <txdv> there is already some git-bzr hack, so he wanted to make it sound new and cool
[10:46] <vila> hrw: Your post is not very specific about what is missing in bzr, filing bugs at https://launchpad.net/bzr/+filebug would get you more attention and better hope that we address your needs
[10:46] <hrw> ok
[10:47] <txdv> it's missing a proper remote managing interface
[10:47] <mgz> the stuff you said in here the other day was actually more enlightening
[10:48] <txdv> those half backed branches which are tied to remote branches are buggy as shit
[10:48] <mgz> you were trying to adapt your git-y workflow to bzr and struggling
[10:49] <txdv> i can adapt to new bzr'ish workflows
[10:49] <txdv> no problem
[10:49] <mgz> that was aimed at hrw, but either way.
[10:50] <mgz> hacking up a giant change then splitting it into little bits to merge on the current trunk isn't something bzr supports particularly well, but there are ways
[10:57] <Glenjamin> hrw: re: your blog post - the first link on related is a similarly exasperated post about git from 3 years ago (which i presume is when you started using it)
[10:58] <hrw> Glenjamin: yes, related posts are often crazy
[10:58] <Glenjamin> my point being, maybe you'll get used to it :)
[10:58] <hrw> who knows.. maybe in 2014 I will use bzr more often
[11:00] <mgz> heh, good point Glenjamin. I do "graaa, new thing I don't want to adapt to" all the time.
[11:02] <Glenjamin> for instance, I wouldn't generally try and re-organise a patch before trying to get it upstream, i'd just supply a mergable branch
[11:02] <Glenjamin> but presumably cleaning up a patch like this is common in git
[11:02] <mgz> yeah, it's standard workflow for a bunch of projects.
[11:03] <Glenjamin> my assumption is the reviewer would look at the final diff
[11:11] <vila> mgz: 22min on FreeBSD, nothing spectacular nor unseen
[11:12] <vila> unless
[11:12] <vila> no, parallel=fork in both cases
[11:19] <DaffyDuck_`> Hello
[11:19] <mgz> the slowness there does seem to be a little all over from disk access rather than lots in smart server tests, so shouldn't be suprised
[11:19] <DaffyDuck_`> I had some breakage in a repository earlier today, so I thought I'd take the opportunity to upgrade bzr to 2.1.2 (on Windows).
[11:20] <DaffyDuck_`> With the previous (2.0.0) version I got a bazaar directory with a bzr.exe file, but with this new version, I have not bzr.exe.
[11:20] <DaffyDuck_`> ..and not bzr.py along the path.
[11:20] <DaffyDuck_`> Do I need to do some post-installation set up to get a command line "bzr" in Windows?
[11:21] <mgz> okay, #1 did you use the right installer? and #2 were there any error messages during the install process?
[11:21] <DaffyDuck_`> No error -- and I'm certain I used the correct installer.
[11:22] <DaffyDuck_`> Oh, just found it. I think. There's no dedicated bazaar directory any longer, but it has placed a bzr.bat under c:\python26\scripts.
[11:22] <DaffyDuck_`> I assume that's what I'm supposed to use instead.
[11:22] <mgz> called -setup.exe rather than .win32-py2.6.exe right?
[11:22] <mgz> okay, so you did use a different installer.
[11:23] <DaffyDuck_`> Hmm.. I wasn't aware there was more than one. :)
[11:23] <mgz> that's fine (and often actually preferable if you have python installed anyway), but you do need to add the scripts dir to your path manually for some reason
[11:23] <mgz> the actual python installer should do it for you really.
[11:24] <DaffyDuck_`> So the *-setup.exe contains a full python installation too?
[11:24] <mgz> it does.
[11:24] <mgz> and various bundled plugins as well.
[11:24] <DaffyDuck_`> Hm.. Seems overkill since I already had it. Well, that's one mystery less.
[11:25] <DaffyDuck_`> Well, time to get back to work. Thanks for the clarification.
[11:27] <vila> meh, I meant 2.2.1 not 2.1.2 right ?
[11:28] <mgz> you typoing release notices still vila? :)
[11:28] <vila> errr, *he* meant, DaffyDuck_
[11:30] <mgz> nope, I think they really meant 2.1.2 as was upgrading from 2.0
[11:30] <mgz> and had done it long enough ago not to remember the installer looked different last time.
[11:31] <vila> shudder
[11:32] <mgz> okay, so about this hook.
[11:32] <mgz> we want something that runs just before an actual connection is established?
[11:33] <vila> or just after ?
[11:33] <mgz> or a generic transport setup thingy?
[11:33] <vila> no, I think at connection, so that it gets called if we re-connect too
[11:34] <vila> both pre and post can be useful, but I think we want post first
[11:35] <mgz> currently I see there's no one connect method like the disconnect you added, instead it's all connect_something
[11:37] <vila> right, unifying this may come later, since we're talking about connection, the hook may be specific to ConnectedTransport, but generally adding stuff there is not worth avoiding adding it as unimplemented as the Transport level
[11:38] <vila> I mean, define the hook at the Transport level even if it's called only by ConnectedTransport
[11:38] <vila> And ConnectedTransport defines _set_connection that should be used by all relevant classes as part of their connect_something
[11:42] <mgz> hm, yeah, after the connection has been established
[11:42] <vila> yes, post_connect
[12:01] <vila> spiv: ......and lp finally made your maverick package available, I installed it on the babune slave which turned blue for the first time. Pfew, just in time ;)
[12:48] <sender> bzr-svn is giving me problems since a day, bzr pull https+urllib://svn.uitburo.nl/Website/trunk barfs at me: http://pastebin.com/PZUuaHyU
[12:49] <sender> Bazaar (bzr) 2.2.1 / svn 1.0.4
[12:50] <sender> Ideas are very welcome
[12:50] <sender> :)
[13:08] <maxb> hmm
[13:08]  * maxb tries
[13:09] <maxb> oh, private repo
[13:09]  * maxb shrugs
[13:09] <maxb> sender: Your subvertpy version is what?
[13:10] <maxb> (dpkg -l python-subvertpy)
[13:11] <sender> maxb: thanks! 0.7.3-1ubuntu0~bazaar1~lucid1
[13:11] <maxb> hmm. That's recent
[13:12] <sender> It broke yesterday 'all of a sudden', I was using svn 1.0.2, and upgraded.
[13:12] <maxb> In that case, there's a fair chance you've found a bug somewhere
[13:12] <maxb> Is this repository proprietary/confidential?
[13:28] <sender> maxb: well, yes. nothing changed on the repository side...
[13:28] <maxb> nothing, other than new revisions?
[13:32] <sender> maxb: that's right
[13:43] <jelmer> sender: can you try a clone into a fresh repository ?
[13:44] <sender> jelmer: so you mean locally, using bzr branch? or using svn?
[13:50] <jelmer> sender: using bzr branch, but cloning into a fresh repository, not reusing your existing local branch.
[13:53] <sender> jelmer: ok, understood. Trying now
[14:02] <sender> jelmer: taking a while...
[14:02] <sender> jelmer: do you think the local copy has corrupted in a way?
[14:02] <sender> jelmer: bzr check dies with an error aswell..
[14:06] <txdv> muahahahaha die bzr die
[14:07] <sender> txdv: *grin*
[14:07] <jelmer> sender: yes, older versions of bzr-svn had a bug
[14:07] <sender> jelmer: too bad, error (dies) too
[14:07] <jelmer> sender: same error?
[14:09] <sender> jelmer: http://pastebin.com/nNebXdHE
[14:10] <jelmer> sender: hmm
[14:10] <jelmer> sender: can you try again but remove the cache for your svn repository first ? It should be in ~/.cache/bazaar/svn
[14:11] <sender> jelmer: try the branch again?
[14:11] <sender> jelmer:  rm ~/.cache/bazaar/svn/* -Rf ?
[14:12] <sender> jelmer: ok, here goes again
[14:12] <sender> jelmer: thanks for helping me out :)
[14:24] <sender> jelmer: darn, it still crashes after a long time
[14:25] <sender> jelmer: it even throws an ubuntu report the problem thingy, never seen that before. Oh and it complains that the problem cant be reported (typical...).
[14:26] <sender> arg! how am I going to work with this repo again :S
[14:26] <jelmer> sender: what error do you get this time?
[14:27] <jelmer> still the same?
[14:27] <sender> jelmer: what do you exactly want to know? bzr: ERROR: exceptions.AssertionError: 408 != 619
[14:34] <jelmer> sender: so, the last resort is to try lp:bzr-svn and do the fresh clone again (with cache removed). If you can still reproduce it with that, plesae file a bug and I'll have a look at it tonight.
[14:35] <sender> jelmer: ok, thanks. So I go: sander@ubuntu:~/.bazaar/plugins$ bzr branch lp:bzr-svn
[14:35] <sender> Do I need to remove the package bzr-svn?
[14:35] <sender> What version am I pulling in right now? So I can check with bzr plugins?
[14:36] <sender> jelmer: are you Dutch :)
[14:36] <jelmer> sender: bzr branch lp:bzr-svn ~/.bazaar/plugins/svn
[14:36] <jelmer> sender: there's no need to remove the package
[14:37] <jelmer> sender: jup, ik ben ook Nederlands :-)
[14:37] <sender> jelmer: great, now bzr plugins gives me: svn 1.0.5dev :)
[14:37] <sender> jelmer: locale hulp, fantastisch, zeer bedankt!
[14:37] <sender> jelmer: dan zeggen die url's in pastebin je iets meer :)
[14:39] <sender> jelmer: ok here goes again: bzr branch https+urllib://svn.uitburo.nl/Website/trunk uit-website
[14:56] <sender> jelmer: unfortunately, an error again: bzr: ERROR: exceptions.AssertionError: 408 != 619
[14:56] <sender> jelmer: :(
[14:56] <Glenjamin> hrm, what's 619 in base 8?
[14:59] <jelmer> sender: :-(
[14:59] <jelmer> sender: can you try the whole process again after applying http://samba.org/~jelmer/fileids.diff ?
[15:00] <sender> sander@ubuntu:~/.bazaar/plugins/svn$ patch -p0 < fileids.diff \ patching file revmeta.py
[15:01] <sender> jelmer: ~/.bazaar/subversion.conf of any influence?
[15:02] <jelmer> sender: no, that shouldn't be relevant - the cache is, though
[15:03] <sender> jelmer: ok, applied patch, cleared cache, branching again.
[15:30] <sender> jelmer: too bad. bzr: ERROR: exceptions.AssertionError: 408 != 619
[15:30] <sender> jelmer: I don't know what could have changed..
[15:32] <sender> jelmer: can I give you more information to work with in any way?
[15:38] <jelmer> sender: can you at least file a bug about it on launchpad? It's clearly a bug that's still present in current bzr-svn.
[15:38] <jelmer> sender: it would be interesting to have a look at the "svn log --xml --with-all-revprops -v" output of the revision that triggers this issue
[15:38] <sender> jelmer: hope it's not a problem caused by corruption on the repository side... svn checkout seems to work fine
[15:39] <sender> jelmer: how do I proceed to find the revision?
[15:39] <jelmer> sender: I doubt it's a problem on the svn side
[15:39] <jelmer> sender: if you run the command again but set BZR_PDB=1 in the environment it should put you into a python debugger
[15:51] <sender> jelmer: I'm waiting for the svn checkout to finish, it's taking extremely long.
[15:55] <sender> jelmer: I might as well start the branch while it's still running. So: export BZR_PDB=1; bzr branch https+url://svn.uitburo.nl/Website/trunk uitwebsite
[15:57] <sender> jelmer: und jetzt?
[15:57] <jelmer> sender: yep
[15:58] <jelmer> sender: how much python experience do you have?
[15:58] <sender> jelmer: virtually zero :|
[15:59] <lvh> Hello :-)
[15:59] <jelmer> hi lvh
[15:59] <lvh> Can someon reccomend a code review tool for use with bzr?
[15:59] <lvh> So far I've come across lp merge requests, which are super awesome.
[15:59] <lvh> (I'm just scoping out what's available.)
[16:00] <lvh> I've thought about doing code review as commits, since that makes it easy to programmatically verify as well
[16:01] <lvh> (ie, stuff gets proposed for review, I add # XXX: No, fix this in the code)
[16:02] <lvh> the only thing I can think of that would make merge proposals better is a side-by-side view like bzr qdiff or rietveld, but I suppose this is not the right place to suggest that
[16:10] <jelmer> lvh: I don't have experience with the integration in other tools, but I know there's been work done to support bzr in rietveld and reviewboard
[16:11] <lvh> jelmer: Yeah, bzr is supported in rietveld
[17:21] <sender> jelmer: output is getting throttled
[17:22] <sender> jelmer: zie je de output?
[22:00] <poolie> hi all
[22:35] <bzrnewb> hello. i'm planning on using bazaar for a single-user project but I have some questions about how it actually works. Anyone able to enlighten me?
[22:35] <GaryvdM> bzrnewb: sure.
[22:36] <GaryvdM> bzrnewb: Please don't ask to ask, just ask :-)
[22:36] <GaryvdM> Hi poolie
[22:37] <bzrnewb> cheers. I want to edit and maybe create my own scripts in Unrealscript for UDK. Everything is under a folder named src in UDK main folder and if I move it somewhere else the engine won't read them.
[22:37] <poolie> hi gary
[22:37] <bzrnewb> so if I set up a repository somewhere else how does it work with these files? are the files stored in repository or remain at the original folder but changes,  etc go to repositroy?
[22:38] <peitschie> mornin all :)
[22:38] <bzrnewb> repository*
[22:38] <poolie> bzrnewb: (nice nick) there are basically two directories you need to know about
[22:38] <poolie> there's the repository, which holds a bunch of pack and index files etc, which stores the history of the project
[22:39] <poolie> and then there's the working tree, which holds the actual checked out copies that you can edit, run, etc
[22:39] <poolie> in your case you just need the working tree to be under UDK
[22:39] <poolie> perhaps the easiest thing is to just do 'bzr init' in that directory then the repo will be there too
[22:39] <GaryvdM> bzrnewb: I would just "bzr init" in that dir. That will create the working tree and repo there
[22:40] <poolie> then if you want to back it up, you can 'bzr push' from there to somewhere else
[22:41] <bzrnewb> hmm can I select the entire UDK as the worktree and ignore the files/folders I won't need so I can only work with src files I want to edit.
[22:41] <bzrnewb> but also include assets etc.
[22:41] <poolie> yes
[22:42] <GaryvdM> bzrnewb: Yes, with bzr ignore
[22:42] <GaryvdM> or just add the files you do want.
[22:43] <poolie> if you want to ignore most of it and just version a few files, i'd do
[22:43] <bzrnewb> awesome. When I make a change in code does it store the original file somewhere else or does it just save a change history which I can do rollback. Just trying to understand if it will create loads of files for each change and pollute the UDK folder
[22:43] <poolie> 'bzr ignore *'
[22:43] <poolie> (or the equivalent in the gui) then add the rest
[22:43] <bzrnewb> yeah I'll probably stick to gui for now :)
[22:44] <poolie> it stores it into the repo dir, which in your case will be .bzr/repository/....
[22:44] <poolie> in a database
[22:44] <bzrnewb> I tried svn before bazaar and it was a bit complicated which is why I'm trying bazaar, but bazaar sounds a lot easier for single-user use.
[22:45] <mwhudson> i would certainly agree with that
[22:45] <bzrnewb> the whole server thing was overkill for what I'm intenting to do
[22:46] <bzrnewb> does bazaar only support code comparison or can it preview/compare doc, excel and image files?
[22:46] <bzrnewb> like perforce
[22:47] <bzrnewb> or alienbrain
[22:47] <GaryvdM> bzrnewb: bzr qdiff does compare images side by side
[22:49] <bzrnewb> sounds like it's perfect for me. I'll set it up and see how it goes. Thanks for clearing things up for me
[22:49] <GaryvdM> bzrnewb: You can use any diff tool that accepts 2 files with bzr diff --using alienbrain-diff
[22:50] <bzrnewb> cool. I might come back if I run into any problems :) Cheers guys
[22:56] <jam1> poolie: I'm heading out now, but I figured I would at least /wave at you
[22:56] <poolie> hi jam1, thanks!
[22:56] <poolie> have a good weekend
[23:00] <jam> poolie: well, only Thurs here, but thanks for the day off :)
[23:00] <jam> (yes, I plan on working tomorrow)
[23:00] <poolie> i probably won't see you though :)
[23:00] <poolie> so i'm just queueing up the good wishes
[23:01] <poolie> i'm going for a ride tomorrow
[23:02] <mwhudson> jam: hey, btw, can you run 'make lint' in lp-service?
[23:02] <jam> mwhudson: I can before I push again, but not tonight.
[23:02] <mwhudson> there's a bunch of irrelevant stuff, but the unused imports can be fixed at least
[23:02] <mwhudson> jam: fair enough
[23:03] <jam> (spent a fair amount of time getting pyflakes-vim working, since it seems to require a new python which requires a new vim, ...)
[23:04] <mwhudson> argh
[23:05] <jam> mwhudson: I'll probably be back around in another hour or so, would it be possible to work with you a bit and tie up any loose ends here?
[23:05]  * jam really leaves for now
[23:05] <mwhudson> jam: should be, give me a ping
[23:09] <GaryvdM> mwhudson: Is there a way to get pydoctor to syntax a bit of example code? The rst docs suggest .. python::, but that does not work in pydoctor
[23:10] <GaryvdM> *syntax highlight
[23:10] <mwhudson> GaryvdM: uh, don't know off hand
[23:10] <mwhudson> GaryvdM: you are using --docformat restructuredtext i assume?
[23:11] <GaryvdM> mwhudson: Yes
[23:11] <mwhudson> GaryvdM: and what does 'does not work' mean, doesn't highlight or errors?
[23:12] <GaryvdM> mwhudson:  I assume that  --docformat restructuredtext is what is used for http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html
[23:12] <mwhudson> GaryvdM: it is
[23:12] <GaryvdM> mwhudson: Does not highlight
[23:14] <GaryvdM> mwhudson: Ok, don't worry. I'll dig a bit myself.
[23:14] <mwhudson> GaryvdM: if it's doing the highlighting with css it might be generating the appropriate output but pydoctor isn't including the necessary css?
[23:14] <mwhudson> GaryvdM: view source should make that pretty clear
[23:14]  * GaryvdM checks
[23:16] <GaryvdM> mwhudson: nope.
[23:16] <mwhudson> hm
[23:16] <GaryvdM> mwhudson: I think that .. python:: is maybe a feature of spinx
[23:17] <mwhudson> ah, that could be
[23:17]  * GaryvdM tries to find where me read that
[23:17] <mwhudson> but i'd really expect it to blow up in that case
[23:24] <GaryvdM> mwhudson: Oh - It was in the eypdoc docs: http://epydoc.sourceforge.net/manual-othermarkup.html#colorized-snippets-directive
[23:25] <mwhudson> GaryvdM: well pydoctor uses the epydoc routines to do the formatting, so i've no idea why that wouldn't work
[23:25]  * GaryvdM tests if it works in eypdocs
[23:35] <GaryvdM> mwhudson: Ah - It is working, but it dose not highlight much, and css missing. I try submit a patch for the css.
[23:36] <mwhudson> GaryvdM: ah


[14:45]  * lamont grumbles at -m multiport apparently not liking ipv6 very much
[14:45] <lamont> (iptables)
[15:18] <bullgard4> What tools does Ubuntu provide to low-level query the SMBus?
[15:23] <amitk> bullgard4: i2c-tools?
[15:27] <bullgard4> amitk: packages.ubuntu.com doesn't know anything about 'i2c-tools' for Gutsy.
[15:34] <amitk> bullgard4: aah.. I am on Hardy
[15:35] <bullgard4> amitk: Are you going to tell me that Hardy will provide a DEB program package 'i2c-tools'?
[15:35] <amitk> bullgard4: run 'apt-cache search i2c'
[15:36] <amitk> bullgard4: I am telling you it is already available in hardy :)
[15:36] <bullgard4> amitk: Excellent! Thank you very much for the good news.
[15:38] <bullgard4> amitk: http://ubuntuusers.de/paste/46586/
[15:40] <amitk> hmm.. I guess Gutsy didn't have libi2c-dev, python-smbus, i2c-tools, etc. But you could try to compile them from source packages from hardy
[17:30] <ki> ghost ride ittttt!
[18:49] <amitk> jayc: I meant this commit: http://kernel.ubuntu.com/git?p=ume/hardy-ume.git;a=commit;h=1343698dbfde5798b17a56becd663ace088e7cbc
[19:08] <jayc> amitk: so, what's the right way to do it?
[19:11] <amitk> jayc: keep them in separate patches :)
[19:11] <amitk> jayc: I have fixed it now, pushing soon
[19:12] <jayc> amitk: ok, patch for a patch :-)
[21:51] <el_cubano> Hello.  I am trying to build the lustre modules for the 2.6.22 kerne.  However, there appear to be some changes because of the AppArmor patch which prevent the lustre modules from actually building.
[21:51] <el_cubano> Would someone be able to give me a pointer on how to go about removing the AppArmor patch entirely?
[22:35] <johanbr> Shouldn't 2.6.24-10 have appeared in the archive by now?
[22:40] <amitk_> johanbr: lum/lrm still need building
[22:40] <alex_joni> el_cubano: you probably want apt-get source linux-source-...
[22:40] <alex_joni> then check the patches dir, and remove the patch you don't want
[22:41] <johanbr> amitk_: Oh, I see. Thanks.
[22:46] <el_cubano> alex_joni: Really?  There is no patches dir when I apt-get the source.  That is why I am asking for help here.
[23:03] <alex_joni> el_cubano: you probably did apt-get install linux-source..
[23:11] <el_cubano> alex_joni: No.  I did 'dget -x http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.22/linux-source-2.6.22_2.6.22-14.52.dsc'
[23:11] <el_cubano> BTW, I am a Debian developer.  I know the difference between 'apt-get install' and 'apt-get source'
[23:12] <mjg59> There is no patch system
[23:12] <mjg59> It's maintained as a git tree
[23:13] <alex_joni> el_cubano: you should listen to mjg59 :)
[23:15] <mjg59> el_cubano: You can grab it from git on kernel.ubuntu.com and then revert any of the apparmor commits
[23:26] <el_cubano> mjg59: Is there an easy way to see which are the app armor commits?  Or do I just need to read the logs.
[23:26] <mjg59> el_cubano: Probably just the logs, I'm afraid
[23:35] <el_cubano> mjg59: OK.  Thanks.


[03:30] <Bashing-om> 20
[11:27] <cpaelzer> sarnold: eslerm: pre-reminder for https://bugs.launchpad.net/ubuntu/+source/libnet-ip-perl/+bug/2039456/comments/2 into a discussion in tomorrows meeting
[11:27] -ubottu:#ubuntu-meeting- Launchpad bug 2039456 in libnet-ip-perl (Ubuntu) "[MIR] libnet-ip-perl (as libmail-dmarc-perl dependency)" [Undecided, Incomplete]
[19:00] <kanashiro> o/
[19:00] <lvoytek> o/
[19:01] <seb128> hey
[19:02] <bdmurray> o/
[19:03] <seb128> anyone wanting to lead that one (I've said that before but we should really have rotating chairs defined in advance to avoid those akward slow meeting starts)
[19:03] <teward> *yawns* not me.
[19:03] <seb128> anyone wanting to chair today?
[19:03] <bdmurray> I would but have a hard stop at the top of the hour for an interview.
[19:04] <seb128> #startmeeting Developer Membership Board
[19:04] <meetingology> Meeting started at 19:04:39 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[19:04] <meetingology> Available commands: action, commands, idea, info, link, nick
[19:04] <seb128> ok, let me take that one and get started
[19:05] <bdmurray> thanks seb128
[19:05] <seb128> let's start with the application review since we have one today
[19:05] <seb128> #topic Ubuntu Core Developer application for lvoytek
[19:06] <seb128> lvoytek, hey, welcome, do you want to maybe start by introducing yourself?
[19:06] <seb128> #link https://wiki.ubuntu.com/LenaVoytek/UbuntuCoreDeveloperApplication
[19:06] <lvoytek> Hi all! I'm Lena Voytek. I am from Arizona, USA, and I work for Canonical as a part of server distro. I have been on the team for just over two years, and gained server package upload permissions in January.
[19:07] <seb128> great, thanks lvoytek!
[19:07] <seb128> let's start with questions for lvoytek
[19:08] <seb128> has anyone questions they would like to ask?
[19:09] <kanashiro> since Lena is a colleague of mine and I already endorsed her application, I'll let the questioning for the others :)
[19:10] <seb128> the wikipage is quite detailled, good work, I think that cover most of the aspect of work needed by a coredev
[19:10] <lvoytek> thanks :)
[19:10] <seb128> let me still ask one
[19:11] <seb128> lvoytek, could you tell us what are the different freezes in the Ubuntu release cycles and where you could find their dates?
[19:11] <lvoytek> Sure thing, you can find them here for noble specifically: https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649, I'll list them out
[19:12] <lvoytek> Feature freeze is when new content (non bug fix) items need to be in, unless you go through the FFe process
[19:13] <lvoytek> Debian import freeze (same day) is when packages from debian stop syncing automatically
[19:14] <lvoytek> Others are self explanatory but I can go further if needed. The other important one for me is beta freeze, where we pause changes to focus on beta testing week
[19:14] <lvoytek> Ah then of course final freeze where the release pocket freezes and things go to updates after
[19:15] <seb128> is there any acception to the final freeze rule you just described?
[19:16] <seb128> and no need to details the other freezes
[19:16] <lvoytek> Only critical/security related bugs can go out after final freeze
[19:16] <lvoytek> or other exceptional circumstances
[19:17] <seb128> thanks
[19:17] <bdmurray> rbasak mentions your plan to defer updating MySQL for noble. Could you provide some more details about what lead you to such a decision?
[19:17] <lvoytek> Ah yeah I sent out an email about that today
[19:18] <lvoytek> Basically MySQL 8.4 is the next LTS but it comes out in April, so there's no possible way to get it into Noble on time, so we have to stick with 8.0, which at least is in support for 2 more years
[19:19] <lvoytek> 8.2/8.3 are interrim releases and not advisable for an LTS
[19:21] <bdmurray> Okay, that sounds very reasonable to me.
[19:22] <seb128> any other question for lvoytek?
[19:23] <bdmurray> None from me
[19:23] <seb128> not from me
[19:23] <seb128> teward, any from you?
[19:24] <seb128> seems not, let's go to vote then!
[19:25] <seb128> #vote Grant CoreDev to LenaVoytek
[19:25] <meetingology> Please vote on: Grant CoreDev to LenaVoytek
[19:25] <meetingology> Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname')
[19:26] <bdmurray> +1 I really appreciated the amount of details in your application, it made reviewing it quite easy.
[19:26] <meetingology> +1 I really appreciated the amount of details in your application, it made reviewing it quite easy. received from bdmurray
[19:26] <seb128> +1 from me, I think the work described on the wiki is quite high standard and there are a number of solid endorsements
[19:26] <meetingology> +1 from me, I think the work described on the wiki is quite high standard and there are a number of solid endorsements received from seb128
[19:28] <seb128> teward, kanashiro ?
[19:29] <kanashiro> I was waiting for teward to be the last one
[19:29] <kanashiro> +1 , not much to add :)
[19:29] <meetingology> +1 , not much to add :) received from kanashiro
[19:30] <seb128> ok, now it's annoying, we need teward to vote to have the quorum right?
[19:31] <kanashiro> I think so
[19:32] <seb128> he was around at the start of the meeting, unsure if we should wait a bit longer on him to return or not :/
[19:33] <arraybolt3> Knowing him he probably got sucked into a meeting that will end a few seconds after the DMB meeting (though I just tried to ping him over Telegram elsewhere to get his attention)
[19:33] <seb128> arraybolt3, thanks
[19:33] <seb128> let's wait one more minute...
[19:35] <seb128> ok, seems he's not around, maybe we can try to do another vote before the end of the meeting if he shows up, otherwise we will have to continue via emails to reach a decision
[19:35] <seb128> #endvote
[19:35] <meetingology> Voting ended on: Grant CoreDev to LenaVoytek
[19:35] <meetingology> Votes for: 3, Votes against: 0, Abstentions: 0
[19:35] <meetingology> Motion carried
[19:36] <seb128> lvoytek, thanks, and sorry we don't have a decision yet for you
[19:36] <lvoytek> It's alright, thanks all!
[19:36] <seb128> let's cover the other topics
[19:36] <seb128> #topic Outstanding mailing list requests to assign
[19:37] <seb128> there is https://lists.ubuntu.com/archives/devel-permissions/2023-November/002373.html which already got discussed by the TB previous week
[19:38] <seb128> tsimonq2 was requesting we review arraybolt3's for motu, but the TB conclusion was that Aaron needs to write an application
[19:39] <arraybolt3> (which I'm in the process of doing and intending to submit for the December 11th DMB meeting)
[19:39] <seb128> I would expect that to be also the DMB position unless someone disagrees or has something they want to add?
[19:39] <kanashiro> we had an informal discussion about this last meeting
[19:39] <kanashiro> and we agreed on that too
[19:39] <seb128> ok, so let's move on, that was the only mailing list email which wasn't handled
[19:40] <seb128> arraybolt3, ack, thanks
[19:40] <tsimonq2> seb128: Was that TB or DMB? I don't think I was at the last TB meeting?
[19:40] <seb128> ok, time is flying and I got confused then :p
[19:40] <seb128> sorry
[19:40] <tsimonq2> No worries. I've been sponsoring uploads for arraybolt3 like mad, and he's really getting stronger. I hope you all can review his application soon :)
[19:40] <seb128> I remembered having a recent meeting discussion about it and didn't got back to check logs
[19:40] <seb128> #topic Open TB bugs
[19:40] <seb128> no open bug
[19:41] <seb128> #topic AOB
[19:41] <seb128> any other topics?
[19:41] <bdmurray> The Agenda page lists a meeting on the 25th which I'll remove.
[19:41] <bdmurray> I'll be here for the the 11th will anyone else?
[19:42] <kanashiro> I will
[19:42] <seb128> I will
[19:42] <kanashiro> should we try to fix this chairing issue? Start a rotation to be fair with everyone
[19:42] <arraybolt3> If someone wants to review my preliminary application draft and tell me if there's anything I'm missing that would be handy.
[19:42] <seb128> kanashiro, well, we don't have a quorum, but I will email the list about it
[19:42] <arraybolt3> (obviously it's not finished yet, more packages will be added to the list of 'work I'm proud of' among other things)
[19:42] <seb128> arraybolt3, sure, can you share the url?
[19:42] <arraybolt3> https://wiki.ubuntu.com/ArrayBolt3/MotuApplication
[19:42] <seb128> ack, thanks
[19:42] <arraybolt3> thanks!
[19:43] <seb128> anything else?
[19:43] <kanashiro> thanks for starting the discussion via email seb128 :)
[19:43] <seb128> np!
[19:44] <kanashiro> I think that is it
[19:44] <seb128> right, and teward didn't come back so we will continue the vote via the mailing list, I will send a follow up email
[19:44] <seb128> #endmeeting
[19:44] <meetingology> Meeting ended at 19:44:50 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-11-27-19.04.moin.txt
[19:44] <seb128> thanks everyone
[19:45] <kanashiro> thanks everyone and seb128 for chairing
[19:45] <teward> seb128: sorry i lost my internet for 30 minutes
[19:45] <teward> ISP unexpected outage, but it was traced to a broken fiber node
[19:45] <seb128> hum
[19:45] <seb128> can we do that vote now?
[19:45] <teward> *reads back*
[19:45] <seb128> kanashiro, bdmurray, you are still around if needed?
[19:45] <seb128> teward, ack
[19:46] <kanashiro> yes
[19:47] <teward> ye sorry for apologies for disappearing i'm ready to put my vote
[19:47] <teward> +1 for LenaVoytek's application being granted
[19:47] <seb128> thanks
[19:48] <seb128> I don't think we need to cast another vote through the bot, that should do, unless someone disagrees?
[19:49] <Eickmeyer> You have the chat logs courtesy ubuntulog .
[19:49] <seb128> right
[19:49] <arraybolt3> I mean the bot already thinks the motion was carried so if it's opinion matters it already has the right idea.
[19:49] <seb128> that's good enough for me
[19:49] <seb128> lvoytek, congrats!
[19:49] <lvoytek> :D
[19:49] <tsimonq2> Congratulations lvoytek! 🎉🎉🎉
[19:49] <seb128> and it's a wrap for good this time :)
[19:50] <kanashiro> congrats lvoytek !
[19:50] <lvoytek> thanks!
[19:51] <tsimonq2> Fun fact, as a new member of ~ubuntu-core-dev, you are also now a member of ~canonical-dx-team. :P
[19:51] <kanashiro> seb128 are you announcing and adding Lena to the core-dev group?
[19:51]  * arraybolt3 wonders where on earth tsimonq2 pulls these random factoids from :P
[19:51] <seb128> kanashiro, yes, I'm doing that in a minute
[19:51] <kanashiro> cool :)
[20:01] <seb128> and done now


[04:30] <mup> Bug #1461226 changed: Clicking "Nodes" in 1.8 takes several seconds to load - seems much slower than 1.7.5 <MAAS:Expired> <https://launchpad.net/bugs/1461226>
[04:33] <mup> Bug #1461226 opened: Clicking "Nodes" in 1.8 takes several seconds to load - seems much slower than 1.7.5 <MAAS:Expired> <https://launchpad.net/bugs/1461226>
[04:42] <mup> Bug #1461226 changed: Clicking "Nodes" in 1.8 takes several seconds to load - seems much slower than 1.7.5 <MAAS:Expired> <https://launchpad.net/bugs/1461226>
[12:22] <vibol> Hello, anyone here i just have a really simple question here


[00:36] <Makyo> gary_poster, bcsaller I proposed but never merged.  Want to just include my change, bcsaller ?
[00:36] <Makyo> Fell asleep :(
[00:37] <Makyo> I'll keep QAing tonight, though
[00:37] <bcsaller> Makyo: I haven't seen it yet, but am happy to look. I've been working through test failures here
[00:38] <Makyo> bcsaller, Okay,  https://codereview.appspot.com/14430061/ lp:~makyo/juju-gui/coords - gary_poster QA'
[00:38] <Makyo> qa'd for initial rendering of services with annotations
[00:38] <Makyo> (though if your branch gets that incidentally, nvm)
[00:39] <bcsaller> that was a good find, I have tried to remove the whole hasBeenPositioned case and leave the annotations in place to know that (but haven't been able to convince the tests of this yet)
[02:15] <rick_h_> huwshimi: ping
[02:16] <huwshimi> rick_h_: Hey
[02:16] <rick_h_> huwshimi: hey, can you dump out what services is in your code sample?
[02:16] <huwshimi> rick_h_: Sure, one sec.
[02:16] <rick_h_> huwshimi: the token doesn't take a model, it has to be model.getAttrs()
[02:17] <rick_h_> huwshimi: but not sure that a bundle.get('services') will be real charm models either. Looking at that now
[02:18] <huwshimi> rick_h_: services is Object {haproxy: Object, mediawiki: Object, memcached: Object, mysql: Object}
[02:18] <rick_h_> huwshimi: right, so services isn't really good info.
[02:18] <rick_h_> https://manage.jujucharms.com/api/3/bundle/~bac/wiki/wiki/
[02:18] <rick_h_> huwshimi: check out that bundle and note that the services block is kind of wishy-washy. It might be a branch, it might be a charm store url, it might be a charm name/series
[02:19] <rick_h_> huwshimi: so when you request a bundle from charmworld, it'll provide the charm model details in the charm_metadata key
[02:20] <rick_h_> huwshimi: you have to look in there. It doesn't appear it's in the bundle model atm, but it's used in the view and such it looks like
[02:20] <rick_h_> huwshimi: bzr grep "charm_metadata"
[02:22] <huwshimi> rick_h_: OK thanks, I'll take a look
[02:24] <rick_h_> huwshimi: ok, put notes into the email reply. Let me know if you need more help.
[02:25] <huwshimi> rick_h_: Thanks rick, much appreciated.
[12:09]  * gary_poster starts review & qa of Ben's branch.  Departure in T-26 minutes
[12:09] <gary_poster> s/in/at/
[12:11] <bac> rick_h_: i'm about half-way done with your review.  must relocate right now but will get right on it.
[12:13] <rick_h_> bac: rgr, thanks!
[12:26] <gary_poster> quick hack idea: http://jujugui.wordpress.com/2013/10/15/if-you-want-to-run-a-custom-gui/
[12:29] <frankban> nice!
[13:37] <antdillon> Hey guys, does anyone have some spare time to review my onboarding branch and help land it under a flag?
[13:42] <rick_h_> antdillon: sure thing, paste the merge proposal in here. Can you submit with lbox?
[13:49] <bac> rick_h_: review done.
[13:49] <rick_h_> bac: ty much sir
[13:57] <rick_h_> antdillon: make sure to run 'make lint' in your branch
[13:58] <rick_h_> antdillon: checking out the test run now to make sure I can lbox it up for you
[14:00] <bac> rick_h_: now that we have 'bzr rvsubmit' we may want to start requiring the use of lbox for charmworld.  if we do, we can add a .lbox that does 'make lint'.  that'll prevent late stage, landing failures due to lint.
[14:00] <rick_h_> bac: true, there's a .lbox now just don't think it runs lint
[14:00] <bac> i'm +2 on it.  (me and presuming benji's +1 given previous conversations)
[14:00] <rick_h_> bac: at least I hope that's why it took forevery for my lbox to submit
[14:01] <bac> oh, whee, it has been there all along
[14:01] <rick_h_> antdillon: we're going to have to talk about lint :P
[14:02] <antdillon> rick_h_, Sure
[14:02] <bac> rick_h_: .lbox.check could probably be simplified to 'make check'
[14:03] <rick_h_> bac: ah, good call
[14:03] <bac> i*hate* that we do 'apt-get update' twice!
[14:03] <rick_h_> bac: did we find out if there's any reason?
[14:03] <rick_h_> something for the charm or something?
[14:05] <rick_h_> running through the lint fixes since they're pretty easy, just a bunch of them. Things like proper spacing, lines too long, etc.
[14:05] <rick_h_> antdillon: ^
[14:05] <rick_h_> antdillon: will push up to lbox in a sec
[14:06] <bac> rick_h_: i think they just want to be up-to-date before installing the python-software-properties and then it is required to update again after adding the PPAs.
[14:06] <antdillon> rick_h_, Cool thanks
[14:06] <bac> probably the right thing to do for a clean install but annoying waste of time for devs
[14:09] <rick_h_> antdillon: do you need the JujuBaseView (horrible name of something to get model binding?
[14:10] <antdillon> rick_h_, I dont believe I do, I inherited it from the login view
[14:10]  * bac off to get flu shot.  bbiab with sore arm
[14:10] <rick_h_> antdillon: coolio
[14:10] <rick_h_> bac: ouch, yea mine was sore for 2 days :/
[14:29] <rick_h_> man, lbox hates me today. Timed out 3 times now
[14:32] <gary_poster> hey antdillon.  did you get the info you wanted about flags?  Sorry, was out for a while on a tour of a school for my older son
[14:33] <antdillon> gary_poster, Yeah rick_h_ is on it. Thanks
[14:33] <gary_poster> cool
[14:33] <rick_h_> antdillon: https://codereview.appspot.com/14700043 is your review url
[14:34] <rick_h_> antdillon: will review and add notes. We'll need to rope a second person in on it and go through qa and such.
[14:37] <antdillon> rick_h_, Great thanks
[14:37] <antdillon> rick_h_, I'll wait for a second reviewer and your notes
[14:38] <rick_h_> antdillon: yep, and I'll add notes for the feature flag in my review notes.
[14:38] <rick_h_> antdillon: the reason we're flagging it is that we expect more feedback/changes before we 'release' it to the wild?
[14:39] <antdillon> rick_h_, The main reason is because its not storing the dismiss value so its showing on each reload which would get annoying quickly
[14:39] <rick_h_> antdillon: oh, yea that's not good
[14:56] <rick_h_> antdillon: https://codereview.appspot.com/14700043/ is initial review feedback and one is as not on checking the feature flag.
[14:56] <rick_h_> loading up to qa now
[14:57] <rick_h_> antdillon: and I thought you had a test file? I don't see any test code
[15:00] <rick_h_> antdillon: qa notes added as well
[15:00] <antdillon> rick_h_, No test file im afraid
[15:00] <antdillon> rick_h_, Thanks
[15:01] <rick_h_> antdillon: ok, we'll have to work on that. :)
[15:01] <antdillon> rick_h_, Sure
[15:02] <gary_poster> juju-gui, hadoop charm still broken (broken again!) in comingsoon.  release blocker.  will make critical card asap
[15:02] <antdillon> rick_h_, Should I work through your notes and let you know when my branch is updated?
[15:02] <rick_h_> antdillon: yes please. Let me know if you need to chat on any of them.
[15:03] <antdillon> rick_h_, Will do thanks
[15:03] <rick_h_> antdillon: and once you've got an update I'll pull those down and update this merge proposal. Then we'll get a second review in on the updated branch.
[15:04] <gary_poster> bcsaller, please ping when you are around
[15:04] <bcsaller> gary_poster: I'm around
[15:35] <gary_poster> bcsaller, did a code review as well.  lots of small stuff.  If you would like me to prepare a branch with the trivials, to save you some time, I would be happy to.
[15:35] <gary_poster> (well, there was lots of small stuff, but a few less trivial issues as well)
[15:39] <antdillon> rick_h_, I didn't use CSS hover for the cross icon because its moving the sprite background so I need to change the class on it. Is there a way to use the sprite with :hover?
[15:41] <rick_h_> antdillon: hmm, I missed that. I thought it was just for the hand effect. I didn't notice a cross icon. /me qa's it up again
[15:41] <antdillon> rick_h_, Cool thanks, thought I was missing something :)
[15:42] <gary_poster> j u j u g u i call in 18 (me warms up)
[15:42] <rick_h_> antdillon: any reason we can't just show/hide the panels? and the cross not need to move?
[15:43] <rick_h_> antdillon: ignore me, I'm confused
[15:44] <rick_h_> antdillon: ok, so the sprite X icon. Ugh, ok. Let it be then.
[15:44] <antdillon> rick_h_, Cool, might be nice in the future to have a hander class for sprite interactions
[15:45] <antdillon> handler*
[15:48] <gary_poster> fwiw, the hadoop issue is with the charm, not the gui.  it is the same thing hatch fixed a week or two ago.
[15:48] <rick_h_> phew, not my fault then :)
[15:48] <rick_h_> gary_poster: proof needs <3 then?
[15:49] <rick_h_> gary_poster: or charmworld ingest?
[15:49] <gary_poster> rick_h_, oh, good point.  yeah, proof I guess. the problem is that config option names must not have dots in them
[15:49] <gary_poster> it breaks CLI and GUI in different ways
[15:49] <gary_poster> jujugui call in 10
[15:49] <rick_h_> gary_poster: cool, maybe hit up marcoceppi witha bug while he's in the proof code right now
[15:49] <Makyo> jujugui call in 10
[15:50] <Makyo> !!!
[15:50] <rick_h_> gary_poster: goes 2 for 2!
[15:50] <gary_poster> :-)
[15:50] <rick_h_> while holding a side conversation, impressive
[15:50] <gary_poster> rick_h_, yeah, thanks will do
[15:50] <Makyo> I had it all typed out and everything :(
[15:50] <gary_poster> well, you knowm, you have to keep focus on what's important :-P
[15:50] <rick_h_> lol, I see SFO time being spent on... "guitbot2000"
[15:50] <marcoceppi> gary_poster: I think there's a fix for that already
[15:51] <gary_poster> marcoceppi, there's a fix for the charm that we offered but apparently t has not been merged
[15:51] <gary_poster> Jeff gave it to Kapil--we did not propose
[15:51] <gary_poster> marcoceppi, I can try to get that out there
[15:51] <gary_poster> marcoceppi, but you are saying proof already has that rule?
[15:52] <hazmat> i pushed it out to a charm branch
[15:52] <marcoceppi> gary_poster: there are a bunch of fixes to proof from adeuring, let me check if that was one
[15:52] <gary_poster> thanks marcoceppi
[15:52] <gary_poster> hazmat, yeah, cool.  Could you propose it for merging to official charm?  Or do you want me to?
[15:53] <hazmat> gary_poster, if you could that would be great
[15:53] <gary_poster> hazmat, cool will do.
[15:54] <adeuring> gary_poster, marcoceppi: the charmtools proofer will _not_ check if dots appear in config option names. But that would be easy to add, of course
[15:54] <bac> gary_poster: huw asked me on irc last night about priority for new blingy import/export icon work.  i wasn't at my computer so i didn't reply.  i'd guess it is low but don't know what he's working on.
[15:54] <marcoceppi> adeuring: cool, thanks for the confirmation. I'll just throw that in there
[15:54] <marcoceppi> gary_poster: is that policy anywhere?
[15:55] <marcoceppi> hazmat: ?
[15:55] <gary_poster> marcoceppi, no.
[15:56] <hazmat> marcoceppi, juju docs are the only place they would, most of the rules are encoded as code the core charm implementation, the intent was that proof would remain an independent validation of that implicit spec.
[15:56] <adeuring> seems that we need a way to synchronize the charm docs and the proofer somehow...
[15:57] <hazmat> i dunno that i find that intent very compelling..  its more bugs than reality.. the alternative is to just go ahead and have proof run a simple go program against the charm
[15:57] <hazmat> so that proof is a final word on validity that matches against juju and the store
[15:58] <gary_poster> jujugui clal in 2
[15:59] <gary_poster> or 1
[16:24] <rick_h_> bac oops he ran away
[16:27] <rick_h_> antdillon: very cool, one more comment on your build/browse. Did you verify the QA issue where the mask was acting funny the first two steps?
[16:33] <antdillon> rick_h_, Oh no, must have missed that one
[16:33] <antdillon> rick_h_, Let me take a look
[16:48] <antdillon> rick_h_, Resolved your comment. It's EOD here soon, is there anything you need from me before I head off?
[16:48] <rick_h_> antdillon: looking
[16:49] <rick_h_> antdillon: did you see the one "QA Notes:" ?
[16:49] <rick_h_> antdillon: if you're EOD I'll hit you up in the morning and we can go from there and get this landed tomorrow
[16:49] <rick_h_> antdillon: thanks for the work on it today.
[16:50] <rick_h_> bac: welcome back! fyi updated with comments and code https://codereview.appspot.com/14441069/
[16:51] <antdillon> rick_h_, Got the QA Notes one and replied. Np, thanks for your review today. See ya tomorrow.
[17:02] <gary_poster> frankban, LGTM with a few trivials
[17:02] <gary_poster> have a nice evening
[17:02] <frankban> gary_poster: thanks!
[17:08] <frankban> gary_poster: re "juju switch". I decided to use that because 1) "juju switch myenv" does not change the environment.yaml[default] and 2) ~/.juju/current-environment seemed to me an implementation detail for the thing exposed by "juju switch" (with no args). I agree it feels fragile, I'd like something like "juju switch --format json"...
[17:10] <gary_poster> frankban, sounds good.  file juju core bug tomorrow?
[17:10] <frankban> gary_poster: ok :-)
[17:35] <bac> re-reviewed rick_h_.  looks great.
[17:35] <rick_h_> bac: thanks!
[17:55] <jcastro> gary_poster, I am filing your BPs etc for the sprint, so if you get a ton of spam, I apologize now!
[17:56] <gary_poster> :-) ack jcastro thx
[19:06] <bac> my favorite recent discover is 'pp' in pdb.  for the longest time i would import pprint when i needed it.  silly me.
[19:07] <bac> s/discover/discovery
[19:25] <gary_poster> jujugui, super-duper important sprint activity: update our wordpress blog's background to have new service blocks!  Let's do it!
[19:26] <bac> gary_poster: +1
[19:26] <gary_poster> :-)
[19:26] <Makyo> gary_poster, haha, yeah!  Someone make a pretty openstack deployment!
[19:26] <gary_poster> :-)
[19:30] <gary_poster> OK, a prize for the person who guesses this without looking at blog stats: what country has the most page views of the gui blog in the past 30 days?    Freezing :|
[22:10] <gary_poster> :-/
[22:11] <huwshimi> gary_poster: I'm not sure, I'm going off what Rick said yesterday
[22:11] <huwshimi> gary_poster: And he seemed to think we didn't have the pieces in place yet...
[22:11] <Makyo> Next winter comes slowly pale meager and old, first trembling with age and then quiv'ring with cold. (Why I still have all my Freshman jury music memorized is beyond me...)
[22:12] <gary_poster> I think we may be reading different things huwshimi.  I'm trying to rush but I can probably do a hangout in 5
[22:13] <huwshimi> gary_poster: We can if you like, but this stuff is WAY over my head :(
[22:13]  * gary_poster had to look up to see Makyo's quote was Purcell
[22:13] <gary_poster> huwshimi, ok.  let's talk
[22:13] <gary_poster> soon
[22:13] <gary_poster> ready soon
[22:13] <huwshimi> gary_poster: OK, let me know :)
[22:13] <Makyo> Though Sting did a cover recently, gary_poster :)
[22:14] <gary_poster> Makyo, heh
[22:14] <gary_poster> Makyo, I think I heard that album.  pseudo early music?  my vague memory is "enh"
[22:14] <Makyo> gary_poster, yeah.  It wasn
[22:14] <Makyo> Oop.
[22:14] <Makyo> It wasn't awful, but gosh, Sting's mouth is big.
[22:15] <gary_poster> lol
[22:15] <Makyo> Ditto Bowie.  Words just come tumbling out, tripping over everything in the way.
[22:15] <gary_poster> heh, yeah I think I know what you mean.  I can remember delivering a song in that manner and being less than pleased when I heard the recording
[22:16] <Makyo> And no matter how much Christmas music he sings, he'll always be Feyd Rautha in David Lynch's Dune wailing "Rooooxaaanne!", to me.
[22:16] <Makyo> His past is colorful, I guess.
[22:17] <gary_poster> lol yeah
[22:17] <gary_poster> bcsaller, "Awesome!  LGTM and qa good, with trivial.  Thank you!"
[22:17] <bcsaller> ahh great
[22:17] <gary_poster> oh wait I forgot to try live instance, 1 sec
[22:17] <Makyo> Uh, sorry, reviews.  Will get on that.
[22:21] <gary_poster> bcsaller only one qa problem, and I'm ok with pushing this to another branch (& person) if you wish.  it is kind of important, though.  In a real environment, I did the following: (1) open GUI.  I see GUI service in center.  fine.  (2) drag GUI.  GUI moves around fine. (3) Make mediawiki ghost via drag.  Fine.  (4) drag ghost. Fine. (5) Deploy ghost.  fine.  (6) reload GUI.  Uh-oh: charms are to bottom right, and en
[22:21] <gary_poster> vironment is not panned to center.
[22:22] <bcsaller> hmm
[22:22] <gary_poster> bcsaller, ok with landing without fix, though fix will be necessary from team before release.  Thanks!
[22:22] <gary_poster> huwshimi, I need to go to dinner.  will ping you later.
[22:22] <huwshimi> gary_poster: Sure
[22:23] <bcsaller> gary_poster: yeah, I might have to pass that off, doesn't seem too big though, might have to put the centroid recording back in, I didn't see that case in my qa
[22:33] <rick_h_> gary_poster: huwshimi all good?
[22:34] <rick_h_> gary_poster: huwshimi the api thing was just adding an ATTR to the bundle model if I follow where you're chatting
[22:35] <huwshimi> rick_h_: We were going to try and have a call to figure things out...
[22:35] <rick_h_> huwshimi: k, let me know if there's anything I can do to help. You and I can chat if you want real quick if it unblocks you?
[22:36] <rick_h_> huwshimi: the card isn't very descriptive so not 100% sure what you're heading on. Is there a wireframe you're working from?
[22:37] <huwshimi> rick_h_: Nope, making things up as I go :)
[22:37] <rick_h_> huwshimi: awesome! :)
[22:37] <rick_h_> huwshimi: invite on the way
[22:37] <huwshimi> rick_h_: Essentially we need to display a list of charms and have some what to show their config details as well
[22:37] <huwshimi> *some way
[22:37] <rick_h_> all the charms config details?
[22:37] <rick_h_> huwshimi: https://plus.google.com/hangouts/_/lite/2bdee1ff16f92239f6723ec2db0efd4af3bbde88?hl=en
[22:39] <huwshimi> rick_h_: "You're not allowed to join this video call."
[22:39] <rick_h_> bah
[22:40] <gary_poster> rick_h_, huwshimi may I come by?
[22:40] <rick_h_> huwshimi: try https://plus.google.com/hangouts/_/10fe9c48d75b9ebbe273219cb03f4e53869ce4f7?authuser=1
[22:41] <gary_poster> but take off "authuser"
[22:41] <rick_h_> gary_poster: coolio we're in
[22:58] <Makyo> gary_poster, bcsaller will work on centering.
[22:58] <gary_poster> Awesome thank you Makyo.  Making card for you now
[22:58] <bcsaller> Makyo: I suspect my change about not recording centroid will go back and it can solve that case, I didn't think of it at the time
[23:01] <huwshimi> rick_h_: Hmmm... still getting "Failed to load charm details. Charm API server did not respond". It appears to be looping through the charms ok: http://paste.ubuntu.com/6242914/
[23:02] <Makyo> gary_poster, bcsaller cool, thanks.  Will get on that.  LGTM otherwise; I say land.
[23:02] <Makyo> (If you haven't already)
[23:02] <gary_poster> +1 bcsaller
[23:02] <bcsaller> I think that was a pretty good "on to the next thing" branch
[23:03] <gary_poster> definitely!  thanks bcsaller :-)
[23:03] <gary_poster> we'll miss you, but you will do awesome things in the new place
[23:03] <bcsaller> thanks :)
[23:04] <bcsaller> I'll miss this team
[23:13] <rick_h_> huwshimi: what call is it making?
[23:14] <rick_h_> huwshimi: in the network tab, what api call is going out that's failing?
[23:14] <rick_h_> huwshimi: this is called from the _renderBundleView I assume?
[23:16] <huwshimi> rick_h_: Yeah, called in the _renderBundleView
[23:18] <huwshimi> rick_h_: How would I tell which call it is?
[23:18] <rick_h_> huwshimi: it should be a 404 or something?
[23:18] <rick_h_> a failed request
[23:18] <huwshimi> rick_h_: Nothing is 404ing. I only get the error in the gui itself
[23:18] <huwshimi> (a growl-style notification)
[23:19] <rick_h_> huwshimi: right, but that error is that the Gui made an API call (which should show in the network tab as the page loads) and failed to get a successsfull response from manage.jujucharms.com
[23:19] <rick_h_> huwshimi: so some api call m.j.c/api/3/xxxxxxx should show as a failed 404 or something strange in the network tab
[23:20] <huwshimi> rick_h_: Yeah, I dunno why I'm not getting one...
[23:20] <rick_h_> huwshimi: hangout again ands screenshare? maybe I can spot what is odd going on there?
[23:20] <huwshimi> rick_h_:  Sure :)
[23:20] <rick_h_> https://plus.google.com/hangouts/_/10fe9c48d75b9ebbe273219cb03f4e53869ce4f7?authuser=1


[06:27] <bkerensa> akgraner: ello
[07:09] <dholbach> good morning
[11:13] <akgraner> bkerensa, hello
[12:27] <pleia2> akgraner: newsletter should be all ready except for security and stats
[13:47] <akgraner> pleia2, yep - just looked - will add that shortly and publish :-)
[16:42] <MrChrisDruif> akgraner; it seems the Unity Contributor meetings aren't held anymore. Is there a way to remove them from the Fridge?
[16:43] <akgraner> yes
[16:44] <MrChrisDruif> Awesome
[17:35] <akgraner> MrChrisDruif, from the Fridge or the Fridge Calendar?
[17:36] <akgraner> sorry should have asked that sooner
[17:37] <MrChrisDruif> Fridge Calendar
[17:37] <MrChrisDruif> I'ts got two entries on Wednesday, both are unnecessary
[17:38] <akgraner> ok - I was looking at the Fridge and was like - um... :-)
[17:38] <MrChrisDruif> I already confirmed this with jcastro on #ubuntu-community-team
[20:27] <akgraner> The new edition of the Ubuntu Weekly Newsletter is now available here:
[20:27] <akgraner> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue258
[20:28] <SilverLion> akgraner, good job - as always - mrs graner ;)
[20:29] <akgraner> awww thanks - y'all did all the hard work :-)
[20:29]  * SilverLion did nothing but screw his source code for full circle :(
[20:29] <akgraner> I had to to this old school today as the script broke halfway through the test version for some reason
[20:29] <akgraner> SilverLion, thats work too
[20:30] <SilverLion> akgraner, u can say that loud :/
[20:30] <SilverLion> will take ALL NIGHT AND TOMORROW TO FIX
[20:30] <SilverLion> sorry 4 caps
[20:30] <SilverLion> typing one finger sucks :D
[20:32] <MrChrisDruif> Why one finger?
[20:32] <SilverLion> MrChrisDruif, the other hand was full of chips ;)
[20:33]  * SilverLion is watching International Table Tennis online during his coding breaks
[20:33] <MrChrisDruif> akgraner; did you get to removing those Unity Contributors meetings?
[20:33] <MrChrisDruif> Ghehe
[20:33] <akgraner> nope  - but I will :-)  I just have to login to the Calendar
[20:33] <MrChrisDruif> Alright ^_^
[20:33] <MrChrisDruif> I'll see it on my agenda then
[20:34] <akgraner> nods - until later tonight at least
[20:34] <akgraner> bkerensa, did pleia2 show you how to run the script?
[20:35] <akgraner> if so can you run it just to see if it breaks this news letter for you as well
[20:35] <akgraner> it's going to be a few hours before I add it to the forums as I am going to have to format it by hand if the script breaks for you as well
[20:36]  * MrChrisDruif is off shortly to bed
[20:37] <akgraner> MrChrisDruif, did jcastro tell you to remove that meeting?  I just pinged him to verify since he created it
[20:37] <MrChrisDruif> I asked him if he knew about the double entry earlier today
[20:38] <bkerensa> akgraner: she did and I took notes but my HDD failed the other day so I would need to be shown how again
[20:38] <akgraner> hmm I'm seeing one entry - which one is the wrong one
[20:38] <MrChrisDruif> MrChrisDruif> jcastro; did you notice the Unity Contributors Meeting is on the Fridge twice? <MrChrisDruif> Every week? <jcastro> no <jcastro> I don't think we've had that meeting in a while <jcastro> you can just remove it for now if you'd lik
[20:38] <MrChrisDruif> Both can be removed
[20:39] <akgraner> removing now
[20:39] <MrChrisDruif> Awesome
[20:40] <akgraner> done
[20:42] <MrChrisDruif> Great, awesome!
[20:42] <MrChrisDruif> That cleans my agenda up quite nicely
[20:42] <akgraner> ok I'll work on the Fridge and Forums posts in just a few then :-)
[20:42] <akgraner> back to work for a while :-)
[21:29] <JoseeAntonioR> team, I just arrived home, I'm transferring the stats to the ES version
[21:35] <JoseeAntonioR> Guest25332: Jacky?
[21:47] <JoseeAntonioR> ok, everything's done in the Spanish edition :)